本ブログは、オラクル・クラウドの個人ブログの1つです。
初めに
オブジェクト・ストレージからOracle Base DB 或いは Autonomous DBへデータをロードする方法はさまざまですが、よく使われる手法を取りまとめて紹介したいと思います。
どの手段をいつ使うべきか迷っている方には、この記事が参考となり、適切な方法を選択できることを願っています。
OCIオブジェクト・ストレージを例に紹介しますが、利用方法によっては他のデータソース（AWS S3、Azure Blobなど）にも対応しています。
なお、今回はオラクルの公式製品とサービスに焦点を当てて紹介します。下記の方法以外にも多くのサードパーティー製ツールが存在しますが、選択肢が多いため割愛させていただきます。
目次
1. オブジェクト・ストレージから、データを Oracle Base DB/ADB にロード
1-1. ローカルにコピーしてから、Oracle Base DBへ
ネットワーク構成について
- Oracle Base DBインスタンスが、パブリック/プライベート・サブネットのどちらに存在してもこの方法が適用する。（下記他方法も同様）
- パブリック・サブネット：Internet GWを経由しオブジェクト・ストレージへアクセスする。
- プライベート・サブネット：NAT GWか、Service GWを経由する。
- Oracle Base DBがプライベート・サブネットに格納されるのは一般的であり、Service GWを経由し、OCI オブジェクト・ストーレジにアクセスのは、推奨です。
作業ステップ
- STEP-1. データをローカルに転送。
- OCI Object Storageからの場合：OCI CLIの利用を推奨 (最新版のOracle Base DBに実装済、前のバージョンのDBインスタンスにもインストール可能)
- AWS S3, Azure Blobからの場合：例 rcloneを利用
- STEP-2. ローカルからDBへロード （従来通りのやり方）
- 2-1) テキストファイル：例 SQL Loader
- 2-2) Data Pumpファイル：impdp
メリット
✅ ローカルにコピーした後、従来通りの方法で処理できるため、他のツールやサービスを利用する必要がない。
✅ DBMS_CLOUDと比較して、Oracle DBのバージョンに制限がない。
✅ OCI CLIはOracle Base DBに実装済で、データ転送が便利。
デメリット
- ローカルへの一時保存は必要で、ストレージの容量が少ない時、収まらない可能性がある。
1-2. オブジェクト・ストレージをローカルにマウントし、Oracle Base DBへ
作業ステップ
- STEP-1: オブジェクト・ストレージをDBインスタンスにマウントする （例：s3fs-fuseを利用）
- STEP-2: マウントポイントからデータDBへロード（従来通りのやり方）
- 2-1) テキストファイル：例 SQL Loader
- 2-2) Data Pumpファイル：impdp
メリット
✅ マウントの設定は比較的に簡単である。マウント後、従来通りのやり方と同じ。
✅ DBのバージョンに依存せず、DBMS_CLOUDプロシージャのインストールは不要。（Base DBにDBMS_CLOUDをインストールする際に、DBバージョンの制限がある）
✅ 直接にオブジェクト・ストレージからインポートするため、ローカルへの一時保存は不要。
注意点
DBインスタンス再起動後、マウント・ポイントが切れないように再マウントするか/etc/fstabを編集してください。
実施方法の詳細について、次の記事をご参照ください。
マウント・ポイントを経由して、Oracle Base DBからオブジェクト・ストレージへデータをエクスポートする手順
1-3. DBMS_CLOUD プロシージャの利用
Oracle Base DB の場合
作業ステップ
- STEP-1. Oracle Base DBに、DBMS_CLOUDプロシージャをインストールし、関連設定を実施。
- STEP-2. クレデンシャルの作成 ( DBMS_CLOUD.CREATE_CREDENTIAL )
- STEP-3. データロード
- 3-1) テキストファイル： DBMS_CLOUD.COPY_DATAを利用
- 3-2) Data Pumpファイル：
impdp User/Password credential=XXXX dumpfile= https://<Object_File_URL>
Oracle Base DBの実施例は、次のステップ・バイ・ステップの手順を提供していますので、ご参考ください。（下記記事のSTEP-1からSTEP-8までは、DBMS_CLOUDのインストールと関連設定の作業に当たる。）
オブジェクト・ストレージからOracle DB 19c/21cにデータを導入する
Autonomous DB の場合
DBMS_CLOUDプロシージャは、ADBに既に実装済で、クレデンシャルの作成から実施すればOKです。
メリット
✅ 指定した間隔で実行し、新しいデータが到着すると、すぐにソースとターゲット間の連携が可能。
✅ オブジェクト・ストレージからADBへのロードだけでなく、ADBからオブジェクト・ストレージへのエクスポートも可能。
✅ OCI Object Storage以外にも、AWS S3やAzure Blobなどのデータソースに対応しており、マルチクラウドのユーザーに適している。
デメリット
- Oracle DB の場合、DBMS_ClOUDのインストールと権限まわりの設定は必要、手順はやや複雑。
- Oracle DB のバージョン制限がある (19c, 21c のみ)。
1-4. DBMS_CLOUD_PIPELINE プロシージャを利用し、ADBへ
これは、2022年12月にリリースされたAutonomous DB の新機能です。機能の詳細は、ドキュメントをご参照ください。
作業流れ
メリット
✅ 指定間隔で実行し、新しいデータが来たら、直ぐにソースとターゲット間の連携は可能。
✅ オブジェクト・ストレージからADBへのロードだけではなく、ADBからオブジェクト・ストレージへのエクスポートも可能。
✅ OCI Object Storage以外、AWS S3, Azure Blob などのデータ・ソースも対応。マルチクラウドのユーザに向く。
利用制限
- 現在(2023年1月)、ADB特有な機能で、Oracle Base DBを対応していない。
1-5. ODI Marketplace の利用
ネットワーク構成について
- ODI MPインスタンスを作成する時、必ずVCNの指定は必要。ターゲットDBと同じVCNにするか、別々のVCNにするかどちらでもOK。
- ODI MPは、Autonomous LinuxベースのComputeインスタンスで、クライアント側からVNCツールで接続すれば、GUIが利用できる。
作業ステップ
- STEP-1. Marketplaceから、ODI インスタンスを立てる
- STEP-2. VNCツールでOCI MPに接続し、ODI Studioを起動
- STEP-3. レポジトリDBの作成 (ターゲットDBと同じでもよい)
- STEP-4. ソースとターゲットへの物理接続を立てる
- STEP-5. モデルの作成 (物理接続を論理化に)
- STEP-6. プロジェクトとマッピングの作成
- STEP-7. マッピング実行及びモニタリング
メリット
✅ OCIオブジェクト・ストレージやOracle Base DB/ADBだけでなく、多くの種類のデータソースに対応している。
✅ データ編集や複数ファイルのマージなど、複雑なデータフローを作成できる。
✅ スケジューリング実行が可能で、管理・監視機能が豊富。
✅ コスト面でのメリットがある。（Classic版は無料で使用でき、OCPUあたりのソフトウェア価格は$0.00）
デメリット
- レポジトリDBの設定は必須である。
- マッピングが実施できるまでの設定が複雑。（初心者が慣れるまでの時間を考慮する必要がある）
1-6. OCI Data Integration の利用
ネットワーク構成について
- OCI DIのワークスペースは、VCN内部か外部の2種類があり、デフォルトはVCN内部で作成する。
- VCN内部で作成する場合、オブジェクト・ストレージとDBインスタンスに接続するため、関連セキュリティ・リスト及びルート表の設定は必要である。
Egress ルールの参考例：
Object Storage 接続用： 宛先 0.0.0.0/0 TCP 443
DB 接続用： 宛先 DBのプライベートIP TCP 1521
作業ステップ
- STEP-1. OCI DI のワークスペースの作成
- STEP-2. データ・アセットの作成 （ソースとターゲット両方）
- STEP-3. プロジェクトとデータフローの作成
- STEP-4. 統合タスクとアプリケーションの作成
- STEP-5. アプリケーションへのタスクの公開
- STEP-6. タスク実行およびモニタリング
※、OCI DI ワークスペースは、機能的に ODI Studio (On-P or MP) と相当します。
Oracle DBの実施例は、次のステップ・バイ・ステップの手順をご参考ください。
OCI Data Integrationを使用しオブジェクト・ストレージからOracle DBにデータをロードする
メリット
✅ OCI マネージド サービスで、従来のODI On-P、ODI Marketplaceと比べて、使いやすくなる。（レポジトリDBの管理は不要）
✅ OCIオブジェクト・ストレージ、Oracle DB/ADBだけではなく、たくさんの種類のデータ・ソースを対応している。（対応一覧は、こちらへ）
✅ データ編集、複数ファイルのマージなど、複雑なデータフローを作成できる。
✅ スケジューリング実行は可能、管理・監視の機能は豊富。
✅ OCI DIからOCI Functionsの呼び出しも可能。
デメリット
- 他方法と比べて、サービス料金がかかる。(内訳は以下の通り)
- ワークスペース料金 (時間単位)
- データ処理料金 (時間×GB単位)
- パイプライン・オペレーターの実行料金 (時間単位)
パイプライン・オペレーターの部分はオプションです。それが発生しない前提で、毎月の概算見積もりは、次のようです。（１個ワークスペースのみ、１時間あたり１GBのデータを処理すると想定）
2. 各種方法の比較
上記各種方法のメリットとデメリットを抜粋して、一覧表を作りましたので、ご参考ください。
サマリー
- 各方法には、それぞれ適用場面と制限があります。ユーザーケースに応じて、いつどの方法を使うべきかを判断することが重要です。データ転送量、転送頻度(一時か定期か)、データ編集の必要性、データ・ソースのタイプと場所、DBバージョン、コスト面（製品・サービス価格、学習時間）などが重要な考慮事項です。
- ODI On-P版も技術的には実現可能ですが、今回のケース（ソースとターゲットの両方がクラウド上にある場合）にはベストプラクティスではないため、候補から外します。
以上です。
関連記事
オラクル・クラウドの個人ブログ一覧
オブジェクト・ストレージからOracle DB 19c/21cにデータを導入する
マウント・ポイントを経由して、データ・ポンプ・ファイルをOracle DBCSからオブジェクト・ストレージにエクスポートする
OCI Data Integrationを利用し、オブジェクト・ストレージからOracle DBにデータをロードする
ODI On-PとODI MarketplaceとOCI Data Integrationの比較
オフィシャル・リンク
OCI Data Integration サービス・ホームページ (価格表、見積もりを含める)
OCI Data Integration ドキュメント・ホームページ