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

Qdrant から Zilliz Cloud への移行

このトピックでは、Qdrant から移行する際に、Zilliz Cloud がデータ型マッピング、payload フィールド変換、collection 命名ルールをどのように処理するかについて説明します。

前提条件​

Qdrant から Zilliz Cloud への移行を開始する前に、以下の要件を満たしていることを確認してください。

Qdrant の要件​

要件詳細
ネットワークアクセスソース Qdrant cluster はパブリックインターネットからアクセス可能である必要があります
API アクセスアクセス権限を持つ cluster endpoint と API key
データの有無ソース collection にはデータが含まれている必要があります。空の collection は移行できません。

Zilliz Cloud の要件​

要件詳細
ユーザーロールOrganization Owner または Project Admin
cluster 容量十分なストレージおよび計算リソース（CU サイズの見積もりには CU calculator を使用）
ネットワークアクセスネットワーク制限を使用している場合は、Zilliz Cloud IPs を許可リストに追加します

データ型マッピング​

移行計画を立てるうえで、Qdrant のデータ型が Zilliz Cloud にどのようにマッピングされるかを理解することは重要です。

Qdrant フィールド型Zilliz Cloud フィールド型備考
Primary keyVARCHAR (primary key)自動的にマッピングされます。新しい ID を生成するには Auto ID を有効にします（元の値は破棄されます）。
Dense vectorFLOAT_VECTOR次元はそのまま正確に保持され、変更は不要です
Sparse vectorSPARSE_FLOAT_VECTORサンプルデータ内で空でない場合にのみマッピングされます。
PayloadJSON (dynamic fields)デフォルトでは dynamic schema としてマッピングされ、固定フィールドに変換できます。
詳細は Dynamic Field を参照してください。

Payload フィールド変換​

📘注意

Zilliz Cloud は payload schema を検出するために 100 行をサンプリングします。必要に応じて追加のフィールドを手動で追加できます。

Qdrant の payload は、最大限の柔軟性を得るために、最初は Zilliz Cloud の dynamic schema にマッピングされます。必要に応じて、payload フィールドを固定フィールドに変換して、以下の利点を得ることができます。

  • より強力な検証のためのデータ型の強制

  • より良いクエリパフォーマンスのための最適化された index

  • 一貫したデータ管理のための構造化 schema

payload を固定フィールドに変換する場合:

Qdrant Payload 型Zilliz 固定フィールド型備考
IntegerINT64直接的な型変換
FloatDOUBLEすべての浮動小数点数は DOUBLE になります
BoolBOOL直接マッピング
KeywordVARCHAR最大 65,535 バイトをサポート
GeoJSONJSON 構造として保持されます。固定フィールドには変換できません
DatetimeVARCHAR最大 65,535 バイトをサポート
UUIDVARCHAR最大 65,535 バイトをサポート

配列型のサポート​

配列型は既存の payload データでは検出されず、dynamic fields から変換することもできません。ただし、ほとんどの配列型は移行設定時に新しいフィールドとして手動で追加できます。

Qdrant 配列型Zilliz Cloud 配列型手動追加の可否
Array<Integer>ARRAY<INT64> 新しいフィールドとして追加可能
Array<Float>ARRAY<DOUBLE> 新しいフィールドとして追加可能
Array<Bool>ARRAY<BOOL> 新しいフィールドとして追加可能
Array<Keyword>ARRAY<VARCHAR> 新しいフィールドとして追加可能
Array<Geo>サポート対象外 利用不可
Array<Datetime>ARRAY<VARCHAR> 新しいフィールドとして追加可能
Array<UUID>ARRAY<VARCHAR> 新しいフィールドとして追加可能

固定フィールドに変換された payload フィールドについては、追加の属性を設定できます。

  • Nullable: フィールドが null 値を受け入れられるかどうかを決定します。この機能はデフォルトで有効です。詳細は Nullable attribute を参照してください。

  • Default Value: データが欠落している場合のフォールバック値を設定します。詳細は Default values を参照してください。

  • Partition Key: 必要に応じて INT64 または VARCHAR フィールドを partition key として指定できます。各 collection でサポートされる partition key は 1 つだけであり、選択したフィールドは nullable にできない点に注意してください。詳細は Use Partition Key を参照してください。

Qdrant 固有の処理ルール​

Collection 命名ルール​

Qdrant の collection 名は、以下の点を考慮して Zilliz Cloud に転送されます。

シナリオ影響解決策
命名の競合同じ名前の collection が database にすでに存在する場合、移行ジョブを送信できません既存の collection を削除する、別のターゲット database を選択する、または移行設定中に名前を変更してください
特殊文字collection 名は Qdrant からそのまま保持されますcollection 名が Zilliz Cloud の命名規則に準拠していることを確認してください
Ctrl I