Pinecone から Zilliz Cloud への移行

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

前提条件

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

要件	詳細
インデックスの種類	Pinecone Serverless インデックスからの移行のみサポート
API アクセス	アクセス権限を持つ Pinecone API キー
データの可用性	Pinecone のソースインデックスにはデータが含まれている必要があります。空のインデックスは移行できません。
ベクトル次元	次元は 1 より大きい必要があります。1 次元のベクトルは移行失敗の原因となります

要件	詳細
ユーザーロール	組織オーナーまたはプロジェクト管理者
クラスター容量	十分なストレージおよびコンピューティングリソース（CU サイズの見積もりには CU 計算ツールを使用してください）
ネットワークアクセス	ネットワーク制限を使用している場合は、Zilliz Cloud IPs を許可リストに追加してください

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

Pinecone フィールド型	Zilliz Cloud フィールド型	備考
プライマリキー	VARCHAR (プライマリキー)	自動的にマッピングされます。自動IDを有効にすると新しい ID が生成されます（元の値は破棄されます）。
密ベクトル	FLOAT_VECTOR	次元は正確に保持され、変更は不要です
疎ベクトル	SPARSE_FLOAT_VECTOR	サンプルデータで空でない場合のみマッピングされます。
メタデータ	動的フィールド	デフォルトで動的スキーマとしてマッピングされます。固定フィールドに変換できます。詳細については、動的フィールドを参照してください。
名前空間	パーティションキー / パーティション	パフォーマンス最適化を推奨。詳細については、名前空間の処理を参照してください。

📘Notes

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

Pinecone のメタデータは、最大限の柔軟性を得るために、最初は Zilliz Cloud の動的スキーマにマッピングされます。メタデータフィールドを固定フィールドに変換することで、以下のメリットを得ることができます。

メタデータを固定フィールドに変換する場合：

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

NULL許容: フィールドが null 値を受け入れるかどうかを決定します。この機能はデフォルトで有効になっています。詳細については、NULL許容属性を参照してください。
デフォルト値: データが欠損している場合のフォールバック値を設定します。詳細については、デフォルト値を参照してください。

Pinecone の名前空間は、2 つの戦略を使用して移行できます。

戦略	実装	パフォーマンスへの影響	ユースケース
名前空間をパーティションキーとして（推奨）	名前空間がパーティションキーフィールドの値になります	検索パフォーマンスの自動最適化	複数の名前空間を持つほとんどのシナリオ
名前空間をパーティションとして	各名前空間が個別のパーティションになります	手動のパーティション管理が必要	名前空間が少なく安定したシンプルなシナリオ

📘Notes

Pinecone の default 名前空間の処理：

パーティションおよびパーティションキーの概念の詳細については、パーティションの管理およびパーティションキーの使用を参照してください。

Pinecone のインデックス名は、Zilliz Cloud の互換性のために自動的に処理されます。

Pinecone インデックス名	Zilliz Cloud コレクション名	適用されたルール
`my-vector-index`	`my_vector_index`	ハイフン（`-`）がアンダースコア（`_`）に変換され、Zilliz Cloud のコレクション命名規則に準拠します
`product_search`	`product_search`	変更は不要です

名前の競合: ターゲットデータベースに同じ名前のコレクションが既に存在する場合、以下のいずれかを行う必要があります。