MongoDB ベクトル検索のマルチテナントアーキテクチャをビルドする

You can implement multi-tenancy with MongoDB Vector Search so that a single instance of an application serves multiple tenants. This page describes design recommendations that apply specifically to MongoDB Vector Search. These recommendations differ from our multi-tenancy recommendations for Atlas.

推奨事項

MongoDB ベクトル検索のマルチテナントアーキテクチャを設計する際には、次の推奨事項を参照してください。

重要

このガイダンスでは、単一のVPC内にテナントを配置できることを前提としています。それ以外の場合は、テナントごとに個別のプロジェクトを維持する必要があります。これはMongoDB ベクトル検索には推奨されません。

すべてのテナントに対して 1 つのコレクション

すべてのテナントデータを単一のコレクション、データベース、およびクラスターに保存することをお勧めします。各ドキュメント内に tenant_id フィールドを含めることで、テナントを区別できます。このフィールドは、UUID やテナント名など、テナントの一意の識別子になります。このフィールドは、MongoDB ベクトル検索インデックスやクエリのプレフィルターとして使用できます。

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

モデル化と増やすことが容易。
メンテナンス操作を簡素化
tenant_id によるプレフィルターでクエリルーティングを効率化

注意
このフィルターは、このフィルターに一致するテナントのデータのみをクエリが返すことを保証します。

テナントごとに 1 つのコレクションまたはテナントごとに 1 つのデータベース

次の理由で、各テナントを個別のコレクションまたはデータベースに保存することは推奨されません。

パフォーマンスへの影響: このアプローチでは、コレクションの数に応じて変更ストリームの負荷が異なる可能性があり、パフォーマンスとモニタリング機能に悪影響を影響可能性があります。
追加の分離なし: Atlas のデータ分離保証はデータベースレベルで適用されます。同じデータベース内で個別のコレクションを使用しても、追加のデータ分離の利点は得られません。別個のデータベースを使用すると運用が複雑になり、ほとんどのユースケースで意味のあるセキュリティ上の利点はありません。

Instead, use one collection for all tenants. For an example of how to migrate from a collection-per-tenant model to a single collection model, see Migrating from a Collection-Per-Tenant Model.

Considerations

次の戦略を考慮し、推奨アプローチを使用してパフォーマンスに関する潜在的な問題を軽減してください。

テナントのサイズ不一致

それぞれのドキュメント数が比較的少ないテナントが多い場合、またはデータの分散が不均衡であるためにパフォーマンスの問題が発生している場合（一部の大規模テナントと多数の小規模テナント）は、次の戦略を検討してください。

多数の小規模テナントにフラットインデックスを使用

多数のテナントがあり（最大1 00 万）、各テナントのドキュメント数が比較的に少ない場合（それぞれ10 000 ドキュメント未満）は、デフォルトのHierarchical Navigable Small Worlds インデックスではなく、flat インデックスを使用します。フラットインデックスを作成するには、インデックス定義で indexingMethod フィールドを flat に設定します。

各テナントのドキュメント数が少ない場合、特定のテナントにフィルターされたクエリはすでに徹底的に検索されています。このような場合、Hierarchical Navigable Small Worlds グラフはメモリとメンテナンスのオーバーヘッドを増やすだけで、メリットはありません。フラットインデックスにより、この不要なオーバーヘッドが解消されます。

フラットインデックスは、マルチテナントワークロードに対して次の利点を提供します。

選択的フィルターに最適化: 各テナントのドキュメント数が少ない選択性の高いクエリでは、網羅的なスキャンがすでに最速のパスです。平面インデックスはこれを直接サポートするため、レイテンシと再現率の両方が向上します。
予測可能なパフォーマンス: どのテナントが対象になっているかに関係なく、クエリのレイテンシが緊密な範囲内に収まるため、テナント間の近隣地域影響を排除できます。
リソース効率: 平面インデックスにより、Hierarchical Navigable Small Worlds グラフの構築に関連するメモリとメンテナンスのオーバーヘッドが排除されます。

例えば、次のインデックス定義は、tenant_id フィルターフィールドを使用してフラットインデックスを作成します。MongoDB ベクトル検索で Voyage AI モデルを使用して埋め込みを自動的に生成する場合は autoEmbed タイプを選択します。または、既に埋め込みがある場合は vector タイプを選択します。

例: 自動埋め込みインデックス

{
  "fields": [
    {
      "type": "autoEmbed",
      "modality": "text",
      "path": "<fieldToIndex>",
      "model": "<embeddingModel>",
      "indexingMethod": "flat"
    },
    {
      "type": "filter",
      "path": "tenant_id"
    }
  ]
}

例: ベクトルインデックス

{
  "fields": [
    {
      "type": "vector",
      "path": "<fieldToIndex>",
      "numDimensions": <numberOfDimensions>,
      "similarity": "euclidean | cosine | dotProduct",
      "indexingMethod": "flat"
    },
    {
      "type": "filter",
      "path": "tenant_id"
    }
  ]
}

注意

平面インデックスは、autoEmbed タイプで自動埋め込みを使用するか、vector タイプで既存の埋め込みを使用するかにかかわらず、スカラーおよびバイナリ量子化と互換性があります。平面インデックスを使用する場合は、常に tenant_id フィールドをプレフィルターとしてクエリに含めてください。

大規模なテナントのビューでの HNSW インデックスの使用

それぞれのドキュメント数が 10、000 よりも大きい大規模なテナントの場合は、Hierarchical Navigable Small Worlds インデックスを MongoDBビューで使用して、大規模なテナントと小規模なテナントを区別します。

大規模テナント（上位 1%）:
- 大規模なテナントごとにビューを作成してください。
- 各ビューに対してHierarchical Navigable Small Worldsインデックスを作成します。
- 大規模テナントの記録を保持し、クエリ時に確認してそれに応じてクエリをルーティングします。
小規模テナント（残りのテナント）:
- すべての小規模テナント用にビューを 1 つ作成します。
- Build a single flat index for this view.
- tenant_idフィールドをプレフィルターとして使用し、それに応じてクエリをルーティングします。

例

The following example demonstrates how to create views for large and small tenants by using mongosh:

大規模テナントとそれに対応する tenant_id の値を記録し、これらのテナントごとにビューを作成します。

db.createView(
  "<viewName>",
  "<collectionName>",
  [
    {
      "$match": {
        "tenant_id": "<largeTenantId>"
      }
    }
  ]
)

大規模テナントを除外して、小規模テナント用のビューを作成します。

db.createView(
  "<viewName>",
  "<collectionName>",
  [
    {
      "$match": {
        "tenant_id": {
          "$nin": [ "<largeTenantId1>", "<largeTenantId2>", ... ]
        }
      }
    }
  ]
)

ビューを作成した後、各ビューのインデックスを作成してください。次の点を確認してください。

インデックスのコレクション名を指定する際は、元のコレクション名ではなく、ビュー名を使用してください。
大規模なテナントビューの場合は、Hierarchical Navigable Small Worldsインデックス (デフォルト) を作成します。
For the small tenant view, create an index with the flat indexing method and include the tenant_id field as a pre-filter.

インデックスの作成について詳しくは、「インデックスの作成」ページを参照してください。

多数の大規模テナント

If you have many tenants that each have a large number of documents, consider using a partition-based system by distributing data across shards.

You can use the tenant_id field as a shard key to distribute the data across specific ranges based on the tenant ID. For more information, see Ranged Sharding.

テナントごとのコレクションモデルからの移行

テナントごとのコレクションモデルから単一コレクションモデルに移行するには、各テナントのコレクションを処理し、ドキュメントを新しいコレクションに挿入します。

For example, the following script uses the Node.js driver to migrate your data from a collection-per-tenant model to a single collection model. The script also includes a tenant_id field for each document based on the source collection's name.

migrate-コレクション.js

import { MongoClient } from 'mongodb';
const uri = "<connectionString>"; 
const sourceDbName = "<sourceDatabaseName>"; 
const targetDbName = "<targetDatabaseName>"; 
const targetCollectionName = "<targetCollectionName>";
async function migrateCollections() {
 const client = new MongoClient(uri);
 try {
     await client.connect();
     const sourceDb = client.db(sourceDbName);
     const targetDb = client.db(targetDbName);
     const targetCollection = targetDb.collection(targetCollectionName);
     const collections = await sourceDb.listCollections().toArray();
     console.log(`Found ${collections.length} collections.`);
     const BATCH_SIZE = 1000; // Define a suitable batch size based on your requirements
     let totalProcessed = 0;
     for (const collectionInfo of collections) {
         const collection = sourceDb.collection(collectionInfo.name);
         let documentsProcessed = 0;
         let batch = [];
         const tenantId = collectionInfo.name; // Uses the collection name as the tenant_id
         const cursor = collection.find({});
         for await (const doc of cursor) {
             doc.tenant_id = tenantId; // Adds a tenant_id field to each document
             batch.push(doc);
             if (batch.length >= BATCH_SIZE) {
                 await targetCollection.insertMany(batch);
                 totalProcessed += batch.length;
                 documentsProcessed += batch.length;
                 console.log(`Processed ${documentsProcessed} documents from ${collectionInfo.name}. Total processed: ${totalProcessed}`);
                 batch = [];
             }
         }
         if (batch.length > 0) {
             await targetCollection.insertMany(batch);
             totalProcessed += batch.length;
             documentsProcessed += batch.length;
             console.log(`Processed ${documentsProcessed} documents from ${collectionInfo.name}. Total processed: ${totalProcessed}`);
         }
     }
     console.log(`Migration completed. Total documents processed: ${totalProcessed}`);
 } catch (err) {
     console.error('An error occurred:', err);
 } finally {
     await client.close();
 }
}
await migrateCollections().catch(console.error);