MongoDBを使ってマルチテナントアプリを作ろうと思っています。テナントの数についてはまだ推測できませんが、数千にスケールできるようにしたいと考えています。
次の 3 つの戦略を考えることができます。
- セキュリティのためにテナント固有のフィールドを使用する、同じコレクション内のすべてのテナント
- 1 つの共有 DB 内のテナントごとに 1 つのコレクション
- テナントごとに 1 つのデータベース
私の頭の中の声は、オプション 2 を採用することを提案しています。
考えと意味、誰か?
MongoDBを使ってマルチテナントアプリを作ろうと思っています。テナントの数についてはまだ推測できませんが、数千にスケールできるようにしたいと考えています。
次の 3 つの戦略を考えることができます。
私の頭の中の声は、オプション 2 を採用することを提案しています。
考えと意味、誰か?
このリンクのコメントで良い答えを見つけました:
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 にあり、参照することをお勧めします。この記事で触れたいくつかの重要なトピック:
また、Software as a Service (SaaS) 構成のパターンについても触れています。
さらに、一見の価値があるのは、SQL Anywhere 関係者による興味深い記事です。
私自身の個人的な見解 - 強制されたセキュリティ/信頼を確信していない限り、オプション 3 を使用するか、スケーラビリティの懸念によりオプション 2 へのフォールバックが少なくとも禁止されている場合は、オプション 2 を使用します。そうは言っても...私はMongoDBのプロではありません。共有の「スキーマ」を使用するのはかなり神経質になりますが、経験豊富な実践者に喜んで委ねます。