[解決済み] MongoDBのマルチテナントデータベースへの推奨されるアプローチとは？

質問

MongoDB を使ってマルチテナントのアプリを作ろうと思っています。テナントの数についてはまだ推測していませんが、数千にスケールできるようにしたいと思っています。

私は3つの戦略を考えることができます。

1. すべてのテナントを同じコレクションに入れ、セキュリティのためにテナント固有のフィールドを使用する。
2. 1つの共有DBで、テナントごとに1つのコレクション
3. 1テナントにつき1データベース

私の頭の中の声は、オプション 2 にすることを勧めています。

どなたか、感想や含意を聞かせてください。

どのように解決するのですか？

私は同じ問題を解決するために、また、変種を検討しています。 私は 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/ )

1.の場合、1.をお勧めします。

• このシナリオの複雑さに対処するための十分な時間とリソースがある。 設計、実装、およびテストの複雑さに対処するための十分な時間とリソースがある。
• テナントごとにデータベースの構造や機能に大きな違いがない場合。 テナントによってデータベースの構造や機能に大きな違いがない場合。
• アプリケーションの設計により、テナントが実行時に最小限のカスタマイズしか行えない場合。 実行時にカスタマイズすることができます。
• スペースを最適化し、ハードウェアリソースの使用を最小限に抑えたい場合。 リソースの使用を最小限に抑えたい場合。
• 数千のテナントがいる場合。
• 高速かつ低コストでスケールアウトしたい場合。
• テナントごとにデータをバックアップしない場合 (テナントごとに個別のバックアップを維持する)。 バックアップを行う)。このシナリオでも可能ですが しかし、その労力は膨大なものになるでしょう。

私なら、もしもの時はバリエーション3にします。

• 小規模なテナントリスト（数百人）を持つことになる。
• ビジネスの仕様上、テナントごとにデータベース構造の大きな違いをサポートできる必要がある（例：サードパーティシステムとの統合、データのインポート/エクスポート）。
• アプリケーションの設計では、顧客（テナント）がアプリケーションのランタイムに大きな変更を加えることができます（モジュールの追加、フィールドのカスタマイズなど）。
• 新しいハードウェアノードで迅速にスケールアウトするのに十分なリソースがある場合。
• テナントごとにデータのバージョン/バックアップを保持することが必要な場合。また、リストアも簡単でしょう。
• 法的/規制上の制約により、異なるテナントを異なるデータベース (データセンターも) に保持することを余儀なくされている場合。
• ロールなど、mongodb のすぐに使えるセキュリティ機能を完全に利用したい場合。
• テナント間のサイズの問題で大きな違いがある（多くの小さなテナントと少数の非常に大きなテナントがある）。

アプリケーションの詳細を投稿していただければ、より詳細なアドバイスを差し上げることができるかもしれません。