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

Qdrant から Zilliz Cloud への移行

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

事前準備​

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

Qdrant の要件​

要件詳細
ネットワークアクセスソース Qdrant クラスターはパブリックインターネットからアクセス可能である必要があります
API アクセスアクセス権限を持つクラスターエンドポイントと API キー
データの可用性ソースコレクションにはデータが含まれている必要があります。空のコレクションは移行できません。

Zilliz Cloud の要件​

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

データ型マッピング​

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

Qdrant のフィールド型Zilliz Cloud のフィールド型備考
プライマリキーVARCHAR（primary key）自動的にマッピングされます。新しい ID を生成するには Auto ID を有効にします（元の値は破棄されます）。
密ベクトルFLOAT_VECTOR次元は正確に保持され、変更は不要です
スパースベクトルSPARSE_FLOAT_VECTORサンプルデータ内で空でない場合にのみマッピングされます。
ペイロードJSON（動的フィールド）デフォルトでは動的スキーマとしてマッピングされ、固定フィールドに変換できます。
詳細については、Dynamic Field を参照してください。

ペイロードフィールドの変換​

Notes

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

Qdrant のペイロードは、最大限の柔軟性を確保するために、まず Zilliz Cloud の動的スキーマにマッピングされます。必要に応じて、ペイロードフィールドを固定フィールドに変換すると、次の利点が得られます。

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

  • より良いクエリパフォーマンスのための最適化されたインデックス作成

  • 一貫したデータ管理のための構造化されたスキーマ

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

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

配列型のサポート​

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

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> 新しいフィールドとして追加できます

固定フィールドに変換されたペイロードフィールドには、以下の追加属性を設定できます:

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

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

  • Partition Key: 必要に応じて、INT64 または VARCHAR フィールドをパーティションキーとして指定できます。各コレクションでサポートされるパーティションキーは 1つだけであり、選択したフィールドを null 許容にすることはできない点に注意してください。詳細については、Partition Key の使用 を参照してください。

Qdrant 固有の処理ルール​

コレクションの命名規則​

Qdrant のコレクション名は、以下の点を考慮して Zilliz Cloud に引き継がれます。

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