OceanBase APシナリオにおいて、データ転送はデータ移行、データインポート、データ同期、およびデータサブスクリプションを含みます。それぞれデータベースの切り替え、一括テーブル投入、継続的なデータ書き込みの整合性、変更イベントの配信に対応しています。以下では、ビジネス目標に基づいて選定ポイントをまとめ、対応するドキュメントへのリンクを示します。
データ移行
明確な時点または段階でターゲットデータベースの構築または置換を完了し、業務の読み書きをOceanBase（または新しいテナント）に切り替え、構造の整合性とデータの収束を図ります。
典型的なシナリオ：MySQL/Oracleなどの一括または段階的な置換；OceanBaseバージョンのアップグレード、クラスタの置換；TPデータベースからの移行後のAP処理；特定の時点の履歴スナップショットのみが必要で、継続的なCDCが不要な少数のオフライン移行。
関連ドキュメント：データ移行の概要、ツールを使用したデータ移行、データインポート戦略とベストプラクティス、主要APデータベースからOceanBaseへの移行に関するベストプラクティス。
データインポート
外部データをOceanBaseの内部テーブルにインポートする際、データソースはローカルファイル、オブジェクトストレージ、HDFSなどが可能です。LOAD DATA、外部テーブル、FILESテーブル関数、またはINSERT INTO ... SELECTなどの方法でインポートを実行できます。
典型的なシナリオ：履歴明細やログアーカイブの一括取り込み；CSV/ORC/ParquetなどのファイルがOSS、HDFSなどのリモートパスにある場合；超大規模テーブルや全量データをダイレクトロードでより効率的に書き込む場合；外部テーブルや
FILESを使用してレイクハウスのデータを読み取った後、内部テーブルにインポートする場合。関連ドキュメント：データインポートの概要、LOAD DATA FROM FILES、LOAD DATA INFILE、LOAD DATA LOCAL INFILE、ダイレクトロードの概要、全量ダイレクトロード、INSERT INTO SELECT FROM FILES、外部テーブルを使用したINSERT INTO SELECTによるインポート、obloaderを使用したデータインポート。
データ同期
長期間にわたり、ターゲットデータベース（通常はOceanBase）とソースデータベースの間で業務上許容可能な一貫性または遅延の上限を維持し、ツールがターゲットデータベースへの継続的な書き込みを行います。
典型的なシナリオ：同一リージョン/異リージョンの災害復旧、二台構成のホットスタンバイ；切り替え前後の短期間の二重書き込みとロールバックウィンドウ；マルチアクティブまたは読み書き分離環境におけるレプリカとプライマリデータベースの整合性。
関連ドキュメント：データ同期の概要。
データサブスクリプション
上流からデータベースログやCDCイベントを継続的に読み取り、解析後にKafka、Flinkなどに転送します。これにより、複数の下流システムがそれぞれ消費、処理、または選択的にデータベースに書き込みます。
典型的なシナリオ：Canal、Flink CDCなどのコンポーネントを使用してデータベースの変更をサブスクライブし、変更データをKafkaなどのメッセージシステムに書き込みます。これにより、リアルタイムデータウェアハウス、ストリーム処理タスク、または複数の業務システムがそれぞれ消費できます。
関連ドキュメント：データサブスクリプションの概要、データ同期の概要（OMSのデータ書き込み経路と照らし合わせて参照）、データインポート戦略とベストプラクティス。