Oracle NoSQL Database Migratorの使用

Oracle NoSQL Database Migratorと、それをデータ移行に使用する方法について学習します。

Oracle NoSQL Database Migratorは、Oracle NoSQL表をあるデータソースから別のデータソースに移行できるツールです。このツールは、Oracle NoSQL Database Cloud Service、オンプレミスのOracle NoSQL DatabaseおよびAWS S3の表で操作できます。ミグレータ・ツールは、複数の異なるデータ形式と物理メディア・タイプをサポートします。サポートされているデータ形式は、JSON、Parquet、MongoDB形式のJSON、DynamoDB形式のJSONおよびCSVファイルです。サポートされている物理メディア・タイプは、ファイル、OCIオブジェクト・ストレージ、オンプレミスのOracle NoSQL Database、Oracle NoSQL Database Cloud ServiceおよびAWS S3です。

この記事には次のトピックが含まれます:

関連項目

概要

Oracle NoSQL Database Migratorを使用すると、Oracle NoSQL表をあるデータ・ソースから別のデータ・ソース(オンプレミスまたはクラウドのOracle NoSQL Database、単純なJSONファイルなど)に移動できます。

Oracle NoSQL Database間でNoSQL表を移行する必要がある状況は多数あります。 たとえば、NoSQL Databaseアプリケーションを拡張する開発者のチームは、cloudsimを使用して、ローカルのOracle NoSQL Database Cloud Service (NDCS)インスタンスで更新されたコードをテストする必要があります。考えられるすべてのテスト・ケースを検証するには、実績データと同様のテスト・データを設定する必要があります。これを行うには、NoSQL表を本番環境からローカルNDCSインスタンス(cloudsim環境)にコピーする必要があります。別の状況では、NoSQL開発者は、開発またはテストのために、アプリケーション・データをオンプレミスからクラウドに、またはその逆に移動する必要がある場合があります。

このようなすべての場合および他の多くの場合に、Oracle NoSQL Database Migratorを使用して、NoSQL表をあるデータ・ソースから別のデータ・ソース(オンプレミスまたはクラウドのOracle NoSQL Database、単純なJSONファイルなど)に移動できます。NoSQL表は、MongoDB書式のJSON入力ファイル、DynamoDB書式のJSON入力ファイル(AWS S3ソースに格納済またはファイルから格納済)またはCSVファイルからオンプレミスまたはクラウドのNoSQLデータベースにコピーすることもできます。

次の図に示すように、NoSQL Database Migratorユーティリティは、データ・ソースとターゲット(シンクと呼びます)の間のコネクタまたはパイプとして機能します。基本的に、このユーティリティは選択したソースからデータをエクスポートし、そのデータをシンクにインポートします。このツールは表指向です。つまり、表レベルでのみデータを移動できます。単一の移行タスクは単一の表で動作し、様々なデータ形式でソースからシンクへの表データの移行をサポートします。

Oracle NoSQL Database Migratorは、将来、追加のソースおよびシンクをサポートできるように設計されています。現在のリリースでOracle NoSQL Database Migratorによってサポートされているソースとシンクのリストは、「サポートされるソースとシンク」を参照してください。

migrator_overview.epsの説明が続きます
図migrator_overview.epsの説明

Oracle NoSQL Database Migratorで使用される用語

前述の図で使用されている様々な用語について詳しく説明します。

  • ソース: NoSQL表を移行用にエクスポートするエンティティ。ソースの例は、オンプレミスまたはクラウドのOracle NoSQL Database、JSONファイル、MongoDB形式のJSONファイル、DynamoDB形式のJSONファイルおよびCSVファイルです。
  • シンク: NoSQLデータベース・マイグレータからNoSQL表をインポートするエンティティ。シンクの例は、オンプレミスまたはクラウドのOracle NoSQL Database、JSONファイルです。

NoSQL Database Migratorツールは、様々なタイプのソースとシンク(物理メディアまたはデータのリポジトリ)およびデータ形式(データがソースまたはシンクで表現される方法)をサポートしています。サポートされているデータ形式は、JSON、Parquet、MongoDB形式のJSON、DynamoDB形式のJSONおよびCSVファイルです。サポートされているソースおよびシンク・タイプは、ファイル、OCIオブジェクト・ストレージ、オンプレミスのOracle NoSQL DatabaseおよびOracle NoSQL Database Cloud Serviceです。

  • 移行パイプ:ソースのデータは、NoSQL Database Migratorによってシンクに転送されます。これは移行パイプとして視覚化できます。
  • 変換:ルールを追加して、移行パイプ内のNoSQL表データを変更できます。これらのルールは変換と呼ばれます。Oracle NoSQL Database Migratorでは、最上位のフィールドまたは列でのみデータ変換が可能です。ネストされたフィールドのデータは変換できません。許可される変換の例を次に示します。
    • 1つ以上の列を削除または無視します。
    • 1つ以上の列の名前を変更します。
    • 複数の列を単一のフィールド(通常はJSONフィールド)に集計します。
  • 構成ファイル:構成ファイルは、移行アクティビティに必要なすべてのパラメータをJSON形式で定義する場所です。あとで、この構成ファイルを CLIから runMigratorコマンドに1つのパラメータとして渡します。一般的な構成ファイルの形式は次のようになります。
    {
 "source": {
   "type" : <source type>,
   //source-configuration for type. See Source Configuration Templates  .
 },
 "sink": {
   "type" : <sink type>,
   //sink-configuration for type. See Sink Configuration Templates  .
 },
 "transforms" : {
   //transforms configuration. See Transformation Configuration Templates  .
 },
 "migratorVersion" : "<migrator version>",
 "abortOnError" : <true|false>
}
    グループ Parameters 必須(Y/N) 目 的 サポートされる値
    source type はい データの移行元のソースを表します。ソースは、移行用のデータおよびメタデータ(存在する場合)。 各ソースのtype値の詳細は、サポートされるソースとシンクを参照してください。
    source タイプのソース構成 はい ソースの構成を定義します。これらの構成パラメータは、前に選択したソースのタイプに固有です。 各ソース・タイプの構成パラメータの一覧は、ソース構成テンプレートを参照してください。
    sink type はい データの移行先のシンクを表します。シンクは、移行のターゲットまたは宛先です。 各ソースのtype値の詳細は、サポートされるソースとシンクを参照してください。
    sink タイプのシンク構成 はい シンクの構成を定義します。これらの構成パラメータは、前に選択したシンクのタイプに固有です。 シンク・タイプごとの構成パラメータの一覧は、Sink Configuration Templates を参照してください。
    transforms 変換構成 N 移行パイプ内のデータに適用する変換を定義します。 NoSQLデータ・マイグレータでサポートされている変換の一覧は、変換構成テンプレート を参照してください。
    - migratorVersion N NoSQLデータ・マイグレータのバージョン -
    - abortOnError N

    エラーの場合に移行アクティビティを停止するかどうかを指定します。

    デフォルト値はtrueで、移行エラーが発生するたびに移行が停止することを示します。

    この値をfalseに設定すると、失敗したレコードやその他の移行エラーが発生した場合でも移行が続行されます。失敗したレコードおよび移行エラーは、CLI端末に警告として記録されます。

    		true、false

    ノート:

    JSONファイルでは大/小文字が区別されるため、特に指定されていないかぎり、構成ファイルに定義されているすべてのパラメータで大文字小文字が区別されます。

サポートされているソースとシンク

このトピックでは、Oracle NoSQL Database Migratorでサポートされるソースとシンクのリストを示します。

移行アクティビティには、この表の有効なソースとシンクの組合せを使用できます。ただし、少なくとも一方の端、つまりソースまたはシンクがOracle NoSQL製品である必要があります。NoSQLデータベース・マイグレータを使用して、NoSQL表データを別のファイルに移動することはできません。

タイプ
(値)

フォーマット
(値)

有効なソース 有効なシンク

Oracle NoSQL Database
(nosqldb)

NA はい はい

Oracle NoSQL Database Cloud Service
(nosqldb_cloud)

NA はい はい

ファイル・システム
(file)

JSON
(json)

はい はい

MongoDB JSON
(mongodb_json)

はい N

DynamoDB JSON
(dynamodb_json)

はい N

パーケット(parquet)

N はい

CSV
(csv)

はい N

OCIオブジェクト・ストレージ
(object_storage_oci)

JSON
(json)

はい はい

MongoDB JSON
(mongodb_json)

はい N

パーケット(parquet)

N はい

CSV
(csv)

はい N
AWS S3

DynamoDB JSON
(dynamodb_json)

はい N

ノート:

ソースとシンクの構成では、多くの構成パラメータが共通しています。簡単に参照できるように、このようなパラメータの説明は、ドキュメントの項内のソースおよびシンクごとに繰り返されます。これらの項では、様々なタイプのソースやシンクの構成ファイル形式について説明します。いずれの場合も、同じ名前のパラメータの構文とセマンティクスは同じです。

ソースおよびシンク・セキュリティ

ソースおよびシンクの一部には、認証のためにオプションまたは必須のセキュリティ情報が含まれています。

Oracle Cloud Infrastructure (OCI)のサービスを使用するすべてのソースおよびシンクは、特定のパラメータを使用してオプションのセキュリティ情報を提供できます。この情報は、OCI構成ファイルまたはInstance Principalを使用して指定できます。

インストールがセキュアで、Oracle Walletベースの認証を使用する場合は、Oracle NoSQL Databaseのソースとシンクに必須のセキュリティ情報が必要です。<MIGRATOR_HOME>/libディレクトリにjarファイルを追加することで、この情報を提供できます。

Walletベースの認証

Oracle NoSQL DatabaseインストールでOracle Walletベースの認証を使用する場合は、EEインストールの一部である追加のjarファイルを含める必要があります。詳細は、Oracle Walletに関する項を参照してください。

jarファイルがない場合は、次のエラー・メッセージが表示されます。

libディレクトリにkvstore-ee.jarおよびkvstore-ee-<version>.jarが見つかりませんでした。kvstore-ee.jarおよびkvstore-ee-<version>.jarをlibディレクトリにコピーします。

前述の例外を回避するには、EEサーバー・パッケージから<MIGRATOR_HOME>/libディレクトリにkvstore-ee.jarおよびkvstore-ee-<version>.jarファイルをコピーする必要があります。<MIGRATOR_HOME>は、Oracle NoSQL Database Migratorパッケージを抽出して作成されたnosql-migrator-M.N.O/ディレクトリであり、M.N.Oはソフトウェアのrelease.major.minor番号を表します。たとえば、nosql-migrator-1.1.0/libです。

ノート:

ウォレット・ベースの認証は、Oracle NoSQL DatabaseのEnterprise Edition (EE)のみでサポートされています。

Instance Principalsを使用した認証

インスタンス・プリンシパルは、IAMサービス機能です。これにより、インスタンスは、サービス・リソースに対するアクションを実行できる認可済アクター(またはプリンシパル)になります。各コンピュート・インスタンスは、自身のアイデンティティを持ち、追加された証明書を使用して認証します。

Oracle NoSQL Database Migratorには、NoSQLクラウドおよびOCIオブジェクト・ストレージのソースに接続し、インスタンス・プリンシパル認証を使用するシンクに接続するオプションがあります。これは、OCIでホストされたVMで実行されているNoSQL Database Migratorツールなど、OCIコンピュート・インスタンス内でのみサポートされます。 この機能を有効にするには、NoSQLクラウド・ソースおよびシンク構成ファイルのuseInstancePrincipal属性を使用します。様々なタイプのソースおよびシンクの構成パラメータの詳細は、ソース構成テンプレート およびシンク構成テンプレート を参照してください。

インスタンス・プリンタの詳細は、インスタンスからのサービスのコールに関する項を参照してください。

Oracle NoSQL Database Migratorのワークフロー

Oracle NoSQL Database Migratorユーティリティを使用してNoSQLデータを移行するための様々なステップについて学習します。

次の図に、NoSQL Database Migratorの使用に関連するタスクの高レベル・フローを示します。


migrator_flow.epsの説明が続きます
図migrator_flow.epsの説明

NoSQLデータ・マイグレータ・ユーティリティのダウンロード

Oracle NoSQL Database Migratorユーティリティは、Oracle NoSQLのダウンロード・ページからダウンロードできます。マシンにダウンロードして展開すると、コマンドライン・インタフェースからrunMigratorコマンドにアクセスできます。

ノート:

Oracle NoSQL Database Migratorユーティリティを実行するには、Java 11以降のバージョンが必要です。

ソースとシンクの指定

マイグレータを使用する前に、データ・ソースとシンクを指定する必要があります。たとえば、オンプレミスのOracle NoSQL DatabaseからJSON形式のファイルにNoSQL表を移行する場合、ソースはOracle NoSQL Databaseになり、シンクはJSONファイルになります。「サポートされているソースとシンク」を参照して、指定したソースとシンクがOracle NoSQL Database Migratorでサポートされていることを確認します。これは、ターゲットまたはシンクのNoSQL表のスキーマを決定して作成するための適切なフェーズでもあります。
  • シンク表スキーマの指定:シンクがオンプレミスまたはクラウドのOracle NoSQL Databaseの場合は、シンク表のスキーマを指定し、ソース・データがターゲット・スキーマと一致することを確認する必要があります。必要に応じて、変換を使用してソース・データをシンク表にマップします。
    • デフォルト・スキーマ: NoSQL Database Migratorには、表のスキーマを事前定義する必要はありません。これは、主にOracle NoSQL DatabaseにJSONソース・ファイルをロードする場合に役立ちます。
      ソースがMongoDB形式のJSONファイルの場合、表のデフォルト・スキーマは次のようになります。
      CREATE TABLE IF NOT EXISTS <tablename>(ID STRING, DOCUMENT JSON,PRIMARY KEY(SHARD(ID))

      説明:

      - タブ名= 構成のtable属性に指定された値。

      - ID = mongoDBでエクスポートされた各JSONソース・ファイルの_id値。

      - DOCUMENT = mongoDBでエクスポートされたファイル内のドキュメントごとに、_idフィールドを除く内容がDOCUMENT列に集計されます。

      ソースがDynamoDB形式のJSONファイルの場合、表のデフォルト・スキーマは次のようになります。
      CREATE TABLE IF NOT EXISTS <TABLE_NAME>(DDBPartitionKey_name DDBPartitionKey_type, 
[DDBSortKey_name DDBSortKey_type],DOCUMENT JSON,
PRIMARY KEY(SHARD(DDBPartitionKey_name),[DDBSortKey_name]))

      説明:

      - TABLE_NAME = 構成内のシンク表に指定された値

      - DDBPartitionKey_name = 構成のパーティション・キーに指定された値

      - DDBPartitionKey_type = 構成内のパーティション・キーのデータ型に指定された値

      - DDBSortKey_name = 構成のソート・キーに指定された値(ある場合)

      - DDBSortKey_type = 構成内のソート・キーのデータ型に指定された値(ある場合)

      - DOCUMENT = NoSQL JSON列に集計されたDynamo DB表アイテムのパーティションおよびソート・キーを除くすべての属性

      ソース形式がCSVファイルの場合、ターゲット表ではデフォルトのスキーマはサポートされていません。ソースCSVファイルと同じ数の列とデータ型を含む表定義を作成できます。スキーマ・ファイルの作成の詳細は、「表スキーマの提供」を参照してください。

      その他すべてのソースでは、デフォルト・スキーマは次のようになります。
      CREATE TABLE IF NOT EXISTS <tablename> (ID LONG GENERATED ALWAYS AS IDENTITY, DOCUMENT JSON, PRIMARY KEY(ID))

      説明:

      - タブ名= 構成のtable属性に指定された値。

      - ID = 自動生成されたLONG値。

      - DOCUMENT = ソースによって提供されるJSONレコードがDOCUMENT列に集計されます。

      ノート:

      MongoDB形式のJSONファイルで_id値が文字列として指定されていない場合、NoSQL Database Migratorは、デフォルト・スキーマに挿入する前に値を文字列に変換します。
  • 表スキーマの提供: NoSQL Database Migratorでは、ソースはschemaInfo属性を使用して表データのスキーマ定義を提供できます。schemaInfo属性は、暗黙的スキーマがまだ定義されていないすべてのデータ・ソースで使用できます。シンク・データ・ストアでは、次のオプションのいずれかを選択できます。
    • NoSQL Database Migratorで定義されたデフォルトのスキーマを使用します。
    • ソース提供スキーマを使用します。
    • 独自のスキーマを定義して、ソース提供のスキーマをオーバーライドします。たとえば、ソース・スキーマから別のスキーマにデータを変換する場合は、ソース提供のスキーマをオーバーライドし、NoSQL Database Migratorツールの変換機能を使用する必要があります。

    source_sink_schema_example.pngの説明が続きます
    図source_sink_schema_example.pngの説明

    たとえば、表スキーマ・ファイルmytable_schema.DDLには、表DDL文を含めることができます。NoSQL Database Migratorツールは、移行を開始する前にこの表スキーマ・ファイルを実行します。マイグレータ・ツールでは、スキーマ・ファイルの1行に1つのDDL文のみをサポートします。例
    CREATE TABLE IF NOT EXISTS(id INTEGER, name STRING, age INTEGER, PRIMARY KEY(SHARD(ID)))

    ノート:

    表がシンクに存在し、schemaPathのDDLが表と異なる場合、移行が失敗します。
  • シンク表の作成:シンク表スキーマの指定後は、管理CLIまたはシンク構成ファイルのschemaInfo属性を使用してシンク表を作成します。Sink Configuration Templates を参照してください。

    ノート:

    ソースがCSVファイルの場合は、ターゲット表のスキーマに対するDDLコマンドを使用してファイルを作成します。シンク構成ファイルのschemaInfo.schemaPathパラメータにファイル・パスを指定します。

runMigratorコマンドの実行

runMigrator実行可能ファイルは、抽出されたNoSQL Database Migratorファイルで使用できます。Java 11以上のバージョンおよびbashをシステムにインストールして、runMigratorコマンドを正常に実行する必要があります。

次の2つの方法で、runMigratorコマンドを実行できます。
  1. 次のように、runMigratorコマンドのランタイム・オプションを使用して構成ファイルを作成します。 
    [~]$ ./runMigrator
configuration file is not provided. Do you want to generate configuration? (y/n)                                                                              
 
[n]: y
...
...
    • runMigratorユーティリティを起動すると、一連の実行時オプションが提供されて、各オプションの選択内容に基づいて構成ファイルが作成されます。
    • ユーティリティによって構成ファイルが作成された後は、同じ実行で移行アクティビティを続行するか、将来の移行のために構成ファイルを保存できます。
    • 生成された構成ファイルでの移行アクティビティの続行または延期に関係なく、将来の要件を満たすようにファイルを編集またはカスタマイズできます。カスタマイズした構成ファイルは、後で移行に使用できます。
  2. -cまたは --configオプションを使用して、手動で作成した構成ファイル(JSON形式)を実行時パラメータとして渡します。-cまたは --configオプションを付けて runMigratorコマンドを実行する前に、構成ファイルを手動で作成する必要があります。ソースおよびシンク構成パラメータのヘルプは、Oracle NoSQL Databaseマイグレータ・リファレンスを参照してください。
    [~]$ ./runMigrator -c </path/to/the/configuration/json/file>

ノート:

NoSQL Database Migratorは、Oracle NoSQL Cloud Service表から任意の有効なシンクへのデータ・エクスポートの実行中に読取りユニットを消費します。

ミグレータの進捗状況のロギング

NoSQL Database Migratorツールには、トレース、デバッグおよび進行状況のメッセージを標準出力またはファイルに出力できるオプションが用意されています。このオプションは、特に大規模な表またはデータ・セットで、移行操作の進捗状況を追跡するために役立ちます。

  • ログ・レベル

    NoSQL Database Migratorツールを使用してロギング動作を制御するには、--log-levelまたは-l run timeパラメータをrunMigratorコマンドに渡します。書き込むログ情報の量を指定するには、適切なログ・レベルの値を渡します。 

    $./runMigrator --log-level <loglevel>
    次に例を示します:
    $./runMigrator --log-level debug

    表- NoSQL Database Migratorでサポートされるログ・レベル

    ログ・レベル 説明
    警告 エラーおよび警告を出力します。
    情報(デフォルト) ソースの検証、シンクの検証、表の作成、移行されたデータ・レコードの数など、データ移行の進捗状況ステータスを出力します。
    debug 追加のデバッグ情報を出力します。
    すべて すべてを出力します。このレベルはロギングのすべてのレベルをオンにします。
  • ログ・ファイル:
    --log-fileまたは-fパラメータを使用して、ログ・ファイルの名前を指定できます。--log-fileがランタイム・パラメータとしてrunMigratorコマンドに渡された場合、NoSQL Database Migratorはすべてのログ・メッセージをファイルに、それ以外の場合は標準出力に書き込みます。
    $./runMigrator --log-file <log file name>
    次に例を示します:
    $./runMigrator --log-file nosql_migrator.log

制限事項

Oracle NoSQL Database Migratorは、バックアップ中にデータベースをロックせず、他のユーザーをブロックします。そのため、移行タスクの実行時には、次のアクティビティを実行しないことを強くお薦めします。

  • ソース表に対するDML/DDL操作。
  • データ・ストアに対するトポロジ関連の変更。

表の行のTTLメタデータの移行

ソースからシンクにTTLデータを移行する方法を学習します。

Time to Live (TTL)は、表の行を自動的に期限切れにできるメカニズムです。TTLは、ストアにデータが存在できる時間で表されます。有効期限タイムアウト値に達したデータは取得できなくなり、ストア統計にも表示されません。

Oracle NoSQL Database表の移行の実行時に、表の行のTTLメタデータを実際のデータとともに含めるように選択できます。NoSQLデータベース・ミグレータには、次のソース・タイプの表行のTTLメタデータのエクスポートおよびインポートをサポートする構成パラメータが用意されています。

表- TTLメタデータの移行

ソース・タイプ ソース構成パラメータ シンク構成パラメータ
Oracle NoSQL Database includeTTL includeTTL
Oracle NoSQL Database Cloud Service includeTTL includeTTL
DynamoDB形式のJSONファイル ttlAttributeName includeTTL
DynamoDB-AWS S3に格納されたJSONファイル ttlAttributeName includeTTL

Oracle NoSQL DatabaseおよびOracle NoSQL Database Cloud ServiceでのTTLメタデータのエクスポート

NoSQL Database Migratorには、表の行のTTLメタデータのエクスポートをサポートするincludeTTL構成パラメータが用意されています。

テーブルがエクスポートされると、有効な有効期限を持つテーブル行のTTLデータがエクスポートされます。行が失効しない場合、_metadata JSONオブジェクトは、有効期限値は常に0であるため、エクスポートされたデータに明示的に含まれません。NoSQLデータベース・マイグレータは、各行の有効期限を、UNIXエポック(1970年1月1日)以降のミリ秒数としてエクスポートします。例
//Row 1
{
    "id" : 1,
    "name" : "xyz",
    "age" : 45,
    "_metadata" : {
        "expiration" : 1629709200000   //Row Expiration time in milliseconds
    }
}

//Row 2
{
    "id" : 2,
    "name" : "abc",
    "age" : 52,
    "_metadata" : {
        "expiration" : 1629709400000   //Row Expiration time in milliseconds
    }
}

//Row 3 No Metadata for below row as it will not expire
{
    "id" : 3,
    "name" : "def",
    "age" : 15
}

TTLメタデータのインポート

オプションで、シンク構成テンプレートのincludeTTL構成パラメータを使用してTTLメタデータをインポートできます。

インポート操作のデフォルトの参照時間は、NoSQLデータベース・マイグレータ・ツールが実行されているマシンのSystem.currentTimeMillis()から取得された現在の時間(ミリ秒)です。ただし、有効期限を延長し、それ以外の場合はすぐに期限切れになる行をインポートする場合は、ttlRelativeDate構成パラメータを使用してカスタム参照時間を設定することもできます。拡張は次のように計算され、有効期限に追加されます。 

Extended time = expiration time - reference time

インポート操作では、TTLメタデータを含む表の行を移行するときに、次のユースケースが処理されます。これらのユースケースは、includeTTL構成パラメータがtrueに設定されている場合にのみ適用されます。

  • ユースケース1: インポートする表の行にTTLメタデータ情報がありません。

    インポートする行にTTL情報が含まれていない場合、NoSQLデータベース・マイグレータは行のTTL=0を設定します。

  • ユースケース2: ソース表の行のTTL値は、表の行がインポートされる参照時間と比較して失効します。

    失効した表の行は無視され、ストアに書き込まれません。

  • ユースケース3: ソース表の行のTTL値は、表の行がインポートされる参照時間と比較して失効していません。

    表の行はTTL値でインポートされます。ただし、インポートされたTTL値は、TimeToLiveクラスの整数時間および日ウィンドウ制約のため、元のエクスポートされたTTL値と一致しない場合があります。例

    エクスポートされた表の行について考えてみます。
    {
  "id" : 8,
  "name" : "xyz",
  "_metadata" : {
  "expiration" : 1734566400000 //Thursday, December 19, 2024 12:00:00 AM in UTC
  }
}

    インポート中の参照時間は1734480000000で、これは2024年12月18日水曜日午前12:00:00です。

    インポートされた表の行
    {
  "id" : 8,
  "name" : "xyz",
  "_metadata" : {
    "ttl" :  1734739200000 //Saturday, December 21, 2024 12:00:00 AM
  }
}

DynamoDB形式のJSONファイルでのTTLメタデータのインポート、およびAWS S3に格納されているDynamoDB形式のJSONファイル

NoSQL Database Migratorには、DynamoDB形式のJSONファイル・アイテムからのTTLメタデータのインポートをサポートする追加の構成パラメータttlAttributeNameが用意されています。

DynamoDBエクスポートされたJSONファイルには、TTL有効期限タイムスタンプを格納するための特定の属性が各アイテムに含まれます。To optionally import the TTL values from DynamoDB exported JSON files, you must supply the specific attribute's name as a value to the ttlAttributeName configuration parameter in the DynamoDB-Formatted JSON File or DynamoDB-Formatted JSON File stored in AWS S3 source configuration files. また、シンク構成テンプレートでincludeTTL構成パラメータを設定する必要があります。有効なシンクは、Oracle NoSQL DatabaseおよびOracle NoSQL Database Cloud Serviceです。NoSQL Database Migratorは、インポートされたアイテムの_metadata JSONオブジェクトにTTL情報を格納します。

インポート操作では、エクスポートされたDynamoDB JSONファイルの表項目を移行するときに、次のユースケースが管理されます。

  • ユースケース1: ttlAttributeName構成パラメータ値は、エクスポートされたDynamoDB JSONファイルで指定されたTTL属性名に設定されます。

    NoSQL Database Migratorは、このアイテムの有効期限をUNIXエポック(1970年1月1日)からのミリ秒数としてインポートします。

    たとえば、エクスポートされたDynamoDB JSONファイルの項目について考えてみます。
    {
    "Item": {
        "DeptId": {
            "N": "1"
        },
        "DeptName": {
            "S": "Engineering"
        },
        "ttl": {
            "N": "1734616800"
        }
    }
}
    ここで、属性ttlは、アイテムの存続時間の値を指定します。ttlAttributeName構成パラメータをttlとしてDynamoDB形式のJSONファイルまたはAWS S3ソース構成ファイルに格納されているDynamoDB形式のJSONファイルに設定すると、NoSQL Database Migratorによってアイテムの有効期限が次のようにインポートされます。
    {
  "DeptId": 1,
  "document": {
      "DeptName": "Engineering"
    }  
  "_metadata": {
    "expiration": 1734616800000
  }
}

    ノート:

    失効時間を計算するための参照時間として、シンク構成テンプレートにttlRelativeDate構成パラメータを指定できます。
  • ユースケース2: ttlAttributeName構成パラメータ値が設定されていますが、この値は、エクスポートされたDynamoDB JSONファイルの項目に属性として存在しません。

    NoSQLデータベース・マイグレータは、指定されたアイテムのTTLメタデータ情報をインポートしません。

  • ユースケース3: ttlAttributeName構成パラメータ値が、エクスポートされたDynamoDB JSONファイルの項目の属性名と一致しません。
    NoSQL Database Migratorは、シンク構成に基づいて次のいずれかの方法でインポートを処理します。
    • デフォルト・スキーマを使用してインポートするように構成されている場合、属性を標準フィールドとしてコピーします。
    • ユーザー定義スキーマを使用してインポートするように構成されている場合は、属性をスキップします。

IDENTITY列を含むシンクへのデータのインポート

IDENTITY列を含むシンクにデータをインポートする方法を学習します。

有効なソースのデータをIDENTITY列を含むシンク表(オンプレミス/クラウド・サービス)にインポートできます。IDENTITY列は、GENERATED ALWAYS AS IDENTITYまたはGENERATED BY DEFAULT AS IDENTITYのいずれかとして作成します。IDENTITY列を含む表の作成の詳細は、SQLリファレンス・ガイドのIDENTITY列を含む表の作成を参照してください。

データをインポートする前に、シンクのOracle NoSQL Database表(存在する場合)が空であることを確認してください。シンク表に既存のデータがある場合、移行によって、シンク表の既存のデータの上書きやインポート中のソース・データのスキップなどの問題が発生する可能性があります。

IDENTITY列がGENERATED ALWAYS AS IDENTITYであるシンク表

IDENTITY列がGENERATED ALWAYS AS IDENTITYとして作成されたシンク表について考えます。データ・インポートは、ソースが構成ファイルのIDENTITY列およびignoreFields変換パラメータに値を指定するかどうかによって異なります。

たとえば、JSONファイル・ソースのデータをシンクとしてのOracle NoSQL Database表にインポートします。シンク表のスキーマは次のとおりです: 

CREATE TABLE IF NOT EXISTS migrateID(ID INTEGER GENERATED ALWAYS AS IDENTITY, name STRING, course STRING, PRIMARY KEY
      (ID))
ミグレータ・ユーティリティは、次のケースで説明するようにデータ移行を処理します:
ソース条件 ユーザー処理 移行結果

ケース1: ソース・データでシンク表のIDENTITYフィールドの値が指定されていません。

例: JSONソース・ファイルsample_noID.JSON

{"name":"John", "course":"Computer Science"}
{"name":"Jane", "course":"BioTechnology"}
{"name":"Tony", "course":"Electronics"}

構成ファイルを作成/生成します。

データ移行に成功しました。IDENTITY列の値は自動生成されます。Oracle NoSQL Databaseシンク表migrateIDにデータを移行しました: 

{"ID":1001,"name":"Jane","course":"BioTechnology"}
{"ID":1003,"name":"John","course":"Computer Science"}
{"ID":1002,"name":"Tony","course":"Electronics"}

ケース2: ソース・データで、シンク表のIDENTITYフィールドに値が指定されます。

例: JSONソース・ファイルsampleID.JSON

{"ID":1, "name":"John", "course":"Computer Science"}
{"ID":2, "name":"Jane", "course":"BioTechnology"}
{"ID":3, "name":"Tony", "course":"Electronics"}

構成ファイルを作成/生成します。シンク構成テンプレートのID列にignoreFields変換を指定します。

"transforms" : { "ignoreFields" : ["ID"] }

データ移行に成功しました。指定されたID値はスキップされ、IDENTITY列の値は自動生成されます。

Oracle NoSQL Databaseシンク表migrateIDにデータを移行しました:
{"ID":2003,"name":"John","course":"Computer Science"}
{"ID":2002,"name":"Tony","course":"Electronics"}
{"ID":2001,"name":"Jane","course":"BioTechnology"}

IDENTITY列のignoreFields変換なしで、構成ファイルを作成/生成します。

データ移行は次のエラー・メッセージで失敗します:

"Cannot set value for a generated always identity column".

トランスフォーメーション・コンフィギュレーション・パラメータの詳細は、「トランスフォーメーション・コンフィギュレーション・テンプレート」のトピックを参照してください。

IDENTITY列がGENERATED BY DEFAULT AS IDENTITYであるシンク表

IDENTITY列がGENERATED BY DEFAULT AS IDENTITYとして作成されたシンク表について考えます。データ・インポートは、ソースがIDENTITY列およびignoreFields変換パラメータに値を指定するかどうかによって異なります。

たとえば、JSONファイル・ソースのデータをシンクとしてのOracle NoSQL Database表にインポートします。シンク表のスキーマは次のとおりです: 

CREATE TABLE IF NOT EXISTS migrateID(ID INTEGER GENERATED BY DEFAULT AS IDENTITY, name STRING, course STRING, PRIMARY KEY
      (ID))
ミグレータ・ユーティリティは、次のケースで説明するようにデータ移行を処理します:
ソース条件 ユーザー処理 移行結果

ケース1: ソース・データでシンク表のIDENTITYフィールドの値が指定されていません。

例: JSONソース・ファイルsample_noID.JSON

{"name":"John", "course":"Computer Science"}
{"name":"Jane", "course":"BioTechnology"}
{"name":"Tony", "course":"Electronics"}

構成ファイルを作成/生成します。
データ移行に成功しました。IDENTITY列の値は自動生成されます。Oracle NoSQL Databaseシンク表migrateIDにデータを移行しました:
{"ID":1,"name":"John","course":"Computer Science"}
{"ID":2,"name":"Jane","course":"BioTechnology"}
{"ID":3,"name":"Tony","course":"Electronics"}

ケース2: ソース・データがシンク表のIDENTITYフィールドに値を提供し、これが主キー・フィールドです。

例: JSONソース・ファイルsampleID.JSON

{"ID":1, "name":"John", "course":"Computer Science"}
{"ID":2, "name":"Jane", "course":"BioTechnology"}
{"ID":3, "name":"Tony", "course":"Electronics"}

構成ファイルを作成/生成します。シンク構成テンプレート(推奨)のID列にignoreFields変換を指定します。

"transforms" : { "ignoreFields" : ["ID"] }

データ移行に成功しました。指定されたID値はスキップされ、IDENTITY列の値は自動生成されます。

Oracle NoSQL Databaseシンク表migrateIDにデータを移行しました:
{"ID":1002,"name":"John","course":"Computer Science"}
{"ID":1001,"name":"Jane","course":"BioTechnology"}
{"ID":1003,"name":"Tony","course":"Electronics"}

IDENTITY列のignoreFields変換なしで、構成ファイルを作成/生成します。

データ移行に成功しました。ソースから指定されたID値は、シンク表のID列にコピーされます。

ID値を指定せずに表に追加行を挿入しようとすると、順序ジェネレータがID値の自動生成しようとします。シーケンス・ジェネレータの開始値は1です。その結果、生成されたID値がシンク表内の既存のID値のいずれかを複製する可能性があります。これは主キー制約違反であるため、エラーが返され、行は挿入されません。

詳細は、順序ジェネレータを参照してください。

主キー制約違反を回避するために、順序ジェネレータは、シンク表の既存のID値と競合しない値で順序を開始する必要があります。START WITH属性を使用してこの変更を行うには、次の例を参照してください:

例: Oracle NoSQL Databaseシンク表migrateIDにデータを移行しました:
{"ID":1,"name":"John","course":"Computer Science"}
{"ID":2,"name":"Jane","course":"BioTechnology"}
{"ID":3,"name":"Tony","course":"Electronics"}
順序ジェネレータがID列に挿入する適切な値を検索するには、次の問合せを使用してIDフィールドの最大値をフェッチします:
SELECT max(ID) FROM migrateID
出力: 
{"Column_1":3}
シンク表のID列の最大値は3です。複製を避けるために、順序ジェネレータで3を超えるID値の生成を開始する必要があります。次の文を使用して、順序ジェネレータのSTART WITH属性を4に更新します:
ALTER Table migrateID (MODIFY ID GENERATED BY DEFAULT AS IDENTITY (START WITH 4))

これにより、順序は4から開始されます。

これで、ID値を指定せずにシンク表に行を挿入すると、順序ジェネレータによってID値が4以降から自動生成され、IDの重複が回避されるようになります。

トランスフォーメーション・コンフィギュレーション・パラメータの詳細は、「トランスフォーメーション・コンフィギュレーション・テンプレート」のトピックを参照してください。

問合せ述語を使用したデータのフィルタ処理

問合せ述語を指定して、フィルタ基準に一致する表の行のみをエクスポートする方法を学習します。

問合せ述語

NoSQL Database Migratorには、問合せ述語を指定して、エクスポート中にデータをフィルタ処理するオプションがあります。問合せ述語は、行がエクスポートされるために満たす必要がある条件を指定します。Migratorユーティリティは、問合せ述語をSQL WHERE句に変換し、指定された表に適用して、指定された条件に一致する行のみをエクスポートするフィルタ条件を提供します。問合せ述語で組込み関数(modification_time()、expiration_time()、creation_time())を使用して、拡張フィルタ・オプションを作成できます。

問合せ述語は、サポートされているすべてのシンクについて、Oracle NoSQL DatabaseおよびOracle NoSQL Database Cloud Serviceソースでのみ使用できます。詳細は、Oracle NoSQL DatabaseおよびOracle NoSQL Database Cloud Serviceを参照してください。

ユース・ケースのデモンストレーションについては、Oracle NoSQL Database Cloud ServiceからJSONファイルへの移行を参照してください。

ダンプ・フィルタ

Migratorユーティリティには、バックエンドで実行されるSQL問合せをエコーするオプションがあります。この機能により、生成された問合せを検証し、必要に応じて、移行タスクを実行する前にフィルタを絞り込むことができます。

Migratorユーティリティは、次のようにダンプ・フィルタ・オプションを使用して実行できます。
[~/nosqlMigrator]$./runMigrator --dump-filter|df [optional-config-file]
  • 構成ファイルの使用: Migratorユーティリティでは、次の例に示すように、指定された構成ファイルと生成された問合せが表示されます。
    [~/nosqlMigrator]./runMigrator --dump-filter migrator-config.json
    [INFO] Configuration for migration:
{
  "source" : {
    "type" : "nosqldb",
    "storeName" : "kvstore",
    "helperHosts" : ["<hostname>:5000"],
    "table" : "users",
    "queryFilter" : "$row.address.city='Houston'",
    "includeTTL" : true,
    "requestTimeoutMs" : 5000
  },
  "sink" : {
    "type" : "file",
    "format" : "json",
    "useMultiFiles" : false,
    "schemaPath" : "<complete/path/to/the/JSON/file/with/DDL/commands/for/the/schema/definition>",
    "pretty" : true,
    "dataPath" : "<complete/path/to/directory>"
  },
  "abortOnError" : true,
  "migratorVersion" : "1.8.0"
}
[INFO] Query for the migration: 'select $row, expiration_time($row) from users $row where $row.address.city='Houston''
  • 構成ファイルなし: Migratorユーティリティは、問合せ述語を含む構成ファイルの生成に必要なすべての入力を対話形式で収集します。次に、生成された構成ファイルおよび問合せが表示されます。

ノート:

ダンプ・フィルタ・オプションでは、構成ファイルと問合せのみが表示されます。データ移行は開始されません。確認後、移行を実行するには、次のように--cまたは--configオプションを使用して、構成ファイルでMigratorユーティリティを実行します。
$./runMigrator --config <complete/path/to/the/JSON/config/file>

Oracle NoSQL Database Migratorのユースケース・デモ

特定のユースケースでOracle NoSQL Database Migratorを使用してデータ移行を実行する方法を学習します。移行を実行するためのコード例を含む詳細な体系的手順は、各ユースケースにあります。

この記事には次のトピックが含まれます:

Oracle NoSQL Database Cloud ServiceからJSONファイルへの移行

この例では、Oracle NoSQL Database Migratorを使用して、Oracle NoSQL Database Cloud Service (NDCS)からNoSQL表のデータおよびスキーマ定義をJSONファイルにコピーする方法を示します。

ユースケース

組織は、Oracle NoSQL Database Cloud Service (NDCS)データを使用してモデルをトレーニングし、将来の行動を予測し、パーソナライズされた推奨を提供することを決定します。NDCS表のデータの定期的なコピーをJSONファイルに取得し、分析エンジンに適用してモデルを分析およびトレーニングできます。これは、分析問合せを低遅延のクリティカル・パスから分離するのに役立ちます。

例

デモンストレーションでは、myTableというNoSQL表のデータおよびスキーマ定義をNDCSからJSONファイルに移行する方法について説明します。
前提条件
  • 移行するソースとシンクを指定します。
    • ソース: Oracle NoSQL Database Cloud Service
    • シンク: JSONファイル
  • OCIクラウド資格証明を指定し、OCI構成ファイルで取得します。構成ファイルを/home/.oci/configに保存します。資格証明の取得を参照してください。
    [DEFAULT]
tenancy=ocid1.tenancy.oc1....
user=ocid1.user.oc1....
fingerprint= 43:d1:....
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=<passphrase>
  • Oracle NoSQL Database Cloud Serviceのリージョン・エンドポイントおよびコンパートメント名を指定します。
    • エンドポイント: us-ashburn-1
    • コンパートメント: ocid1.compartment.oc1..aa..rhsmq
手順
表のデータおよびスキーマ定義をOracle NoSQL Database Cloud ServiceからJSONファイルに移行するには、次のいずれかのオプションを使用できます:
  1. コマンド・プロンプトを開き、NoSQL Database Migratorユーティリティを抽出したディレクトリに移動します。
  2. NoSQL Database Migratorを使用して構成ファイルを生成するには、ランタイム・パラメータを指定せずにrunMigratorコマンドを実行します。
    [~/nosqlMigrator]$./runMigrator
  3. ランタイム・パラメータとして構成ファイルを指定しなかったため、構成を今すぐ生成するかどうかを尋ねるプロンプトが表示されます。「y」と入力します。
    Configuration file is not provided. Do you want to generate
configuration? (y/n) [n]: y

Generating a configuration file interactively.
  4. ユーティリティのプロンプトに基づいて、ソース構成のオプションを選択します。
    Enter a location for your config [./migrator-config.json]: /home/<user>/nosqlMigrator/NDCS2JSON
Select the source: 
1) nosqldb
2) nosqldb_cloud
3) file
4) object_storage_oci
5) aws_s3
#? 2

Configuration for source type=nosqldb_cloud
Enter endpoint URL or region ID of the Oracle NoSQL Database Cloud: us-phoenix-1
Select the authentication type: 
1) credentials_file
2) instance_principal
3) delegation_token
4) session_token
5) oke_workload_identity
#? 1
Enter path to the file containing OCI credentials [/home/<user>/.oci/config]:
Enter the profile name in OCI credentials file [DEFAULT]: 
Enter the compartment name or id of the table []: developers
Enter table name: myTable
Include TTL data? If you select 'yes' TTL of rows will also 
be included in the exported data.(y/n) [n]: 
Enter percentage of table read units to be used for migration operation. (1-100) [90]:
Enter store operation timeout in milliseconds. (1-30000) [5000]:
  5. ユーティリティのプロンプトに基づいて、シンク構成のオプションを選択します。
    Select the sink:
1) nosqldb
2) nosqldb_cloud
3) file
#? 3
Configuration for sink type=file
Enter path to a directory to store JSON data: /home/<user>/nosqlMigrator
would you like to export data to multiple files for each source?(y/n) [y]: n
Would you like to store JSON in pretty format? (y/n) [n]: y
Would you like to migrate the table schema also? (y/n) [y]: y
Enter path to a file to store table schema: /home/<user>/nosqlMigrator/myTableSchema
  6. ユーティリティのプロンプトに基づいて、ソース・データ変換のオプションを選択します。デフォルト値はnです。
    Would you like to add transformations to source data? (y/n) [n]:
  7. レコードの移行に失敗した場合に移行を続行するかどうかを決定するための選択肢を入力します。
    Would you like to continue migration in case of any record/row is failed to migrate?: (y/n) [n]:
  8. 生成された構成が画面に表示されます。
    generated configuration is:
{
  "source": {
    "type": "nosqldb_cloud",
    "endpoint": "us-ashburn-1",
    "table": "myTable",
    "compartment": "ocid1.compartment.oc1..aa..rhsmq",
    "credentials": "/home/<user>/.oci/config",
    "credentialsProfile": "DEFAULT",
    "readUnitsPercent": 90,
    "requestTimeoutMs": 5000
  },
  "sink": {
    "type": "file",
    "format": "json",
    "useMultiFiles" : false,
    "schemaPath": "/home/<user>/nosqlMigrator/myTableSchema",
    "pretty": true,
    "dataPath": "/home/<user>/nosqlMigrator"
  },
  "abortOnError": true,
  "migratorVersion": "1.7.0"
}
  9. 最後に、生成された構成ファイルで移行を続行するかどうかを決定するように求められます。デフォルト・オプションはyです。

    ノート:

    nを選択すると、生成された構成ファイルを使用して、./runMigrator -cまたは./runMigrator --configオプションを使用して移行を実行できます。 
    would you like to run the migration with above configuration?
If you select no, you can use the generated configuration file to run the migration using
./runMigrator --config /home/<user>/nosqlMigrator/NDCS2JSON
(y/n) [y]:
  10. NoSQL Database Migratorによって、NDCSからJSONファイルにデータおよびスキーマが移行されます。
    Records provided by source=10,Records written to sink=10,Records failed=0,Records skipped=0.
Elapsed time: 0min 1sec 277ms
Migration completed.
検証

移行を検証するには、指定したシンク・ディレクトリに移動し、スキーマおよびデータを表示できます。 

-- Exported myTable Data. JSON files are created in the supplied data path
 
[~/nosqlMigrator]$cat myTable_1_5.json
{
  "id" : 10,
  "document" : {
    "course" : "Computer Science",
    "name" : "Neena",
    "studentid" : 105
  }
}
{
  "id" : 3,
  "document" : {
  "course" : "Computer Science",
    "name" : "John",
    "studentid" : 107
  }
}
{
  "id" : 4,
  "document" : {
    "course" : "Computer Science",
    "name" : "Ruby",
    "studentid" : 100
  }
}
{
  "id" : 6,
  "document" : {
    "course" : "Bio-Technology",
    "name" : "Rekha",
    "studentid" : 104
  }
}
{
  "id" : 7,
  "document" : {
    "course" : "Computer Science",
    "name" : "Ruby",
    "studentid" : 100
  }
}
{
  "id" : 5,
  "document" : {
    "course" : "Journalism",
    "name" : "Rani",
    "studentid" : 106
  }
}
{
  "id" : 8,
  "document" : {
    "course" : "Computer Science",
    "name" : "Tom",
    "studentid" : 103
  }
}
{
  "id" : 9,
  "document" : {
    "course" : "Computer Science",
    "name" : "Peter",
    "studentid" : 109
  }
}
{
  "id" : 1,
  "document" : {
    "course" : "Journalism",
    "name" : "Tracy",
    "studentid" : 110
  }
}
{
  "id" : 2,
  "document" : {
    "course" : "Bio-Technology",
    "name" : "Raja",
    "studentid" : 108
  }
}
-- Exported myTable Schema
 
[~/nosqlMigrator]$cat myTableSchema
CREATE TABLE IF NOT EXISTS myTable (id INTEGER, document JSON, PRIMARY KEY(SHARD(id)))

  1. Oracle NoSQL Database Cloud Service (NDCS)ソースおよびJSONシンクの詳細を使用して、構成ファイル(JSON形式)を準備します。ソース構成テンプレート およびシンク構成テンプレート を参照してください。

    users表は、この例の次のデータとともに使用されます。
    {"id":10,"firstName":"John","lastName":"Smith","age":22,"income":45000,"address":{"city":"Santa Cruz","number":101,"phones":[{"area":408,"kind":"work","number":4538955},{"area":831,"kind":"home","number":7533341},{"area":831,"kind":"mobile","number":7533382}],"state":"CA","street":"Pacific Ave","zip":95008}}
{"id":20,"firstName":"Jane","lastName":"Smith","age":22,"income":55000,"address":{"city":"San Jose","number":201,"phones":[{"area":608,"kind":"work","number":6538955},{"area":931,"kind":"home","number":9533341},{"area":931,"kind":"mobile","number":9533382}],"state":"CA","street":"Atlantic Ave","zip":95005}}
{"id":30,"firstName":"Adam","lastName":"Smith","age":45,"income":75000,"address":{"city":"Houston","number":301,"phones":[{"area":618,"kind":"work","number":6618955},{"area":951,"kind":"home","number":9613341},{"area":981,"kind":"mobile","number":9613382}],"state":"TX","street":"Indian Ave","zip":95075}}
{"id":40,"firstName":"Joanna","lastName":"Smith","age":null,"income":75000,"address":{"city":"Houston","number":401,"phones":[{"area":null,"kind":"work","number":1618955},{"area":451,"kind":"home","number":4613341},{"area":481,"kind":"mobile","number":4613382}],"state":"TX","street":"Tex Ave","zip":95085}}

    必要な行のみを表からエクスポートするには、ソース構成テンプレートに適切な問合せ述語を含むqueryFilterパラメータを含めてください。問合せ述語の作成方法の詳細は、NoSQL Database Cloudサービス・ソースのトピックのサンプル問合せ述語の表を参照してください。

    この例では、問合せ述語によって、users表からaddress JSON列= 'Houston'のcityフィールドを持つ行がエクスポートされます。 

    {
  "source" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "users",
    "queryFilter" : "$row.address.city='Houston'",
    "compartment" : "ocid1.compartment.oc1..aa..rhsmq",
    "credentials" : "/home/<user>/.oci/config",
    "credentialsProfile" : "DEFAULT",
    "readUnitsPercent" : 90,
    "includeTTL" : true,
    "requestTimeoutMs" : 5000
  },
  "sink" : {
    "type" : "file",
    "format" : "json",
    "useMultiFiles" : true,
    "chunkSize" : 32,
    "schemaPath" : "/scratch/<user>/nosqlMigrator/tableschema.ddl",
    "pretty" : false,
    "dataPath" : "/scratch/<user>/nosqlMigrator"
  },
  "abortOnError" : true,
  "migratorVersion" : "1.7.0"
}
  2. コマンド・プロンプトを開き、NoSQLデータベース・マイグレータ・ユーティリティを抽出したディレクトリに移動します。
  3. 構成ファイルを渡して、runMigratorコマンドを実行します。--configまたは -cオプションを使用します。
    [~/nosqlMigrator]$./runMigrator --config <complete/path/to/the/JSON/config/file>

    ノート:

    --dump-filter|dfオプションを指定してコマンドを実行すると、次のように、生成された問合せを表示および検証してから移行タスクを実行することもできます。詳細は、Dump Filterを参照してください。
    [~/nosqlMigrator]$./runMigrator --dump-filter <complete/path/to/the/JSON/config/file>
    次のように、ユーティリティはデータの移行に進みます。
    [INFO] creating source from given configuration:
[INFO] [cloud source] : query = 'SELECT $row,expiration_time_millis($row) AS expiration FROM users $row where $row.address.city='Houston''
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] [json file sink] : writing table schema to /scratch/raumesh/nosqlMigrator/tableschema.ddl
[INFO] migration started
[INFO] Migration success for source users. read=2,written=2,failed=0
[INFO] Migration is successful for all the sources.
[INFO] migration completed.
Records provided by source=2, Records written to sink=2, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 182ms
Migration completed.

検証

移行を確認するには、指定したシンク・ディレクトリに移動し、スキーマとデータを表示できます。cityフィールド値が'Houston'のaddress JSON列の行のみがエクスポートされます。
-- Exported users data. Schema and JSON files are created in the supplied data paths. 

[~/nosqlMigrator]: cat tableschema.ddl 

CREATE TABLE IF NOT EXISTS users (id INTEGER, firstName STRING, lastName STRING, age INTEGER, income INTEGER, address JSON, PRIMARY KEY(SHARD(id)))

[~/nosqlMigrator]: cat users_6_10.json

{"id":30,"firstName":"Adam","lastName":"Smith","age":45,"income":75000,"address":{"city":"Houston","number":301,"phones":[{"area":618,"kind":"work","number":6618955},{"area":951,"kind":"home","number":9613341},{"area":981,"kind":"mobile","number":9613382}],"state":"TX","street":"Indian Ave","zip":95075}}
{"id":40,"firstName":"Joanna","lastName":"Smith","age":null,"income":75000,"address":{"city":"Houston","number":401,"phones":[{"area":null,"kind":"work","number":1618955},{"area":451,"kind":"home","number":4613341},{"area":481,"kind":"mobile","number":4613382}],"state":"TX","street":"Tex Ave","zip":95085}}
bash-4.4$

オンプレミスのOracle NoSQL DatabaseからOracle NoSQL Database Cloud Serviceへの移行

この例では、Oracle NoSQL Database Migratorを使用して、データおよびNoSQL表のスキーマ定義をOracle NoSQL DatabaseからOracle NoSQL Database Cloud Service (NDCS)にコピーする方法を示します。

ユースケース

開発者は、既存のNoSQLデータベースKVStoreワークロードのリソース、クラスタおよびガベージ・コレクションの管理のオーバーヘッドを回避するためのオプションを調べています。解決策として、NDCSによって既存のオンプレミスのKVStoreワークロードが自動的に管理されるため、これらをOracle NoSQL Database Cloud Serviceに移行することにします。

例

デモでは、myTableというNoSQL表のデータおよびスキーマ定義をNoSQLデータベースKVStoreからNDCSに移行する方法について説明します。また、このユースケースを使用して、事前作成済の構成ファイルを渡してrunMigratorユーティリティの実行方法を示します。
前提条件
  • 移行するソースとシンクを指定します。
    • ソース: Oracle NoSQL Database
    • シンク: Oracle NoSQL Database Cloud Service
  • OCIクラウド資格証明を指定し、OCI構成ファイルで取得します。構成ファイルを/home/.oci/configに保存します。Oracle NoSQL Database Cloud Serviceの使用の資格証明の取得を参照してください。
    [DEFAULT]
tenancy=ocid1.tenancy.oc1....
user=ocid1.user.oc1....
fingerprint= 43:d1:....
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=<passphrase>
  • Oracle NoSQL Database Cloud Serviceのリージョン・エンドポイントおよびコンパートメント名を指定します。
    • エンドポイント: us-phoenix-1
    • コンパートメント: developers
  • オンプレミスKVStoreの次の詳細を指定します。
    • storeName: kvstore
    • helperHosts: <hostname>:5000
    • 表: myTable
手順
myTableのデータおよびスキーマ定義をNoSQLデータベースKVStoreからNDCSに移行するには:
  1. 識別されたソースおよびシンクの詳細を含む構成ファイル(JSON形式)を準備します。ソース構成テンプレート およびリンク構成テンプレートを参照してください。
    {
  "source" : {
    "type" : "nosqldb",
    "storeName" : "kvstore",
    "helperHosts" : ["<hostname>:5000"],
    "table" : "myTable",
    "requestTimeoutMs" : 5000
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-phoenix-1",
    "table" : "myTable",
    "compartment" : "developers",
    "schemaInfo" : {
      "schemaPath" : "<complete/path/to/the/JSON/file/with/DDL/commands/for/the/schema/definition>",
      "readUnits" : 100,
      "writeUnits" : 100,
      "storageSize" : 1
    },
    "credentials" : "<complete/path/to/oci/config/file>",
    "credentialsProfile" : "DEFAULT",
    "writeUnitsPercent" : 90,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.7.0"
}
  2. コマンド・プロンプトを開き、NoSQL Database Migratorユーティリティを抽出したディレクトリに移動します。
  3. --configまたは -cオプションを使用して構成ファイルを渡し、runMigratorコマンドを実行します。
    [~/nosqlMigrator/nosql-migrator-1.7.0]$./runMigrator --config <complete/path/to/the/JSON/config/file>
  4. 次に示すように、ユーティリティはデータの移行に進みます。
    Records provided by source=10, Records written to sink=10, Records failed=0.
Elapsed time: 0min 10sec 426ms
Migration completed.
検証

移行を検証するには、NDCSコンソールにログインし、ソース・データを使用してmyTableが作成されていることを確認します。

JSONファイル・ソースからOracle NoSQL Database Cloud Serviceへの移行

この例では、Oracle NoSQL Database Migratorを使用して、JSONファイル・ソースからOracle NoSQL Database Cloud Serviceにデータをコピーする方法を示します。

複数のオプションを評価した後、組織はOracle NoSQL Database Cloud ServiceをNoSQLデータベース・プラットフォームとして最終決定します。ソース・コンテンツはJSONファイル形式であるため、Oracle NoSQL Database Cloud Serviceに移行する方法を探しています。

この例では、SampleData.JSONというJSONファイルからのデータの移行について学習します。runMigratorユーティリティは、事前作成済の構成ファイルを渡して実行します。構成ファイルがランタイム・パラメータとして指定されていない場合、runMigratorユーティリティでは、対話型プロシージャを使用して構成を生成するように求められます。

前提条件
  • 移行するソースとシンクを指定します。
    • ソース: JSONソース・ファイル。
      SampleData.jsonはソース・ファイルです。1行に1つのドキュメントがあり、改行文字で区切られた複数のJSONドキュメントが含まれています。
      {"id":6,"val_json":{"array":["q","r","s"],"date":"2023-02-04T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-03-04T02:38:57.520Z","numfield":30,"strfield":"foo54"},{"datefield":"2023-02-04T02:38:57.520Z","numfield":56,"strfield":"bar23"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}}
{"id":3,"val_json":{"array":["g","h","i"],"date":"2023-02-02T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-02-02T02:38:57.520Z","numfield":28,"strfield":"foo3"},{"datefield":"2023-02-02T02:38:57.520Z","numfield":38,"strfield":"bar"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}}
{"id":7,"val_json":{"array":["a","b","c"],"date":"2023-02-20T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-01-20T02:38:57.520Z","numfield":28,"strfield":"foo"},{"datefield":"2023-01-22T02:38:57.520Z","numfield":38,"strfield":"bar"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}}
{"id":4,"val_json":{"array":["j","k","l"],"date":"2023-02-03T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-02-03T02:38:57.520Z","numfield":28,"strfield":"foo"},{"datefield":"2023-02-03T02:38:57.520Z","numfield":38,"strfield":"bar"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}}
    • シンク: Oracle NoSQL Database Cloud Service
  • OCIクラウド資格証明を指定し、構成ファイルで取得します。構成ファイルを/home/user/.oci/configに保存します。詳細は、Oracle NoSQL Database Cloud Serviceの使用の資格証明の取得を参照してください。
    [DEFAULT]
tenancy=ocid1.tenancy.oc1....
user=ocid1.user.oc1....
fingerprint= 43:d1:....
region=us-ashburn-1
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=<passphrase>
  • Oracle NoSQL Database Cloud Serviceのリージョン・エンドポイントおよびコンパートメント名を指定します。
    • エンドポイント: us-ashburn-1
    • コンパートメント: Training-NoSQL
  • JSONソース・ファイルの次の詳細を特定します。

    • schemaPath: <absolute path to the schema definition file containing DDL statements for the NoSQL table at the sink>.

      この例では、DDLファイルはschema_json.DDLです。
      create table Migrate_JSON (id INTEGER, val_json JSON, PRIMARY
    KEY(id));

      Oracle NoSQL Database Migratorには、schemaPathが指定されていない場合、デフォルト・スキーマを使用して表を作成するオプションがあります。詳細は、Oracle NoSQL Database Migratorのワークフローのソースとシンクの識別のトピックを参照してください。

    • データパス: <absolute path to a file or directory containing the JSON data for migration>。
手順
SampleData.JSONからOracle NoSQL Database Cloud ServiceにJSONソース・ファイルを移行するには、次を実行します。
  1. 識別されたソースおよびシンクの詳細を含む構成ファイル(JSON形式)を準備します。ソース構成テンプレート およびSink Configuration Templates を参照してください。
    {
  "source" : {
    "type" : "file",
    "format" : "json",
    "schemaInfo" : {
      "schemaPath" : "[~/nosql-migrator-1.7.0]/schema_json.ddl"
    },
    "dataPath" : "[~/nosql-migrator-1.7.0]/SampleData.json"
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "Migrate_JSON",
    "compartment" : "Training-NoSQL",
    "includeTTL" : false,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "useSourceSchema" : true
    },
    "credentials" : "/home/user/.oci/config",
    "credentialsProfile" : "DEFAULT",
    "writeUnitsPercent" : 90,
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.7.0"
}
  2. コマンド・プロンプトを開き、Oracle NoSQL Database Migratorユーティリティを抽出したディレクトリに移動します。
  3. --configまたは -cオプションを使用して構成ファイルを渡し、runMigratorコマンドを実行します。
    [~/nosql-migrator-1.7.0]$./runMigrator --config <complete/path/to/the/config/file>
  4. 次に示すように、ユーティリティはデータの移行に進みます。Migrate_JSON表は、schemaPathに指定されたスキーマでシンクに作成されます。
    creating source from given configuration:
source creation completed
creating sink from given configuration:
sink creation completed
creating migrator pipeline
migration started
[cloud sink] : start loading DDLs
[cloud sink] : executing DDL: create table Migrate_JSON (id INTEGER, val_json JSON, PRIMARY KEY(id)),limits: [100, 60, 1]
[cloud sink] : completed loading DDLs
[cloud sink] : start loading records
[json file source] : start parsing JSON records from file: SampleData.json
[INFO] migration completed.
Records provided by source=4, Records written to sink=4, Records failed=0, Records skipped=0.
Elapsed time: 0min 5sec 778ms
Migration completed.
検証
移行を検証するには、Oracle NoSQL Database Cloud Serviceコンソールにログインし、ソース・データでMigrate_JSON表が作成されていることを確認します。コンソールにアクセスする手順は、Oracle NoSQL Database Cloud Serviceドキュメントのインフラストラクチャ・コンソールからのサービスへのアクセスを参照してください。

図- Oracle NoSQL Database Cloud Serviceコンソールの表


図の説明が続きます
「図- Oracle NoSQL Database Cloud Serviceコンソールの表」の説明

図- Oracle NoSQL Database Cloud Serviceコンソールの表データ


図の説明が続きます
「図- Oracle NoSQL Database Cloud Serviceコンソールの表データ」の説明

MongoDB JSONファイルからOracle NoSQL Database Cloud Serviceへの移行

この例では、Oracle NoSQL Database Migratorを使用して、MongoDB形式のデータをOracle NoSQL Database Cloud Service (NDCS)にコピーする方法を示します。

ユースケース

複数のオプションを評価した後、組織はOracle NoSQL Database Cloud ServiceをNoSQLデータベース・プラットフォームとして最終決定します。表とデータはMongoDBにあり、組織は両方をOracle NDCSに移行しようとしています。

MongoDBでエクスポートされた移行用のJSONデータを含むファイルまたはディレクトリは、ソース構成テンプレートでファイルまたはディレクトリを指定することでコピーできます。

ユースケースを示すために、MongoDBからエクスポートされた次の2つのサンプルJSONファイルを検討します。

MongoDB形式のJSONファイルのサンプルを次に示します:
{"_id":0,"name":"Aimee Zank","scores":[{"score":1.463179736705023,"type":"exam"},{"score":11.78273309957772,"type":"quiz"},{"score":35.8740349954354,"type":"homework"}]}
{"_id":1,"name":"Aurelia Menendez","scores":[{"score":60.06045071030959,"type":"exam"},{"score":52.79790691903873,"type":"quiz"},{"score":71.76133439165544,"type":"homework"}]}
{"_id":2,"name":"Corliss Zuk","scores":[{"score":67.03077096065002,"type":"exam"},{"score":6.301851677835235,"type":"quiz"},{"score":66.28344683278382,"type":"homework"}]}
{"_id":3,"name":"Bao Ziglar","scores":[{"score":71.64343899778332,"type":"exam"},{"score":24.80221293650313,"type":"quiz"},{"score":42.26147058804812,"type":"homework"}]}
{"_id":4,"name":"Zachary Langlais","scores":[{"score":78.68385091304332,"type":"exam"},{"score":90.2963101368042,"type":"quiz"},{"score":34.41620148042529,"type":"homework"}]}
SpringアプリケーションからエクスポートされるMongoDB形式のJSONファイルのサンプルを次に示します。
{"_id":{"$oid":"63d3a87cf564fc21dac3838d"},"firstName":"John","lastName":"Smith","address":{"Country":"France"},"_class":"com.example.demo.Customer"}
{"_id":{"$oid":"63d3a87cf564fc21dac3838e"},"firstName":"Sam","lastName":"David","address":{"Country":"USA"},"_class":"com.example.demo.Customer"}
{"_id":"3","firstName":"Dona","lastName":"William","address":{"Country":"England"},"_class":"com.example.demo.Customer"}

MongoDBは、標準モード および緩和モードの2種類のファイルのJSON形式に対する拡張をサポートしています。mongoexportツールを使用して正規モードで生成されるMongoDB形式のJSONファイルまたは緩和モードで指定できます。NoSQL Database Migratorでは、両方のモードがサポートされています。

MongoDB Extended JSON (v2)ファイルの詳細は、mongoexport_formatsを参照してください。

MongoDB形式のJSONファイルの生成の詳細は、mongoexportを参照してください。

例

デモでは、MongoDB形式のJSONファイルをNDCSに移行する方法について説明します。この例では、手動で作成した構成ファイルを使用します。
前提条件
  • 移行するソースとシンクを指定します。
    • ソース: MongoDB形式のJSONファイル
    • シンク: Oracle NoSQL Database Cloud Service
  • mongoexportユーティリティを使用して、MongoDBからデータを抽出します。詳細は、mongoexportを参照してください。
  • OCIクラウド資格証明を指定し、OCI構成ファイルで取得します。構成ファイルを/home/<user>/.oci/configディレクトリに保存します。詳細は、「資格証明の取得」を参照してください。
    [DEFAULT]
tenancy=ocid1.tenancy.oc1....
user=ocid1.user.oc1....
fingerprint= 43:d1:....
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=<passphrase>
  • Oracle NoSQL Database Cloud Serviceのリージョン・エンドポイントおよびコンパートメント名を指定します。
    • エンドポイント: us-ashburn-1
    • コンパートメント: ocid1.compartment.oc1..aaaaaaaaadeskhnnfkenws4k2vdyklcc32hfpzzz4z3zum3ubhmpz6zxnoza
手順

MongoDB形式のJSONデータをOracle NoSQL Database Cloud Serviceに移行するには、次のいずれかのオプションを選択できます。

  1. 識別されたソースおよびシンクの詳細を含む構成ファイル(JSON形式)を準備します。ソース構成テンプレート およびシンク構成テンプレート を参照してください。

    ここでは、defaultSchema構成パラメータをtrueに設定します。したがって、NoSQL Database Migratorは、シンクにデフォルト・スキーマを持つ表を作成します。
    {
  "source" : {
    "type" : "file",
    "format" : "mongodb_json",
    "dataPath" : "<complete/path/to/the/MongoDB/Formatted/JSON/file>"
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "mongoImport",
    "compartment" : "ocid1.compartment.oc1..aaaaaaaaadeskhnnfkenws4k2vdyklcc32hfpzzz4z3zum3ubhmpz6zxnoza",

    "includeTTL" : false,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "defaultSchema" : true
    },
    "credentials" : "<complete/path/to/the/oci/config/file>",
    "credentialsProfile" : "DEFAULT",
    "writeUnitsPercent" : 90,
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.7.0"
}
    MongoDB形式のJSONファイル・ソースのデフォルト・スキーマは次のとおりです。 
    CREATE TABLE IF NOT EXISTS <tablename>(id STRING, document JSON,PRIMARY KEY(SHARD(id));
    説明:
    • tablename = 構成のtable属性に指定された値。
    • id = MongoDBでエクスポートされたJSONソース・ファイルの各ドキュメントの_id値。
    • document = MongoDBでエクスポートされたファイル内のドキュメントごとに、 _idフィールドを除く内容がdocument列に集計されます。

    ノート:

    <tablename>表がOracle NoSQL Database Cloud Serviceにすでに存在し、defaultSchema構成を使用して表にデータを移行する場合は、既存の表に小文字(ID)のID列があり、タイプがSTRINGであることを確認する必要があります。

  2. コマンド・プロンプトを開き、NoSQL Database Migratorユーティリティを抽出したディレクトリに移動します。

  3. 構成ファイルを渡して、runMigratorコマンドを実行します。--configまたは -cオプションを使用します。
    $./runMigrator --config <complete/path/to/the/JSON/config/file>
  4. 次に示すように、ユーティリティはデータの移行に進みます。
    [INFO] creating source from given configuration:
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] [cloud sink] : start loading DDLs
[INFO] [cloud sink] : executing DDL: CREATE TABLE IF NOT EXISTS mongoImport (id STRING, document JSON, PRIMARY KEY(SHARD(id))),limits: [100, 60, 1]
[INFO] [cloud sink] : completed loading DDLs
[INFO] migration started
[INFO] [mongo file source] : start parsing MongoDB JSON records from file: mongoDBSample.json
[INFO] Migration success for source mongoDBSample. read=5,written=5,failed=0
[INFO] Migration is successful for all the sources.
[INFO] migration completed.
Records provided by source=5, Records written to sink=5, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 448ms
Migration completed.

検証

移行を確認するために、Oracle NoSQL Database Cloud Serviceコンソールにログインし、ソース・データでmongoImport表が作成されていることを確認します。コンソールにアクセスする手順は、インフラストラクチャ・コンソールからサービスへのアクセスの記事を参照してください。

  1. 識別されたソースおよびシンクの詳細を含む構成ファイル(JSON形式)を準備します。ソース構成テンプレート およびシンク構成テンプレート を参照してください。

    ここでは、シンク表のDDL文を含むファイルを、ソース構成テンプレートのschemaPathパラメータで指定します。それに応じて、シンク構成テンプレートでuseSourceSchema構成パラメータをtrueに設定します。

    カスタム・スキーマは、次のように生成できます。

    • MongoDB形式のJSONデータからの各列の名前とデータ型に注意してください。この情報を使用して、Oracle NoSQL Database Cloud Service表のスキーマDDLファイルを作成します。
    • スキーマ・ファイルで、最初の列(主キー)にSTRING型のidという名前を付けます。MongoDB形式のJSONファイルに記録されている列と同じ名前とタイプを含めます。
    • スキーマ・ファイルを保存し、完全なパスを書き留めます。
    この例では、次のユーザー定義スキーマが使用されています。 
    CREATE TABLE IF NOT EXISTS sampleMongoDBImp (id STRING, name STRING, scores JSON, PRIMARY KEY(SHARD(id)));
    表の作成時に_id列をidに変換するようにNoSQL Database Migratorに指示するrenameFields変換を含める必要があります。パラメータの詳細は、「変換構成テンプレート」を参照してください。NoSQL Database Migratorは、シンクにカスタム・スキーマを含む表を作成します。
    {
  "source" : {
    "type" : "file",
    "format" : "mongodb_json",
    "schemaInfo" : {
      "schemaPath" : "<complete/path/to/the/schema/file>"
    },
    "dataPath" : "<complete/path/to/the/MongoDB/Formatted/JSON/file>"
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "sampleMongoDBImp",
    "compartment" : "ocid1.compartment.oc1..aaaaaaaaadeskhnnfkenws4k2vdyklcc32hfpzzz4z3zum3ubhmpz6zxnoza",
    "includeTTL" : true,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "useSourceSchema" : true
    },
    "credentials" : "<complete/path/to/the/oci/config/file>",
    "credentialsProfile" : "DEFAULT",
    "writeUnitsPercent" : 90,
    "overwrite" : false,
    "requestTimeoutMs" : 5000
  },
  "transforms": {
    "renameFields" : {
      "_id":"id"
    }
  },
  "abortOnError" : true,
  "migratorVersion" : "1.7.0"
}

  2. コマンド・プロンプトを開き、NoSQL Database Migratorユーティリティを抽出したディレクトリに移動します。

  3. 構成ファイルを渡して、runMigratorコマンドを実行します。--configまたは -cオプションを使用します。
    $./runMigrator --config <complete/path/to/the/JSON/config/file>
  4. 次に示すように、ユーティリティはデータの移行に進みます。
    [INFO] creating source from given configuration:
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] [cloud sink] : start loading DDLs
[INFO] [cloud sink] : executing DDL: CREATE TABLE IF NOT EXISTS sampleMongoDBImp (id INTEGER, name STRING, scores JSON, PRIMARY KEY(SHARD(id))),limits: [100, 60, 1]
[INFO] [cloud sink] : completed loading DDLs
[INFO] migration started
[INFO] [mongo file source] : start parsing MongoDB JSON records from file: mongoDBSample.json
[INFO] Migration success for source mongoDBSample. read=5,written=5,failed=0
[INFO] Migration is successful for all the sources.
[INFO] migration completed.
Records provided by source=5, Records written to sink=5, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 438ms
Migration completed.

検証

移行を確認するために、Oracle NoSQL Database Cloud Serviceコンソールにログインし、ソース・データでsampleMongoDBImp表が作成されていることを確認します。コンソールにアクセスする手順は、インフラストラクチャ・コンソールからサービスへのアクセスの記事を参照してください。

  1. このユースケースでは、SpringアプリケーションからエクスポートされたサンプルMongoDB形式のJSONファイルをソースとして使用します。この形式の詳細は、Spring Dataを参照してください。

  2. 識別されたソースおよびシンクの詳細を含む構成ファイル(JSON形式)を準備します。ソース構成テンプレート およびシンク構成テンプレート を参照してください。

    ここでは、シンク表のDDL文を含むファイルを、ソース構成テンプレートのschemaPathパラメータで指定します。それに応じて、シンク構成テンプレートでuseSourceSchema構成パラメータをtrueに設定します。

    カスタム・スキーマは、次のように生成できます。

    • MongoDB形式のJSONデータからの各列の名前とデータ型に注意してください。
    • スキーマ・ファイルで、最初の列(主キー)にSTRING型のidという名前を付けます。残りのフィールドを、Springデータ形式に準拠して、JSON型のkv_json_という名前のフィールドに集計します。詳細は、Springデータ・フレームワークの永続性モデルを参照してください。
    • スキーマ・ファイルを保存し、完全なパスを書き留めます。
    この例では、次のユーザー定義スキーマが使用されます。 
    CREATE TABLE IF NOT EXISTS sampleMongoDBSpringImp(id STRING, kv_json_ JSON, PRIMARY KEY(SHARD(id)))
    前述のSpringデータ・サンプルでは、次の変換を含める必要があります。
    • _id列をidに変換するためのrenameFields変換
    • _class列を無視し、シンク表に含めないignoreFields変換
    • 残りのフィールド(id以外)をJSON型のフィールドに集計するaggregateFields変換
    パラメータの詳細は、「変換構成テンプレート」を参照してください。NoSQL Database Migratorは、シンクにカスタム・スキーマを含む表を作成します。
    {
  "source": {
    "type": "file",
    "format": "mongodb_json",
    "schemaInfo": {
      "schemaPath": "<complete/path/to/the/schema/file>"
    },
    "dataPath": "<complete/path/to/the/MongoDB/Formatted/JSON/file>"
  },
  "sink": {
    "type": "nosqldb_cloud",
    "endpoint": "us-ashburn-1",
    "table": "sampleMongoDBSpringImp",
    "compartment": "ocid1.compartment.oc1..aaaaaaaaadeskhnnfkenws4k2vdyklcc32hfpzzz4z3zum3ubhmpz6zxnoza",
    "includeTTL": true,
    "schemaInfo": {
      "readUnits": 100,
      "writeUnits": 60,
      "storageSize": 1,
      "useSourceSchema": true
    },
    "credentials": "<complete/path/to/the/oci/config/file>",
    "credentialsProfile": "DEFAULT",
    "writeUnitsPercent": 90,
    "overwrite": false,
    "requestTimeoutMs": 5000
  },
  "transforms": {
    "renameFields": {
      "_id": "id"
    },
    "ignoreFields": ["_class"],
    "aggregateFields": {
      "fieldName": "kv_json_",
      "skipFields": ["id"]
    }
  },
  "abortOnError" : true,
  "migratorVersion" : "1.7.0"
}

  3. コマンド・プロンプトを開き、NoSQL Database Migratorユーティリティを抽出したディレクトリに移動します。

  4. 構成ファイルを渡して、runMigratorコマンドを実行します。--configまたは -cオプションを使用します。
    $./runMigrator --config <complete/path/to/the/JSON/config/file>
  5. 次に示すように、ユーティリティはデータの移行に進みます。
    creating source from given configuration:
source creation completed
creating sink from given configuration:
sink creation completed
creating migrator pipeline
[cloud sink] : start loading DDLs
[cloud sink] : executing DDL: CREATE TABLE IF NOT EXISTS sampleMongoDBSpringImp (id STRING, kv_json_ JSON, PRIMARY KEY(SHARD(id))),limits: [100, 60, 1]
[cloud sink] : completed loading DDLs
migration started
[mongo file source] : start parsing MongoDB JSON records from file: mongodbspring.json
Migration success for source mongodbspring. read=3,written=3,failed=0
Migration is successful for all the sources.
migration completed.
Records provided by source=3, Records written to sink=3, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 393ms
Migration completed.

検証

移行を確認するために、Oracle NoSQL Database Cloud Serviceコンソールにログインし、ソース・データでsampleMongoDBImp表が作成されていることを確認します。コンソールにアクセスする手順は、インフラストラクチャ・コンソールからサービスへのアクセスの記事を参照してください。

DynamoDB JSONファイルからOracle NoSQL Database Cloud Serviceへの移行

この例では、Oracle NoSQL Database Migratorを使用してDynamoDB JSONファイルをNoSQL Database Cloud Serviceにコピーする方法を示します。

ユース・ケース

複数のオプションを評価した後、組織はDynamoDBデータベースを介してOracle NoSQL Database Cloud Serviceを最終決定します。組織は、表およびデータをDynamoDBからOracle NoSQL Database Cloud Serviceに移行しようとしています。

詳細については、「Oracle NoSQL表からDynamoDB表へのマッピング」を参照してください。

ソース構成テンプレートでパスを指定することで、DynamoDBがエクスポートしたJSONデータを含むファイルまたはディレクトリをファイル・システムから移行できます。

DynamoDB形式のJSONファイルの例を次に示します。
{"Item":{"Id":{"N":"101"},"Phones":{"L":[{"L":[{"S":"555-222"},{"S":"123-567"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"570004"},"Street":{"S":"21 main"},"DoorNum":{"N":"201"},"City":{"S":"London"}}},"FirstName":{"S":"Fred"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"Smith"},"FavColors":{"SS":["Red","Green"]},"Age":{"N":"22"},"ttl": {"N": "1734616800"}}}
{"Item":{"Id":{"N":"102"},"Phones":{"L":[{"L":[{"S":"222-222"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"560014"},"Street":{"S":"32 main"},"DoorNum":{"N":"1024"},"City":{"S":"Wales"}}},"FirstName":{"S":"John"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"White"},"FavColors":{"SS":["Blue"]},"Age":{"N":"48"},"ttl": {"N": "1734616800"}}}

エクスポートしたDynamoDB表データをAWS S3ストレージからローカルにマウントされたファイル・システムにコピーします。

Eaxmple

このデモでは、Oracle NoSQL Database Cloud ServiceにDynamoDB JSONファイルを移行する方法について学習します。この例では、手動で作成した構成ファイルを使用します。

前提条件

  • 移行するソースとシンクを指定します。
    • ソース: DynamoDB JSONファイル
    • シンク: Oracle NoSQL Database Cloud Service
  • DynamoDB表データをOracle NoSQL Databaseにインポートするには、最初にDynamoDB表をS3にエクスポートする必要があります。表のエクスポートには、Amazon S3へのDynamoDB表のデータのエクスポートに関する項のステップに関する項を参照してください。エクスポート時に、DynamoDB JSONとして形式を選択します。エクスポートされたデータには、次に示すように、複数のgzipファイルにDynamoDB表データが含まれています。
    / 01639372501551-bb4dd8c3 
|-- 01639372501551-bb4dd8c3 ==> exported data prefix
|----data
|------sxz3hjr3re2dzn2ymgd2gi4iku.json.gz ==>table data
|----manifest-files.json
|----manifest-files.md5
|----manifest-summary.json
|----manifest-summary.md5
|----_started
  • AWS S3からファイルをダウンロードする必要があります。ダウンロード後のファイルの構造は、次のようになります。
    download-dir/01639372501551-bb4dd8c3   
|----data  
|------sxz3hjr3re2dzn2ymgd2gi4iku.json.gz ==>table data  
|----manifest-files.json  
|----manifest-files.md5  
|----manifest-summary.json  
|----manifest-summary.md5  
|----_started
  • OCIクラウド資格証明を指定し、構成ファイルで取得します。構成ファイルを/home/user/.oci/configに保存します。詳細は、Oracle NoSQL Database Cloud Serviceの使用の資格証明の取得に関する項を参照してください。
    [DEFAULT]
tenancy=ocid1.tenancy.oc1....
user=ocid1.user.oc1....
fingerprint= 43:d1:....
region=us-ashburn-1
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=<passphrase>
  • Oracle NoSQL Database Cloud Serviceのリージョン・エンドポイントおよびコンパートメント名を指定します。
    • エンドポイント: us-ashburn-1
    • コンパートメント: Training-NoSQL

手順

DynamoDB JSONデータをOracle NoSQL Databaseに移行するには:

  1. 識別されたソースおよびシンクの詳細を含む構成ファイル(JSON形式)を準備します。詳細は、ソース構成テンプレートおよびシンク構成テンプレートに関する説明を参照してください。

    ノート:

    DynamoDBエクスポートされたJSON表アイテムにTTL属性が含まれている場合、オプションでTTL値をインポートするには、ソース構成テンプレートのttlAttributeName構成パラメータで属性を指定し、シンク構成テンプレートでincludeTTL構成パラメータをtrueに設定します。詳細は、「表の行のTTLメタデータの移行」を参照してください。

    ここでは、defaultSchema構成パラメータをtrueに設定します。したがって、NoSQL Database Migratorは、シンクにデフォルトのスキーマを作成します。DDBPartitionKeyおよび対応するNoSQL列タイプを指定する必要があります。それ以外の場合は、エラーが表示されます。

    DynamoDBエクスポート済JSONソースのデフォルト・スキーマの詳細は、Oracle NoSQLデータ・マイグレータのワークフローの「ソースとシンクの識別」のトピックを参照してください。 

    {
 "source" : {
  "type" : "file",
  "format" : "dynamodb_json",
  "ttlAttributeName" : "ttl",
  "dataPath" : "complete/path/to/the/DynamoDB/Formatted/JSON/file"
 },
 "sink" : {
  "type" : "nosqldb_cloud",
  "endpoint" : "us-sanjose-1",
  "table" : "sampledynDBImp",
  "compartment" : "ocid1.compartment.oc1..aaaaaaaa......smq",
  "includeTTL" : true,
  "schemaInfo" : {
   "readUnits" : 10,
   "writeUnits" : 10,
   "storageSize" : 1,
   "schemaPath" : "complete/path/to/the/DDl/file"
  },
  "credentials" : "/home/<username>/.oci/config",
  "credentialsProfile" : "DEFAULT",
  "writeUnitsPercent" : 90,
  "overwrite" : true,
  "requestTimeoutMs" : 5000
 },
 "abortOnError" : true,
 "migratorVersion" : "1.7.0"
}
    この例では、次のデフォルト・スキーマが使用されています。
    CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))
  2. コマンド・プロンプトを開き、NoSQLデータベース・マイグレータ・ユーティリティを抽出したディレクトリに移動します。
  3. 別個の構成ファイルを渡して、runMigratorコマンドを実行します。--configまたは -cオプションを使用します。
    ./runMigrator --config <complete/path/to/the/JSON/config/file>
  4. 次の例に示すように、ユーティリティはデータ移行を続行します。
    [INFO] creating source from given configuration:
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] [cloud sink] : start loading DDLs
[INFO] [cloud sink] : executing DDL: CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))
[INFO] [cloud sink] : completed loading DDLs
[INFO] migration started
[INFO] Start writing data to OnDB Sink
[INFO] executing for source:DynamoSample
[INFO] [DDB file source] : start parsing JSON records from file: DynamoSample.json.gz
[INFO] Writing data to OnDB Sink completed.
[INFO] migration completed.
Records provided by source=2, Records written to sink=2, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 45ms
Migration completed.

検証

移行を検証するには、Oracle NoSQL Database Cloud Serviceコンソールにログインし、ソース・データでsampledynDBImp表が作成されていることを確認します。

  1. 識別されたソースおよびシンクの詳細を含む構成ファイル(JSON形式)を準備します。詳細は、ソース構成テンプレートおよびシンク構成テンプレートに関する項を参照してください。

    ノート:

    DynamoDBエクスポートされたJSON表アイテムにTTL属性が含まれている場合、オプションでTTL値をインポートするには、ソース構成テンプレートのttlAttributeName構成パラメータで属性を指定し、シンク構成テンプレートでincludeTTL構成パラメータをtrueに設定します。

    ここでは、defaultSchema構成パラメータをfalseに設定します。したがって、シンク表のDDL文を含むファイルをschemaPathパラメータで指定します。詳細は、「DynamoDB型からOracle NoSQL型へのマッピング」を参照してください。

    この例では、次のユーザー定義スキーマが使用されます。
    CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))

    NoSQL Database Migratorは、スキーマ・ファイルを使用して、移行の一部としてシンクに表を作成します。主キー・データが指定されているかぎり、入力JSONレコードが挿入されます。それ以外の場合は、エラーが表示されます。

    ノート:

    • Dynamo DB表にNoSQLデータベースでサポートされていないデータ型がある場合、移行は失敗します。
    • 入力データに特定の列(主キー以外)の値が含まれていない場合は、列のデフォルト値が使用されます。デフォルト値は、表の作成時に列定義の一部である必要があります。たとえば、id INTEGER not null default 0です。列にデフォルト定義がない場合、列に値を指定しないと、SQL NULLが挿入されます。
    • DynamoDB表をJSONドキュメントとしてモデル化する場合は、主キー以外のデータがJSON列に集計されるように、AggregateFields変換を使用してください。詳細については、aggregateFieldsを参照してください。
    Generated configuration is
{
 "source" : {
  "type" : "file",
  "format" : "dynamodb_json",
  "ttlAttributeName" : "ttl",
  "dataPath" : "complete/path/to/the/DynamoDB/Formatted/JSON/file"
 },
 "sink" : {
  "type" : "nosqldb_cloud",
  "endpoint" : "us-sanjose-1",
  "table" : "sampledynDBImp",
  "compartment" : "ocid1.compartment.oc1..aaaaaaaa......smq",
  "includeTTL" : true,
  "schemaInfo" : {
   "readUnits" : 10,
   "writeUnits" : 10,
   "storageSize" : 1,
   "schemaPath" : "complete/path/to/the/DDl/file"
  },
  "credentials" : "/home/<username>/.oci/config",
  "credentialsProfile" : "DEFAULT",
  "writeUnitsPercent" : 90,
  "overwrite" : true,
  "requestTimeoutMs" : 5000
 },
 "abortOnError" : true,
 "migratorVersion" : "1.7.0"
}
  2. コマンド・プロンプトを開き、NoSQL Database Migratorユーティリティを抽出したディレクトリに移動します。
  3. 別個の構成ファイルを渡して、runMigratorコマンドを実行します。--configまたは -cオプションを使用します。
    ./runMigrator --config <complete/path/to/the/JSON/config/file>
  4. 次のサンプルに示すように、ユーティリティはデータ移行を続行します。
    [INFO] creating source from given configuration:
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] [cloud sink] : start loading DDLs
[INFO] [cloud sink] : executing DDL: CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))
[INFO] [cloud sink] : completed loading DDLs
[INFO] migration started
[INFO] Start writing data to OnDB Sink
[INFO] executing for source:DynamoSample
[INFO] [DDB file source] : start parsing JSON records from file: DynamoSample.json.gz
[INFO] Writing data to OnDB Sink completed.
[INFO] migration completed.
Records provided by source=2, Records written to sink=2, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 45ms
Migration completed.

検証

移行を検証するには、Oracle NoSQL Database Cloud Serviceコンソールにログインし、ソース・データでsampledynDBImp表が作成されていることを確認します。

AWS S3のDynamoDB JSONファイルからOracle NoSQL Database Cloud Serviceへの移行

この例では、Oracle NoSQL Database Migratorを使用して、AWS S3ストアに格納されているDynamoDB JSONファイルをOracle NoSQL Database Cloud Service (NDCS)にコピーする方法を示します。

ユースケース:

複数のオプションを評価した後、組織はDynamoDBデータベースを使用してOracle NoSQL Database Cloud Serviceを最終決定します。組織は、表およびデータをDynamoDBからOracle NoSQL Database Cloud Serviceに移行しようとしています。

詳細は、「DynamoDB表からOracle NoSQL表へのマッピング」 を参照してください。

DynamoDBエクスポートされたJSONデータを含むファイルは、ソース構成テンプレートでパスを指定することで、AWS S3ストレージから移行できます。

DynamoDB形式のJSONファイルの例を次に示します。
{"Item":{"Id":{"N":"101"},"Phones":{"L":[{"L":[{"S":"555-222"},{"S":"123-567"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"570004"},"Street":{"S":"21 main"},"DoorNum":{"N":"201"},"City":{"S":"London"}}},"FirstName":{"S":"Fred"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"Smith"},"FavColors":{"SS":["Red","Green"]},"Age":{"N":"22"}}}
{"Item":{"Id":{"N":"102"},"Phones":{"L":[{"L":[{"S":"222-222"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"560014"},"Street":{"S":"32 main"},"DoorNum":{"N":"1024"},"City":{"S":"Wales"}}},"FirstName":{"S":"John"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"White"},"FavColors":{"SS":["Blue"]},"Age":{"N":"48"}}}

DynamoDB表は、「DynamoDB表データのAmazon S3へのエクスポート」の説明に従って、AWS S3ストレージにエクスポートします。

次に例を示します:

このデモでは、AWS S3ソースのDynamoDB JSONファイルをNDCSに移行する方法について学習します。この例では、手動で作成した構成ファイルを使用します。

前提条件

  • 移行するソースとシンクを指定します。
    • ソース: DynamoDB JSONファイル(AWS S3)
    • シンク: Oracle NoSQL Database Cloud Service
  • NDCSに移行する必要があるAWS DynamoDBの表を特定します。資格情報を使用してAWSコンソールにログインします。DynamoDBに移動します。「Tables」で、移行する表を選択します。
  • オブジェクト・バケットを作成し、表をS3にエクスポートします。AWSコンソールから、S3に移動します。バケットの下に、新しいオブジェクト・バケットを作成します。DynamoDBに戻り、「S3にエクスポート」をクリックします。ソース表および宛先のS3バケットを指定して、「Export」をクリックします。
    表をエクスポートするには、Amazon S3へのDynamoDB表のエクスポートに関する項のステップを参照してください。エクスポート時に、DynamoDB JSONとして形式を選択します。エクスポートされたデータには、次に示すように、複数のgzipファイルにDynamoDB表データが含まれています。
    / 01639372501551-bb4dd8c3 
|-- 01639372501551-bb4dd8c3 ==> exported data prefix
|----data
|------sxz3hjr3re2dzn2ymgd2gi4iku.json.gz  ==>table data
|----manifest-files.json
|----manifest-files.md5
|----manifest-summary.json
|----manifest-summary.md5
|----_started
  • NoSQLデータベース・マイグレータからAWS S3にアクセスするには、AWS資格証明(アクセス・キーIDおよびシークレット・アクセス・キーを含む)と構成ファイル(資格証明とオプションで構成)が必要です。構成ファイルの詳細は、構成設定の設定および表示に関する項を参照してください。アクセス・キーの作成の詳細は、キー・ペアの作成に関する項を参照してください。
  • OCIクラウド資格証明を指定し、OCI構成ファイルで取得します。構成ファイルをホーム・ディレクトリ(~/.oci/config)の下の.ociディレクトリに保存します。詳細は、資格証明の取得に関する項を参照してください。 
    [DEFAULT]              
tenancy=ocid1.tenancy.oc1....         
user=ocid1.user.oc1....         
fingerprint= 43:d1:....         
key_file=</fully/qualified/path/to/the/private/key/>              
pass_phrase=<passphrase>
  • Oracle NoSQL Database Cloud Serviceのリージョン・エンドポイントおよびコンパートメント名を指定します。例
    • エンドポイント: us-phoenix-1
    • コンパートメント:開発者

手順

DynamoDB JSONデータをOracle NoSQL Database Cloud Serviceに移行するには、次のいずれかのオプションを使用します:

  1. 識別されたソースおよびシンクの詳細を含む構成ファイル(JSON形式)を準備します。詳細は、ソース構成テンプレートおよびシンク構成テンプレートに関する項を参照してください。

    ノート:

    AWS S3のDynamoDB JSONファイルのアイテムにTTL属性が含まれている場合、オプションでTTL値をインポートするには、ソース構成テンプレートのttlAttributeName構成パラメータで属性を指定し、シンク構成テンプレートでincludeTTL構成パラメータをtrueに設定します。詳細は、「表の行のTTLメタデータの移行」を参照してください。
    defaultSchemaをTRUEに設定して、マイグレータ・ユーティリティがシンクにデフォルトのスキーマを作成します。DDBPartitionKeyおよび対応するNoSQL列タイプを指定する必要があります。そうでない場合、エラーがスローされます。
    {
 "source" : {
   "type" : "aws_s3",
   "format" : "dynamodb_json",
   "s3URL" : "<https://<bucket-name>.<s3_endpoint>/export_path>",
   "credentials" : "</path/to/aws/credentials/file>",
   "credentialsProfile" : <"profile name in aws credentials file">
 },
 "sink" : {
   "type" : "nosqldb_cloud",
   "endpoint" : "<region_name>",
   "table" : "<table_name>",
   "compartment" : "<compartment_name>",
   "schemaInfo" : {
      "defaultSchema" : true,
      "readUnits" : 100,
      "writeUnits" : 60,
      "DDBPartitionKey" : "<PrimaryKey:Datatype>",
      "storageSize" : 1
   },
   "credentials" : "<complete/path/to/the/oci/config/file>",
   "credentialsProfile" : "DEFAULT",
   "writeUnitsPercent" : 90,
   "requestTimeoutMs" : 5000
 },
 "abortOnError" : true,
 "migratorVersion" : "1.7.0"
}
    DynamoDB JSONソースの場合、表のデフォルト・スキーマは次のようになります:
    CREATE TABLE IF NOT EXISTS <TABLE_NAME>(DDBPartitionKey_name DDBPartitionKey_type, 
[DDBSortKey_name DDBSortKey_type], DOCUMENT JSON, 
PRIMARY KEY(SHARD(DDBPartitionKey_name),[DDBSortKey_name]))

    説明:

    TABLE_NAME = 構成内のシンクのtableに指定された値

    DDBPartitionKey_name = 構成内のパーティション・キーに指定された値

    DDBPartitionKey_type = 構成内のパーティション・キーのデータ型に指定された値

    DDBSortKey_name = 構成のソート・キーに指定された値(ある場合)

    DDBSortKey_type = 構成内のソート・キーのデータ型に指定された値(ある場合)

    DOCUMENT = NoSQL JSON列に集計されたDynamo DB表アイテムのパーティションおよびソート・キーを除くすべての属性

  2. コマンド・プロンプトを開き、NoSQL Database Migratorユーティリティを抽出したディレクトリに移動します。
  3. 構成ファイルを渡して、runMigratorコマンドを実行します。--configまたは -cオプションを使用します。
    [~/nosqlMigrator]$./runMigrator 
--config <complete/path/to/the/JSON/config/file>
  4. 次に示すように、ユーティリティはデータの移行に進みます。
    Records provided by source=7..,
Records written to sink=7,
Records failed=0,
Records skipped=0.
Elapsed time: 0 min 2sec 50ms
Migration completed.

検証

Oracle NoSQL Database Cloud Serviceコンソールにログインし、ソース・データで新規表が作成されていることを確認します。

  1. 識別されたソースおよびシンクの詳細を含む構成ファイル(JSON形式)を準備します。詳細は、ソース構成テンプレートおよびシンク構成テンプレートに関する項を参照してください。

    ノート:

    AWS S3のDynamoDB JSONファイルのアイテムにTTL属性が含まれている場合、オプションでTTL値をインポートするには、ソース構成テンプレートのttlAttributeName構成パラメータで属性を指定し、シンク構成テンプレートでincludeTTL構成パラメータをtrueに設定します。詳細は、「表の行のTTLメタデータの移行」を参照してください。
    シンク構成テンプレートでユーザー定義スキーマ・ファイルを指定するには、defaultSchemaをFALSEに設定し、schemaPathをDDL文を含むファイルとして指定します。詳細は、「Oracle NoSQL型からDynamoDB型へのマッピング」を参照してください。

    ノート:

    Dynamo DB表のデータ型がNoSQLでサポートされていない場合、移行は失敗します。
    サンプル・スキーマ・ファイルを次に示します。
    CREATE TABLE IF NOT EXISTS sampledynDBImp (AccountId INTEGER,document JSON, 
PRIMARY KEY(SHARD(AccountId)));
    スキーマ・ファイルは、移行の一部としてシンクに表を作成するために使用されます。主キー・データが指定されているかぎり、入力JSONレコードが挿入され、それ以外の場合はエラーがスローされます。

    ノート:

    • 入力データに(主キー以外の)特定の列の値が含まれていない場合は、列のデフォルト値が使用されます。デフォルト値は、表の作成時に列定義の一部である必要があります。たとえば、id INTEGER not null default 0です。列にデフォルト定義がない場合、列に値が指定されていないと、SQL NULLが挿入されます。
    • DynamoDB表をJSONドキュメントとしてモデル化する場合は、主キー以外のデータをJSON列に集計するためにAggregateFields変換を使用してください。詳細は、aggregateFieldsを参照してください。 
    {
 "source" : {
   "type" : "aws_s3",
   "format" : "dynamodb_json",
   "s3URL" : "<https://<bucket-name>.<s3_endpoint>/export_path>",
   "credentials" : "</path/to/aws/credentials/file>",
   "credentialsProfile" : <"profile name in aws credentials file">
 },
 "sink" : {
   "type" : "nosqldb_cloud",
   "endpoint" : "<region_name>",
   "table" : "<table_name>",
   "compartment" : "<compartment_name>",
   "schemaInfo" : {
      "defaultSchema" : false,
      "readUnits" : 100,
      "writeUnits" : 60,
      "schemaPath" : "<full path of the schema file with the DDL statement>",
      "storageSize" : 1
   },
   "credentials" : "<complete/path/to/the/oci/config/file>",
   "credentialsProfile" : "DEFAULT",
   "writeUnitsPercent" : 90,
   "requestTimeoutMs" : 5000
 },
  "transforms": {
    "aggregateFields" : {
      "fieldName" : "document",
      "skipFields" : ["AccountId"]
    }
  },
 "abortOnError" : true,
 "migratorVersion" : "1.7.0"
}
  2. コマンド・プロンプトを開き、NoSQL Database Migratorユーティリティを抽出したディレクトリに移動します。
  3. 構成ファイルを渡して、runMigratorコマンドを実行します。--configまたは -cオプションを使用します。
    [~/nosqlMigrator]$./runMigrator 
--config <complete/path/to/the/JSON/config/file>
  4. 次に示すように、ユーティリティはデータの移行に進みます。
    Records provided by source=7..,
Records written to sink=7,
Records failed=0,
Records skipped=0.
Elapsed time: 0 min 2sec 50ms
Migration completed.

検証

Oracle NoSQL Database Cloud Serviceコンソールにログインし、ソース・データで新規表が作成されていることを確認します。

Oracle NoSQL Database Cloud Serviceリージョン間の移行

この例では、Oracle NoSQL Database Migratorを使用してリージョン間移行を実行する方法を示します。

ユースケース

組織は、Oracle NoSQL Database Cloud Serviceを使用してデータを格納および管理します。新しいリージョンを本番環境で起動する前に、テスト目的で既存のリージョンから新しいリージョンにデータをレプリケートすることを決定します。

このユースケースでは、NoSQL Database Migratorを使用して、アッシュバーン・リージョンのuser_data表からフェニックス・リージョンにデータをコピーする方法を学習します。

runMigratorユーティリティは、事前作成済の構成ファイルを渡して実行します。ランタイム・パラメータとして構成ファイルを指定しない場合、runMigratorユーティリティでは、対話型プロシージャを使用して構成を生成するように求められます。

前提条件
  • Oracle NoSQLのダウンロード・ページからOracle NoSQL Database Migratorをダウンロードし、その内容をマシンに抽出します。詳細は、Oracle NoSQL Database Migratorのワークフローを参照してください。
  • 移行するソースとシンクを指定します。
    • ソース: 「アッシュバーン」リージョンのuser_data表。
      user_data表には、次のデータがあります。 
      {"id":40,"firstName":"Joanna","lastName":"Smith","otherNames":[{"first":"Joanna","last":"Smart"}],"age":null,"income":75000,"address":{"city":"Houston","number":401,"phones":[{"area":null,"kind":"work","number":1618955},{"area":451,"kind":"home","number":4613341},{"area":481,"kind":"mobile","number":4613382}],"state":"TX","street":"Tex Ave","zip":95085},"connections":[70,30,40],"email":"joanna.smith123@reachmail.com","communityService":"**"}

{"id":10,"firstName":"John","lastName":"Smith","otherNames":[{"first":"Johny","last":"Good"},{"first":"Johny2","last":"Brave"},{"first":"Johny3","last":"Kind"},{"first":"Johny4","last":"Humble"}],"age":22,"income":45000,"address":{"city":"Santa Cruz","number":101,"phones":[{"area":408,"kind":"work","number":4538955},{"area":831,"kind":"home","number":7533341},{"area":831,"kind":"mobile","number":7533382}],"state":"CA","street":"Pacific Ave","zip":95008},"connections":[30,55,43],"email":"john.smith@reachmail.com","communityService":"****"}

{"id":20,"firstName":"Jane","lastName":"Smith","otherNames":[{"first":"Jane","last":"BeGood"}],"age":22,"income":55000,"address":{"city":"San Jose","number":201,"phones":[{"area":608,"kind":"work","number":6538955},{"area":931,"kind":"home","number":9533341},{"area":931,"kind":"mobile","number":9533382}],"state":"CA","street":"Atlantic Ave","zip":95005},"connections":[40,75,63],"email":"jane.smith201@reachmail.com","communityService":"*****"}

{"id":30,"firstName":"Adam","lastName":"Smith","otherNames":[{"first":"Adam","last":"BeGood"}],"age":45,"income":75000,"address":{"city":"Houston","number":301,"phones":[{"area":618,"kind":"work","number":6618955},{"area":951,"kind":"home","number":9613341},{"area":981,"kind":"mobile","number":9613382}],"state":"TX","street":"Indian Ave","zip":95075},"connections":[60,45,73],"email":"adam.smith201reachmail.com","communityService":"***"}
      ソースのリージョン・エンドポイントまたはサービス・エンドポイントとコンパートメント名を識別します。
      • エンドポイント: us-ashburn-1
      • コンパートメント: ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya
    • シンク: 「フェニックス」リージョンのuser_data表。
      リージョン・エンドポイントまたはサービス・エンドポイント、およびシンクのコンパートメント名を識別します。
      • エンドポイント: us-phoenix-1
      • コンパートメント: ocid1.compartment.oc1..aaaaaaaaleiwplazhwmicoogv3tf4lum4m4nzbcv5wfjmoxuz3doreagvdma

      シンク表スキーマを識別します。

      ソース表と同じ表名およびスキーマを使用できます。他のスキーマ・オプションの詳細は、Oracle NoSQL Database Migratorのワークフローのソースとシンクの識別のトピックを参照してください

  • 両方のリージョンのOCIクラウド資格証明を指定し、構成ファイルで取得します。マシン上の構成ファイルを/home/<user>/.oci/configの場所に保存します。詳細は、資格証明の取得に関する項を参照してください。

ノート:

  • リージョンが異なるテナンシの下にある場合は、/home/<user>/.OCI/configファイルの異なるプロファイルに、それぞれに適切なOCIクラウド資格証明を指定する必要があります。
  • リージョンが同じテナンシの下にある場合は、/home/<user>/.oci/configファイルに単一のプロファイルを設定できます。

この例では、リージョンは異なるテナンシの下にあります。DEFAULTプロファイルにはアッシュバーン・リージョンのOCI資格証明が含まれ、DEFAULT2にはフェニックス・リージョンのOCI資格証明が含まれます。

マイグレータ構成ファイルのendpointパラメータ(ソース構成テンプレートとシンク構成テンプレートの両方)では、サービス・エンドポイントURLまたはリージョンのリージョンIDを指定できます。Oracle NoSQL Database Cloud Serviceでサポートされるデータ・リージョンとそのサービス・エンドポイントURLのリストは、Oracle NoSQL Database Cloud Serviceドキュメントのデータ・リージョンおよび関連するサービスURLを参照してください。
[DEFAULT]
user=ocid1.user.oc1....
fingerprint=fd:96:....
tenancy=ocid1.tenancy.oc1....
region=us-ashburn-1
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=abcd


[DEFAULT2]
user=ocid1.user.oc1....
fingerprint=1b:68:....
tenancy=ocid1.tenancy.oc1....
region=us-phoenix-1
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=23456
手順
user_data表をアッシュバーン・リージョンからフェニックス・リージョンに移行するには、次を実行します:
  1. 識別されたソースおよびシンクの詳細を含む構成ファイル(JSON形式)を準備します。ソース構成テンプレート およびSink Configuration Templates を参照してください。
    {
  "source" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "user_data",
    "compartment" : "ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya",
    "credentials" : "/home/<user>/.oci/config",
    "credentialsProfile" : "DEFAULT",
    "readUnitsPercent" : 100,
    "includeTTL" : false,
    "requestTimeoutMs" : 5000
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-phoenix-1",
    "table" : "user_data",
    "compartment" : "ocid1.compartment.oc1..aaaaaaaaleiwplazhwmicoogv3tf4lum4m4nzbcv5wfjmoxuz3doreagvdma",
    "includeTTL" : false,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "useSourceSchema" : true
    },
    "credentials" : "/home/<user>/.oci/config",
    "credentialsProfile" : "DEFAULT2",
    "writeUnitsPercent" : 90,
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.7.0"
}
  2. マシンで、NoSQL Database Migratorユーティリティを抽出したディレクトリに移動します。コマンドライン・インタフェースからrunMigratorコマンドにアクセスできます。
  3. --configまたは-cオプションを使用して構成ファイルを渡し、runMigratorコマンドを実行します。
    [~/nosql-migrator]$./runMigrator --config <complete/path/to/the/config/file>
  4. 次に示すように、ユーティリティはデータの移行に進みます。user_data表は、シンク構成テンプレートでuseSourceSchemaパラメータをtrueとして構成したものと同じスキーマを持つシンクに作成されます。
    creating source from given configuration:
source creation completed
creating sink from given configuration:
sink creation completed
creating migrator pipeline
migration started
[cloud sink] : start loading DDLs
[cloud sink] : executing DDL: CREATE TABLE IF NOT EXISTS user_data (id INTEGER, firstName STRING, lastName STRING, otherNames ARRAY(RECORD(first STRING, last STRING)), age INTEGER, income INTEGER, address JSON, connections ARRAY(INTEGER), email STRING, communityService STRING, PRIMARY KEY(SHARD(id))),limits: [100, 60, 1]
[cloud sink] : completed loading DDLs
[cloud sink] : start loading records
migration completed.
Records provided by source=5, Records written to sink=5, Records failed=0, Records skipped=0.
Elapsed time: 0min 5sec 603ms
Migration completed.

    ノート:

    • ソース表と同じスキーマを持つシンクに表がすでに存在する場合、構成テンプレートでoverwriteパラメータをtrueに指定した場合と同じ主キーを持つ行は上書きされます。
    • ソース表とは異なるスキーマを持つシンクに表がすでに存在する場合、移行は失敗します。
検証

移行を検証するには、「フェニックス」リージョンでOracle NoSQL Database Cloud Serviceコンソールにログインします。「アッシュバーン」リージョンのuser_data表のソース・データが、このリージョンのuser_data表にコピーされていることを確認します。コンソールにアクセスする手順は、インフラストラクチャ・コンソールからのサービスへのアクセスを参照してください。

Oracle NoSQL Database Cloud ServiceからOCI Object Storageへの移行

この例では、クラウド・シェルからのOracle NoSQL Database Migratorの使用方法を示します。

ユースケース

スタートアップ企業では、Oracle NoSQL Database Cloud Serviceをデータ・ストレージ・ソリューションとして使用することを計画しています。同社は、Oracle NoSQL Database Migratorを使用して、データを定期的にバックアップするために、Oracle NoSQL Database Cloud Serviceの表からOCI Object Storageにデータをコピーすることを希望しています。コスト効率に優れた手段として、すべてのOCIユーザーがアクセスできるクラウド・シェルからNoSQL Database Migratorユーティリティを実行します。

このユースケースでは、NoSQL Database Migratorユーティリティをサブスクライブ済リージョンのクラウド・シェルにコピーし、データ移行を実行する方法を学習します。ソース・データをOracle NoSQL Database Cloud Service表からOCIオブジェクト・ストレージのJSONファイルに移行します。

runMigratorユーティリティは、事前作成済の構成ファイルを渡して実行します。ランタイム・パラメータとして構成ファイルを指定しない場合、runMigratorユーティリティでは、対話型プロシージャを使用して構成を生成するように求められます。

前提条件
  • Oracle NoSQL Database MigratorをOracle NoSQLのダウンロード・ページからローカル・マシンにダウンロードします。
  • クラウド・コンソールの「開発者ツール」メニューからクラウド・シェルを起動します。Webブラウザでホーム・ディレクトリが開きます。「Cloud Shell」ウィンドウの右上隅にある「Cloud Shell」メニューをクリックし、ドロップダウンから「upload」オプションを選択します。ポップアップ・ウィンドウで、ローカル・マシンからOracle NoSQL Database Migratorパッケージをドラッグ・アンド・ドロップするか、「コンピュータから選択」オプションをクリックしてローカル・マシンからパッケージを選択し、「アップロード」ボタンをクリックします。Oracle NoSQL Database Migratorパッケージをローカル・マシンから直接クラウド・シェルのホーム・ディレクトリにドラッグ・アンド・ドロップすることもできます。パッケージのコンテンツを抽出します。
  • バックアップするソースとシンクを指定します。

    • ソース: Oracle NoSQL Database Cloud Service アッシュバーン・リージョンのNDCSupload表。

      デモンストレーションでは、NDCSupload表の次のデータを検討してください。
      {"id":1,"name":"Jane Smith","email":"iamjane@somemail.co.us","age":30,"income":30000.0}
{"id":2,"name":"Adam Smith","email":"adam.smith@mymail.com","age":25,"income":25000.0}
{"id":3,"name":"Jennifer Smith","email":"jenny1_smith@mymail.com","age":35,"income":35000.0}
{"id":4,"name":"Noelle Smith","email":"noel21@somemail.co.us","age":40,"income":40000.0}

      ソースのエンドポイントおよびコンパートメントIDを識別します。エンドポイントには、リージョン識別子またはサービス・エンドポイントのいずれかを指定できます。Oracle NoSQL Database Cloud Serviceでサポートされているデータ・リージョンのリストは、データ・リージョンおよび関連するサービスURLを参照してください。

      • エンドポイント: us-ashburn-1
      • コンパートメントID: ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya

    • シンク: OCIオブジェクト・ストレージ・バケット内のJSONファイル。

      OCI Object Storageのリージョン・エンドポイント、ネームスペース、バケットおよび接頭辞を識別します。詳細は、「Oracle Cloudオブジェクト・ストレージへのアクセス」を参照してください。OCIオブジェクト・ストレージ・サービス・エンドポイントのリストは、オブジェクト・ストレージ・エンドポイントを参照してください。

      • エンドポイント: us-ashburn-1
      • バケット: Migrate_oci
      • 接頭辞: Delegation
      • namespace: <>ネームスペースを指定しない場合、ユーティリティはテナンシのデフォルト・ネームスペースを使用します。

      ノート:

      オブジェクト・ストレージ・バケットが別のコンパートメントにある場合は、バケットにオブジェクトを書き込む権限があることを確認してください。ポリシーの設定の詳細は、オブジェクト・ストレージでのオブジェクトの書込みを参照してください。
手順
クラウド・シェルを使用して、Oracle NoSQL Database Cloud ServiceからOCIオブジェクト・ストレージ・バケットのJSONファイルにNDCSupload表をバックアップするには、次を実行します:
  1. 識別されたソースおよびシンクの詳細を含む構成ファイル(JSON形式)を準備します。ソース構成テンプレート およびSink Configuration Templates を参照してください。ソースおよびシンク構成テンプレートで、useDelegationTokenパラメータをtrueに設定してください。
    このユースケースでは、次の構成テンプレートが使用されます。
    {
  "source" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "NDCSupload",
    "compartment" : "ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya",
    "useDelegationToken" : true,
    "readUnitsPercent" : 90,
    "includeTTL" : true,
    "requestTimeoutMs" : 5000
  },
  "sink" : {
    "type" : "object_storage_oci",
    "format" : "json",
    "endpoint" : "us-ashburn-1",
    "namespace" : "",
    "bucket" : "Migrate_oci",
    "prefix" : "Delegation",
    "chunkSize" : 32,
    "compression" : "",
    "useDelegationToken" : true
  },
  "abortOnError" : true,
  "migratorVersion" : "1.7.0"
}
  2. クラウド・シェルから、NoSQL Database Migratorユーティリティを抽出したディレクトリに移動します。
  3. --configまたは-cオプションを使用して構成ファイルを渡し、runMigratorコマンドを実行します。
    [~/nosql-migrator]$./runMigrator --config <complete/path/to/the/config/file>
  4. NoSQL Database Migratorユーティリティは、データ移行を続行します。useDelegationTokenパラメータをtrueに設定すると、クラウド・シェルはNoSQL Database Migratorユーティリティの実行中に委任トークンを使用して自動的に認証されます。NoSQL Database Migratorは、データをNDCSupload表からオブジェクト・ストレージ・バケットMigrate_ociのJSONファイルにコピーします。ログで正常なデータ・バックアップを確認します。
    [INFO] creating source from given configuration:
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] migration started
[INFO] [OCI OS sink] : writing table schema to Delegation/Schema/schema.ddl
[INFO] [OCI OS sink] : start writing records with prefix Delegation
[INFO] migration completed.
Records provided by source=4,Records written to sink=4,Records failed=0.
Elapsed time: 0min 0sec 486ms
Migration completed.

    ノート:

    データがファイルにコピーされます: Migrate_oci/NDCSupload/Delegation/Data/000000.json

    シンク構成テンプレートのchunkSizeパラメータに応じて、ソース・データを同じディレクトリ内の複数のJSONファイルに分割できます。

    スキーマがファイルにコピーされます: Migrate_oci/NDCStable1/Delegation/Schema/schema.ddl

検証

データ・バックアップを検証するには、Oracle NoSQL Database Cloud Serviceコンソールにログインします。メニューStorage > Object Storage & Archive Storage > Bucketsをナビゲートします。Migrate_ociバケットのNDCSupload/Delegationディレクトリからファイルにアクセスします。コンソールにアクセスする手順は、インフラストラクチャ・コンソールからのサービスへのアクセスを参照してください。

OKE認証を使用したOCIオブジェクト・ストレージからOracle NoSQL Database Cloud Serviceへの移行

この例では、Oracle NoSQL Database MigratorをOKEワークロード・アイデンティティ認証とともに使用して、OCIオブジェクト・ストレージのJSONファイルからOracle NoSQL Database Cloud Service表にデータをコピーする方法を示します。

ユース・ケース

開発者は、コンテナ化されたアプリケーションでNoSQL Database Migratorを使用して、OCI Object Storage (OCI OS)バケットのJSONファイルからOracle NoSQL Database Cloud Service (NDCS)表にデータをリストアするオプションを検討しています。コンテナ化されたアプリケーションは、アプリケーションとそのすべての依存関係(ライブラリ、バイナリ、構成ファイルなど)をパッケージにバンドルする仮想化環境です。これにより、基盤となるインフラストラクチャに関係なく、アプリケーションを異なる環境間で一貫して実行できます。

Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)ポッド内でNoSQL Database Migratorを実行する場合。OKEポッドからOCI OSおよびNDCSサービスに安全にアクセスするには、ワークロード・アイデンティティ認証(WIA)方法を使用します。

このデモンストレーションでは、NoSQL Database Migratorのdockerイメージを構築し、コンテナ・レジストリのリポジトリにイメージをコピーし、OKEクラスタを作成し、OKEクラスタ・ポッドにMigratorイメージをデプロイしてMigratorユーティリティを実行します。ここでは、手動で作成したNoSQL Database Migrator構成ファイルを指定して、Migratorユーティリティをコンテナ化されたアプリケーションとして実行します。

前提条件
  • 移行するソースとシンクを指定します。
    • ソース: OCI OSバケット内のJSONファイルおよびスキーマ・ファイル。
      ソースJSONファイルおよびスキーマが使用可能なOCI OSバケットのリージョン・エンドポイント、ネームスペース、バケットおよび接頭辞を識別します。詳細は、Oracle Cloud Object Storageへのアクセスを参照してください。OCI OSサービス・エンドポイントのリストは、オブジェクト・ストレージ・エンドポイントを参照してください。
      • エンドポイント: us-ashburn-1
      • バケット: Migrate_oci
      • 接頭辞: userSession
      • 名前空間: idhkv1iewjzj
        バケットのネームスペース名は、そのテナンシのネームスペースと同じで、テナンシの作成時に自動生成されます。名前空間名は次のように取得できます。
        • Oracle NoSQL Database Cloud Serviceコンソールから、「ストレージ」→「バケット」に移動します。
        • 「リスト範囲」から「コンパートメント」を選択し、バケットを選択します。「バケットの詳細」ページには、「ネームスペース」パラメータに名前が表示されます。

        OCI OSネームスペース名を指定しない場合、マイグレータ・ユーティリティはテナンシのデフォルト・ネームスペースを使用します。

    • シンク: Oracle NoSQL Database Cloud Serviceのusers表。

      リージョン・エンドポイント、またはサービス・エンドポイントとシンクのコンパートメント名を識別します:

      • エンドポイント: us-ashburn-1
      • コンパートメント: ocid1.compartment.oc1..aaaaaaaaleiwplazhwmicoogv3tf4lum4m4nzbcv5wfjmoxuz3doreagvdma

      シンク表スキーマを識別します。

      OCI OSバケットに格納されている表名およびスキーマを使用するには、useSourceSchemaパラメータをtrueに設定します。その他のスキーマ・オプションの詳細は、Oracle NoSQL Database Migratorのワークフローのソースとシンクの識のトピックを参照してください

      ノート:

      データをNDCS表にリストアするコンパートメントへの書込み権限があることを確認します。詳細は、コンパートメントの管理を参照してください。
  • NoSQL Database MigratorのDockerイメージを準備し、コンテナ・レジストリに移動します。
    1. OCIコンソールからテナンシ・ネームスペースを取得します。

      Oracle NoSQL Database Cloud Serviceコンソールにログインします。ナビゲーション・バーで、「プロファイル」メニューを選択し、「テナンシ: <テナンシ名>」を選択します。

      オブジェクト・ストレージ・ネームスペース名(テナンシ・ネームスペース)をクリップボードにコピーします。

    2. MigratorユーティリティのDockerイメージを構築します。
      NoSQL Database Migratorユーティリティを抽出したディレクトリに移動します。Migratorパッケージには、Dockerfileという名前のdockerファイルが含まれています。コマンド・インタフェースから、次のコマンドを使用して、MigratorユーティリティのDockerイメージを構築します。 
      #Command:
docker build -t nosqlmigrator:<tag> .
      #Example:
docker build -t nosqlmigrator:1.0 .
      Dockerイメージのバージョン識別子は、tagオプションで指定できます。次のコマンドを使用して、Dockerイメージを確認します:
      #Command:
Docker images
      #Example output
------------------------------------------------------------------------------------------

REPOSITORY                 TAG          IMAGE ID         CREATED         SIZE
localhost/nosqlmigrator    1.0          e1dcec27a5cc     10 seconds ago  487 MB
quay.io/podman/hello       latest       83fc7ce1224f     10 months ago   580 kB
docker.io/library/openjdk  17-jdk-slim  8a3a2ffec52a     2 years ago     406 MB

------------------------------------------------------------------------------------------
    3. 認証トークンを生成します。

      Migrator Dockerイメージを格納するためにコンテナ・レジストリにログインするには、認証トークンが必要です。認証トークンがまだない場合は、生成する必要があります。詳細は、認証トークンの取得に関する項を参照してください。

    4. Migrator Dockerイメージをコンテナ・レジストリに格納します。

      KubernetesポッドからマイグレータDockerイメージにアクセスするには、パブリックまたはプライベート・レジストリにイメージを格納する必要があります。たとえば、Docker、アーティファクト・ハブ、OCIコンテナ・レジストリなどは、いくつかのレジストリです。このデモンストレーションでは、コンテナ・レジストリを使用します。詳細は、コンテナ・レジストリの概要を参照してください。

      1. OCIコンソールから、コンテナ・レジストリにリポジトリを作成します。詳細は、リポジトリの作成を参照してください。

        このデモンストレーションでは、okemigratorリポジトリを作成します。

        図- コンテナ・レジストリのリポジトリ


        図の説明が続きます
        「図- コンテナ・レジストリのリポジトリ」の説明

      2. 次のコマンドを使用して、コマンド・インタフェースからコンテナ・レジストリにログインします。
        #Command:
docker login <region-key>.ocir.io -u <tenancy-namespace>/<user name>password: <Auth token>
        #Example:
docker login iad.ocir.io -u idhx..xxwjzj/rx..xxxxh@oracle.com
password: <Auth token>
        #Output:
Login Succeeded!

        前述のコマンドでは、

        region-key: コンテナ・レジストリを使用するリージョンのキーを指定します。詳細は、リージョン別の可用性に関する項を参照してください。

        tenancy-namespace: OCIコンソールからコピーしたテナンシ・ネームスペースを指定します。

        user name: OCIコンソールのユーザー名を指定します。

        password: 認証トークンを指定します。

      3. 次のコマンドを使用して、Migrator Dockerイメージをコンテナ・レジストリにタグ付けしてプッシュします:
        #Command:
docker tag <Migrator Docker image> <region-key>.ocir.io/<tenancy-namespace>/<repo>:<tag>
docker push <region-key>.ocir.io/<tenancy-namespace>/<repo>:<tag>
        #Example:
docker tag localhost/nosqlmigrator:1.0 iad.ocir.io/idhx..xxwjzj/okemigrator:1.0
docker push iad.ocir.io/idhx..xxwjzj/okemigrator:1.0

        前述のコマンドでは、

        repo: コンテナ・レジストリで作成したリポジトリの名前を指定します。

        tag: Dockerイメージのバージョン識別子を指定します。 

        #Output:
Getting image source signatures
Copying blob 0994dbbf9a1b done   | 
Copying blob 37849399aca1 done   | 
Copying blob 5f70bf18a086 done   | 
Copying blob 2f263e87cb11 done   | 
Copying blob f941f90e71a8 done   | 
Copying blob c82e5bf37b8a done   | 
Copying blob 2ad58b3543c5 done   | 
Copying blob 409bec9cdb8b done   | 
Copying config e1dcec27a5 done   | 
Writing manifest to image destination
  • WIAからNDCSおよびOCI OSへのOKEクラスタを構成します。
    1. OKEを使用してKubernetesクラスタを作成します。

      OCIコンソールから、OKEを使用してネットワーク・リソースの可用性に基づいてKubernetesクラスタを定義および作成します。Migratorユーティリティをコンテナ化されたアプリケーションとして実行するには、Kubernetesクラスタが必要です。クラスタの作成の詳細は、コンソール・ワークフローを使用したKubernetesクラスタの作成に関する項を参照してください。

      このデモンストレーションでは、前述のリンクで説明されているクイック作成ワークフローを使用して、単一ノード管理クラスタを作成できます。

      図- MigratorコンテナのKubernetesクラスタ


      図の説明が続きます
      「図- Kubernetes Cluster for Migrator Container」の説明

    2. OCIコンソールからWIAを設定して、Kubernetesクラスタから他のOCIリソースにアクセスします。

      Kubernetesクラスタ・ポッドから実行中に、MigratorユーティリティにNDCSおよびOCI OSバケットへのアクセス権を付与するには、WIAを設定する必要があります。次のステップに従います:

      1. クラスタのkubeconfig構成ファイルを設定します。
        • OCIコンソールから、作成したKubernetesクラスタを開き、「クラスタへのアクセス」ボタンをクリックします。
        • 「クラスタへのアクセス」ダイアログ・ボックスで、「クラウド・シェルのアクセス」をクリックします。
        • 「クラウド・シェールの起動」をクリックして「クラウド・シェル」ウィンドウを表示します。
        • Oracle Cloud Infrastructure CLIコマンドを実行して、kubeconfigファイルを設定します。コマンドは、「クラスタへのアクセス」ダイアログ・ボックスからコピーできます。次の出力が期待できます。
          #Example:  
oci ce cluster create-kubeconfig --cluster-id ocid1.cluster.oc1.iad.aaa...muqzq --file $HOME/.kube/config --region us-ashburn-1 --token-version 2.0.0  --kube-endpoint PUBLIC_ENDPOINT
          #Output:
New config written to the Kubeconfig file /home/<user>/.kube/config
      2. 前述のコマンドのcluster-idオプションからクラスタのOCIDをコピーし、次のステップで使用するために保存します。
        ocid1.cluster.oc1.iad.aaa...muqzq
      3. クラウド・シェル・ウィンドウで次のコマンドを使用して、Kubernetesサービス・アカウントのネームスペースを作成します:
        #Command:
kubectl create namespace <namespace-name>
        #Example:
kubectl create namespace migrator
        #Output:
namespace/migrator created
      4. クラウド・シェル・ウィンドウで次のコマンドを使用して、ネームスペースにMigratorアプリケーションのKubernetesサービス・アカウントを作成します:
        #Command:
kubectl create serviceaccount <service-account-name> --namespace <namespace-name>
        #Example:
kubectl create serviceaccount migratorsa --namespace migrator
        #Output:
serviceaccount/migratorsa created
      5. OCIコンソールからIAMポリシーを定義して、ワークロードがKubernetesクラスタからOCIリソースにアクセスできるようにします。

        OCIコンソールから、メニューの「アイデンティティとセキュリティ」→「アイデンティティ」→「ポリシー」に移動します。次のポリシーを作成して、nosql-familyおよびobject-familyリソースへのアクセスを許可します。前のステップのクラスタ、ネームスペースおよびサービス・アカウント値のOCIDを使用します。 

        #Command:
Allow <subject> to <verb> <resource-type> in <location> where <conditions>
        #Example:
Allow any-user to manage nosql-family in compartment Training-NoSQL where all { request.principal.type = 'workload', request.principal.namespace = 'migrator', request.principal.service_account = 'migratorsa', request.principal.cluster_id = 'ocid1.cluster.oc1.iad.aaaaaaaa2o6h5noeut7i4xr2bp4aohcc2ncozgvn3nny3uqu7cvp2rwmuqzq'}

Allow any-user to manage object-family in compartment Training-NoSQL where all { request.principal.type = 'workload', request.principal.namespace = 'migrator', request.principal.service_account = 'migratorsa', request.principal.cluster_id = 'ocid1.cluster.oc1.iad.aaaaaaaa2o6h5noeut7i4xr2bp4aohcc2ncozgvn3nny3uqu7cvp2rwmuqzq'}

        ポリシーの作成の詳細は、コンソールを使用したポリシーの作成を参照してください。

手順

OCI OSバケットのJSONファイルからNDCS表に移行するには、「クラウド・シェル」ウィンドウから次の手順を実行します。

  1. OCI OSソースおよびNDCSシンクを使用して、マイグレータ構成ファイルmigrator-config.jsonを準備します。テンプレートについては、ソース構成テンプレートおよびシンク構成テンプレートを参照してください。

    OKE WIAを使用してOCI OSバケットおよびNDCSにアクセスするには、ソース構成テンプレートとシンク構成テンプレートの両方でuseOKEWorkloadIdentityパラメータをtrueに設定します。ここでは、OCI OSバケットのスキーマDDLファイルのソース・スキーマを使用します。したがって、シンク構成テンプレートでuseSourceSchemaパラメータをtrueに設定します。

    ノート:

    OKE WIAの使用中に、Migrator構成ファイルを対話形式で生成することはできません。ソースおよびシンク構成テンプレートを参照して、構成ファイルを手動で準備する必要があります。 
    {
  "source" : {
    "type" : "object_storage_oci",
    "format" : "json",
    "endpoint" : "us-ashburn-1",
    "namespace" : "",
    "bucket" : "Migrate_oci",
    "prefix" : "userSession",
    "useOKEWorkloadIdentity" : true
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "users",
    "compartment" : "Training-NoSQL",
    "includeTTL" : true,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "useSourceSchema" : true
    },
    "useOKEWorkloadIdentity" : true,
    "writeUnitsPercent" : 90,
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.7.0"
}
  2. 構成マップ・リソース(configmap)を作成して、実行時にKubernetesポッドのMigratorコンテナにmigrator-config.json構成入力ファイルを渡します。configmapは、マイグレータ構成ファイルをコンテナのファイル・システムにマウント・ボリュームとしてマウントします。
    #Command:
kubectl create configmap oci-migrator-config --from-file=<Migrator configuration file> -n <namespace-name>
    #Example:
kubectl create configmap oci-migrator-config --from-file=migrator-config.json -n migrator
    #Output:
configmap/oci-migrator-config created
  3. コンテナ・レジストリからKubernetesポッドにマイグレータDockerイメージをプルするときに使用するOCI資格証明を含むDockerレジストリ・シークレットを作成します。
    #Command:
kubectl create secret docker-registry ocirsecret --docker-server=<region-key>.ocir.io --docker-username='tenancy-namespace/username' --docker-password='auth token' --docker-email='<user Email>' -n <namespace-name>
    #Example:
kubectl create secret docker-registry ocirsecret --docker-server=iad.ocir.io --docker-username='idhx..xxwjzj/rx..xxxxh@oracle.com' --docker-password='<Auth token>' --docker-email='rx..xxxxh@oracle.com' -n migrator
    #Output:
secret/ocirsecret created
  4. マニフェスト・ファイルを作成します。これを使用して、Migrator Dockerイメージを指定します。ネームスペース、Kubernetesサービス・アカウント名、Dockerイメージ名、Dockerレジストリ・シークレットおよびconfigmapの前のステップの値を指定してください。次のマニフェスト・ファイルのサンプルを参照できます。
    #migrator-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nosql-migrator
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nosql-migrator
  template:
    metadata:
      labels:
        app: nosql-migrator
    spec:
      serviceAccountName: migratorsa
      automountServiceAccountToken: true
      containers:
        - name: nosqlmigrator
          image: iad.ocir.io/idhx..xxwjzj/okemigrator:1.0
          imagePullPolicy: Always
          args: ["--config", "/config/migrator-config.json", "--log-level", "DEBUG"]
          volumeMounts:
            - name: config-volume
              mountPath: /config  # Mount the file here
      imagePullSecrets:
        - name: ocirsecret
      volumes:
        - name: config-volume
          configMap:
            name: oci-migrator-config
  5. 次のコマンドを使用して、マイグレータDockerイメージをKubernetesポッドにデプロイします。OKEは、Kubernetesクラスタのノードの1つ上のコンテナでMigratorユーティリティを実行します。
    #Command:
kubectl create -f <manifest file> -n <namespace-name>
    #Example:
kubectl create -f migrator-deployment.yaml -n migrator
    #Output:
deployment.apps/nosql-migrator created
  6. 次のコマンドを使用して、ログを確認できます。
    1. Migratorユーティリティを実行しているポッドの名前をフェッチします。
      #Command:
kubectl get pods -n <namespace-name>
      #Example:
kubectl get pods -n migrator
      #Output:
NAME                            READY   STATUS    RESTARTS   AGE
nosql-migrator-ccdbf549-6sjjg   1/1     Running   0          56s
    2. ポッドの名前を使用して、Migratorログをフェッチします。
      #Command:
kubectl logs -f <kubernetes cluster pod name> -n <namespace-name>
      #Example:
kubectl logs -f nosql-migrator-ccdbf549-6sjjg -n migrator
      #Output:
SLF4J(I): Connected with provider of type [org.apache.logging.slf4j.SLF4JServiceProvider]
[INFO] Configuration for migration:
{
  "source" : {
    "type" : "object_storage_oci",
    "format" : "json",
    "endpoint" : "us-ashburn-1",
    "namespace" : "idhkv1iewjzj",
    "bucket" : "Migrate_oci",
    "prefix" : "userSession",
    "useOKEWorkloadIdentity" : true
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "users",
    "compartment" : "Training-NoSQL",
    "includeTTL" : true,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "useSourceSchema" : true
    },
    "useOKEWorkloadIdentity" : true,
    "writeUnitsPercent" : 90,
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.7.0"
}
[INFO] creating source from given configuration:
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] migration started
[INFO] [cloud sink] : start loading DDLs
[INFO] [cloud sink] : completed loading DDLs
[INFO] [cloud sink] : start loading records
[INFO] [OCI OS source] : start parsing JSON records from object: users/userSession/Data/users_1_5_0.json
[INFO] [OCI OS source] : start parsing JSON records from object: users/userSession/Data/users_6_10_0.json
[INFO] migration completed.
Records provided by source=5, Records written to sink=5, Records failed=0, Records skipped=0.
Elapsed time: 0min 1sec 15ms
Migration completed.

    ノート:

    データ移行は、次のように反復的に実行できます。

    1. 次のコマンドを使用して、nosql-migratorコンテナを削除します。
      #Command:
kubectl delete -f <manifest file> -n <namespace-name>
      #Example:
kubectl delete -f migrator-deployment.yaml -n migrator
      #Output:
deployment.apps "nosql-migrator" deleted
    2. migrator-config.json構成入力ファイルを更新します。
    3. 手順2のコマンドを使用して、configmapを削除して再作成します。

      Dockerレジストリ・シークレットを作成し、再度マニフェスト・ファイルを作成する必要はありません。

    4. マニフェスト・ファイル(ステップ5)を使用して、KubernetesポッドにMigrator Dockerイメージをデプロイします。
検証

データのリストアを確認するには、Oracle NoSQL Database Cloud Serviceコンソールにログインします。ナビゲーション・バーから、「データベース」→「NoSQLデータベース」に移動します。ドロップダウンからコンパートメントを選択して、users表を表示します。コンソールにアクセスする手順は、インフラストラクチャ・コンソールからサービスへのアクセスを参照してください。

セッション・トークン認証を使用したOracle NoSQL DatabaseからOCIオブジェクト・ストレージへの移行

この例では、Oracle NoSQL Database Migratorをセッション・トークン認証とともに使用して、Oracle NoSQL Database表からOCIオブジェクト・ストレージ・バケット内のJSONファイルにデータをコピーする方法を示します。

ユース・ケース

開発者は、Oracle NoSQL Database表データをOCI Object Storage (OCI OS)にバックアップするオプションを検討しています。セッション・トークンベースの認証を使用します。

このデモンストレーションでは、OCIコマンドライン・インタフェース・コマンド(CLI)を使用してセッション・トークンを作成します。マイグレータ構成ファイルを手動で作成し、データ移行を実行します。

前提条件
  • 移行するソースとシンクを指定します。
    • 出典: Oracle NoSQL Databaseのusers表。
    • Sink: OCI OSバケットのJSONファイル

      OCI OSのリージョン・エンドポイント、ネームスペース、バケットおよび接頭辞を識別します。詳細は、Oracle Cloud Object Storageへのアクセスを参照してください。 OCI OSサービス・エンドポイントのリストは、オブジェクト・ストレージ・エンドポイントを参照してください。

      • エンドポイント: us-ashburn-1
      • バケット: Migrate_oci
      • 接頭辞: userSession
      • 名前空間: idhkv1iewjzj
        バケットのネームスペース名は、そのテナンシのネームスペースと同じで、テナンシの作成時に自動生成されます。名前空間名は次のように取得できます。
        • Oracle NoSQL Database Cloud Serviceコンソールから、「ストレージ」→「バケット」に移動します。
        • 「リスト範囲」から「コンパートメント」を選択し、バケットを選択します。「バケットの詳細」ページには、「ネームスペース」パラメータに名前が表示されます。

        OCI OSネームスペース名を指定しない場合、マイグレータ・ユーティリティはテナンシのデフォルト・ネームスペースを使用します。

      ノート:

      OCI OSバケットにオブジェクトを書き込む権限があることを確認します。ポリシーの設定の詳細は、オブジェクト・ストレージへの書込みを参照してください。
  • 次のステップに従って、セッション・トークンを生成します。
    • OCI CLIをインストールして構成します。クイックスタートを参照してください。
    • 次のOCI CLIコマンドのいずれかを使用して、セッション・トークンを生成します。使用可能なオプションの詳細は、CLIのトークンベース認証を参照してください。
      #Create a session token using OCI CLI from a web browser:
oci session authenticate --region <region_name> --profile-name <profile_name>
      #Example:
oci session authenticate --region us-ashburn-1 --profile-name SESSIONPROFILE

      または

      #Create a session token using OCI CLI without a web browser:
oci session authenticate --no-browser --region <region_name> --profile-name <profile_name>
      #Example:
oci session authenticate --no-browser --region us-ashburn-1 --profile-name SESSIONPROFILE

      前述のコマンドでは、

      region_name: OCI OSのリージョン・エンドポイントを指定します。Oracle NoSQL Database Cloud Serviceでサポートされるデータ・リージョンのリストは、データ・リージョンおよび関連サービスURLを参照してください。

      profile_name: OCI CLIコマンドがセッション・トークンの生成に使用するプロファイルを指定します。

      OCI CLIコマンドは、次のサンプルに示すように、OCI構成ファイルの$HOME/.oci/configパスにエントリを作成します。
      [SESSIONPROFILE]
fingerprint=f1:e9:b7:e6:25:ff:fe:05:71:be:e8:aa:cc:3d:0d:23
key_file=$HOME/.oci/sessions/SESSIONPROFILE/oci_api_key.pem
tenancy=ocid1.tenancy.oc1..aaaaa ... d6zjq
region=us-ashburn-1
security_token_file=$HOME/.oci/sessions/SESSIONPROFILE/token

      security_token_fileは、前述のOCI CLIコマンドを使用して生成したセッション・トークンのパスを指します。

      ノート:

      • プロファイルがOCI構成ファイル内にすでに存在する場合、OCI CLIコマンドは、セッション・トークンの生成中に、セッション・トークン関連の構成でプロファイルを上書きします。
      • シンク構成テンプレートで次を指定します。
        • credentialsパラメータ内のOCI構成ファイルへのパス。
        • credentialsProfileパラメータでセッション・トークンの生成時に使用されるプロファイル。 
        "credentials" : "$HOME/.oci/config"
"credentialsProfile" : "SESSIONPROFILE"

        Migratorユーティリティは、前述のパラメータを使用して生成されたセッション・トークンの詳細を自動的にフェッチします。credentialsパラメータを指定しない場合、マイグレータ・ユーティリティはパス$HOME/.ociの資格証明ファイルを検索します。credentialsProfileパラメータを指定しない場合、Migratorユーティリティでは、OCI構成ファイルからのデフォルトのプロファイル名(DEFAULT)が使用されます。

      • セッション・トークンは60分間有効です。セッション期間を延長するには、セッションをリフレッシュします。詳細は、トークンのリフレッシュを参照してください。
手順

Oracle NoSQL Database表からOCI OSバケットのJSONファイルに移行するには:

  1. OCI OSバケット・シンク内のOracle NoSQL DatabaseソースおよびJSONファイルを使用して、構成ファイル(JSON形式)を準備します。テンプレートについては、「ソース構成テンプレート」および「シンク構成テンプレート」を参照してください
    セッション・トークン認証を使用してOCI OSバケットにアクセスするには、シンク構成テンプレートでuseSessionTokenパラメータをtrueに設定します。それに応じて、credentialsパラメータに構成パスを指定し、credentialsProfileパラメータにプロファイル名を指定します。 
    {
  "source" : {
    "type" : "nosqldb",
    "storeName" : "kvstore",
    "helperHosts" : ["<hostname>:<port>"],
    "table" : "users",
    "includeTTL" : true,
    "requestTimeoutMs" : 5000
  },
  "sink" : {
    "type" : "object_storage_oci",
    "format" : "json",
    "endpoint" : "us-ashburn-1",
    "namespace" : "idhkv1iewjzj",
    "bucket" : "Migrate_oci",
    "prefix" : "userSession",
    "chunkSize" : 32,
    "compression" : "",
    "useSessionToken" : true,
    "credentials" : "$/home/.oci/config",
    "credentialsProfile" : "SESSIONPROFILE"
  },
  "abortOnError" : true,
  "migratorVersion" : "1.7.0"
}
  2. コマンド・プロンプトを開き、NoSQL Database Migratorユーティリティを抽出したディレクトリに移動します。
  3. 構成ファイル・オプションを渡して、runMigratorコマンドを実行します。--configまたは-cオプションを使用して、次のように構成ファイルを渡します。
    ./runMigrator --config ./migrator-config.json
  4. Migratorユーティリティは、データ移行を進めます。次に、出力例を示します。
    useSessionTokenパラメータをtrueに設定すると、マイグレータ・ユーティリティはセッション・トークンを使用して自動的に認証します。Migratorユーティリティは、users表からMigrate_ociという名前のOCI OSバケット内のJSONファイルにデータをコピーします。正常なデータ・バックアップがないかログを確認します。 
    [INFO] creating source from given configuration:
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] [OCI OS sink] : writing table schema to userSession/Schema/schema.ddl
[INFO] migration started
[INFO] Migration success for source users_6_10. read=2,written=2,failed=0
[INFO] Migration success for source users_1_5. read=3,written=3,failed=0
[INFO] Migration is successful for all the sources.
[INFO] migration completed.
Records provided by source=5, Records written to sink=5, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 982ms
Migration completed.

    ノート:

    移行ユーティリティは、シンク構成テンプレートのchunkSizeパラメータに応じて、ソース・データを同じディレクトリ内の複数のJSONファイルに分割します。この例では、Migratorユーティリティによって、Migrate_oci/userSession/Dataディレクトリのusers_1_5_0.jsonファイルおよびusers_6_10_0.jsonファイルにデータがコピーされます。

    ソース表スキーマは、Migrate_oci/userSession/Schemaディレクトリのschema.ddlファイルにコピーされます。

検証

データ・バックアップを確認するには、Oracle NoSQL Database Cloud Serviceコンソールにログインします。メニュー Storage > Object Storage & Archive Storage > Bucketsをナビゲートします。Migrate_ociバケットのuserSessionディレクトリからファイルにアクセスします。コンソールにアクセスする手順は、インフラストラクチャ・コンソールからのサービスのアクセスを参照してください

CSVファイルからOracle NoSQL Database Cloud Serviceへの移行

この例は、Oracle NoSQL Database Migratorを使用してCSVファイルからOracle NoSQL Database Cloud Serviceにデータをコピーする方法を示します。

例

複数のオプションを評価した後、組織はOracle NoSQL Database Cloud ServiceをNoSQLデータベース・プラットフォームとして最終決定します。ソース・コンテンツはCSVファイル形式であるため、これをOracle NoSQL Database Cloud Serviceに移行する方法を探しています。

この例では、course.CSVというCSVファイルからデータを移行する方法を学習します。このファイルには、大学が提供する様々なコースに関する情報が含まれています。構成ファイルは、runMigratorユーティリティから対話形式で生成します。

識別されたソースおよびシンクの詳細を含む構成ファイルを準備することもできます。Oracle NoSQL Database Migratorリファレンスを参照してください。

前提条件
  • 移行のソースを特定します。
    • ソース: CSVファイル

      この例では、ソース・ファイルはcourse.csvです

      
1,"Computer Science", "San Francisco", "2500"
2,"Bio-Technology", "Los Angeles", "1200"
3,"Journalism", "Las Vegas", "1500"
4,"Telecommunication", "San Francisco", "2500"
    • CSVファイルはRFC4180形式に準拠している必要があります。
    • ターゲット表courseのスキーマのDDLコマンドを含むファイルを作成します。テーブル定義は、カラム数とそのタイプに関するCSVデータファイルと一致する必要があります。

      この例では、DDLファイルはmytable_schema.DDLです。

      
create table course (id INTEGER, name STRING, location STRING, fees INTEGER, PRIMARY KEY(id));
  • 移行するシンクを特定します。
    • シンク: Oracle NoSQL Database Cloud Service
    • OCIクラウド資格証明を指定し、構成ファイルで取得します。構成ファイルを/home/<user>/.oci/configに保存します。詳細は、「資格証明の取得」を参照してください。
      [DEFAULT]
tenancy=ocid1.tenancy.oc1....
user=ocid1.user.oc1....
fingerprint= 43:d1:....
region=us-ashburn-1
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=<passphrase>
    • Oracle NoSQL Database Cloud Serviceのリージョン・エンドポイントおよびコンパートメント名を指定します。
      • エンドポイント: us-ashburn-1
      • コンパートメント: ocid1.compartment.oc1..aaaaaaaavjikiwmylfnpofefbdaleg6rqyf7cdnr5o6vozg4lyajeunrhsmq
手順
course.csvファイルからOracle NoSQL Database Cloud Serviceにデータを移行するには、次のステップを実行します:
  1. コマンド・プロンプトを開き、Oracle NoSQL Database Migratorユーティリティを抽出したディレクトリに移動します。
  2. Oracle NoSQL Database Migratorを使用して構成ファイルを生成するには、ランタイム・パラメータを指定せずにrunMigratorコマンドを実行します。
    [~/nosql-migrator-1.7.0]$./runMigrator
  3. ランタイム・パラメータとして構成ファイルを指定しなかったため、構成を今すぐ生成するかどうかを尋ねるプロンプトが表示されます。yと入力します。
    構成ファイルの場所を選択するか、Enter keyを押してデフォルトの場所を保持できます。 
    
Configuration file is not provided. Do you want to generate
configuration? (y/n) [n]: y
Generating a configuration file interactively.

Enter a location for your config [./migrator-config.json]: 
./migrator-config.json already exist. Do you want to overwrite?(y/n) [n]: y
  4. ユーティリティーのプロンプトに基づいて、ソース構成のオプションを選択します。
    
Select the source: 
1) nosqldb
2) nosqldb_cloud
3) file
4) object_storage_oci
5) aws_s3
#? 3

Configuration for source type=file
Select the source file format: 
1) json
2) mongodb_json
3) dynamodb_json
4) csv
#? 4
  5. ソースCSVファイルへのパスを指定します。さらに、ユーティリティからのプロンプトに基づいて、列名の順序変更、エンコーディング方法の選択、ターゲット表からの末尾のスペースの削除を選択できます。
    
Enter path to a file or directory containing csv data: [~/nosql-migrator]/course.csv
Does the CSV file contain a headerLine? (y/n) [n]: n
Do you want to reorder the column names of NoSQL table with respect to
CSV file columns? (y/n) [n]: n
Provide the CSV file encoding. The supported encodings are:
UTF-8,UTF-16,US-ASCII,ISO-8859-1. [UTF-8]: 
Do you want to trim the tailing spaces? (y/n) [n]: n
  6. ユーティリティーのプロンプトに基づいて、シンク構成に nosqldb_cloudオプションを選択します。 
    
Select the sink:
1) nosqldb
2) nosqldb_cloud
#? 2
  7. テナンシのエンド・ポイントURLまたはリージョンIDを指定し、Oracle NoSQL Database Cloud ServiceにアクセスするためのMigratorユーティリティの認証タイプを選択します。
    Configuration for sink type=nosqldb_cloud
Enter endpoint URL or region ID of the Oracle NoSQL Database Cloud: us-ashburn-1
Select the authentication type: 
1) credentials_file
2) instance_principal
3) delegation_token
4) session_token
5) oke_workload_identity
#? 1
  8. ユーティリティからのプロンプトに基づいて、認証に使用する資格証明ファイルの名前、資格証明プロファイル、コンパートメントID、およびシンクでのデータのコピー先となる表の名前を指定します。 
    Enter path to the file containing OCI credentials [/home/<user>/.oci/config]: 
Enter the profile name in OCI credentials file [DEFAULT]: 
Enter the compartment name or id of the table []: ua_nosql
Enter table name: course
  9. 選択を入力してTTL値を設定します。デフォルト値はnです。 
    
Include TTL data? If you select 'yes' TTL value provided by the
source will be set on imported rows. (y/n) [n]: y
Would you like to provide TTL reference time?(y/n) [n]: n
  10. ユーティリティからのプロンプトに基づいて、Oracle NoSQL Database Migratorツールを使用してターゲット表を作成する必要があるかどうかを指定します。表がすでに作成されている場合は、nを指定することをお薦めします。表が作成されない場合、ユーティリティは、ターゲット表のスキーマに対するDDLコマンドを含むファイルのパスをリクエストします。
    
Would you like to create table as part of migration process?
Use this option if you want to create table through the migration tool.
If you select yes, you will be asked to provide a file that contains
table DDL or to use schema provided by the source or default schema.
(y/n) [n]: y
Enter path to a file containing table DDL: [~/nosql-migrator]/mytable_schema.ddl
  11. シンクテーブルのスループット値とストレージ割り当てを入力します。 
    Would you like to use on demand read and write units? (y/n) [n]: n
Enter read throughput in KB of new table: 100
Enter write throughput in KB of new table: 60
Enter storage size in GB of new table: 1
Enter percentage of table write units to be used for migration operation. 
(1-100) [90]: 90
  12. 選択内容を入力して、表がシンクですでに使用可能かどうか、レコードを上書きするかどうかを決定します。ソース・データに変換を追加することもできます。
    
would you like to overwrite records which are already present?
If you select 'no' records with same primary key will be skipped [y/n] [y]: y
Enter store operation timeout in milliseconds. [5000]: 
Would you like to add transformations to source data? (y/n) [n]: n
Would you like to continue migration if any data fails to be migrated?
 (y/n) [n]: n
  13. 生成された構成が画面に表示されます。 
    {
  "source" : {
    "type" : "file",
    "format" : "csv",
    "dataPath" : "[~/nosql-migrator]/course.csv",
    "hasHeader" : false,
    "csvOptions" : {
      "encoding" : "UTF-8",
      "trim" : false
    }
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "course",
    "compartment" : "ua_nosql",
    "includeTTL" : true,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "schemaPath" : "[~/nosql-migrator]/mytable_schema.ddl"
    },
    "credentials" : "/home/<user>/.oci/config",
    "credentialsProfile" : "DEFAULT",
    "writeUnitsPercent" : 90,
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.7.0"
}
  14. 最後に、生成された構成ファイルを使用して移行を続行するかどうかを指定するよう求められます。デフォルトのオプションはyです。
    ノート:

    nを選択すると、データ移行は開始されません。生成された構成ファイルは、Migratorディレクトリに保存されます。次のいずれかのコマンドを使用して、構成ファイル・オプションを指定して移行ユーティリティを実行します。

    ./runMigrator -c ./migrator-config.json

    ./runMigrator --config ./migrator-config.json

    
Would you like to run the migration with above configuration?
If you select no, you can use the generated configuration file to
run the migration using:
./runMigrator --config ./migrator-config.json
(y/n) [y]: y
  15. NoSQL Database Migratorが、CSVファイルからOracle NoSQL Database Cloud Serviceにデータをコピーします。
    creating source from given configuration:
source creation completed
creating sink from given configuration:
sink creation completed
creating migrator pipeline
[cloud sink] : start loading DDLs
[cloud sink] : executing DDL: create table if not exists course (id INTEGER, name STRING, location STRING, fees INTEGER, PRIMARY KEY(id)),limits: [100, 60, 1]
[cloud sink] : completed loading DDLs
migration started
[csv file source] : start parsing CSV records from file: course.csv
Migration success for source course. read=4,written=4,failed=0
Migration is successful for all the sources.
migration completed.
Records provided by source=4, Records written to sink=4, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 395ms
Migration completed.
検証

移行を検証するには、Oracle NoSQL Database Cloud Serviceコンソールにログインし、course表にアクセスします。表にはソース・データが含まれます。コンソールにアクセスする手順は、Oracle NoSQL Database Cloud Serviceドキュメントのインフラストラクチャ・コンソールからのサービスへのアクセスを参照してください。