

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

# AWS Database Migration Service のターゲットとしての Amazon DocumentDB の使用
<a name="CHAP_Target.DocumentDB"></a>

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

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

**注記**  
ソース エンドポイントが MongoDB または Amazon DocumentDB の場合は、**[Document mode]** (ドキュメントモード) で移行します。

MongoDB はバイナリ JSON 形式 (BSON) でデータを保存します。 は、Amazon DocumentDB でサポートされているすべての BSON データ型 AWS DMS をサポートします。これらのデータ型のリストについては、*Amazon DocumentDB デベロッパーガイド* の「[サポートされている MongoDB API およびオペレーション、データ型](https://docs.aws.amazon.com/documentdb/latest/developerguide/mongo-apis.html)」をご参照ください。

ソースエンドポイントがリレーショナルデータベースの場合、 は次のようにデータベースオブジェクトを Amazon DocumentDB に AWS DMS マッピングします。
+ リレーショナルデータベースあるいはデータベーススキーマは、Amazon DocumentDB の*データベース*にマップされます。
+ リレーショナルデータベース内のテーブルは、Amazon DocumentDB 内の*コレクションです*にマップされます。
+ リレーショナルテーブル内のレコードは、Amazon DocumentDB 内の*文書*にマップされます。ソースレコードのデータから各ドキュメントが構築されます。

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

```
s3://amzn-s3-demo-bucket/hr/employee
```

この場合、 は のオブジェクトを次のように Amazon DocumentDB `amzn-s3-demo-bucket`に AWS DMS マッピングします。
+ URI の最上位パート (`hr`) は、 Amazon DocumentDB データベースにマップされます。
+ 次の URI パート (`employee`) は、Amazon DocumentDB のコレクションにマップされます。
+ `employee` の各オブジェクトは Amazon DocumentDB 内のドキュメントにマップされます。

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

**Amazon DocumentDB のエンドポイント設定**

 AWS DMS バージョン 3.5.0 以降では、並列スレッドと一括オペレーションのタスク設定を調整することで、Amazon DocumentDB エンドポイントの変更データキャプチャ (CDC) のパフォーマンスを向上させることができます。これを行うには、`ParallelApply*` タスク設定を使用して、同時スレッドの数、スレッドあたりのキュー数、バッファに格納するレコード数を指定します。例えば、CDC ロードを実行し、128 本のスレッドを並列に適用するとします。また、スレッドあたり 64 個のキューにアクセスして、バッファあたり 50 個のレコードを保存する必要があります。

CDC パフォーマンスを向上させるために、 は次のタスク設定 AWS DMS をサポートしています。
+ `ParallelApplyThreads` – CDC ロード中に AWS DMS がデータレコードを Amazon DocumentDB ターゲットエンドポイントにプッシュするために使用する同時スレッドの数を指定します。デフォルト値は 0 で、最大値は 32 です。
+ `ParallelApplyBufferSize` – CDC ロード中に Amazon DocumentDB ターゲットエンドポイントにプッシュする同時スレッドの各バッファキューに格納するレコードの最大数を指定します。デフォルト値は 100 で、最大値は 1,000 です。このオプションは、`ParallelApplyThreads` で複数のスレッドを指定する場合に使用します。
+ `ParallelApplyQueuesPerThread` – CDC 中に各スレッドがキューからデータレコードを取り出して Amazon DocumentDB エンドポイントのバッチロードを生成するためにアクセスするキューの数を指定する。デフォルトは 1 です。最大数は 512。

**注記**  
 Amazon DocumentDB ターゲットの場合、並列 CDC 適用によってキーエラーが重複したり、セカンダリ一意インデックスを使用するワークロードや変更の厳密な順序付けが必要なワークロードに CDC 適用が停止されたりする可能性があります。これらのワークロードには、デフォルトのシングルスレッド CDC 適用設定を使用します。

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

**Topics**
+ [ソースから Amazon DocumentDB ターゲットへのデータのマッピング](#CHAP_Target.DocumentDB.data-mapping)
+ [ターゲットとしての Amazon DocumentDB Elastic Cluster への接続](#CHAP_Target.DocumentDB.data-mapping.elastic-cluster-connect)
+ [Amazon DocumentDB をターゲットとする継続的なレプリケーション](#CHAP_Target.DocumentDB.data-mapping.ongoing-replication)
+ [Amazon DocumentDB をターゲットとして使用する場合の制限事項](#CHAP_Target.DocumentDB.limitations)
+ [ターゲットとしての Amazon DocumentDB のエンドポイントの設定](#CHAP_Target.DocumentDB.ECAs)
+ [Amazon DocumentDB のターゲットデータ型](#CHAP_Target.DocumentDB.datatypes)

**注記**  
移行プロセスのstep-by-stepのチュートリアルについては、 AWS Database Migration Service Step-by-Step移行ガイド[」のMongoDB から Amazon DocumentDB への移行](https://docs.aws.amazon.com/dms/latest/sbs/CHAP_MongoDB2DocumentDB.html)」を参照してください。

## ソースから Amazon DocumentDB ターゲットへのデータのマッピング
<a name="CHAP_Target.DocumentDB.data-mapping"></a>

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

### 単一列のソースデータ
<a name="CHAP_Target.DocumentDB.data-mapping.single-column"></a>

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

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

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

### 複数列のソースデータ
<a name="CHAP_Target.DocumentDB.data-mapping.multiple-columns"></a>

ソースデータが複数の列で構成されている場合、 はこれらのすべての列から JSON ドキュメント AWS DMS を作成します。ドキュメントの `_id`フィールドを決定するために、 は次のように AWS DMS 処理します。
+ `_id` という名前の列がある場合は、その列のデータがターゲット `_id` として使用されます。
+ `_id` 列がないが、ソースデータにプライマリキーまたは一意のインデックスがある場合、 AWS DMS はそのキーまたはインデックス値を`_id`値として使用します。プライマリキーや一意のインデックスのデータは、JSON ドキュメント内の明示的なフィールドとしても表示されます。
+ `_id` 列も、プライマリ キーも、一意のインデックスもない場合は、Amazon DocumentDB によって自動的に `_id` 値が生成されます。

### ターゲットエンドポイントのデータ型の強制変換
<a name="CHAP_Target.DocumentDB.coercing-datatype"></a>

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

#### ネストされた JSON ドキュメント (json\$1 プレフィックス) の使用
<a name="CHAP_Target.DocumentDB.coercing-datatype.json"></a>

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

```
{
    "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\$1 プレフィックス) の使用
<a name="CHAP_Target.DocumentDB.coercing-datatype.array"></a>

列の名前に `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 配列に強制変換することができます。その例を次の表に示します。


****  

| ソース列の元の名前 | ソース列の変更後の名前 | 
| --- | --- | 
| ContactAddress | array\$1ContactAddress | 
| ContactPhoneNumbers | array\$1ContactPhoneNumbers | 

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

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

### TLS を使用して Amazon DocumentDB に接続する
<a name="CHAP_Target.DocumentDB.tls"></a>

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

Amazon DocumentDB のパブリックキーを取得するには、ホストされている Amazon Amazon S3バケット`rds-combined-ca-bundle.pem`から ファイル をダウンロードします。 AWS ファイルのダウンロードの詳細については、*Amazon DocumentDB デベロッパーガイド*の「[TLS を使用した接続の暗号化](https://docs.aws.amazon.com/documentdb/latest/developerguide/security.encryption.ssl.html)」をご参照ください。

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

#### AWS マネジメントコンソール
<a name="CHAP_Target.DocumentDB.tls.con"></a>

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

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

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

1. [**Import certificate (証明書のインポート)**] を選択し、次の操作を行います。
   + [**Certificate identifier (証明書の識別子)**] に、証明書の一意の名前を入力します (例: `docdb-cert`)。
   + [**Import file (ファイルのインポート)**] で、.pem ファイルを保存した場所を参照します。

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

#### AWS CLI
<a name="CHAP_Target.DocumentDB.tls.cli"></a>

次の例に示すように `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 への接続
<a name="CHAP_Target.DocumentDB.data-mapping.elastic-cluster-connect"></a>

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

**新しい SSL 証明書を Amazon DocumentDB Elastic クラスターエンドポイントにアタッチするには**

1. ブラウザで [https://www.amazontrust.com/repository/SFSRootCAG2.pem](https://www.amazontrust.com/repository/SFSRootCAG2.pem) を開いて、コンテンツを `.pem` に一意のファイル名を付けて保存します (`SFSRootCAG2.pem` など)。この証明書ファイルは、後半の手順でインポートする必要がありますす。

1. Elastic クラスターエンドポイントを作成して、次のオプションを設定します。

   1. **[エンドポイント設定]** の下で、**[新しい CA 証明書の追加]** をクリックします。

   1. **[証明書の識別子]** には、**SFSRootCAG2.pem** を入力します。

   1. **[証明書ファイルのインポート]** では、**[ファイルを選択]** をクリックして、前のタスクでダウンロードした `SFSRootCAG2.pem` ファイルに移動します。

   1. ファイルを選択して、ダウンロードした `SFSRootCAG2.pem` ファイルを選択します。

   1. [**証明書のインポート**] を選択します。

   1. **[証明書の選択]** ドロップダウンで、**[SFSRootCAG2.pem]** を選択します。

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

## Amazon DocumentDB をターゲットとする継続的なレプリケーション
<a name="CHAP_Target.DocumentDB.data-mapping.ongoing-replication"></a>

Amazon DocumentDB をターゲットとした継続的なレプリケーション (変更データキャプチャ、CDC) が有効になっている場合、 AWS DMS バージョン 3.5.0 以降では以前のリリースと比べてパフォーマンスが 20 倍向上しています。が 1 秒あたり最大 250 レコード AWS DMS を処理する以前のリリースでは、 AWS DMS は現在、1 秒あたり 5000 レコード以上を効率的に処理します。 AWS DMS また、 は Amazon DocumentDB のドキュメントがソースと同期していることを確認します。ソースレコードを作成または更新するときは、まず以下を実行して、影響を受ける Amazon DocumentDB レコードを決定 AWS DMS する必要があります。
+ ソースレコードに `_id` という名前の列がある場合は、その列の値を使用して Amazon DocumentDB コレクションの対応する `_id` が特定されます。
+ `_id` 列がないが、ソースデータにプライマリキーまたは一意のインデックスがある場合、 AWS DMS はそのキーまたはインデックス値を Amazon DocumentDB コレクションの として使用`_id`します。
+ ソースレコードに `_id`列、プライマリキー、または一意のインデックスがない場合、 はすべてのソース列を Amazon DocumentDB コレクションの対応するフィールドに AWS DMS 一致させます。

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

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

### ソースの構造の変更 (DDL)
<a name="CHAP_Target.DocumentDB.data-mapping.ongoing-replication.ddl"></a>

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


****  

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

## Amazon DocumentDB をターゲットとして使用する場合の制限事項
<a name="CHAP_Target.DocumentDB.limitations"></a>

Amazon DocumentDB をターゲットとして使用する場合は、次の制限が適用されます AWS DMS。
+ Amazon DocumentDB では、コレクション名にドル記号 (\$1) を含めることはできません。また、データベース名に Unicode 文字を含めることもできません。
+ AWS DMS では、複数のソーステーブルを 1 つの Amazon DocumentDB コレクションに統合することはできません。
+  AWS DMS がプライマリキーを持たないソーステーブルから変更を処理すると、そのテーブル内の LOB 列は無視されます。
+ **[変更テーブル]** オプションが有効で、 AWS DMS で「*\$1id*」という名前のソース列が検出されると、その列が変更テーブルに 「*\$1\$1id*」 (アンダースコア 2 つが前に付く) として表示されます。
+ ソースエンドポイントとして Oracle を選択する場合は、Oracle ソースで完全なサプリメンタルロギングが有効になっている必要があります。有効になっていないと、ソースに変更されていない列がある場合にデータが null 値として Amazon DocumentDB にロードされます。
+ レプリケーション タスクの設定、`TargetTablePrepMode:TRUNCATE_BEFORE_LOAD` は、DocumentDB ターゲット エンドポイントでの使用には対応していません。
+ MongoDB の上限付きコレクションは、Amazon DocumentDB ではサポートされていません。ただし AWS DMS は、ターゲット DocumentDB の上限なしのコレクションなどのオブジェクトを自動的に移行します。
+ Amazon DocumentDB ターゲットに並列 CDC を適用すると、キーエラーが重複したり、セカンダリ一意インデックスを使用するワークロードや変更の厳密な順序付けが必要なワークロードに CDC 適用が停止されたりする可能性があります。このようなワークロードでは、デフォルトのシングルスレッド CDC 適用設定を使用します。

## ターゲットとしての Amazon DocumentDB のエンドポイントの設定
<a name="CHAP_Target.DocumentDB.ECAs"></a>

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

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


| 属性名 | 有効値 | デフォルト値と説明 | 
| --- | --- | --- | 
|   `replicateShardCollections`   |  boolean `true` `false`  |  `true` の場合、このエンドポイント設定には次のような影響がおよび、次のとおりの制限がある。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Target.DocumentDB.html)  | 

## Amazon DocumentDB のターゲットデータ型
<a name="CHAP_Target.DocumentDB.datatypes"></a>

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


|  AWS DMS データ型  |  Amazon DocumentDB データ型  | 
| --- | --- | 
|  BOOLEAN  |  ブール値  | 
|  BYTES  |  バイナリデータ  | 
|  DATE  | 日付 | 
|  TIME  | 文字列 (UTF8) | 
|  DATETIME  | 日付 | 
|  INT1  | 32 ビット整数 | 
|  INT2  |  32 ビット整数  | 
|  INT4  | 32 ビット整数 | 
|  INT8  |  64 ビット整数  | 
|  NUMERIC  | 文字列 (UTF8) | 
|  REAL4  |  Double  | 
|  REAL8  | Double | 
|  STRING  |  データが JSON として認識された場合、 はデータをドキュメントとして Amazon DocumentDB AWS DMS に移行します。それ以外の場合は文字列 (UTF8) にマップされます。  | 
|  UINT1  | 32 ビット整数 | 
|  UINT2  | 32 ビット整数 | 
|  UINT4  | 64 ビット整数 | 
|  UINT8  |  文字列 (UTF8)  | 
|  WSTRING  | データが JSON として認識された場合、 はデータをドキュメントとして Amazon DocumentDB AWS DMS に移行します。それ以外の場合は文字列 (UTF8) にマップされます。 | 
|  BLOB  | バイナリ | 
|  CLOB  | データが JSON として認識された場合、 はデータをドキュメントとして Amazon DocumentDB AWS DMS に移行します。それ以外の場合は文字列 (UTF8) にマップされます。 | 
|  NCLOB  | データが JSON として認識された場合、 はデータをドキュメントとして Amazon DocumentDB AWS DMS に移行します。それ以外の場合は文字列 (UTF8) にマップされます。 | 