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

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

が AWS DMS サポートする Amazon DocumentDB (MongoDB 互換) のバージョンについては、「」を参照してくださいのターゲット AWS DMS。 AWS DMS を使用して、 AWS DMS がサポートするソースデータエンジンから Amazon DocumentDB にデータを移行できます。ソースエンジンは、Amazon RDS、Aurora、Amazon S3 などの AWS マネージドサービス上に配置できます。このエンジンは Amazon EC2 またはオンプレミスで実行されている MongoDB などの自己管理データベース上に存在していてもかまいません。

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

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

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

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

s3://mybucket/hr/employee

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

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

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

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

AWS DMS はソースエンドポイントからレコードを読み取り、読み取りデータに基づいて JSON ドキュメントを作成します。JSON ドキュメントごとに、一意の識別子として機能する _idフィールドを決定 AWS DMS する必要があります。このターゲットは次に、その _id フィールドをプライマリ キーとして使用してJSON ドキュメントを、Amazon DocumentDB コレクションに書き込みます。

単一列のソースデータ

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

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

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

複数列のソースデータ

ソースデータが複数の列で構成されている場合、 はこれらのすべての列から JSON ドキュメント AWS DMS を作成します。ドキュメントの _idフィールドを決定するために、 は次のように AWS DMS 処理します。

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

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 に強制変換するには、ソースに「*json_*」プレフィックスを手動で追加するか、変換ルールを使用して、ソースエンドポイントの列名前「JSON_ContactDetails」に変更する必要があります。例えば、次の変換ルールを使用できます。

{
    "rules": [
    {
    "rule-type": "transformation",
    "rule-id": "1",
    "rule-name": "1",
    "rule-target": "column",
    "object-locator": {
    "schema-name": "%",
    "table-name": "%",
    "column-name": "ContactDetails"
     },
    "rule-action": "rename",
    "value": "json_ContactDetails",
    "old-value": null
    }
    ]
}
                    

AWS DMS は、次のように ContactDetails フィールドをネストされた JSON としてレプリケートします。

{
    "_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 配列と見なし、ターゲットドキュメントにそのように作成します。

たとえば、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\"]"

}                

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

AWS DMS はContactPhoneNumbers、次のように ContactAddressと をレプリケートします。

{
    "_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 のパブリックキーを取得するには、ホストされた Amazon Amazon S3バケットrds-combined-ca-bundle.pemから ファイル をダウンロードします。 AWS ファイルのダウンロードの詳細については、Amazon DocumentDB デベロッパーガイドの「TLS を使用した接続の暗号化」をご参照ください。

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

AWS Management Console

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 Elastic Cluster への接続

AWS DMS バージョン 3.4.7 以降では、Amazon DocumentDB ターゲットエンドポイントを Elastic クラスターとして作成できます。ターゲットエンドポイントを Elastic クラスターとして作成する場合、既存の SSL 証明書は機能しないため、Amazon DocumentDB Elastic クラスターエンドポイントに新しい SSL 証明書をアタッチする必要があります。

ダウンロードした SFSRootCAG2.pem ファイルからの新しい SSL 証明書が、Amazon DocumentDB Elastic クラスターエンドポイントにアタッチされます。

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

Amazon DocumentDB をターゲットとした継続的なレプリケーション (変更データキャプチャ、CDC) が有効になっている場合、 AWS DMS バージョン 3.5.0 以降では以前のリリースと比べてパフォーマンスが 20 倍向上しています。が 1 秒あたり最大 250 レコード AWS DMS を処理する以前のリリースでは、 AWS DMS 現在は 1 秒あたり 5,000 レコード以上を効率的に処理します。 AWS DMS また、 は Amazon DocumentDB 内のドキュメントがソースと同期していることを確認します。ソースレコードが作成または更新されると、まず、以下を実行して、影響を受ける Amazon DocumentDB レコードを特定 AWS DMS する必要があります。

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

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

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

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

Amazon DocumentDB をターゲットとして使用する場合の制限事項

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

ターゲットとしての Amazon DocumentDB のエンドポイントの設定

追加の接続属性の使用と同様、エンドポイントの設定を使用して、ターゲットの Amazon DocumentDB データベースを設定できます。 AWS DMS コンソールを使用するか、 の create-endpoint コマンドを JSON --doc-db-settings '{"EndpointSetting": "value", ...}' 構文で使用してAWS CLI、ターゲットエンドポイントを作成するときに設定を指定します。

次の表は、ターゲットとして Amazon DocumentDB を使用できるエンドポイント設定を説明しています。

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

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