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