アプリのアーキテクチャ、使用状況とクエリ パターン、クライアント間の分布に大きく依存するため、簡単な答えではありません (つまり、使用レベルはクライアント間でほぼ同じでしょうか、またはクライアントの 10% で 90% を使用できるでしょうか)。リソース)、コード対運用の管理に費やすことができる金額、およびその他の多くの問題。考慮すべき点は次のとおりです。
1) 1 つのデータベースを使用すると、運用管理が容易になり、必要なコンピューティング リソースが少なくなり、スケールアウトが改善される可能性があります。また、接続数が大幅に少なくなるため、クライアント/Web サーバー側で消費するリソースも少なくなります。
1 つのモノリシック データベースにアプローチする場合、2 つの一般的なスキーマ オプションがあります。
- 類似したすべてのデータを 1 つのコレクションに入れ (つまり、すべてのアカウントのプロファイルを同じコレクションに入れる)、各ドキュメントに clientid キーを与えて、どのデータがどのアカウントに属しているかを識別することができます。これにより、(スキーマ アーキテクチャに応じて) 最小限のコンピューティング リソースでスケールアウトするための最適なオプションが提供される場合があります。
- もう 1 つのオプションは、コレクションごとにクライアント データを分離することです。各クライアントは、clientid プレフィックス (例: clientid_userprofiles) で識別されるデータベース内に独自のコレクションを持ちます。
2) クライアントごとのデータベース オプションでは、より多くのコンピューティング リソースが必要になるため、運用管理の頭痛の種が増え、コストが高くなります。一方で、コードが書きやすくなるため、コーディング コストは少なくて済みます。また、ヘビー ユーザーとライト ユーザーの間でリソースをより適切に分散することもできます。たとえば、使用率の高いクライアントをより強力なマシンに移動し、顧客ごとにシャーディングを提供できます。
3) 2 つのオプションの組み合わせを提供できます。つまり、ハイエンド ユーザー (より多くの料金を支払うアカウント) 用の専用データベースと、ローエンド クライアントおよびテスト/フリーミアム アカウント用の収集によって分離されたデータを含む共有データベースです。
多くのデータベースルートを使用する場合は、 --smallfiles 起動オプションを調べる必要があることに注意してください。これは、多くの人が「テスト アカウント」をセットアップしているが、それらをあまり使用しない状況で役立ちます。
とにかく、うまくいけば、上記があなたに思考の糧を与えることを願っています. この特定の問題について Mongo フォーラムで多くの議論があったため 、 https: //groups.google.com/forum/?fromgroups#!searchin/mongodb-user/multitenantで検索してください。
監査への影響に関しては、準拠する必要がある監査コンプライアンスのレベルによって異なります。フォーチュン 1000 のクライアントを期待する場合、クライアントが SAS70 などを聞いたことのないスタートアップである場合よりも、コンプライアンス要件ははるかに高くなります (そしてコストがはるかに高くなります - 数千ドルから数十万ドルと考えてください)。また、保存しているデータの種類によっても異なります。それはユーザーの財務データですか、それとも単なるユーザー フォーラムですか? 基本的に、将来大企業のセキュリティ監査に合格する必要があるという懸念がある場合は、共有データベースのアプローチについて考えることさえしないでください。