同じ問題を解決し、バリアントも検討しています。SaaSマルチテナントアプリケーションの作成に長年の経験があるため、リレーショナルデータベースでの以前の経験に基づいて2番目のオプションも選択する予定でした。
調査を行っているときに、mongodbサポートサイトでこの記事を見つけました（なくなってからずっと前に追加されました）：https：//web.archive.org/web/20140812091703/http：//support.mongohq.com/use-cases/multi -tenant.html
彼らは、私が理解しているように、mongodbに特に固有ではない2番目のオプションを絶対に避けるように述べました。私の印象では、データベース設計の詳細により、これは私が調査したほとんどのNoSQLデータベース（CoachDB、Cassandra、CouchBase Serverなど）に適用できます。
コレクション（またはバケット、または異なるDBでそれを呼び出す）は、適切なテナント分離を適用するのに役に立たないドキュメントのコンテナーとして動作するにもかかわらず、RDBMSのセキュリティスキーマと同じものではありません。コレクションに基づいてセキュリティ制限を適用できるNoSQLデータベースが見つかりませんでした。
もちろん、mongodbロールベースのセキュリティを使用して、データベース/サーバーレベルでアクセスを制限できます。 （http://docs.mongodb.org/manual/core/authorization/）
次の場合に最初のオプションをお勧めします：
- このシナリオの設計、実装、テストの複雑さに対処するのに十分な時間とリソースがあります。
- テナントごとにデータベースの構造と機能に大きな違いがない場合。
- アプリケーションの設計により、テナントは実行時に最小限のカスタマイズのみを行うことができます。
- スペースを最適化し、ハードウェアリソースの使用を最小限に抑えたい場合。
- 何千ものテナントがいる場合。
- 迅速かつ高コストでスケールアウトしたい場合。
- テナントに基づいてデータをバックアップしない場合（テナントごとに個別のバックアップを保持します）。このシナリオでもそれを行うことは可能ですが、多大な労力が必要になります。
次の場合はバリアント3を選択します：
- テナントのリストが少なくなります（数百）。
- ビジネスの詳細では、テナントごとにデータベース構造の大きな違いをサポートできる必要があります（サードパーティシステムとの統合、データのインポート/エクスポートなど）。
- アプリケーションの設計により、顧客（テナント）はアプリケーションの実行時間に大幅な変更を加えることができます（モジュールの追加、フィールドのカスタマイズなど）。
- 新しいハードウェアノードで迅速にスケールアウトするのに十分なリソースがある場合。
- テナントごとにデータのバージョン/バックアップを保持する必要がある場合。また、復元も簡単です。
- さまざまなデータベース（データセンターであっても）にさまざまなテナントを保持することを強制する法規制上の制限があります。
- ロールなど、mongodbのすぐに使用できるセキュリティ機能を十分に活用したい場合。
- テナント間でサイズの点で大きな違いがあります（小さなテナントが多く、非常に大きなテナントはほとんどありません）。
アプリケーションに関する追加の詳細を投稿する場合は、おそらくより詳細なアドバイスを提供できます。