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