PineconeからZilliz Cloudへの移行

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

前提条件

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

要件	詳細
インデックスタイプ	Pineconeサーバーレスインデックスからの移行のみサポート
APIアクセス	アクセス権限を持つPinecone APIキー
データ可用性	Pineconeからのソースインデックスにはデータが含まれている必要があります。空のインデックスは移行できません。
ベクター次元	次元は1より大きくなければなりません。1次元のベクターは移行の失敗を引き起こします

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

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

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

📘注意

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

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

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

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

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

Pineconeの名前空間は、2つの戦略で移行できます：

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

📘注意

Pineconeのdefault名前空間の処理：

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

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

Pineconeインデックス名	Zilliz Cloudコレクション名	適用されたルール
`my-vector-index`	`my_vector_index`	ハイフン（`-`）はアンダースコア（`_`）に変換されて、Zilliz Cloudコレクション名付け規則に準拠
`product_search`	`product_search`	変更は必要ありません

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