MongoDBのマルチテナントデータベースに対して推奨されるアプローチは何ですか？

MongoDBを使用してマルチテナントアプリを作成することを考えています。テナントの数はまだわかりませんが、数千に拡張できるようにしたいと考えています。

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

1. セキュリティのためにテナント固有のフィールドを使用する、同じコレクション内のすべてのテナント
2. 単一の共有DB内のテナントごとに1つのコレクション
3. テナントごとに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/）

私は次の場合に最初のオプションをお勧めします：

• このシナリオの設計、実装、およびテストの複雑さを処理するのに十分な時間とリソースがあります。
• テナントごとにデータベースの構造と機能に大きな違いがない場合。
• アプリケーション設計により、テナントは実行時に最小限のカスタマイズのみを行うことができます。
• スペースを最適化し、ハードウェアリソースの使用を最小限に抑える場合。
• 何千ものテナントがある場合。
• 迅速かつ適切なコストでスケールアウトしたい場合。
• テナントに基づいてデータをバックアップしない場合（テナントごとに個別のバックアップを保持します）。このシナリオでもそれを行うことは可能ですが、作業は膨大になります。

私はバリアント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を参照して ください

MSDNには、マルチテナントデータアーキテクチャに関する妥当な記事があり、参考にしてください。この記事で触れたいくつかの重要なトピック：

• 経済的考察
• 安全保障
• テナントの考慮事項
• 規制（法的）
• スキルセットの懸念

また、Software as a Service（SaaS）構成のパターンについても触れています。

さらに、一見の価値はSQL Anywhereの連中からの興味深い記事です。

私の個人的な見解-強制されたセキュリティ/信頼が確実でない限り、オプション3を使用するか、またはスケーラビリティの懸念により少なくともオプション2へのフォールバックが禁止されている場合。とはいえ、私はMongoDBのプロではありません。私は共有の「スキーマ」を使用してかなり緊張します-しかし、私はより経験豊富な開業医に喜んで延期します。

オプション2を選びます。

ただし、mongod.exeコマンドラインオプション--smallfilesを設定できます。つまり、エクステントの最大ファイルサイズは2ギガバイトではなく0.5ギガバイトになります。私はmongo 1.42でこれをテストしました。したがって、オプション3は不可能ではありません。

MongoDBでの私の研究によると。Trucos y consejos。Aplicacionesマルチテナント。 保有できるテナントの数がわからない場合、このオプションはお勧めできません。シャーディングに関しては、数千に及ぶ可能性があり、複雑になる可能性があります。また、単一のデータベースに数千のコレクションがあることを想像してください。オプション1を使用することをお勧めします。ユーザーの数を制限する場合は、すでに異なります。そうです。考えたとおり、オプション2を使用できます。

ここでの議論はNoSQLの、主にMongoDBの上ですが、私たちのCitusは、 PostgreSQLのを使用して、分散/シャードマルチテナントデータベースを構築しています。

我々のユースケースガイドは、スキーマおよび様々なマルチテナント固有の特徴を覆う、例えばアプリケーションを介して歩きます。

さらに非構造化データについては、PostgreSQLのJSONB列を使用して、そのようなデータとテナント固有のデータを格納します。