クライアントごとに1つのデータベースがどの時点で実行不可能になりますか？

私たちのシステムの1つでは、クライアントの機密データがあり、各クライアントのデータを個別のデータベースに保存します。そのシステムには約10〜15のクライアントがあります。

ただし、50〜100のクライアント、またはそれ以上のクライアントを持つ新しいシステムを開発しています。この例では、クライアントごとに1つのデータベースを持つことは（機密レコードと監査履歴を格納するために）実行不可能だと考えています。ただし、これが完全に正常かどうか、またはセキュリティを維持する別の方法があるかどうかはわかりません。

これについて何か考えはありますか？

100または500のデータベースを管理することは、5または10を管理することとそれほど違いはありません-自動化を採用し、スケーラビリティプランを用意する必要がありますクライアント）。

以前の仕事では、このアーキテクチャを使用していましたが、2つのクライアントを1つのデータベースにマージすることを考えたことは一度もありませんでした。

大きな利点は、独立した復旧モデル（a単純なもの、b完全なものなど）、他のクライアントを中断することなく特定の時点に復元（または完全に削除）できる機能、リソースが重いクライアントをシームレスに移動できる機能です独自のストレージまたは完全に別のサーバーに、ほとんど透明性のない方法で（アプリケーションにそのクライアントの場所を知らせる構成ファイルまたはテーブルを更新します）。

これらの投稿で、いくつかの異議申し立て、および/または問題へのアプローチ方法について説明します。

• マルチテナントデータベースアーキテクチャで増え続けるテナントの処理

• SQL Server 2008を使用するマルチテナントデータベース？

• 多数のデータベースのバックアップの自動化

結局のところ、私たちの誰もがあなたにとって経営が非現実的になるポイントをあなたに伝えることができないと思います - あなたが遭遇する特定の課題が何であれ、あなたはそれらの問題について個別に尋ねることができることを知ってください。

Multi-Tenant Data Architectureをお読みになることをお勧めします。これは、お持ちのオプションと賛否両論について説明しているホワイトペーパーです。要約すると、次の3つのオプションがあります。

• 個別のDB
• 別のスキーマ
• 共有スキーマ

現在、個別のDBステージにあり、最適な分離（テナント間の分離）を提供していますが、管理が最も困難です。数百のテナントに成長するにつれて、数百のDBを管理するロジスティクスが些細なものではないことに気付くでしょう。バックアップと復元（バックアップされたファイル、ジョブ、スケジュールなどの場所）を考えてください。ファイルの割り当て、使用されるディスク領域、および数百のDBにわたるデータベースの成長をどのように監視および管理するかを考えてください。1000テナントの近い将来の高可用性/災害復旧シナリオはどうなると思いますか？1000のミラーリングされたDB、1000のログ配布セッション？6か月後に開発チームがあなたに来て、「この素晴らしい機能を製品に提供する方法を知っています。トランザクションレプリケーションを使用します！」と言ったらどうなるでしょうか。「確かに、500の出版社を設定させてください。「！数百のDBを管理することは不可能ではありませんが、計画する場合は、PowerShellスキルを磨き、UI管理ツールの使用を今すぐ中止することをお勧めします。

さらに、複数（数百）のDBがパフォーマンスとコストに測定可能な影響を与えることを考慮する必要があります。

• 物理ディスクの空き容量が少なく効率的に使用されている（すべてのデータベースを持っている必要がありますいくつかの予備の部屋を、あなたは、DBの数を乗じたもの予備の部屋を持っています）
• 書き込みを集中的に行うタスク専用のログディスクを作成する方法はありません。これらすべてのLDFを1つ（または複数）のSSDストレージに移動する必要があります。
• ログの書き込みは、多くの個々のログブロックレコードにまたがって1つに集約されるため、頻繁なコミットでは効率が低下します（使用されないログブロックが発生します）。私が話していることを理解するには、LSNとは何か：ログシーケンス番号を参照してください。

分離されたDBにはいくつかの利点がありますが、分離のため、主な利点は独立したバックアップ/復元です。

しかし、あなたのようなシナリオは、SQL Azureデータベースの完璧な候補です。ディスクスペースの管理、HA / DRの提供、数百/数千のDBへの拡張などは不要です。

私の以前の仕事では、クライアントごとに1つのデータベースだけをホストしていませんでした-ほとんどの場合、それはそれ以上でした！私が去ったとき、1つのMariaDBクラスターで実行されている4,500を超えるデータベース、別の（皮肉なことに）クラスターでほぼ7,000のデータベース、および4つの「シャード」（完全に独立したWebおよびデータベースサーバー、完全に独立したデータセンターでも）がホストされていました単一のMySQLサーバーに200〜500個のデータベース。そして、その会社はまだ良いクリップで成長しています。

長いことと短いことは、その会社の成功がそのようなアーキテクチャが実際に実行可能であることを証明するということです。（注意：個別のデータベースを使用することによる分離の明らかな利点に反して、すべてのデータはすべて同じデータベースユーザー/パスを使用する密結合アプリケーションのトリオを介してアクセスされました！各クライアントが別のユーザー/パスがありましたが、ほんのわずかです。）

システム管理者と密接に連携した経験から（技術的には私は会社のプログラマーでしたが、実際には彼らが持っていた最高のDBAであり、ファイアウォールの設定方法を知っていた唯一の人でした！）、パフォーマンス関連同時アクセス、クエリの複雑さ/時間、インデックスのパフォーマンスなどに集約された懸念-言い換えれば、サーバー上のデータベースの数はすべて、認識できる部分を果たさなかったため、結論は高給の専門家によって確認されました定期的に相談したコンサルタント。

肝心なのは、たまたま所有しているデータベースの数ではなく、アプリケーションに関心を向けるべきだということです。他のすべての要因は、パフォーマンスの問題とボトルネックの解決に忙しくし続けるのに十分すぎるほどです。