データベース計画-複数のスキーマvs複数のデータベースvs単一の大規模なデータベースvsパーティション
不動産会社向けのウェブサイトをデザインしています。 Webサイトは情報を表示するためにのみ使用され、すべてのWebサイトは共通のテンプレートを共有します。さまざまな顧客向けに約150のWebサイトがあります。一部のサードパーティデータプロバイダーは、ウェブサイト上の各リスティングに関するすべての更新を1時間ごとに提供しています。各顧客の更新は別の時間に行われます。平均して、ウェブサイトごとに1000のリストがあります。また、毎時の更新ごとに、データの80％が変更または更新されます。
現在、SQL Server 2008には、すべての顧客向けに単一のデータベースがあります（最初は10〜20のWebサイトに対応するように設計されています）。データベース内のテーブルはすべての人が共有します。問題は、更新が発生するたびに、更新にまったく関係のない他の顧客のWebサイトも遅くなることです。また、顧客データを削除すると、すべてのサイトの速度が低下します。
顧客ごとに個別のスキーマを作成してデータベースを再構築することを計画していますが、それが私たちの問題を処理するための最良の方法であるかどうかはわかりません。別のデータベースを使用すると、メンテナンス（バックアップ、ミラーリングなど）に関して多くの問題が発生します。誰かがこの問題を処理するより良い方法を私に提案できますか？顧客ごとに個別のスキーマを作成し、それらのテーブルを他のユーザーから分離すると、パフォーマンスにどのように影響するかわかりません。それとももっと良い解決策はありますか？
私の個人的な好みは、さまざまなDMVを使用して、どのデータベースがIOとRAMを最も多く使用しているかを確認できるため、複数のデータベースを使用することです。さらに、常にクライアントを安心させるセキュリティの分離があります。
Brent Ozarはこの問題を最近のブログ投稿で取り上げました-彼は非常に優れているので、一読の価値があります： http://www.brentozar.com/archive/2011/06/how-design-multiclient-databases/
おそらく、顧客ごとにデータベースを使用することをお勧めしますが、1つのデータベースにこだわりたい場合は、要件に応じてスキーマが適しているように見えます。
ただし、顧客ごとのスキーマに加えて、顧客ごとにファイルグループを作成し、各顧客のすべてのデータベースオブジェクトをそのファイルグループに配置することをお勧めします。これにはいくつかの利点があります。
- データベースの可用性が向上します。 1人の顧客に属するデータファイルに破損がある場合でも、データベースの残りの部分をオンラインにすることが可能です。破損したデータファイルは、他のトランザクションが実行されている間でも、バックアップから復元できます。
- （潜在的に）より良いパフォーマンス。システムが成長するにつれて、ファイルグループを異なるストレージデバイスに配置してI/Oを分散させることができます（もちろん、1つのファイルグループと複数のファイルで同様のことを行うことができますが、これによりIO =顧客による）。
- バックアップのしやすさ。データベースのバックアップはファイルグループレベルで実行できるため、各顧客のテーブルをいつバックアップするかにより柔軟に対応できます。
- 復元の細分性が向上します。 ＃1と同様に、データベースを最初から復元する場合、プライマリファイルグループがオンラインになると、最も重要な顧客から始めて、ファイルグループを個別に復元することができます。後続の復元は既に復元されたファイルグループに影響を与えないので、データベースを1つずつオンラインで起動することができます。これは オンラインの段階的部分復元 と呼ばれ、エンタープライズ版のみの機能です（ただし、標準版では同様のことを実行できますが、データベースをオフラインにする必要があります）。
ファイルグループの最大数は32,000っぽいので、別のデータベースへの分割について本当に考える必要があるまで、この戦略は続くはずです。
詳細については、書籍のオンライン記事 ' Files and Filegroups Architecture 'と、部分的なデータベースの可用性に関するSQLCATホワイトペーパーをお勧めします： http://sqlcat.com/sqlcat/b/whitepapers/archive /2007/11/21/partial-database-availability.aspx
すべての顧客が同じデータベースを共有し、すべてのWebサイトが同じテンプレートを使用する場合、これはマルチテナントcmsに似ているため、単一のデータベースを持つことは実際にはここで完全に意味があります。
私は、問題が1つの顧客の更新が他のすべてに影響を与えるとは考えていませんが、一般的には、遅いレベルの更新とクエリの低いレベルです。ハードウェアと負荷が変化しないと仮定すると、150個のデータベースが単一のデータベースソリューションと同様に実行される可能性があります（特定の状況ではおそらく遅くなります）。
あなたの主要なテーブルは、約150 * 1000のライブ行（おそらく+履歴レコード）を持つ「リスト」テーブルであると思います。
これはロングショットによる大量のデータではなく、適度に仕様化されたマシンに問題はないはずです。
履歴レコードが独自のテーブルに移動されることを確認します。読み取りクエリで、「コミットされていないスナップショットの読み取り」を追加します
更新では、これに対するいくつかの可能な修正があります。1。複数の更新ステートメントではなくマージを使用します。2。カーソルを使用してロックエスカレーションを防止します。3。更新されたリストに新しいレコードを追加し、「is current」ビットを更新します。古いものにフラグを立てる
これが2年前だとすると、最終的な解決策は何でしたか？
データベースインフラストラクチャの再構築を計画したときにも、同じ質問をしました。この記事はとても役に立ちました。
[ https://msdn.Microsoft.com/en-us/library/aa479086.aspx] [1]
ピーターが別のデータベースに分割することの主なポイントはパフォーマンスと長期的な拡張性に関係していたため、コストを問わずすべてを1つのデータベースに保持することにもっと関心があるようです。その場合は、テーブルを顧客用の異なるスキーマに分割するOR Enterprise Editionライセンスに切り替えて、テーブルのパーティション分割を使用し、顧客に基づいて共有テーブルをパーティション分割できるようにします。数。