メインコンテンツまでスキップ

Zilliz Cloud の制限

このページでは、Zilliz Cloud プラットフォームの制限事項について説明します。このページで言及されている設定の大部分は、Zilliz が提供する OPS システムを使用して調整できます。さらにサポートが必要な場合は、引き続き お問い合わせ いただくこともできます。

組織とプロジェクト​

次の表は、1 人のユーザーに許可される組織とプロジェクトの最大数に関する制限を示しています。

項目最大数備考
プロジェクト100各ユーザーは、1 つの組織内に最大 100 個のプロジェクトを作成できます。

ユーザーとロール​

次の表は、Zilliz Cloud で許可されるユーザーとロールの最大数に関する制限を示しています。

項目最大数備考
クラスターユーザー5001 つのクラスターには、合計で最大 500 人のユーザーを含めることができます。
クラスターのカスタムロール5001 つのクラスターには、合計で最大 500 個のカスタムロールを含めることができます。この制限を解除するには、お問い合わせ ください。

API キー​

項目最大数備考
API キー100各組織には、リソースを最適に利用してセキュリティを確保するために、最大 100 個のカスタマイズされた API キーを含めることができます。

コンソール IP 許可リスト​

項目最大数備考
組織のコンソール IP 許可リスト内の IP100各組織のコンソール IP 許可リストには、最大 100 個の IP または CIDR ブロックを含めることができます。

クラスター​

CUs​

CU は、データの並列処理に使用されるコンピュートリソースの基本単位であり、CU タイプによって CPU、メモリ、ストレージの組み合わせが異なります。CU の概念は Dedicated クラスターにのみ適用されます。

プロジェクトプランとクラスターデプロイオプション制限備考
Standard プロジェクトの Dedicated サービングクラスターCU size <=32コンソールでは、1 つのクラスターに対して最大 32 CUs を作成できます。
Enterprise プロジェクトの Dedicated サービングクラスターCU size x Replica Count <=204,800コンソールでは、1 つのクラスターに対して最大 2,048 CUs を作成できます。
ただし、レプリカを追加する場合の制限は CU size x Replica Count <=204,800 です。

以下の場合は、お問い合わせ ください。

  • Standard プロジェクトの Dedicated クラスターで 32 CUs を超える必要がある場合

  • Enterprise プロジェクトの Dedicated クラスターで 1,024 CUs を超える必要がある場合

レプリカ​

レプリカを追加するには、クラスターに 少なくとも 8 CUs が必要です。さらに、次の制限も適用されます。

項目制限備考
レプリカ100最大 100 個のレプリカを作成できます。
Query CU x Replica Count204,800クラスターのレプリカ x Query CU は 204,800 を超えてはなりません。
Notes

以前の Milvus リリースと互換性のある一部のクラスターでは、レプリカを追加するために少なくとも 12 CUs が必要になる場合があります。

query CU が少ないクラスターにレプリカを追加するには、お問い合わせ ください。

データベース​

  • 各 Serving-Dedicated クラスターは、最大 1024 個のデータベースを持つことができます。

  • デフォルトデータベースは削除できません。

コレクション​

Zilliz Cloud クラスター内のコレクションとパーティションの最大数は、そのクラスターに割り当てられた CUs 数と、互換性のある Milvus バージョンによって異なります。以下の説明を参照して、クラスター内のコレクションとパーティションの最大数を計算できます。

CU あたり最大 1,024 個のコレクションまたは 4,096 個のパーティションを作成でき、1 つのコレクションあたり最大 1,024 個のパーティションが許可されます。次の計算式を使用して、クラスター内のコレクション数とパーティション数の上限を計算できます:

I1aJwA2LShihxQbyG30cFm14ngf

  • クラスター内のコレクションの総数は、クラスター内の CUs 数の 1,024 倍または 16,384 のいずれか小さい方未満である必要があります。

  • クラスター内のすべてのコレクションにまたがるパーティションの総数は、クラスターに割り当てられた CUs 数の 4,096 倍または 65,536 のいずれか小さい方未満である必要があります。

  • 両方の条件を満たす必要があります。

フィールド​

項目最大数
コレクションあたりのフィールド数64
コレクションあたりのベクトルフィールド数10

フィールドに関するその他の制限:

  • VarChar や JSON などの一部のフィールドは、想定よりも多くのメモリを使用し、クラスターが満杯になる原因となることがあります。

次元​

ベクトルフィールドの最大次元数は 32,768 です。

シャード​

許可されるシャードの最大数は、クラスターの CU Size によって異なります。

CU Size最大数
1 - 2 CU2
4 - 8 CU4
12 - 64 CU8
> 64 CU16

レート制限​

Zilliz Cloud は、コレクションおよびパーティションのデータ定義言語（DDL）操作にもレート制限を課しています。これには、コレクションの作成、load、release、drop が含まれます。次のレート制限は、Serverless クラスターと Dedicated クラスターの両方のコレクションに適用されます。

レート制限
コレクション DDL 操作
(create, load, release, drop)		クラスターあたり 20 req/s
パーティション DDL 操作
(create, load, release, drop)		クラスターあたり 20 req/s

操作​

このセクションでは、Zilliz Cloud クラスターにおける一般的なデータ操作のレート制限に焦点を当てます。

Insert と Upsert​

insert および upsert 操作のレート制限は、クラスターのデプロイオプションと使用中の CUs 数によって異なります。

Insert および Upsert の最大レート制限
Dedicated クラスター16 MB/s + 1 MB/s × CU
最大 256 MB/s です。

例:

  • 1 CU: 17 MB/s

  • 8 CUs: 24 MB/s

  • 64 CUs: 80 MB/s

  • 240 CUs: 256 MB/s

  • >= 240 CUs: 最大 256 MB/s

さらに、次の追加制限が適用されます。

  • 単一シャードの書き込みレートは 32 MB/s. を超えてはなりません。

  • データを insert する場合は、スキーマで定義されたすべてのフィールドを含めてください。コレクションで AutoID が有効になっている場合は、プライマリキーを除外してください。

  • データを upsert する場合は、スキーマで定義されたすべてのフィールドを含めてください。

  • insert または upsert したエンティティを search や query で即座に取得できるようにするには、search または query リクエストの consistency level を Strong に変更することを検討してください。詳細については、整合性レベル を参照してください。

インデックス​

インデックスタイプはフィールドタイプによって異なります。次の表は、インデックス化可能なフィールドタイプと、対応するインデックスタイプを示しています。

フィールドタイプインデックスタイプメトリクスタイプ
ベクトルフィールドAUTOINDEXL2、IP、COSINE
VarChar フィールドTRIEN/A
Int8/16/32/64STL_SORTN/A
Float32/64STL_SORTN/A

Flush​

flush リクエストのレート制限は 1 秒あたり 0.1 リクエストで、特定のクラスタータイプではコレクションレベルで適用されます。このレート制限は、Milvus v2.4.x 以降と互換性のあるクラスターに適用されます。

Notes

flush 操作を手動で実行することは推奨されません。Zilliz Cloud クラスターがこれを適切に処理します。

Load​

load リクエストのレート制限は、クラスターあたり 20 req/s です。

Notes

すでにロードされているコレクションには、新しいデータがこれらのコレクションに流入している場合でも、コレクションの load を実行する必要はありません。

各 search request/response は 64 MB 以下である必要があります。

各 search リクエストが保持するクエリベクトルの数（通常 nq と呼ばれます）は 16,384 以下であり、各 search レスポンスが返すエンティティ数（通常 topK と呼ばれます）は 16,384 以下です。

Query​

各 query request/response は 64 MB 以下である必要があります。

各 query レスポンスが返すエンティティ数は 16,384 以下です（通常 topK と呼ばれます）。

Delete​

各 delete request/response は 64 MB 以下である必要があります。

delete リクエストのレート制限は、クラスターあたり 0.5 MB/s です。

Drop​

drop リクエストのレート制限は、クラスターあたり 20 req/s です。

データインポート​

1 つのコレクションでは、実行中または保留中のインポートジョブを最大 10,000 件まで持つことができます。

Zilliz Cloud は、Web コンソールでインポートするファイルにも制限を設けています。

ファイルタイプローカルアップロードオブジェクトストレージから
JSON1 GBインポートの合計最大サイズは 1 TB、各ファイルの最大サイズは 10 GB で、ファイル数は最大 1,000 個です。
Parquet1 GBインポートの合計最大サイズは 1 TB、各ファイルの最大サイズは 10 GB で、ファイル数は最大 1,000 個です。
Numpyサポート対象外インポートの合計最大サイズは 1 TB、各サブディレクトリの最大サイズは 10 GB で、サブディレクトリ数は最大 1,000 個です。

詳細については、ストレージオプション および フォーマットオプション を参照してください。

コンソールでのバックアップ​

手動で作成したバックアップは永続的に保持されます。

自動作成されたバックアップの最大保持期間は 30 日です。

コンソールでの復元​

バックアップファイルは、そのバックアップファイルの元のクラスターと同じリージョンで復元できます。復元の対象となるクラスターは、元のクラスターと同じ CU タイプを使用する必要があります。

IP アクセスリスト​

項目最大数備考
コンソール IP アクセス100コンソール IP 許可リストには、最大 100 個の IP アドレスを追加できます。

移行​

他のベンダーからお使いの Zilliz Cloud クラスターにデータを移行でき、移行ごとのコレクションの最大数はお使いの Zilliz Cloud クラスターによって異なります。移行時には、毎回最大 10 個のコレクションを移行できます。

API の提供状況

Zilliz Cloud は、より優れたユーザー体験を提供するために、Milvus とは若干異なる動作をします。この記事は、API の観点から 2 つのプラットフォームの違いを明確にすることを目的としています。 | BYOC

Ctrl I