論理的に分割されたデータを持つ複数のデータベースと単一のデータベース
データベース設計の問題について考えています。どんな助けも大歓迎です。
20個のテーブルを持つアプリケーションを設計しています（新機能の開発中に最大で約30個まで増加する可能性があります）
技術スタック
MVC4、.NET 4.X、Entity Framework 5、SQL Server 2012、ASP.NETメンバーシップフレームワーク
ユーザー数
私たちは、平均20人のユーザーを持つ約1000人のクライアントに対応する予定です。
質問
テーブルが論理的にパーティション分割されるようにデータベースとアプリケーションを設計する必要があります。つまり、すべてのクライアントがパーティションGUIDを持つ同じテーブルを使用してデータを分離します。
OR
新機能の起動とバグ修正中に困難であることが判明する可能性のある複数のデータベースを探します。しかし、潜在的にスケーリングが可能ですか？
警告：テーブルの1つには、ファイルを保存するバイナリ列があります（レコードごとに最大5MB）
これに加えて、メンバーシップフレームワークテーブルを考慮する必要があります。このテーブルは、別のカスタムテーブルに拡張し、ユーザーをパーティションGUIDに論理的にマッピングします。
別々のデータベースを使用したいと思うでしょう：
- データベース自体へのアクセス許可をクライアントまたはスーパーユーザーに付与する場合。
- 他のデータに影響を与えずに1つのクライアントのデータベースのみを復元したい場合。
- データおよびデータ侵害を規制する規制上の懸念があり、遅かれ早かれ、これらの規制は個別のデータベースを持つことによってのみ満たすことができることを発見した場合。
- 顧客データを複数のデータベースサーバーに簡単に移動したり、スケールアウトしたり、より大きな/より重要な顧客を異なるハードウェアに移動したい場合。世界の別の部分で。
- 古い顧客データを簡単にアーカイブおよびデコミッションしたい場合。
- 顧客がサイロ化されたデータを気にしているのに、そうでないとわかった場合。
- データが召喚され、1つのクライアントのデータだけでなくデータベース全体を作成する必要がある場合。
- 警戒を怠ることを忘れ、
AND CustomerID = @CustomerIDを含まないクエリが1つだけ抜けたとき。ヒント：スクリプト化された権限ツールまたはスキーマを使用するか、WHERE CustomerID = SomeUserReturningFunction()を含むビューですべてのテーブルをラップするか、これらの組み合わせを使用します。 - アプリケーションレベルで権限を誤って取得し、顧客データが誤った顧客に公開された場合。
- さまざまなクライアントに対してさまざまなレベルのバックアップと回復の保護が必要な場合。
- 新しいデータベースを作成、プロビジョニング、構成、デプロイ、またはスピンアップ/ダウンするためのインフラストラクチャを構築することは、それを上手く使うことを余儀なくされるため、投資する価値があることを理解したら。
- あるクラスの人々が複数の顧客のデータへのアクセスを必要とする可能性を許可しなかった場合、
WHERE CustomerID = @CustomerIDはそれをカットしないため、Customerの上に抽象化レイヤーが必要です。 - ハッカーがサイトやシステムを標的にしている場合、管理者の資格情報をoneデータベースで取得すると、すべてのデータを簡単に取得できます。
- データベースのバックアップの実行に5時間かかり、その後失敗する場合。
- エンタープライズ版のDBMSを入手して圧縮バックアップを作成する必要がある場合、ネットワーク経由でバックアップファイルをコピーするのに5時間未満more。
- 5時間かかるテストサーバーにデータベース全体を毎日復元し、完了するのに2時間かかる検証スクリプトを実行する必要がある場合。
- 少数の顧客のみが複製を必要とし、それらの少数だけではなく、すべての顧客に複製を適用する必要がある場合。
- 政府の顧客を引き付けたい場合、別のサーバーとデータベースを使用する必要があることがわかりますが、エコシステムは単一のサーバーとデータベースを中心に構築されており、変更が非常に難しいか、時間がかかりすぎます。
別々のデータベースを使用して良かったと思います：
- 1人の顧客へのパイロットロールアウトが完全に爆発し、他の999人の顧客が完全に影響を受けない場合。また、バックアップから復元して問題を修正できます。
- データベースバックアップの1つが失敗し、10時間のプロセス全体を再度開始する代わりに、25分でその1つだけを修正できる場合。
単一のデータベースを使用したいと思うでしょう：
- 1000個すべてのクライアントに影響するバグを発見し、1000個のデータベースに修正プログラムを展開するのは困難です。
- データベースレベルで誤った権限を取得し、顧客データが間違った顧客に公開された場合。
- あるクラスの人々がすべてのデータベースのサブセットへのアクセスを必要とする可能性を許可しなかったとき（おそらく2人の顧客がマージします）。
- 2つの異なるデータデータベースをマージすることがどれほど難しいかと思わなかったとき。
- 2つの異なるデータデータベースをマージし、1つが間違っていることを認識し、このシナリオからの回復を計画していなかった場合。
- 単一のサーバーで32,767を超える顧客/データベースを成長させようとすると、これがSQL Server 2012の最大値であることがわかります。
- 1,000以上のデータベースの管理が想像以上に大きな悪夢であることに気付いたとき。
- テーブルにデータを追加するだけでは新しい顧客を登録できないことに気付いた場合、新しいデータベースの権限を作成、設定、設定するために、多くの恐ろしく複雑なスクリプトを実行する必要があります。
- 毎日1000のデータベースバックアップを実行する必要がある場合、それらがすべて成功することを確認し、ネットワークを介してそれらをコピーし、すべてをテストデータベースに復元し、各単一で検証スクリプトを実行し、保証された方法で障害を報告します簡単かつ迅速に実行可能であることを確認してください。そして、これらの150個はさまざまな場所で失敗し、一度に1つずつ修正する必要があります。
- 判明したら、1000個のデータベースのレプリケーションをセットアップする必要があります。
理由をもっと挙げたからといって、それが良いというわけではありません。
一部の読者は、 MSDN：Multi-Tenant Data Architecture から値を取得できます。または、おそらく SaaS Tenancy App Design Patterns 。または クラウド向けマルチテナントアプリケーションの開発、第3版
アーキテクチャを「マルチテナント」と呼ぶ場合、Microsoftには here を読む価値のある優れた記事があります。 "isolated" (multiple db)と"shared" (single db)の比較を示しています。一般的に、テナント（クライアント）の数が大きい場合は共有が優先されますが、各テナントのサイズが大きい場合は、分離アプローチが推奨されます。
ただし、これらの考慮事項は経験豊富な開発者のみが計算できます。
それでもisolated (multiple db)アーキテクチャを使用できたとしても、まだ 同じインスタンスで実行されている場合はパフォーマンスに直接メリットはありません です。また、shared (single db)アーキテクチャを使用する場合は、intの代わりにguidを使用することを検討してください。使用する必要がある場合は、sequential guidを使用してください。