質問は以前に投稿されたことがありますが、完全には回答されていません。また、それはまだ問題のパラメータに依存していると思います。多数の顧客がいるSaaSサービスがあるが、顧客あたりのデータ量が比較的少ない場合、単一のデータベースを使用することはおそらく理にかなっています。
顧客が長期的に数千の範囲になく（たとえば、非常に良いシナリオでは100）、5〜6で始まるが、今回は顧客ごとに大量のデータがある場合（たとえば、ビジネスインテリジェンスサービス）に何が起こりますか？大量のデータを集約して処理します）。ヒントとして、最初に顧客ごとに25〜50 GBのデータ（分析やその他のもの）を処理し、次に顧客ごとに年間約10GBを追加します。
単一のデータベースのパスをたどる場合は、特定のフィールド（もちろんインデックス付け）を使用してデータを顧客にタグ付けし、レプリケーションとシャーディングに依存しますmongoのおかげでかなり簡単なシステム。インデックス付きフィールドに対するシャードコレクションでは、クエリのルックアップ時間が高速であると思います（テストは行っていません。そのような場合は、洞察を共有してください）。ただし、今度は別の顧客、さらに50 GBを追加するとします（8〜10のコレクションに分散しているため、何百万ものアイテム/コレクション）。1）インデックスを削除して再構築する（システムが実質的に使用できなくなるため、最悪だと思います）2）インデックスを削除して挿入しないでください（永遠にかかります）、システムは応答します3）私はレプリカセットはノードを停止し、インデックスを削除し、新しい顧客で更新し、インデックスを戻し、レプリカセットに参加させて、同期を開始できるようにします。
一方、顧客ごとに1つのデータベースがある場合、システムが顧客を実質的に分離するため、追加または削除を比較的迅速に行うことができます。行はまだ数百万の範囲にありますが、10億に近くはありません。これは、適切なルックアップです。時間は明らかに速いです。この場合に何をするにしても、単一のデータベースの場合よりも常に比較的少ない数で作業するため、実装の点ではるかに簡単で迅速です。ただし、メンテナンス（顧客ごとにデータを追加し続けるため、レプリケーションとシャーディング）に関しては、摩擦が発生します。確かにプラスこの場合、開いているファイルの数のOS制限のため、そしてもちろん複数のデータベースでの複数の同時接続のために余分なオーバーヘッドがあるため、別々のマシン/インスタンスでデータベースを物理的に分離する必要があると思います。
私が何かを逃した場合は、いくつかの光を当ててください、しかし私はこれについて他の意見を聞くことに最も興味があります...
ありがとう