AWS Database Migration Service のターゲットとしての Amazon DocumentDB の使用 - AWS Database Migration Service

「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。」

AWS Database Migration Service のターゲットとしての Amazon DocumentDB の使用

AWS DMS を使用して、AWS DMS がサポートするソースデータエンジンのいずれかから Amazon DocumentDB (MongoDB 互換) にデータを移行できます。ソースエンジンは、 、 、 などの Amazon RDS AWS マネージド型サービスAurora上に存在できます。Amazon S3または、エンジンは、オンプレミスMongoDBやオンプレミスで実行されているなどのセルフマネージド型データベース上にAmazon EC2存在していてもかまいません。

AWS DMS を使用すると、ソースデータを Amazon DocumentDB のデータベース、コレクション、またはドキュメントにレプリケートできます。

ソースエンドポイントが MongoDB の場合は、次の追加の接続属性を有効にしてください。

  • nestingLevel="none"

  • extractDocID="false"

詳細については、を参照してください のソースMongoDBとして を使用する場合の追加の接続属性AWS DMS

MongoDBは、データをバイナリ JSON 形式 (BSON) AWS DMS で保存します。 Amazon DocumentDB は、 でサポートされているすべての BSON データ型をサポートしています。これらのデータ型のリストについては、 開発者ガイドの「MongoDBサポートされている APIs 、 オペレーション、およびデータ型」を参照してください。Amazon DocumentDB

ソースエンドポイントがリレーショナルデータベースである場合は、AWS DMS はデータベースオブジェクトを次のように Amazon DocumentDB にマップします。

  • リレーショナルデータベース (データベーススキーマ) は、Amazon DocumentDB のデータベースにマップされます。

  • リレーショナルデータベース内のテーブルは、Amazon DocumentDB のコレクションにマップされます。

  • リレーショナルテーブル内のレコードは、Amazon DocumentDB のドキュメントにマップされます。ソースレコードのデータから各ドキュメントが構築されます。

ソースエンドポイントが Amazon S3 である場合は、Amazon S3 の AWS DMS マッピングルールに対応する Amazon DocumentDB オブジェクトが作成されます。たとえば次のような URI があったとします。

s3://mybucket/hr/employee

この場合、AWS DMSは mybucket 内のオブジェクトを次のように Amazon DocumentDB にマップします。

  • URI の最上位の部分 (hr) は、Amazon DocumentDB のデータベースにマップされます。

  • URI の次の部分 (employee) は、Amazon DocumentDB のコレクションにマップされます。

  • employee 内の各オブジェクトは、Amazon DocumentDB のドキュメントにマップされます。

Amazon S3 のマッピングルールの詳細については、「AWS DMS のソースとしての Amazon S3 の使用」を参照してください。

AWS DMS のターゲットとしての Amazon DocumentDB の使用の詳細については、以下のセクションを参照してください。

注記

移行プロセスのステップバイステップチュートリアルについては、ステップバイステップ移行ガイドMongoDBDocumentDBの「 から Amazon への移行」を参照してください。AWS Database Migration Service

ソースから Amazon DocumentDB ターゲットへのデータのマッピング

AWS DMS は、ソースエンドポイントからレコードを読み取り、読み取ったデータに基づいて JSON ドキュメントを構築します。各 JSON ドキュメントでは、AWS DMS で _id フィールドを一意の識別子として機能するよう特定する必要があります。JSON ドキュメントは、その _id フィールドをプライマリキーとして使用して Amazon DocumentDB コレクションに書き込まれます。

単一列のソースデータ

ソースデータが 1 つの列で構成されている場合、そのデータは文字列型である必要があります。(実際のデータ型は、ソースエンジンの種類に応じて、VARCHAR、NVARCHAR、TEXT、LOB、CLOB などになります)。AWS DMS はこれらのデータを有効な JSON ドキュメントであると見なし、そのまま Amazon DocumentDB にレプリケートします。

結果の JSON ドキュメントに _id という名前のフィールドが含まれている場合は、そのフィールドが Amazon DocumentDB で一意の _id として使用されます。

JSON に _id フィールドが含まれていない場合は、Amazon DocumentDB によって自動的に _id 値が生成されます。

複数列のソースデータ

ソースデータが複数の列で構成されている場合、AWS DMS はそのすべての列から JSON ドキュメントを構築します。この場合、AWS DMS がドキュメントの _id フィールドを特定するプロセスは次のようになります。

  • _id という名前の列がある場合は、その列のデータがターゲット _id として使用されます。

  • _id 列はないがプライマリキーまたは一意のインデックスがある場合、AWS DMS はそのキーまたはインデックスの値を _id 値として使用します。プライマリキーや一意のインデックスのデータは、JSON ドキュメント内の明示的なフィールドとしても表示されます。

  • _id 列も、プライマリキーも、一意のインデックスもない場合は、Amazon DocumentDB によって自動的に _id 値が生成されます。

ターゲットエンドポイントのデータ型の強制変換

AWS DMS では、Amazon DocumentDB ターゲットエンドポイントへの書き込み時にデータ構造を変更できます。これらの変更をリクエストするには、ソースエンドポイントでテーブルや列の名前を変更するか、タスクの実行時に適用される変換ルールを指定します。

ネストされた JSON ドキュメント (json_ プレフィックス) の使用

ソース列の名前に json_ というプレフィックスを付けることによってデータ型を強制変換することができます (json_columnName)。手動で行うことも、変換を使用して行うこともできます。この場合、その列は、文字列フィールドとしてではなく、ターゲットドキュメント内のネストされた JSON ドキュメントとして作成されます。

たとえば、MongoDBソースエンドポイントから次のドキュメントを移行するとします。

{ "_id": "1", "FirstName": "John", "LastName": "Doe", "ContactDetails": "{"Home": {"Address": "Boston","Phone": "1111111"},"Work": { "Address": "Boston", "Phone": "2222222222"}}" }

これらのソースデータ型を強制変換しない場合、埋め込まれている ContactDetails ドキュメントは文字列として移行されます。

{ "_id": "1", "FirstName": "John", "LastName": "Doe", "ContactDetails": "{\"Home\": {\"Address\": \"Boston\",\"Phone\": \"1111111\"},\"Work\": { \"Address\": \"Boston\", \"Phone\": \"2222222222\"}}" }

しかし、変換ルールを追加して、ContactDetails を JSON オブジェクトに強制変換することができます。たとえば、元のソース列名が であるとContactDetailsします。 また、次のように、名前を変更したソース列を json_ContactDetails にすると仮定します。 AWS DMS はフィールドをネストされた JSON としてContactDetailsレプリケートします。

{ "_id": "1", "FirstName": "John", "LastName": "Doe", "ContactDetails": { "Home": { "Address": "Boston", "Phone": "1111111111" }, "Work": { "Address": "Boston", "Phone": "2222222222" } } }

JSON 配列 (array_ プレフィックス) の使用

列の名前に array_ というプレフィックスを付けることによってデータ型を強制変換することができます (array_columnName)。手動で行うことも、変換を使用して行うこともできます。この場合、AWS DMS はその列を JSON 配列と見なし、ターゲットドキュメントに JSON 配列を作成します。

MongoDBソースエンドポイントから次のドキュメントを移行するとします。

{ "_id" : "1", "FirstName": "John", "LastName": "Doe",
 "ContactAddresses": ["Boston", "New York"],
 "ContactPhoneNumbers": ["1111111111", "2222222222"] }

これらのソースデータ型を強制変換しない場合、埋め込まれている ContactDetails ドキュメントは文字列として移行されます。

{ "_id": "1", "FirstName": "John", "LastName": "Doe",
 "ContactAddresses": "[\"Boston\", \"New York\"]",
 "ContactPhoneNumbers": "[\"1111111111\", \"2222222222\"]"
 }

しかし、変換ルールを追加して、ContactAddressContactPhoneNumbers を JSON 配列に強制変換することができます。その例を次の表に示します。

ソース列の元の名前 ソース列の変更後の名前
ContactAddress array_ContactAddress
ContactPhoneNumbers array_ContactPhoneNumbers

これにより、AWS DMS で ContactAddressContactPhoneNumbers が次のようにレプリケートされます。

{ "_id": "1", "FirstName": "John", "LastName": "Doe", "ContactAddresses": [ "Boston", "New York" ], "ContactPhoneNumbers": [ "1111111111", "2222222222" ] }

TLS を使用した Amazon DocumentDB への接続

デフォルトでは、新しく作成された Amazon DocumentDB クラスターは、Transport Layer Security (TLS) を使用したセキュアな接続のみを受け入れます。TLS が有効になっている場合、Amazon DocumentDB へのすべての接続でパブリックキーが必要になります。

Amazon DocumentDB のパブリックキーを取得するには、AWS がホストする Amazon S3 バケットから rds-combined-ca-bundle.pem ファイルをダウンロードします。このファイルのダウンロードの詳細については、『』の「TLS を使用した接続の暗号化」を参照してください。Amazon DocumentDB 開発者ガイド

この.pem ファイルをダウンロードしたら、以下で説明するように、そのファイルに含まれるパブリックキーを AWS DMS にインポートできます。

AWS マネジメントコンソール

パブリックキー (.pem) ファイルをインポートするには

  1. AWS DMS コンソール (https://console.aws.amazon.com/dms) を開きます。

  2. ナビゲーションペインで [Certificates] を選択します。

  3. [Import certificate (証明書のインポート)] を選択し、次の操作を行います。

    • [Certificate identifier (証明書の識別子)] に、証明書の一意の名前を入力します (例: docdb-cert)。

    • [Import file (ファイルのインポート)] で、.pem ファイルを保存した場所を参照します。

    すべての設定が正しいことを確認したら、[Add new CA certificate (新しい CA 証明書の追加)] を選択します。

AWS CLI

次の例に示すように aws dms import-certificate コマンドを使用します。

aws dms import-certificate \ --certificate-identifier docdb-cert \ --certificate-pem file://./rds-combined-ca-bundle.pem

AWS DMS のターゲットエンドポイントを作成するときに、証明書の識別子 (docdb-cert など) を指定します。また、[SSL mode (SSL モード)] パラメータを [verify-full] に設定します。

Amazon DocumentDB をターゲットとする継続的なレプリケーション

AWS DMS で継続的なレプリケーションが有効になっている場合、Amazon DocumentDB 内のドキュメントでソースとの同期が維持されます。ソースレコードが作成または更新されると、AWS DMS はまず、影響を受ける Amazon DocumentDB レコードを次のように特定します。

  • ソースレコードに _id という名前の列がある場合は、その列の値を使用して Amazon DocumentDB コレクションの対応する _id が特定されます。

  • _id 列はないがプライマリキーまたは一意のインデックスがある場合、AWS DMS はそのキーまたはインデックスの値を Amazon DocumentDB コレクションの _id として使用します。

  • ソースレコードに _id 列も、プライマリキーも、一意のインデックスもない場合、AWS DMS はすべてのソース列を Amazon DocumentDB コレクションに対応するフィールドとして照合します。

新しいソースレコードが作成されると、AWS DMS は対応するドキュメントを Amazon DocumentDB に書き込みます。既存のソースレコードが更新された場合、AWS DMS は Amazon DocumentDB のターゲットドキュメントに対応するフィールドを更新します。ターゲットドキュメントには存在するがソースレコードには存在しないフィールドは、一切変更されません。

ソースレコードが削除されると、AWS DMS は対応するドキュメントを Amazon DocumentDB から削除します。

ソースの構造の変更 (DDL)

継続的なレプリケーションでは、ソースのデータ構造 (テーブル、列など) の変更が Amazon DocumentDB の対応する要素に反映されます。リレーショナルデータベースでは、これらの変更はデータ定義言語 (DDL) ステートメントを使用して開始されます。次の表に、AWS DMS でこれらの変更がどのように Amazon DocumentDB に反映されるかを示します。

ソースの DDL Amazon DocumentDB ターゲットへの影響
CREATE TABLE 空のコレクションが作成されます。
テーブル名を変更するステートメント (RENAME TABLEALTER TABLE...RENAME など) コレクションの名前が変更されます。
TRUNCATE TABLE コレクションからすべてのドキュメントを削除しますが、 が HandleSourceTableTruncatedである場合のみtrueです。 詳細については、「」を参照してください変更処理の DDL 処理のタスク設定
DROP TABLE コレクションを削除しますが、 が の場合のみ削除されますHandleSourceTableDroppedtrue 詳細については、「」を参照してください変更処理の DDL 処理のタスク設定
テーブルに列を追加するステートメント (ALTER TABLE...ADD など) この DDL ステートメントは無視され、警告が表示されます。ソースで最初の INSERT が実行されたときに、ターゲットドキュメントに新しいフィールドが追加されます。
ALTER TABLE...RENAME COLUMN この DDL ステートメントは無視され、警告が表示されます。ソースで最初の INSERT が実行されたときに、ターゲットドキュメントに新しい名前のフィールドが追加されます。
ALTER TABLE...DROP COLUMN この DDL ステートメントは無視され、警告が表示されます。
列のデータ型を変更するステートメント (ALTER COLUMN...MODIFY など) この DDL ステートメントは無視され、警告が表示されます。ソースでその新しいデータ型を使用した最初の INSERT が実行されたときに、その新しいデータ型のフィールドを使用してターゲットドキュメントが作成されます。

ターゲットとしての Amazon DocumentDB の使用における制限

AWS DMS のターゲットとして Amazon DocumentDB を使用する場合、以下の制限が適用されます。

  • Amazon DocumentDB では、コレクション名にドル記号 ($) を含めることはできません。また、データベース名に Unicode 文字を含めることもできません。

  • AWS DMS で複数のソーステーブルを 1 つの Amazon DocumentDB コレクションにマージすることはできません。

  • AWS DMS は、プライマリキーがないソーステーブルの変更を処理する際に、そのテーブルの LOB 列を無視します。

  • [Change table (変更テーブル)] オプションが有効になっている場合に AWS DMS で "_id" という名前のソース列が検出されると、その列が変更テーブルに "__id" (2 つのアンダースコア) として表示されます。

  • ソースエンドポイントとして Oracle を選択する場合は、Oracle ソースで完全なサプリメンタルロギングが有効になっている必要があります。有効になっていないと、ソースに変更されていない列がある場合にデータが null 値として Amazon DocumentDB にロードされます。

Amazon DocumentDB のターゲットデータ型

次の表に、AWS DMS を使用する場合にサポートされる Amazon DocumentDB ターゲットのデータ型と、AWS DMS のデータ型からのデフォルトマッピングを示します。AWS DMS のデータ型の詳細については、「AWS Database Migration Service のデータ型」を参照してください。

AWS DMS データ型

Amazon DocumentDB データ型

BOOLEAN

Boolean

BYTES

バイナリデータ

DATE

日付

TIME

文字列 (UTF8)

DATETIME

日付

INT1

32 ビット整数

INT2

32 ビット整数

INT4

32 ビット整数

INT8

64 ビット整数

NUMERIC

文字列 (UTF8)

REAL4

Double

REAL8

Double

STRING

データが JSON として認識された場合、AWS DMS はこれをドキュメントとして Amazon DocumentDB に移行します。それ以外の場合は文字列 (UTF8) にマップされます。

UINT1

32 ビット整数

UINT2

32 ビット整数

UINT4

64 ビット整数

UINT8

文字列 (UTF8)

WSTRING

データが JSON として認識された場合、AWS DMS はこれをドキュメントとして Amazon DocumentDB に移行します。それ以外の場合は文字列 (UTF8) にマップされます。

BLOB

バイナリ

CLOB

データが JSON として認識された場合、AWS DMS はこれをドキュメントとして Amazon DocumentDB に移行します。それ以外の場合は文字列 (UTF8) にマップされます。

NCLOB

データが JSON として認識された場合、AWS DMS はこれをドキュメントとして Amazon DocumentDB に移行します。それ以外の場合は文字列 (UTF8) にマップされます。