Oracle NoSQL Database Migratorの使用
Oracle NoSQL Database Migratorと、それをデータ移行に使用する方法について学習します。
Oracle NoSQL Database Migratorは、Oracle NoSQL表をあるデータソースから別のデータソースに移行できるツールです。This tool can operate on tables in Oracle NoSQL Database Cloud Service, Oracle NoSQL Database on-premises and 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ファイルなど)に移動できます。
There can be many situations that require you to migrate NoSQL tables from or to an Oracle NoSQL Database.たとえば、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で使用される用語
前述の図で使用されている様々な用語について詳しく説明します。
- ソース: 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) 目 的 サポートされる値 sourcetypeはい データの移行元のソースを表します。ソースは、移行用のデータおよびメタデータ(存在する場合)。 各ソースの type値の詳細は、サポートされるソースとシンクを参照してください。sourceタイプのソース構成 はい ソースの構成を定義します。これらの構成パラメータは、前に選択したソースのタイプに固有です。 各ソース・タイプの構成パラメータの一覧は、ソース構成テンプレートを参照してください。 sinktypeはい データの移行先のシンクを表します。シンクは、移行のターゲットまたは宛先です。 各ソースの type値の詳細は、サポートされるソースとシンクを参照してください。sinkタイプのシンク構成 はい シンクの構成を定義します。これらの構成パラメータは、前に選択したシンクのタイプに固有です。 シンク・タイプごとの構成パラメータの一覧は、Sink Configuration Templates を参照してください。 transforms変換構成 N 移行パイプ内のデータに適用する変換を定義します。 NoSQLデータ・マイグレータでサポートされている変換の一覧は、変換構成テンプレート を参照してください。 - migratorVersionN NoSQLデータ・マイグレータのバージョン - - abortOnErrorN エラーの場合に移行アクティビティを停止するかどうかを指定します。
デフォルト値はtrueで、移行エラーが発生するたびに移行が停止することを示します。
この値をfalseに設定すると、失敗したレコードやその他の移行エラーが発生した場合でも移行が続行されます。失敗したレコードおよび移行エラーは、CLI端末に警告として記録されます。
true、false ノート:
JSONファイルでは大/小文字が区別されるため、特に指定されていないかぎり、構成ファイルに定義されているすべてのパラメータで大文字小文字が区別されます。
サポートされているソースとシンク
このトピックでは、Oracle NoSQL Database Migratorでサポートされるソースとシンクのリストを示します。
移行アクティビティには、この表の有効なソースとシンクの組合せを使用できます。ただし、少なくとも一方の端、つまりソースまたはシンクがOracle NoSQL製品である必要があります。NoSQLデータベース・マイグレータを使用して、NoSQL表データを別のファイルに移動することはできません。
|
タイプ |
フォーマット |
有効なソース | 有効なシンク |
|---|---|---|---|
|
Oracle NoSQL Database |
NA | はい | はい |
|
Oracle NoSQL Database Cloud Service |
NA | はい | はい |
|
ファイル・システム |
JSON |
はい | はい |
|
MongoDB JSON |
はい | N | |
|
DynamoDB JSON |
はい | N | |
|
パーケット( |
N | はい | |
|
CSV |
はい | N | |
|
OCIオブジェクト・ストレージ |
JSON |
はい | はい |
|
MongoDB JSON |
はい | N | |
|
パーケット( |
N | はい | |
|
CSV |
はい | N | |
| AWS S3 |
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.jarをlibディレクトリにコピーします。
<MIGRATOR_HOME>/libディレクトリにkvstore-EE.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の使用に関連するタスクの高レベル・フローを示します。
NoSQLデータ・マイグレータ・ユーティリティのダウンロード
runMigratorコマンドにアクセスできます。
ノート:
Oracle NoSQL Database Migratorユーティリティを実行するには、Java 11以降のバージョンが必要です。ソースとシンクの指定
- シンク表スキーマの指定:シンクがオンプレミスまたはクラウドの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には、表のスキーマを事前定義する必要はありません。これは、主にOracle NoSQL DatabaseにJSONソース・ファイルをロードする場合に役立ちます。
- 表スキーマの提供: NoSQL Database Migratorでは、ソースはschemaInfo属性を使用して表データのスキーマ定義を提供できます。schemaInfo属性は、暗黙的スキーマがまだ定義されていないすべてのデータ・ソースで使用できます。シンク・データ・ストアでは、次のオプションのいずれかを選択できます。
- NoSQL Database Migratorで定義されたデフォルトのスキーマを使用します。
- ソース提供スキーマを使用します。
- 独自のスキーマを定義して、ソース提供のスキーマをオーバーライドします。たとえば、ソース・スキーマから別のスキーマにデータを変換する場合は、ソース提供のスキーマをオーバーライドし、NoSQL Database Migratorツールの変換機能を使用する必要があります。
たとえば、表スキーマ・ファイル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パラメータにファイル・パスを指定します。
表の行のTTLメタデータの移行
ノート:
表の行のTTLメタデータ移行のサポートは、Oracle NoSQL DatabaseおよびOracle NoSQL Database Cloud Serviceのみ使用できます。TTLメタデータをエクスポートしています
_metadata JSONオブジェクトに含まれています。NoSQL Database Migratorは、各行の有効期限を、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メタデータをインポートできます。インポート操作では、TTLメタデータを含む表の行を移行する際に次のユースケースが処理されます。これらのユースケースは、includeTTL構成パラメータが指定されている場合にのみ適用されます。
- ユースケース1: インポートする表の行にTTLメタデータ情報がありません。
外部ソースから生成された、または以前のバージョンの移行を使用してエクスポートされたJSONソース・ファイルをインポートする場合、インポートする行にはTTL情報がありません。ただし、includeTTL構成パラメータは
trueと等しいため、マイグレータは表の行にTTL=0を設定します。つまり、インポートする表の行は失効しません。 - ユースケース2: 表の行がインポートされると、ソース表の行のTTL値が参照時間に対して失効します。
表の行をファイルにエクスポートし、これを表の行の失効後にインポートしようとすると、表の行は無視され、ストアに書き込まれません。
- ユースケース3: 表の行がインポートされると、ソース表の行のTTL値が参照時間に対して失効しません。
表の行をファイルにエクスポートし、これを表の行の失効時間より前にインポートしようとすると、表の行がTTL値でインポートされます。ただし、TimeToLiveクラスの整数時間と日の期間の制約のため、表の行の新しいTTL値はエクスポートされたTTL値と等しくない場合があります。例
エクスポートされた表の行{ "id" : 8, "name" : "xyz", "_metadata" : { "expiration" : 1629709200000 //Monday, August 23, 2021 9:00:00 AM in UTC } }インポート中の参照時間は1629707962582で、2021年8月23日月曜日8:39:22.582 AMです。
インポートされた表の行{ "id" : 8, "name" : "xyz", "_metadata" : { "ttl" : 1629712800000 //Monday, August 23, 2021 10:00:00 AM UTC } }
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ソース・ファイル |
構成ファイルを作成/生成します。 |
データ移行に成功しました。IDENTITY列の値は自動生成されます。Oracle NoSQL Databaseシンク表 |
|
ケース2: ソース・データで、シンク表のIDENTITYフィールドに値が指定されます。 例: JSONソース・ファイル |
構成ファイルを作成/生成します。シンク構成テンプレートのID列にignoreFields変換を指定します。
|
データ移行に成功しました。指定されたID値はスキップされ、IDENTITY列の値は自動生成されます。 Oracle NoSQL Databaseシンク表
migrateIDにデータを移行しました: |
|
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ソース・ファイル |
構成ファイルを作成/生成します。 |
データ移行に成功しました。IDENTITY列の値は自動生成されます。Oracle NoSQL Databaseシンク表
migrateIDにデータを移行しました: |
|
ケース2: ソース・データがシンク表のIDENTITYフィールドに値を提供し、これが主キー・フィールドです。 例: JSONソース・ファイル |
構成ファイルを作成/生成します。シンク構成テンプレート(推奨)のID列にignoreFields変換を指定します。
|
データ移行に成功しました。指定されたID値はスキップされ、IDENTITY列の値は自動生成されます。 Oracle NoSQL Databaseシンク表
migrateIDにデータを移行しました: |
|
IDENTITY列のignoreFields変換なしで、構成ファイルを作成/生成します。 |
データ移行に成功しました。ソースから指定された ID値を指定せずに表に追加行を挿入しようとすると、順序ジェネレータがID値の自動生成しようとします。シーケンス・ジェネレータの開始値は1です。その結果、生成されたID値がシンク表内の既存のID値のいずれかを複製する可能性があります。これは主キー制約違反であるため、エラーが返され、行は挿入されません。 詳細は、順序ジェネレータを参照してください。 主キー制約違反を回避するために、順序ジェネレータは、シンク表の既存のID値と競合しない値で順序を開始する必要があります。START WITH属性を使用してこの変更を行うには、次の例を参照してください: 例: Oracle NoSQL Databaseシンク表
migrateIDにデータを移行しました:順序ジェネレータがID列に挿入する適切な値を検索するには、次の問合せを使用して
IDフィールドの最大値をフェッチします:出力:
シンク表の
ID列の最大値は3です。複製を避けるために、順序ジェネレータで3を超えるID値の生成を開始する必要があります。次の文を使用して、順序ジェネレータのSTART WITH属性を4に更新します:これにより、順序は4から開始されます。 これで、ID値を指定せずにシンク表に行を挿入すると、順序ジェネレータによってID値が4以降から自動生成され、IDの重複が回避されるようになります。 |
トランスフォーメーション・コンフィギュレーション・パラメータの詳細は、「トランスフォーメーション・コンフィギュレーション・テンプレート」のトピックを参照してください。
runMigratorコマンドの実行
runMigrator実行可能ファイルは、抽出されたNoSQL Database Migratorファイルで使用できます。Java 11以上のバージョンおよびbashをシステムにインストールして、runMigratorコマンドを正常に実行する必要があります。
runMigratorコマンドを実行できます。
- 次のように、
runMigratorコマンドのランタイム・オプションを使用して構成ファイルを作成します。[~]$ ./runMigrator configuration file is not provided. Do you want to generate configuration? (y/n) [n]: y ... ...runMigratorユーティリティを起動すると、一連の実行時オプションが提供され、各オプションの選択内容に基づいて構成ファイルが作成されます。- ユーティリティによって構成ファイルが作成された後は、同じ実行で移行アクティビティを続行するか、将来の移行のために構成ファイルを保存できます。
- 生成された構成ファイルでの移行アクティビティの続行または延期に関係なく、将来の要件を満たすようにファイルを編集またはカスタマイズできます。カスタマイズした構成ファイルは、後で移行に使用できます。
-cまたは--configオプションを使用して、手動で作成した構成ファイル(JSON形式)を実行時パラメータとして渡します。-cまたは--configオプションを付けてrunMigratorコマンドを実行する前に、構成ファイルを手動で作成する必要があります。ソースおよびシンク構成パラメータのヘルプは、Oracle NoSQL Databaseマイグレータ・リファレンスを参照してください。[~]$ ./runMigrator -c </path/to/the/configuration/json/file>
ミグレータの進捗状況のロギング
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のユースケース・デモ
特定のユースケースで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> - Identify the region endpoint and compartment name for your Oracle NoSQL Database Cloud Service.
- エンドポイント:
us-phoenix-1 - コンパートメント:
developers
- エンドポイント:
myTableのデータおよびスキーマ定義を移行するには:
JSONシンク・ファイルを開き、スキーマとデータを表示します。
-- Exported myTable Data
[~/nosqlMigrator]$cat myTableJSON
{
"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)))オンプレミスの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> - Identify the region endpoint and compartment name for your Oracle NoSQL Database Cloud Service.
- エンドポイント:
us-phoenix-1 - コンパートメント:
developers
- エンドポイント:
- オンプレミスKVStoreの次の詳細を指定します。
- storeName:
kvstore - helperHosts:
<hostname>:5000 - 表:
myTable
- storeName:
myTableのデータおよびスキーマ定義をNoSQLデータベースKVStoreからNDCSに移行するには:
移行を検証するには、NDCSコンソールにログインし、ソース・データを使用してmyTableが作成されていることを確認します。
Migrate from JSON file source to 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
- ソース: JSONソース・ファイル。
- 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> - Identify the region endpoint and compartment name for your 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ソース・ファイルを移行するには、次を実行します。
Migrate_JSON表が作成されていることを確認します。コンソールにアクセスする手順は、Oracle NoSQL Database Cloud Serviceドキュメントのインフラストラクチャ・コンソールからのサービスへのアクセスを参照してください。
図- Oracle NoSQL Database Cloud Serviceコンソールの表データ
MongoDB JSONファイルからOracle NoSQL Database Cloud Serviceへの移行
この例では、Oracle NoSQL Databaseマイグレータを使用して、Mongo-DB形式のデータをOracle NoSQL Database Cloud Service (NDCS)にコピーする方法を示します。
ユースケース
複数のオプションを評価した後、組織はOracle NoSQL Database Cloud ServiceをNoSQLデータベース・プラットフォームとして最終決定します。NoSQLの表およびデータはMongoDBにあるため、これらの表およびデータをOracle NDCSに移行する方法を探しています。
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"}]}
MongoDBは、標準モードおよび緩和モードの2種類のファイルのJSON形式に対する拡張をサポートしています。モンゴエクスポート・ツールを使用して正規モードまたは緩和モードで生成されるMongoDB形式のJSONファイルを指定できます。どちらのモードも、移行のためにNoSQL Database Migratorでサポートされています。
MongoDB Extended JSON (v2)ファイルの詳細は、mongoexport_formatsを参照してください。
MongoDB形式のJSONファイルの生成の詳細は、mongoexportを参照してください。
例
デモでは、MongoDB形式のJSONファイルをNDCSに移行する方法について説明します。この例では、手動で作成した構成ファイルを使用します。- 移行するソースとシンクを指定します。
- ソース: MongoDB形式のJSONファイル
- シンク: Oracle NoSQL Database Cloud Service
- モンゴ・エクスポート・ユーティリティを使用してモンゴDBからデータを抽出します。詳細は、mongoexportを参照してください。
- Mongo-DB形式のJSONファイルのデータと一致する表スキーマを使用して、シンクにNoSQL表を作成します。もう1つの方法として、
defaultSchema属性をtrueに設定することで、デフォルトのスキーマ構造で表を作成するようにNoSQL Database Migratorに指示することもできます。ノート:
MongoDB形式のJSONソースの場合、表のデフォルト・スキーマは次のようになります。CREATE TABLE IF NOT EXISTS <tablename>(ID STRING, DOCUMENT JSON,PRIMARY KEY(SHARD(ID))説明:tablename= 表構成の値。ID= mongoDBでエクスポートされたJSONソース・ファイルからの_id値。DOCUMENT= mongoDBでエクスポートされたJSONソース・ファイルの内容全体が、_idフィールドを除くDOCUMENT列に集計されます。
- 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> - Identify the region endpoint and compartment name for your Oracle NoSQL Database Cloud Service.
- エンドポイント:
us-phoenix-1 - コンパートメント:
developers
- エンドポイント:
MongoDB形式のJSONデータをOracle NoSQL Database Cloud Serviceに移行するには:
移行を検証するには、NDCSコンソールにログインし、ソース・データを使用してmyTableが作成されていることを確認します。
DynamoDB JSONファイルからOracle NoSQL Databaseへの移行
この例では、Oracle NoSQL Database Migratorを使用したDynamoDB JSONファイルのOracle NoSQL Databaseへのコピー方法を示します。
ユースケース:
複数のオプションを評価した後、組織はDynamoDBデータベースを介してOracle NoSQL Databaseを最終決定します。組織は、表およびデータをDynamoDBからOracle NoSQL Database(オンプレミス)に移行しようとしています。
詳細は、「DynamoDB表からOracle NoSQL表へのマッピング」 を参照してください。
ソース構成テンプレートでパスを指定することで、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表データをAWS S3ストレージからローカルにマウントされたファイル・システムにコピーします。
次に例を示します:
このデモでは、DynamoDB JSONファイルをOracle NoSQL Database (オンプレミス)に移行する方法について学習します。この例では、手動で作成した構成ファイルを使用します。
前提条件
- 移行するソースとシンクを指定します。
- ソース: DynamoDB JSONファイル
- シンク: Oracle NoSQL Database (オンプレミス)
- 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
手順
- 識別されたソースで構成ファイルを(JSON形式で)準備し、details.See 「Source Configuration Templates」および「Sink Configuration Templates」をシンクします。
次の2つのオプションのいずれかを選択できます。
- オプション1:デフォルトのスキーマ構成を使用して、DynamoDB表をJSONドキュメントとしてインポートします。
ここで、
defaultSchemaはTRUEであるため、マイグレータはシンクにデフォルトのスキーマを作成します。DDBPartitionKeyおよび対応するNoSQL列タイプを指定する必要があります。そうしないと、エラーが発生します。{ "source" : { "type" : "file", "format" : "dynamodb_json", "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>" }, "sink" : { "type" : "nosqldb", "table" : "<table_name>", "storeName" : "kvstore", "helperHosts" : ["<hostname>:5000"] "schemaInfo" : { "defaultSchema" : true, "DDBPartitionKey" : "<PrimaryKey:Datatype>", }, }, "abortOnError" : true, "migratorVersion" : "1.0.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:ユーザー指定のスキーマ・ファイルを使用して、DynamoDB表を固定列としてインポートします。
defaultSchemaはFALSEで、schemaPathをDDL文を含むファイルとして指定します。詳細は、「DynamoDB型からOracle NoSQL型へのマッピング」 を参照してください。ノート:
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が挿入されます。{ "source" : { "type" : "file", "format" : "dynamodb_json", "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>" }, "sink" : { "type" : "nosqldb", "table" : "<table_name>", "schemaInfo" : { "defaultSchema" : false, "readUnits" : 100, "writeUnits" : 60, "schemaPath" : "<full path of the schema file with the DDL statement>", "storageSize" : 1 }, "storeName" : "kvstore", "helperHosts" : ["<hostname>:5000"] }, "abortOnError" : true, "migratorVersion" : "1.0.0" }
- オプション1:デフォルトのスキーマ構成を使用して、DynamoDB表をJSONドキュメントとしてインポートします。
- コマンド・プロンプトを開き、NoSQLデータベース・マイグレータ・ユーティリティを抽出したディレクトリに移動します。
--configまたは-cオプションを使用して構成ファイルを渡し、runMigratorコマンドを実行します。[~/nosqlMigrator/nosql-migrator-1.0.0]$./runMigrator --config <complete/path/to/the/JSON/config/file>- 次に示すように、ユーティリティはデータの移行に進みます。
Records provided by source=7.., Records written to sink=7, Records failed=0, Records skipped=0. Elapsed time: 0 min 2sec 50ms Migration completed.
検証
java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstoredesc <table_name>
SELECT * from <table_name>AWS S3のDynamoDB JSONファイルからOracle NoSQL Database Cloud Serviceへの移行
この例では、Oracle NoSQL Database移行プログラムを使用して、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ストレージから移行できます。
{"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 - マイグレータから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のリージョン・エンドポイントおよびコンパートメント名を指定します。例
- エンドポイント: us-phoenix-1
- コンパートメント:開発者
手順
- 識別されたソースおよびシンクの詳細を含む構成ファイル(JSON形式)を準備します。ソース構成テンプレート およびSink Configuration Templates を参照してください。
次の2つのオプションのいずれかを選択できます。
- オプション1:デフォルトのスキーマ構成を使用して、DynamoDB表をJSONドキュメントとしてインポートします。
ここで、
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.0.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:ユーザー指定のスキーマ・ファイルを使用して、DynamoDB表を固定列としてインポートします。
defaultSchemaはFALSEで、schemaPathをDDL文を含むファイルとして指定します。詳細は、「DynamoDB型からOracle NoSQL型へのマッピング」 を参照してください。ノート:
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が挿入されます。{ "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 }, "abortOnError" : true, "migratorVersion" : "1.0.0" }
- オプション1:デフォルトのスキーマ構成を使用して、DynamoDB表をJSONドキュメントとしてインポートします。
- コマンド・プロンプトを開き、NoSQLデータベース・マイグレータ・ユーティリティを抽出したディレクトリに移動します。
--configまたは-cオプションを使用して構成ファイルを渡し、runMigratorコマンドを実行します。[~/nosqlMigrator/nosql-migrator-1.0.0]$./runMigrator --config <complete/path/to/the/JSON/config/file>- 次に示すように、ユーティリティはデータの移行に進みます。
Records provided by source=7.., Records written to sink=7, Records failed=0, Records skipped=0. Elapsed time: 0 min 2sec 50ms Migration completed.
検証
NDCSコンソールにログインし、ソース・データを使用して新しい表が作成されていることを確認します。
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=23456user_data表をアッシュバーン・リージョンからフェニックス・リージョンに移行するには、次を実行します:
移行を検証するには、「フェニックス」リージョンで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: <>ネームスペースを指定しない場合、ユーティリティはテナンシのデフォルト・ネームスペースを使用します。
ノート:
オブジェクト・ストレージ・バケットが別のコンパートメントにある場合は、バケットにオブジェクトを書き込む権限があることを確認してください。ポリシーの設定の詳細は、ユーザーによるオブジェクト・ストレージ・バケットへのオブジェクトの書込みを参照してください。 - エンドポイント:
-
NDCSupload表をバックアップするには、次を実行します:
データ・バックアップを検証するには、Oracle NoSQL Database Cloud Serviceコンソールにログインします。メニューStorage > Object Storage & Archive Storage > Bucketsをナビゲートします。Migrate_ociバケットのNDCSupload/Delegationディレクトリからファイルにアクセスします。コンソールにアクセスする手順は、インフラストラクチャ・コンソールからのサービスへのアクセスを参照してください。
CSVファイルからOracle NoSQL Databaseへの移行
この例は、Oracle NoSQL Database Migratorを使用してCSVファイルのデータをOracle NoSQL Databaseにコピーする方法を示しています。
例
複数のオプションを評価した後、組織はOracle NoSQL DatabaseをNoSQLデータベース・プラットフォームとして最終決定します。ソース・コンテンツがCSVファイル形式であるため、これをOracle NoSQL Databaseに移行する方法を探そうとします。
この例では、course.CSVというCSVファイルからデータを移行する方法を学習します。このファイルには、大学が提供する様々なコースに関する情報が含まれています。構成ファイルは、runMigratorユーティリティから生成します。
識別されたソースおよびシンクの詳細を含む構成ファイルを準備することもできます。Oracle NoSQL Database Migratorリファレンスを参照してください。
- 移行するソースとシンクを指定します。
- ソース: CSVファイル
この例では、ソース・ファイルは
course.csvですcat [~/nosql-migrator-1.5.0]/course.csv 1,"Computer Science", "San Francisco", "2500" 2,"Bio-Technology", "Los Angeles", "1200" 3,"Journalism", "Las Vegas", "1500" 4,"Telecommunication", "San Francisco", "2500" - シンク: Oracle NoSQL Database
- ソース: CSVファイル
- CSVファイルは
RFC4180形式に準拠している必要があります。 - ターゲット表
courseのスキーマのDDLコマンドを含むファイルを作成します。テーブル定義は、カラム数とそのタイプに関するCSVデータファイルと一致する必要があります。この例では、DDLファイルは
mytable_schema.DDLです。cat [~/nosql-migrator-1.5.0]/mytable_schema.ddl create table course (id INTEGER, name STRING, location STRING, fees INTEGER, PRIMARY KEY(id));
course.CSVからOracle NoSQL Database Serviceに移行するには、次のステップを実行します:
java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstore
sql-> select * from course;
{"id":4,"name":"Telecommunication","location":"San Francisco","fees":2500}
{"id":1,"name":"Computer Science","location":"San Francisco","fees":2500}
{"id":2,"name":"Bio-Technology","location":"Los Angeles","fees":1200}
{"id":3,"name":"Journalism","location":"Las Vegas","fees":1500}
4 rows returned