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

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

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

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

MongoDB は、データをバイナリ JSON 形式 (BSON) で保存します。AWS DMS は、Amazon DocumentDB でサポートされているすべての BSON データ型をサポートします。このようなデータ型のリストについては、「Amazon DocumentDB デベロッパーガイド」の「Supported MongoDB APIs, operations, and data types」を参照してください。

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

ソースエンドポイントが Amazon S3 の場合、結果として得られる Amazon DocumentDB オブジェクトは、Amazon S3 の AWS DMS マッピングルールに対応しています。例えば次のような URI がある場合、

s3://mybucket/hr/employee

AWS DMS は、mybucket 内のオブジェクトを次のとおり Amazon DocumentDB にマップします。

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

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

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

AWS DMS は、ソースエンドポイントからレコードを読み取り、読み取ったデータに基づいて JSON ドキュメントを構築します。各 JSON ドキュメントでは、AWS DMS は、一意の識別子として機能する _id フィールドを決定する必要があります。次に、その _id フィールドをプライマリキーとして使用して、JSON ドキュメントを 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 フィールドを特定するために、次のとおり処理します。

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

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

ネストされた JSON ドキュメント (json_ prefix) の使用

データ型を強制変換するには、ソース列名に 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_ prefix) の使用

データ型を強制変換するには、列名に 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\"]"

}                

変換ルールを追加すると、ContactAddress と ContactPhoneNumbers を次の表の例のとおり、JSON 配列に強制変換できます。

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

{
    "_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 ファイルをダウンロードします。このファイルのダウンロードの詳細については、「Amazon DocumentDB デベロッパーガイド」の「Encrypting connections using 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 モードパラメータを [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 倍向上しています。以前のリリースでは、AWS DMS のレコード処理は 1 秒あたり最大 250 レコードでしたが、現在 AWS DMS は 1 秒あたり約 5,000 レコードを処理できるようになりました。AWS DMS を使用すると、Amazon DocumentDB 内のドキュメントのソースとの同期も確実に維持されます。ソースレコードが作成または更新されると、AWS DMS はまず、次の操作を実行し、影響を受ける Amazon DocumentDB レコードを判断する必要があります。

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

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

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

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

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

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

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

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

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

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

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