マルチテナンシーの実装
Zilliz Cloud におけるマルチテナンシーとは、テナントと呼ばれる複数の顧客またはチームが、分離されたデータ環境を維持しながら同じクラスターを共有することを意味します。
Zilliz Cloud は 4 つのマルチテナンシー戦略をサポートしており、それぞれスケーラビリティ、データ分離、柔軟性の間で異なるトレードオフを提供します。このガイドでは各オプションを順に説明し、ユースケースに最適な戦略を選択できるようにします。
マルチテナンシー戦略
Zilliz Cloud は、データベース、コレクション、パーティション、パーティションキー の 4 つのレベルでマルチテナンシーをサポートしています。
データベースレベルのマルチテナンシー
データベースレベルのマルチテナンシーでは、各テナントに 1 つ以上のコレクションを含む対応する データベース が割り当てられます。

-
スケーラビリティ: データベースレベルのマルチテナンシー戦略は、Zilliz Cloud の Dedicated クラスターでのみ利用可能で、最大 1,024 テナントをサポートします。
-
データ分離: 各データベース内のデータは完全に分離されており、規制対象の環境や厳格なコンプライアンス要件を持つ顧客に適したエンタープライズグレードのデータ分離を提供します。
-
柔軟性: 各データベースは異なるスキーマを持つコレクションを持つことができるため、非常に柔軟なデータ構成が可能になり、各テナントが独自のデータスキーマを持つことができます。
-
その他: この戦略は RBAC もサポートしており、テナントごとにユーザーアクセスをきめ細かく制御できます。さらに、特定のテナントのデータを柔軟にロードまたはリリースして、ホットデータとコールドデータを効果的に管理できます。
コレクションレベルのマルチテナンシー
コレクションレベルのマルチテナンシーでは、各テナントに コレクション が割り当てられ、強力なデータ分離を提供します。

-
スケーラビリティ: 1 つのクラスターは最大 16,384 個のコレクションを保持できるため、この戦略ではクラスター内で同数のテナントに対応できます。
-
データ分離: コレクションは互いに物理的に分離されています。この戦略は強力なデータ分離を提供します。
-
柔軟性: この戦略では、各コレクションが独自のスキーマを持つことができ、異なるデータスキーマを持つテナントに対応できます。
-
その他: この戦略は RBAC もサポートしており、テナントに対するきめ細かなアクセス制御が可能です。さらに、特定のテナントのデータを柔軟にロードまたはリリースして、ホットデータとコールドデータを効果的に管理できます。
パーティションレベルのマルチテナンシー
パーティションレベルのマルチテナンシーでは、各テナントは共有コレクション内に手動で作成された パーティション に割り当てられます。

-
スケーラビリティ: 1 つのコレクションはコレクションあたり最大 1,024 個のパーティションを保持でき、その中で同数のテナントに対応できます。
-
データ分離: 各テナントのデータはパーティションによって物理的に分離されます。
-
柔軟性: この戦略では、すべてのテナントが同じデータスキーマを共有する必要があります。また、パーティションは手動で作成する必要があります。
-
その他: RBAC はパーティションレベルではサポートされていません。テナントは個別に、または複数のパーティションにわたってクエリできるため、このアプローチはテナントセグメント全体にわたる集約クエリや分析を伴うシナリオに適しています。さらに、特定のテナントのデータを柔軟にロードまたはリリースして、ホットデータとコールドデータを効果的に管理できます。
パーティションキーレベルのマルチテナンシー
この戦略では、すべてのテナントが単一のコレクションとスキーマを共有しますが、各テナントのデータは パーティションキー の値に基づいて、物理的に分離された 16 個のパーティションに自動的にルーティングされます。各物理パーティションには複数のテナントを含めることができますが、異なるテナントのデータは論理的に分離されたままです。

-
スケーラビリティ: パーティションキーレベルの戦略は最もスケーラブルなアプローチを提供し、数百万のテナントをサポートします。
-
データ分離: 複数のテナントが物理パーティションを共有できるため、この戦略のデータ分離は比較的弱くなります。
-
柔軟性: すべてのテナントが同じデータスキーマを共有する必要があるため、この戦略のデータ柔軟性は限定的です。
-
その他: RBAC はパーティションキーレベルではサポートされていません。テナントは個別に、または複数のパーティションにわたってクエリできるため、このアプローチはテナントセグメント全体にわたる集約クエリや分析を伴うシナリオに適しています。
適切なマルチテナンシー戦略の選択
以下の表は、4 つのレベルのマルチテナンシー戦略を包括的に比較したものです。
| データベースレベル | コレクションレベル | パーティションレベル | パーティションキーレベル | |
|---|---|---|---|---|
| クラスターのデプロイオプション | Dedicated のみ | すべてのデプロイオプション | すべてのデプロイオプション | すべてのデプロイオプション |
| データ分離 | 物理 | 物理 | 物理 | 物理 + 論理 |
| 最大テナント数 | 1024 | クラスターのデプロイオプションとプロジェクトプランに応じて最大 16,384。 Zilliz Cloud Limits を参照してください。 | クラスターのデプロイオプションとプロジェクトプランに応じて、コレクションあたり最大 1,024。 Zilliz Cloud Limits を参照してください。 | 数百万 |
| データスキーマの柔軟性 | 高 | 中 | 低 | 低 |
| RBAC サポート | あり | あり | なし | なし |
| 検索パフォーマンス | 強 | 強 | 中 | 中 |
| クロステナント検索のサポート | なし | なし | あり | あり |
| ホットデータとコールドデータの効果的な処理のサポート | あり | あり | あり | なし 現在、パーティションキーレベルの戦略ではサポートされていません。ただし、大量のテナントがあり、ホットデータとコールドデータの効果的な処理が必要な場合は、お問い合わせください。 |
Zilliz Cloud でマルチテナンシー戦略を選択する際には、いくつかの要素を考慮する必要があります。
-
スケーラビリティ: パーティションキー > パーティション > コレクション > データベース
非常に多数のテナント(数百万以上)をサポートすることを想定している場合は、パーティションキーレベルの戦略を使用します。
-
強力なデータ分離要件: データベース = コレクション > パーティション > パーティションキー
厳格な物理データ分離要件がある場合は、データベース、コレクション、またはパーティションレベルの戦略を選択します。
-
各テナントのデータに対する柔軟なデータスキーマ: データベース > コレクション > パーティション = パーティションキー
データベースレベルおよびコレクションレベルの戦略は、データスキーマに完全な柔軟性を提供します。テナントのデータ構造が異なる場合は、データベースレベルまたはコレクションレベルのマルチテナンシーを選択します。
-
その他
-
パフォーマンス: 検索パフォーマンスは、インデックス、検索パラメーター、マシン構成など、さまざまな要因によって決まります。Zilliz Cloud はパフォーマンスチューニングもサポートしています。マルチテナンシー戦略を選択する前に、実際のパフォーマンスをテストすることを推奨します。
-
ホットデータとコールドデータの効果的な処理: 現在、データベースレベル、コレクションレベル、パーティションレベルの戦略はいずれもホットデータとコールドデータの処理をサポートしています。パーティションキーレベルの戦略を選択したいが、ホットデータとコールドデータの処理が必要な場合は、お問い合わせください。
-
クロステナント検索: パーティションレベルおよびパーティションキーレベルの戦略のみがクロステナントクエリをサポートしています。
-