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

Qdrant から Zilliz Cloud への移行

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

インデックス設定と移行後の手順については、External Migration Basics を参照してください。

事前準備​

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

Qdrant の要件​

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

Zilliz Cloud の要件​

要件詳細
ユーザーロールOrganization Owner または Project Admin
クラスター容量十分なストレージとコンピューティングリソース（CU サイズを見積もるには CU 計算ツール を使用します）
ネットワークアクセスネットワーク制限を使用する場合は、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 の固定フィールド型備考
整数INT64型を直接変換
浮動小数点数DOUBLEすべての浮動小数点数が DOUBLE になります。
ブール値BOOL直接マッピング
キーワードVARCHAR最大 65,535 バイトをサポートします。
地理情報JSONJSON 構造として保持されます。固定フィールドには変換できません。
日時VARCHAR最大 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 attribute を参照してください。

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

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

Qdrant 固有の処理ルール​

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

Qdrant のコレクション名は、次の考慮事項を踏まえて Zilliz Cloud に転送されます。

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