MongoDBのマルチテナントデータベースに対して推奨されるアプローチは何ですか？
MongoDBを使用してマルチテナントアプリを作成することを考えています。私はまだ何人のテナントを持っているのかという点については推測していませんが、数千に拡大できるようにしたいと思います。
私は3つの戦略を考えることができます：
- セキュリティのためにテナント固有のフィールドを使用する、同じコレクション内のすべてのテナント
- 単一の共有DBのテナントごとに1つのコレクション
- テナントごとに1つのデータベース
私の頭の中の声は、私がオプション2に行くことを示唆しています。
考えと意味、誰か？
同じ問題を解決する必要があり、バリアントも検討しています。 SaaSマルチテナントアプリケーションを作成する長年の経験があるので、リレーショナルデータベースでの以前の経験に基づいて2番目のオプションも選択しました。
私の研究を行っている間に、mongodbサポートサイトでこの記事を見つけました（廃止されてから追加されました）： https://web.archive.org/web/20140812091703/http://support.mongohq.com/use -cases/multi-tenant.html
私は、私が理解しているように、mongodbに特に固有のものではないという理由で、2番目のオプションを避けるように言いました。私の印象では、データベース設計の仕様により、これは私が調査したほとんどのNoSQL db（CoachDB、Cassandra、CouchBase Serverなど）に適用できるということです。
コレクション（またはバケット、または異なるDBで呼び出す）は、適切なテナント分離を適用するのに役に立たないドキュメントのコンテナとして動作するにもかかわらず、RDBMSのセキュリティスキーマと同じものではありません。コレクションに基づいてセキュリティ制限を適用できるNoSQLデータベースが見つかりませんでした。
もちろん、mongodbロールベースのセキュリティを使用して、データベース/サーバーレベルでのアクセスを制限できます。 （ http://docs.mongodb.org/manual/core/authorization/ ）
次の場合、1番目のオプションをお勧めします。
- このシナリオの設計、実装、およびテストの複雑さに対処するのに十分な時間とリソースがあります。
- テナントごとにデータベースの構造と機能に大きな違いがない場合。
- アプリケーションの設計により、テナントは実行時に最小限のカスタマイズのみを行うことができます。
- スペースを最適化し、ハードウェアリソースの使用を最小限に抑えたい場合。
- 数千のテナントがいる場合。
- 高速でコストを抑えてスケールアウトしたい場合。
- テナントに基づいてデータをバックアップする予定がない場合（テナントごとに個別のバックアップを保持します）。このシナリオでもそれを行うことは可能ですが、その努力は膨大です。
次の場合、バリアント3に進みます。
- テナントの小さなリスト（数百）を作成します。
- ビジネスの特性により、異なるテナントのデータベース構造の大きな違いをサポートできる必要があります（たとえば、サードパーティシステムとの統合、データのインポート/エクスポート）。
- アプリケーションの設計により、顧客（テナント）はアプリケーションランタイムに大幅な変更を加えることができます（モジュールの追加、フィールドのカスタマイズなど）。
- 新しいハードウェアノードで迅速にスケールアウトするのに十分なリソースがある場合。
- テナントごとにデータのバージョン/バックアップを保持する必要がある場合。また、復元も簡単になります。
- 異なるデータベース（データセンターも含む）に異なるテナントを保持することを強制する法的/規制上の制限があります。
- ロールなどのmongodbのすぐに使えるセキュリティ機能を完全に利用したい場合。
- テナント間でサイズの点で大きな違いがあります（小さなテナントが多く、非常に大きなテナントがほとんどありません）。
アプリケーションに関する追加の詳細を投稿する場合は、おそらくより詳細なアドバイスを提供できます。
このリンクのコメントで良い答えを見つけました：
http://blog.boxedice.com/2010/02/28/notes-from-a-production-mongodb-deployment/
基本的に、オプション＃2が最適な方法のようです。
David Myttonのコメントからの引用：
MongoDBがデータファイルを割り当てる方法のため、顧客ごとにデータベースを持たないことにしました。各データベースは、独自のファイルセットを使用します。
データベースの最初のファイルはdbname.0、次にdbname.1などです。dbname.0は64MB、dbname.1 128MBなど、最大2GBです。ファイルのサイズが2GBに達すると、連続する各ファイルも2GBになります。
したがって、存在する最後のデータファイルが1GBである場合、そのファイルは最近到達した場合、90％空になる可能性があります。
マニュアルから。
ユーザーが試用版にサインアップして試してみると、データファイル全体が使用されていない場合でも、少なくとも2GBのサイズのデータベースが増えてきます。これは、すべてのお客様が複数のデータベースを使用する場合と比較して、ディスクスペースを最大限に活用できるため、大量のディスクスペースを使用することがわかりました。
シャーディングは標準としてコレクションごとに行われますが、これはコレクションの最小サイズに達してシャーディングを開始できないという問題を提示します。ただし、これもデータベースレベルで実行できるように要求しました。 http://jira.mongodb.org/browse/SHARDING-41 を参照してください
大量のコレクションを使用するパフォーマンスのトレードオフはありません。 http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections を参照してください
私はオプション2に行きます。
ただし、mongod.exeコマンドラインオプション--smallfilesを設定できます。つまり、エクステントの最大ファイルサイズは2ギガバイトではなく0.5ギガバイトになります。これをmongo 1.42でテストしました。したがって、オプション3は不可能ではありません。
マルチテナントデータアーキテクチャに関するMSDNの合理的な記事 を参照してください。この記事で触れたいくつかの重要なトピック：
- 経済的考察
- セキュリティ
- テナントの考慮事項
- 規制（法的）
- スキルセットの懸念
また、サービスとしてのソフトウェア（SaaS）構成のいくつかのパターンにも触れています。
さらに、一見の価値は SQL Anywhereの連中からの興味深い記事 です。
私自身の個人的な見解-セキュリティ/信頼が実施されていることが確かでない限り、オプション3を選択します。または、スケーラビリティの問題によりオプション2へのフォールバックが少なくとも禁止されている場合。とはいえ、私はMongoDBのプロではありません。共有の「スキーマ」を使用するとかなり緊張しますが、より経験豊富な開業医には喜んで先送りします。
ここでの議論はNoSQLと主にMongoDBについてですが、私たちは Citus でPostgreSQLを使用し、分散/分割マルチテナントデータベースを構築しています。
se-case guide では、スキーマとさまざまなマルチテナント固有の機能をカバーするサンプルアプリを見ていきます。
より構造化されていないデータについては、PostgreSQLのJSONB列を使用して、そのようなテナント固有のデータを保存します。
MongoDBでの私の調査によると。 Trucos y consejos。 Aplicaciones multitenant。 所有できるテナントの数がわからない場合、このオプションはお勧めできません。単一のデータベースで...したがって、あなたの場合、オプション1を使用することをお勧めします。これで、限られた数のユーザーを使用する場合、それはすでに異なります。はい、考えたとおりにオプション2を使用できます。