MongoDB Search のマルチテナント アーキテクチャを構築

すべてのテナントに単一のコレクション（推奨）

すべてのテナント戦略に 1 つのコレクションを適用することをお勧めします。このアーキテクチャでは、すべてのテナント データを単一のデータベース内の 1 つのコレクションに保存します。各ドキュメント内にtenant_id フィールドを含めることで、テナントを区別できます。このフィールドは、UUID やテナント名など、テナントの一意の識別子にすることができます。

この集中型アプローチには、以下の利点があります。

• インデックスの数を減らします

  すべてのテナント データは 1 つのコレクションに保存されるため、必要なインデックスは1 つだけで、すべてのテナントのドキュメントを提供します。クラスターリソースの制限に達しないようにします。例には、tenant_id およびその他の共有フィールドまたはテナント固有のフィールドを 1 つのインデックスに含めることができます。

• メンテナンス操作を簡素化

  すべてのデータを保存するコレクションが1 つだけであるため、複数のコレクションを保持したり、複数のデータベースにまたがってリソースを増やす必要はありません。また、単一のデータベース内の 1 つのコレクションのみを対象とする必要がある場合は、バックアップ、シャーディング、およびレプリケーション操作も簡素化します。

• クエリを効率的に処理します

  句内で と等価演算子を使用して、クエリに tenant_idフィールドをフィルターとして指定します。$search.compound.filter

  注意

  クエリ結果には、一致するテナントのドキュメントのみが含まれるため、テナント間でのデータの流出を防ぎます。

共存するテナントが同様のアクセス パターンとリソースサイズを共有する場合、この戦略は Luceneインデックスフィールド数も低く維持します。

独自のリソースページまたはインデックス作成要件を持つ大規模なテナントがある場合は、 ビュー を使用します。

1. テナントを分離します。 と $match$expr操作を使用してビューを作成し、テナントのドキュメントのみをフィルタリングします。

2. インデックスは個別に作成されます。ビューでMongoDB Searchインデックスを作成します。

   そのため、他のテナントが使用する共有インデックスに影響を与えずに、大規模なテナントのインデックス定義をカスタマイズできます。他のすべてのテナントは 1 つのインデックスを使用できます。

   クラスターあたり 2500 インデックスを超えると、基本クラスターに高負荷が発生し、データベースワークロードが中断されるリスクがあるため、推奨はされません。

現在、テナントごとに 1コレクション戦略を適用している場合は、多数のインデックスによるリソース競合によってレプリケーションラグの OOM エラーが増加するのを防ぐために、基本階層をスケールアップすることをお勧めします。また、すべてのテナント戦略に 1 つのコレクションに移行することも推奨しています。

テナントごとに 1 つのデータベース

テナントごとのデータベース設定では、各テナントに独自のデータベースが含まれます。この設定はテナント データを分離しますが、クラスター内のインデックスの数も乗じます。各テナントに多くのインデックス付きフィールドがある場合、クラスターは 2500-インデックス上限に達する可能性があります。

テナントごとに 1 つのコレクション（非推奨）

コレクションごとのテナント戦略は、各テナントを 共有データベース内の独自のコレクションにマッピングします。コレクションごとにインデックスを維持するオーバーヘッドによって、次の原因が発生する可能性があります。

• レプリケーションラグの増加

• リソース競合による OOM エラー

• 基本階層の不安定

テナントが非常に予測可能で軽量なワークロードでない限り、 MongoDB Search ではこの戦略は推奨されません。現在この戦略を使用している場合は、すべてのテナントに対して 1 つのコレクション戦略に移行してください。