PostgreSQLからZilliz Cloudへの移行

このトピックでは、Zilliz CloudがPostgreSQLからの移行時にデータ型マッピング、コレクション名付け規則、および考慮事項をどのように処理するかについて説明します。

前提条件

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

要件	詳細
ネットワークアクセス	ソースPostgreSQLデータベースがパプリックインターネットからアクセス可能であること
データベースアクセス	有効なデータベースエンドポイント、ユーザー名、および必要な権限を持つパスワード
pgvector拡張機能	ベクターのデータ保存にpgvector拡張機能を使用する必要があるテーブル
ベクターフール要件	各ソーステーブルには少なくとも1つのベクターフールが含まれており、ベクターフールにはnull値を含めることはできません。
データ可用性	ソーステーブルにはデータが含まれている必要があります。空のテーブルは移行できません。

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

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

PostgreSQLフィールド型	Zilliz Cloudフィールド型	説明
プライマリキー	プライマリキー / 自動ID	単一フィールドのプライマリキー: ターゲットコレクションのプライマリキーとして直接マッピングされます。プライマリキーがない場合: ターゲットコレクションで自動IDが有効になり、プライマリキーのないテーブルをサポートします。複合プライマリキー: 自動IDが有効になります。複合キーは通常のスカラーのフィールドとして処理されます。データを移行する際、自動IDを有効にすることもできます。ただし、その場合、ソースコレクションの元のプライマリキー値は破棄されます。
vector	FLOAT_VECTOR	ベクター次元数は変更されません。
text/varchar/date/time	VARCHAR	文字列として保存されます。
bigint	INT64	-
integer	INT32	-
smallint	INT16	-
double precision	DOUBLE	-
real	FLOAT	-
boolean	BOOL	-
array	ARRAY	-
json	JSON	-

PostgreSQLテーブル名は、以下の考慮事項でZilliz Cloudに転送されます：

シナリオ	影響	解決策
デフォルトの名前付け	コレクション名はソーステーブル名と完全に一致します	PostgreSQLからの名前がそのまま保持されます
命名競合	同じ名前のコレクションが既に存在する場合、ジョブを送信できません	既存のコレクションを削除、異なるデータベースを選択、または移行構成中に名前を変更してください
コレクション名の変更	移行中にサポートされています	移行構成プロセス中にコレクション名を変更できます

以下の機能はPostgreSQL移行ではサポートされていません：

制限	影響	代替案
動的から固定フィールドへの変換	既存の動的フィールドを固定型に変換できません	フィールドは元の動的性質を維持します
フィールドの追加	移行中に新しいフィールドを追加できません	既存のElasticsearchフィールドのみが移行されます