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で使用される用語
前述の図で使用されている様々な用語について詳しく説明します。
- ソース: 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-<version>.jarが見つかりませんでした。kvstore-ee.jarおよびkvstore-ee-<version>.jarをlibディレクトリにコピーします。
<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の使用に関連するタスクの高レベル・フローを示します。
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メタデータの移行
Time to Live (TTL)は、表の行を自動的に期限切れにできるメカニズムです。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構成パラメータが用意されています。
_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情報を格納します。
-
ユースケース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列は、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> - Oracle NoSQL Database Cloud Serviceのリージョン・エンドポイントおよびコンパートメント名を指定します。
- エンドポイント:
us-phoenix-1 - コンパートメント:
developers
- エンドポイント:
myTableのデータおよびスキーマ定義を移行するには:
移行を検証するには、指定したシンク・ディレクトリに移動し、スキーマおよびデータを表示できます。
-- 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)))オンプレミスの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
- storeName:
myTableのデータおよびスキーマ定義をNoSQLデータベースKVStoreからNDCSに移行するには:
移行を検証するには、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
- ソース: 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> - 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表を作成します。かわりに、
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> - 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ファイルを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"},"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ストレージからローカルにマウントされたファイル・システムにコピーします。
次に例を示します:
このデモでは、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形式)を準備します。詳細は、ソース構成テンプレートおよびシンク構成テンプレートを参照してください。
ノート:
エクスポートされたDynamoDB JSON表アイテムにTTL属性が含まれている場合、オプションでTTL値をインポートするには、ソース構成テンプレートのttlAttributeName構成パラメータに属性を指定し、シンク構成テンプレートでincludeTTL構成パラメータをtrueに設定します。次の2つのオプションのいずれかを選択できます。- オプション1:デフォルトのスキーマ構成を使用して、JSONドキュメントとしてDynamoDB表をインポートします。
ここでは、defaultSchema構成パラメータをtrueに設定します。したがって、NoSQL Database Migratorはシンクにデフォルト・スキーマを作成します。
DDBPartitionKeyおよび対応するNoSQL列タイプを指定する必要があります。そうでない場合は、エラーが表示されます。DynamoDBエクスポートされたJSONソースのデフォルト・スキーマの詳細は、Oracle NoSQL Database Migratorのワークフローのソースおよびシンクの識別のトピックを参照してください。{ "source" : { "type" : "file", "format" : "dynamodb_json", "ttlAttributeName" : "ttl", "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>" }, "sink" : { "type" : "nosqldb", "storeName" : "kvstore", "helperHosts" : ["<hostname>:5000"], "table" : "sampledynDBImp", "includeTTL" : true, "schemaInfo" : { "DDBPartitionKey" : "Id:INTEGER", "defaultSchema" : true }, "overwrite" : true, "requestTimeoutMs" : 5000 }, "abortOnError" : true, "migratorVersion" : "1.6.5" }この例では、次のデフォルト・スキーマが使用されています。CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id))) - オプション2:ユーザー指定のスキーマ・ファイルを使用して、DynamoDB表を固定列としてインポートします。
ここでは、defaultSchema構成パラメータをfalseに設定します。したがって、schemaPathパラメータにシンク表のDDL文を含むファイルを指定します。詳細は、「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を参照してください。
{ "source" : { "type" : "file", "format" : "dynamodb_json", "ttlAttributeName" : "ttl", "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>" }, "sink" : { "type" : "nosqldb", "storeName" : "kvstore", "helperHosts" : ["<hostname>:5000"], "table" : "sampledynDBImp", "includeTTL" : true, "schemaInfo" : { "schemaPath" : "<full path of the schema file with the DDL statement>" }, "overwrite" : true, "requestTimeoutMs" : 5000 }, "transforms": { "aggregateFields" : { "fieldName" : "document", "skipFields" : ["Id"] } }, "abortOnError" : true, "migratorVersion" : "1.6.5" }
- オプション1:デフォルトのスキーマ構成を使用して、JSONドキュメントとしてDynamoDB表をインポートします。
- コマンド・プロンプトを開き、NoSQL Database Migratorユーティリティを抽出したディレクトリに移動します。
- オプション1および2に別個の構成ファイルを渡して、
runMigratorコマンドを実行します。--configまたは-cオプションを使用します。./runMigrator --config <complete/path/to/the/JSON/config/file> - 次の例に示すように、ユーティリティはデータ移行を続行します。
[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] [nosqldb sink] : start loading DDLs [INFO] [nosqldb sink] : executing DDL: CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id))) [INFO] [nosqldb 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.
検証
java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstoreSELECT * FROM sampledynDBImp出力
_metadata JSONオブジェクトに含まれていることに注意してください。{"Id":102,"document":{"Address":{"City":"Wales","DoorNum":1024,"Street":"32 main","Zip":560014},"Age":48,"FavColors":["Blue"],"FavNumbers":[10],"FirstName":"John","LastName":"White","Phones":[["222-222"]],"PremierCustomer":false,"_metadata":{"expiration":1734616196000}}}
{"Id":101,"document":{"Address":{"City":"London","DoorNum":201,"Street":"21 main","Zip":570004},"Age":22,"FavColors":["Red","Green"],"FavNumbers":[10],"FirstName":"Fred","LastName":"Smith","Phones":[["555-222","123-567"]],"PremierCustomer":false,"_metadata":{"expiration":1734616196000}}}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形式)を準備します。詳細は、ソース構成テンプレートおよびシンク構成テンプレートを参照してください。
ノート:
AWS S3のDynamoDB JSONファイルのアイテムにTTL属性が含まれている場合、オプションでTTL値をインポートするには、ソース構成テンプレートのttlAttributeName構成パラメータに属性を指定し、シンク構成テンプレートでincludeTTL構成パラメータをtrueに設定します。詳細は、表の行のTTLメタデータの移行を参照してください。次の2つのオプションのいずれかを選択できます。- オプション1:デフォルトのスキーマ構成を使用して、JSONドキュメントとしてDynamoDB表をインポートします。
ここで、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.6.5" }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が挿入されます。 - 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.6.5" } - 入力データに(主キー以外の)特定の列の値が含まれていない場合は、列のデフォルト値が使用されます。デフォルト値は、表の作成時に列定義の一部である必要があります。たとえば、
- オプション1:デフォルトのスキーマ構成を使用して、JSONドキュメントとしてDynamoDB表をインポートします。
- コマンド・プロンプトを開き、NoSQLデータベース・マイグレータ・ユーティリティを抽出したディレクトリに移動します。
--configまたは-cオプションを使用して構成ファイルを渡し、runMigratorコマンドを実行します。[~/nosqlMigrator]$./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ディレクトリからファイルにアクセスします。コンソールにアクセスする手順は、インフラストラクチャ・コンソールからのサービスへのアクセスを参照してください。
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表にリストアするコンパートメントへの書込み権限があることを確認します。詳細は、コンパートメントの管理を参照してください。 - エンドポイント:
- ソース: OCI OSバケット内のJSONファイルおよびスキーマ・ファイル。
- NoSQL Database MigratorのDockerイメージを準備し、コンテナ・レジストリに移動します。
- OCIコンソールからテナンシ・ネームスペースを取得します。
Oracle NoSQL Database Cloud Serviceコンソールにログインします。ナビゲーション・バーで、「プロファイル」メニューを選択し、「テナンシ: <テナンシ名>」を選択します。
オブジェクト・ストレージ・ネームスペース名(テナンシ・ネームスペース)をクリップボードにコピーします。
- 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 ------------------------------------------------------------------------------------------ - 認証トークンを生成します。
Migrator Dockerイメージを格納するためにコンテナ・レジストリにログインするには、認証トークンが必要です。認証トークンがまだない場合は、生成する必要があります。詳細は、認証トークンの取得に関する項を参照してください。
- Migrator Dockerイメージをコンテナ・レジストリに格納します。
KubernetesポッドからマイグレータDockerイメージにアクセスするには、パブリックまたはプライベート・レジストリにイメージを格納する必要があります。たとえば、Docker、アーティファクト・ハブ、OCIコンテナ・レジストリなどは、いくつかのレジストリです。このデモンストレーションでは、コンテナ・レジストリを使用します。詳細は、コンテナ・レジストリの概要を参照してください。
- OCIコンソールから、コンテナ・レジストリにリポジトリを作成します。詳細は、リポジトリの作成を参照してください。
このデモンストレーションでは、
okemigratorリポジトリを作成します。 - 次のコマンドを使用して、コマンド・インタフェースからコンテナ・レジストリにログインします。
#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: 認証トークンを指定します。 - 次のコマンドを使用して、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
- OCIコンソールから、コンテナ・レジストリにリポジトリを作成します。詳細は、リポジトリの作成を参照してください。
- OCIコンソールからテナンシ・ネームスペースを取得します。
- WIAからNDCSおよびOCI OSへのOKEクラスタを構成します。
- OKEを使用してKubernetesクラスタを作成します。
OCIコンソールから、OKEを使用してネットワーク・リソースの可用性に基づいてKubernetesクラスタを定義および作成します。Migratorユーティリティをコンテナ化されたアプリケーションとして実行するには、Kubernetesクラスタが必要です。クラスタの作成の詳細は、コンソール・ワークフローを使用したKubernetesクラスタの作成に関する項を参照してください。
このデモンストレーションでは、前述のリンクで説明されているクイック作成ワークフローを使用して、単一ノード管理クラスタを作成できます。
- OCIコンソールからWIAを設定して、Kubernetesクラスタから他のOCIリソースにアクセスします。
Kubernetesクラスタ・ポッドから実行中に、MigratorユーティリティにNDCSおよびOCI OSバケットへのアクセス権を付与するには、WIAを設定する必要があります。次のステップに従います:
- クラスタの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
- 前述のコマンドの
cluster-idオプションからクラスタのOCIDをコピーし、次のステップで使用するために保存します。ocid1.cluster.oc1.iad.aaa...muqzq - クラウド・シェル・ウィンドウで次のコマンドを使用して、Kubernetesサービス・アカウントのネームスペースを作成します:
#Command: kubectl create namespace <namespace-name>#Example: kubectl create namespace migrator#Output: namespace/migrator created - クラウド・シェル・ウィンドウで次のコマンドを使用して、ネームスペースにMigratorアプリケーションのKubernetesサービス・アカウントを作成します:
#Command: kubectl create serviceaccount <service-account-name> --namespace <namespace-name>#Example: kubectl create serviceaccount migratorsa --namespace migrator#Output: serviceaccount/migratorsa created - 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'}ポリシーの作成の詳細は、コンソールを使用したポリシーの作成を参照してください。
- クラスタのkubeconfig構成ファイルを設定します。
- OKEを使用してKubernetesクラスタを作成します。
OCI OSバケットのJSONファイルからNDCS表に移行するには、「クラウド・シェル」ウィンドウから次の手順を実行します。
データのリストアを確認するには、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バケットにオブジェクトを書き込む権限があることを確認します。ポリシーの設定の詳細は、オブジェクト・ストレージへの書込みを参照してください。 - エンドポイント:
- 出典: Oracle NoSQL Databaseの
- 次のステップに従って、セッション・トークンを生成します。
- 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/tokensecurity_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ファイルに移行するには:
データ・バックアップを確認するには、Oracle NoSQL Database Cloud Serviceコンソールにログインします。メニュー Storage > Object Storage & Archive Storage > Bucketsをナビゲートします。Migrate_ociバケットのuserSessionディレクトリからファイルにアクセスします。コンソールにアクセスする手順は、インフラストラクチャ・コンソールからのサービスのアクセスを参照してください
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