タグ付けされた質問 「deployment」

ダウンタイムなしでライブデータベースのスキーマをどのように変更しますか？ たとえば、すべてが特定のユーザーに関連付けられている、メールアドレスなどのさまざまなユーザーデータを含むテーブルを持つPostgreSQLデータベースがあるとします。電子メールアドレスを新しい専用テーブルに移動する場合は、スキーマを変更してから、電子メールデータを新しいテーブルに移行する必要があります。元のテーブルへの書き込みを停止せずにこれを行うにはどうすればよいですか？確かに、古いテーブルから新しいテーブルにデータが上書きされる間、新しいデータは引き続き古いテーブルに書き込まれ、失われますよね？ この問題はかなり頻繁に発生すると思いますが、それを処理するための標準的なソリューションが見つかりません。 この記事ではこの問題を扱いますが、手順3を本当に理解していませんでした。彼は両方のテーブルに書き込み、古いデータを最初のテーブルから新しいテーブルに移行するように言っています。古いデータのみを移行していることをどのように確認しますか？ （HerokuでPostgreSQLを使用しています。）

43 postgresql  schema  best-practices  migration  deployment 

私たちは、それぞれが基礎となるデータを持つ複数のサービスを組み込んだWebプラットフォームを構築しています。これらのサービスは、Service-Oriented Architectureの原則に従って独立して構築されていますが、潜在的に関連するデータに対して処理します。これらのサービスが1つの大きなデータベースを共有するか、それぞれが独自のデータベースを持つかを検討しています。（Windows 2008クラスターでSQL Server 2008 Enterpriseを使用する予定です。） すでに検討した各アプローチの利点には次のものがあります。 単一のデータベース 異なるサービスからのデータを関連付けることは、外部キーの制約によって結び付けることができます 分析抽出は、作成が簡単で実行が高速です 災害が発生した場合、プラットフォームを一貫した状態に復元する方が簡単です 複数のサービスによって参照されるデータの場合、あるサービスによってキャッシュされたデータは、すぐに別のサービスによって使用される可能性が高い 管理と監視は前もって簡単で安価です 複数のデータベース メンテナンス作業、ハードウェアの問題、セキュリティ侵害などは、必ずしもプラットフォーム全体に影響を与えるとは限りません 各データベースが個別のハードウェア上にあると仮定すると、複数のマシンをスケールアップすると、1つの大きなマシンをスケールアップするよりもパフォーマンス上のメリットが大きくなります 運用の観点から、このプラットフォームの各サービスが独自のデータベースを取得すること、またはそれらがすべて同じデータベースに配置されることは、より有利ですか？この質問の答えを伝える重要な要因は何ですか？

31 database-design  deployment 

ポストポストスクリプトを数回使用し、ビルドアクション "PostDeploy"を常に直感的に使用しました。これで初めて、スクリプトのテンプレートから組み込みの命令に従って":r somescript.sql"構文を使用しようとしました。 すぐにこの行は間違っているとマークされています： 「 '：'の横にあるSQL80001の構文が間違っています」 PDSをビルドアクション「なし」に設定する提案を見つけました。これは役に立たず、エラーは残ります。ここに何が欠けていますか？

17 sql-server  ssdt  deployment  visual-studio-2013 

このドキュメントで説明されているベストプラクティスについて質問したいと思います。 http://info.mongodb.com/rs/mongodb/images/MongoDB-Performance-Best-Practices.pdf 複数のクエリルーターを使用します。複数のサーバーにまたがる複数のmongosプロセスを使用します。一般的な展開は、アプリケーションサーバー上のmongosプロセスを同じ場所に配置することです。これにより、アプリケーションとmongosプロセス間のローカル通信が可能になります。mongosプロセスの適切な数は、アプリケーションと展開の性質によって異なります。 展開についてのほんの少しの背景。多くのアプリケーションサーバーノードがあります。それらはそれぞれ、ステートレスRESTful WSで1つのJVMベースのプロセスを実行します。このベストプラクティスが示唆するように、すべての単一のアプリケーションサーバーノードは独自のmongosプロセスを実行します。つまり、JVMプロセスの数は常にプロセスの数に等しくなりmongosます。 すべてのmongosプロセスは、3つの構成サーバーと複数のmongo断片（各断片内にレプリカセットがある）に接続します。シャード展開を使用している場合でも、実際にはコレクションをシャーディングしていません。実際、作成時にすべてのシャードに分散する多数のデータベースがあります（これが現時点でのシャーディングの主な使用例です）。 ベストプラクティスでは「適切なmongosプロセスの数はアプリケーションとデプロイメントの性質に依存する」ことも示唆しているので、私たちの使用mongosが実際に適切かどうか、または複数の専用mongosノードを用意して、アプリサーバーはmongosローカルで実行せずに接続します。 mongosアプリケーションサーバーのインスタンス数またはMongoDBクラスターのサイズに関連して適切なインスタンスの数を決定するための最適なアプローチについて、あなたはどう思いますか？ 最近、ステートレスWebサービスのクラスター管理を検討し始めました。つまり、Docker、Apache Mesos、Kubernetesなどのツールを意味します。Dockerを使用している場合、一般的にコンテナ内で複数のプロセスを実行することは推奨されません。この事実を考慮すると、アプリケーションサーバーコンテナとmongosコンテナを常に同じ物理ノードに配置し、同じ量のプロセスを確保することは非常に困難になります。これは、このベストプラクティスが今説明したクラスターアーキテクチャにまだ当てはまるのかと思います。そうでない場合は、mongosこのアーキテクチャでプロセスを見つけて展開するためのより良い方法を提案してください。

12 mongodb  best-practices  sharding  deployment  docker 

スキーマにすべてが含まれている既存のデータベースがありますdbo。スキーマを使用して追加するオブジェクトを含むSSDTプロジェクトがありますfoo プロジェクトに次のようなテーブルがあります。 CREATE table foo.a ( id INT NOT NULL CONSTRAINT [PK_foo_a] PRIMARY KEY CLUSTERED CONSTRAINT [FK_foo_a] FOREIGN KEY REFERENCES [dbo].[a], desc NVARCHAR(50) NOT NULL ) dbo.aに依存します。dbo.aには、他の列への外部キーである多くの列があります。他の誰か（デフォルトのスキーマを維持している人）がdbo.aを変更する可能性があります。 私はdbo.aを次のように単純に保存したいと思います： CREATE table dbo.a ( id INT NOT NULL CONSTRAINT [PK_a] PRIMARY KEY CLUSTERED ) したがって、内部的にビルドされますが、デプロイされません。それは可能ですか？

11 ssdt  deployment