マルチテナンシーの実装
Zilliz Cloud におけるマルチテナンシーとは、複数の顧客またはチーム（テナントと呼ばれる）が同じクラスターを共有しながらも、それぞれ独立したデータ環境を維持することを意味します。
Zilliz Cloud では4つのマルチテナンシー戦略をサポートしており、それぞれスケーラビリティ、データ分離、柔軟性のトレードオフが異なります。このガイドでは各オプションを説明し、ユースケースに最も適した戦略を選択できるように支援します。
マルチテナンシー戦略
Zilliz Cloud では、マルチテナンシーを データベース（データベース）、Collection（コレクション）、Partition（パーティション）、パーティションキー（パーティションキー）の4つのレベルでサポートしています。
データベースレベルのマルチテナンシー
データベースレベルのマルチテナンシーでは、各テナントに1つ以上のコレクションを含む対応するデータベースが割り当てられます。
-
Scalability: データベースレベルのマルチテナンシー戦略は Zilliz Cloud の Dedicated クラスターでのみ利用可能で、最大1,024テナントまでサポートします。
-
データ分離: 各データベース内のデータは完全に分離されており、規制された環境や厳格なコンプライアンス要件を持つ顧客向けに、エンタープライズグレードのデータ分離を提供します。
-
柔軟性: 各データベースは異なるスキーマを持つコレクションを保持でき、非常に柔軟なデータ構成が可能で、各テナントが独自のデータスキーマを持つことができます。
-
その他: この戦略は RBAC もサポートしており、テナントごとのユーザーアクセスを細かく制御できます。また、特定のテナントのデータを柔軟にロードまたはリリースすることで、ホットデータとコールドデータを効果的に管理できます。
コレクションレベルのマルチテナンシー
コレクションレベルのマルチテナンシーでは、各テナントにコレクションが割り当てられ、強力なデータ分離を実現します。
-
Scalability: クラスターは最大16,384のコレクションを保持できるため、この戦略ではクラスター内で同数のテナントを収容できます。
-
データ分離: コレクションは物理的に互いに分離されています。この戦略は強力なデータ分離を提供します。
-
柔軟性: この戦略では、各コレクションが独自のスキーマを持つことができ、異なるデータスキーマを持つテナントに対応できます。
-
その他: この戦略も RBAC をサポートしており、テナント単位でのきめ細かいアクセス制御が可能です。また、特定のテナントのデータを柔軟にロードまたはリリースすることで、ホットデータとコールドデータを効果的に管理できます。
パーティションレベルのマルチテナンシー
パーティションレベルのマルチテナンシーでは、各テナントが共有コレクション内に手動で作成されたパーティションに割り当てられます。
-
Scalability: 1つのコレクションは最大1,024のパーティションを保持できるため、コレクション内で同数のテナントを収容できます。
-
データ分離: 各テナントのデータはパーティションによって物理的に分離されます。
-
柔軟性: この戦略では、すべてのテナントが同じデータスキーマを共有する必要があります。また、パーティションは手動で作成する必要があります。
-
その他: RBAC はパーティションレベルではサポートされていません。テナントは個別に、または複数のパーティションにまたがってクエリできます。そのため、テナントセグメント間での集計クエリや分析が必要なシナリオに適しています。また、特定のテナントのデータを柔軟にロードまたはリリースすることで、ホットデータとコールドデータを効果的に管理できます。
パーティションキーレベルのマルチテナンシー
この戦略では、すべてのテナントが単一のコレクションとスキーマを共有しますが、各テナントのデータはパーティションキーの値に基づいて自動的に16の物理的に分離されたパーティションにルーティングされます。各物理パーティションには複数のテナントが含まれる可能性がありますが、異なるテナントのデータは論理的に分離されたままです。
-
Scalability: パーティションキーレベルの戦略は最もスケーラブルで、数百万のテナントをサポートします。
-
データ分離: 複数のテナントが物理パーティションを共有する可能性があるため、この戦略のデータ分離は比較的弱いです。
-
柔軟性: すべてのテナントが同じデータスキーマを共有する必要があるため、この戦略のデータ柔軟性は限定的です。
-
その他: RBAC はパーティションキーレベルではサポートされていません。テナントは個別に、または複数のパーティションにまたがってクエリできます。そのため、テナントセグメント間での集計クエリや分析が必要なシナリオに適しています。
適切なマルチテナンシー戦略の選択
以下の表は、4つのマルチテナンシー戦略を包括的に比較したものです。
データベース-level | Collection-level | Partition-level | Partition key-level | |
|---|---|---|---|---|
Cluster deployment option | Dedicated only | All deployment options | All deployment options | All deployment options |
データ Isolation | Physical | Physical | Physical | Physical + Logical |
Max. number of tenants | 1024 | Up to 16,384 depending on the cluster deployment option and project plan. See Zilliz Cloud 制限s | Up to 1,024 per collection depending on the cluster deployment option and project plan. See Zilliz Cloud 制限s | Millions |
データ schema flexibility | High | 中 | Low | Low |
RBAC support | Yes | Yes | No | No |
Search performance | Strong | Strong | 中 | 中 |
Cross-tenant search support | No | No | Yes | Yes |
Support for effective handling of hot and cold data | Yes | Yes | Yes | No Currently, サポートされていません for the パーティションキー-level strategy. But if you have massive tenants and require effective handling of hot and cold data, please contact us. |
Zilliz Cloud でマルチテナンシー戦略を選択する際には、いくつかの要素を考慮する必要があります。
-
Scalability: パーティションキー > Partition > Collection > データベース
数百万以上のテナントをサポートする必要がある場合は、パーティションキーレベルの戦略を使用してください。
-
厳格なデータ分離要件: データベース = Collection > Partition > パーティションキー
厳格な物理的なデータ分離要件がある場合は、データベース、コレクション、またはパーティションレベルの戦略を選択してください。
-
Flexible data schema for each tenant's data: データベース > Collection > Partition = パーティションキー
データベースレベルおよびコレクションレベルの戦略は、データスキーマにおいて完全な柔軟性を提供します。テナントごとに異なるデータ構造を持つ必要がある場合は、データベースレベルまたはコレクションレベルのマルチテナンシーを選択してください。
-
その他
-
パフォーマンス: 検索パフォーマンスは、インデックス、検索パラメータ、マシン構成などさまざまな要因によって決まります。Zilliz Cloud ではパフォーマンスチューニングもサポートしています。マルチテナンシー戦略を選択する前に、実際のパフォーマンスをテストすることを推奨します。
-
Effective handling of hot and cold data: 現在、データベースレベル、コレクションレベル、パーティションレベルの戦略はすべてホットデータとコールドデータの処理をサポートしています。パーティションキーレベルの戦略を選択したいがホット/コールドデータ処理が必要な場合は、お問い合わせください。
-
テナント間検索: パーティションレベルおよびパーティションキーレベルの戦略のみがテナント間検索をサポートしています。
-