}
```
Sampel berikut menyoroti bagian yang digunakan untuk kondisi ekspresi.
![\[Memulai dengan AWS DMS\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/images/datarep-Tasks-conditional1.png)
### Menggunakan pemetaan atribut dengan pemetaan objek
Pemetaan atribut memungkinkan Anda menentukan string templat menggunakan nama kolom sumber untuk merestrikturisasi data pada target. Tidak ada pemformatan yang dilakukan selain yang ditentukan pengguna dalam templat.
Contoh berikut menunjukkan struktur basis data sumber dan struktur yang diinginkan dari target DynamoDB. Pertama ditunjukkan struktur sumbernya, dalam hal ini basis data Oracle, dan kemudian struktur data yang diinginkan di DynamoDB. Contoh diakhiri dengan JSON yang digunakan untuk membuat struktur target yang diinginkan.
Struktur data Oracle adalah sebagai berikut:
****
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateOfBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Kunci Primer | N/A | |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
Struktur data DynamoDB adalah sebagai berikut:
****
| CustomerName | StoreId | ContactDetails | DateOfBirth |
| --- | --- | --- | --- |
| Kunci partisi | Urutkan Kunci | N/A |
| Randy,Marsh
| 5
| {
"Name": "Randy",
"Home": {
"Address": "221B Baker Street",
"Phone": 1234567890
},
"Work": {
"Address": "31 Spooner Street, Quahog",
"Phone": 9876541230
}
} | 02/29/1988
|
JSON berikut menunjukkan pemetaan objek dan pemetaan kolom yang digunakan untuk mencapai struktur DynamoDB:
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "test",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "TransformToDDB",
"rule-action": "map-record-to-record",
"object-locator": {
"schema-name": "test",
"table-name": "customer"
},
"target-table-name": "customer_t",
"mapping-parameters": {
"partition-key-name": "CustomerName",
"sort-key-name": "StoreId",
"exclude-columns": [
"FirstName",
"LastName",
"HomeAddress",
"HomePhone",
"WorkAddress",
"WorkPhone"
],
"attribute-mappings": [
{
"target-attribute-name": "CustomerName",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${FirstName},${LastName}"
},
{
"target-attribute-name": "StoreId",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${StoreId}"
},
{
"target-attribute-name": "ContactDetails",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "{\"Name\":\"${FirstName}\",\"Home\":{\"Address\":\"${HomeAddress}\",\"Phone\":\"${HomePhone}\"}, \"Work\":{\"Address\":\"${WorkAddress}\",\"Phone\":\"${WorkPhone}\"}}"
}
]
}
}
]
}
```
Cara lain menggunakan pemetaan kolom adalah dengan menggunakan format DynamoDB sebagai jenis dokumen Anda. Contoh kode berikut menggunakan *peta dinamodb* sebagai `attribute-sub-type` untuk pemetaan atribut.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "test",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "TransformToDDB",
"rule-action": "map-record-to-record",
"object-locator": {
"schema-name": "test",
"table-name": "customer"
},
"target-table-name": "customer_t",
"mapping-parameters": {
"partition-key-name": "CustomerName",
"sort-key-name": "StoreId",
"exclude-columns": [
"FirstName",
"LastName",
"HomeAddress",
"HomePhone",
"WorkAddress",
"WorkPhone"
],
"attribute-mappings": [
{
"target-attribute-name": "CustomerName",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${FirstName},${LastName}"
},
{
"target-attribute-name": "StoreId",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${StoreId}"
},
{
"target-attribute-name": "ContactDetails",
"attribute-type": "document",
"attribute-sub-type": "dynamodb-map",
"value": {
"M": {
"Name": {
"S": "${FirstName}"
},
"Home": {
"M": {
"Address": {
"S": "${HomeAddress}"
},
"Phone": {
"S": "${HomePhone}"
}
}
},
"Work": {
"M": {
"Address": {
"S": "${WorkAddress}"
},
"Phone": {
"S": "${WorkPhone}"
}
}
}
}
}
}
]
}
}
]
}
```
Sebagai alternatif untuk`dynamodb-map`, Anda dapat menggunakan `dynamodb-list` sebagai attribute-sub-type for pemetaan atribut, seperti yang ditunjukkan pada contoh berikut.
```
{
"target-attribute-name": "ContactDetailsList",
"attribute-type": "document",
"attribute-sub-type": "dynamodb-list",
"value": {
"L": [
{
"N": "${FirstName}"
},
{
"N": "${HomeAddress}"
},
{
"N": "${HomePhone}"
},
{
"N": "${WorkAddress}"
},
{
"N": "${WorkPhone}"
}
]
}
}
```
### Contoh 1: Menggunakan pemetaan atribut dengan pemetaan objek
Contoh berikut memigrasikan data dari dua tabel database MySQL, nfl\$1data *dan sport\$1team*,* ke dua tabel DynamoDB disebut dan*. *NFLTeams*SportTeams** Struktur tabel dan JSON yang digunakan untuk memetakan data dari tabel basis data MySQL ke tabel DynamoDB ditunjukkan sebagai berikut.
Struktur tabel basis data MySQL *nfl\$1data* ditunjukkan di bawah ini:
```
mysql> desc nfl_data;
+---------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------------+-------------+------+-----+---------+-------+
| Position | varchar(5) | YES | | NULL | |
| player_number | smallint(6) | YES | | NULL | |
| Name | varchar(40) | YES | | NULL | |
| status | varchar(10) | YES | | NULL | |
| stat1 | varchar(10) | YES | | NULL | |
| stat1_val | varchar(10) | YES | | NULL | |
| stat2 | varchar(10) | YES | | NULL | |
| stat2_val | varchar(10) | YES | | NULL | |
| stat3 | varchar(10) | YES | | NULL | |
| stat3_val | varchar(10) | YES | | NULL | |
| stat4 | varchar(10) | YES | | NULL | |
| stat4_val | varchar(10) | YES | | NULL | |
| team | varchar(10) | YES | | NULL | |
+---------------+-------------+------+-----+---------+-------+
```
Struktur tabel basis data MySQL*sport\$1team* ditunjukkan di bawah ini:
```
mysql> desc sport_team;
+---------------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------------------+--------------+------+-----+---------+----------------+
| id | mediumint(9) | NO | PRI | NULL | auto_increment |
| name | varchar(30) | NO | | NULL | |
| abbreviated_name | varchar(10) | YES | | NULL | |
| home_field_id | smallint(6) | YES | MUL | NULL | |
| sport_type_name | varchar(15) | NO | MUL | NULL | |
| sport_league_short_name | varchar(10) | NO | | NULL | |
| sport_division_short_name | varchar(10) | YES | | NULL | |
```
Aturan pemetaan tabel yang digunakan untuk memetakan dua tabel ke dua tabel DynamoDB adalah sebagai berikut:
```
{
"rules":[
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "dms_sample",
"table-name": "nfl_data"
},
"rule-action": "include"
},
{
"rule-type": "selection",
"rule-id": "2",
"rule-name": "2",
"object-locator": {
"schema-name": "dms_sample",
"table-name": "sport_team"
},
"rule-action": "include"
},
{
"rule-type":"object-mapping",
"rule-id":"3",
"rule-name":"MapNFLData",
"rule-action":"map-record-to-record",
"object-locator":{
"schema-name":"dms_sample",
"table-name":"nfl_data"
},
"target-table-name":"NFLTeams",
"mapping-parameters":{
"partition-key-name":"Team",
"sort-key-name":"PlayerName",
"exclude-columns": [
"player_number", "team", "name"
],
"attribute-mappings":[
{
"target-attribute-name":"Team",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"${team}"
},
{
"target-attribute-name":"PlayerName",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"${name}"
},
{
"target-attribute-name":"PlayerInfo",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"{\"Number\": \"${player_number}\",\"Position\": \"${Position}\",\"Status\": \"${status}\",\"Stats\": {\"Stat1\": \"${stat1}:${stat1_val}\",\"Stat2\": \"${stat2}:${stat2_val}\",\"Stat3\": \"${stat3}:${
stat3_val}\",\"Stat4\": \"${stat4}:${stat4_val}\"}"
}
]
}
},
{
"rule-type":"object-mapping",
"rule-id":"4",
"rule-name":"MapSportTeam",
"rule-action":"map-record-to-record",
"object-locator":{
"schema-name":"dms_sample",
"table-name":"sport_team"
},
"target-table-name":"SportTeams",
"mapping-parameters":{
"partition-key-name":"TeamName",
"exclude-columns": [
"name", "id"
],
"attribute-mappings":[
{
"target-attribute-name":"TeamName",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"${name}"
},
{
"target-attribute-name":"TeamInfo",
"attribute-type":"scalar",
"attribute-sub-type":"string",
"value":"{\"League\": \"${sport_league_short_name}\",\"Division\": \"${sport_division_short_name}\"}"
}
]
}
}
]
}
```
Output sampel untuk tabel *NFLTeams*DynamoDB ditunjukkan di bawah ini:
```
"PlayerInfo": "{\"Number\": \"6\",\"Position\": \"P\",\"Status\": \"ACT\",\"Stats\": {\"Stat1\": \"PUNTS:73\",\"Stat2\": \"AVG:46\",\"Stat3\": \"LNG:67\",\"Stat4\": \"IN 20:31\"}",
"PlayerName": "Allen, Ryan",
"Position": "P",
"stat1": "PUNTS",
"stat1_val": "73",
"stat2": "AVG",
"stat2_val": "46",
"stat3": "LNG",
"stat3_val": "67",
"stat4": "IN 20",
"stat4_val": "31",
"status": "ACT",
"Team": "NE"
}
```
Output sampel untuk tabel SportsTeams *DynamoDB* ditunjukkan di bawah ini:
```
{
"abbreviated_name": "IND",
"home_field_id": 53,
"sport_division_short_name": "AFC South",
"sport_league_short_name": "NFL",
"sport_type_name": "football",
"TeamInfo": "{\"League\": \"NFL\",\"Division\": \"AFC South\"}",
"TeamName": "Indianapolis Colts"
}
```
## Target tipe data untuk DynamoDB
Titik akhir DynamoDB untuk AWS DMS mendukung sebagian besar tipe data DynamoDB. Tabel berikut menunjukkan tipe data AWS DMS target Amazon yang didukung saat menggunakan AWS DMS dan pemetaan default dari tipe AWS DMS data.
Untuk informasi tambahan tentang tipe AWS DMS data, lihat[Tipe data untuk AWS Database Migration Service](CHAP_Reference.DataTypes.md).
Saat AWS DMS memigrasikan data dari database heterogen, kami memetakan tipe data dari database sumber ke tipe data perantara yang disebut AWS DMS tipe data. Kami kemudian memetakan tipe data perantara untuk tipe data target. Tabel berikut menunjukkan setiap tipe AWS DMS data dan tipe data yang dipetakan di DynamoDB:
| AWS DMS tipe data | Tipe data DynamoDB |
| --- | --- |
| String | String |
| WString | String |
| Boolean | Boolean |
| Date | String |
| DateTime | String |
| INT1 | Number |
| INT2 | Bilangan |
| INT4 | Bilangan |
| INT8 | Bilangan |
| Numeric | Number |
| Real4 | Number |
| Real8 | Bilangan |
| UINT1 | Bilangan |
| UINT2 | Bilangan |
| UINT4 | Bilangan |
| UINT8 | Bilangan |
| CLOB | String |
# Menggunakan Amazon Kinesis Data Streams sebagai target AWS Database Migration Service
Anda dapat menggunakannya AWS DMS untuk memigrasikan data ke aliran data Amazon Kinesis. Amazon Kinesis data streams adalah bagian dari layanan Amazon Kinesis Data Streams. Anda dapat menggunakan Kinesis data stream untuk mengumpulkan dan memproses sejumlah besar catatan data secara langsung.
Kinesis data stream adalah serangkaian serpihan. *Serpihan* secara unik diidentifikasi urutan catatan data dalam stream. Untuk informasi lebih lanjut tentang serpihan di Amazon Kinesis Data Streams, lihat [Serpihan](https://docs.aws.amazon.com/streams/latest/dev/key-concepts.html#shard) di *Panduan Developer Amazon Kinesis Data Streams.*
AWS Database Migration Service menerbitkan catatan ke aliran data Kinesis menggunakan JSON. Selama konversi, AWS DMS membuat serial setiap catatan dari basis data sumber ke dalam pasangan atribut-nilai dalam format JSON atau format pesan JSON\$1UNFORMATTED. Format pesan JSON\$1UNFORMATTED adalah string JSON baris tunggal dengan pembatas baris baru. Ini memungkinkan Amazon Data Firehose untuk mengirimkan data Kinesis ke tujuan Amazon S3, dan kemudian menanyakannya menggunakan berbagai mesin kueri termasuk Amazon Athena.
Anda menggunakan pemetaan objek untuk memigrasi data Anda dari sumber data mana pun yang didukung ke aliran target. Dengan pemetaan objek, Anda menentukan bagaimana struktur catatan data dalam aliran. Anda juga menentukan kunci partisi untuk setiap tabel, yang digunakan Kinesis Data Streams untuk mengelompokkan data ke dalam serpihannya.
AWS DMS juga menetapkan beberapa nilai parameter Kinesis Data Streams. Biaya pembuatan tabel tergantung pada jumlah data dan jumlah tabel yang akan dimigrasi.
**catatan**
Opsi **Mode SSL** di AWS DMS konsol atau API tidak berlaku untuk beberapa streaming data dan layanan NoSQL seperti Kinesis dan DynamoDB. Mereka aman secara default, jadi AWS DMS menunjukkan pengaturan mode SSL sama dengan tidak ada (Mode **SSL** = Tidak Ada). Anda tidak perlu menyediakan konfigurasi tambahan untuk titik akhir Anda untuk menggunakan SSL. Misalnya, saat menggunakan Kinesis sebagai titik akhir target, Kinesis sudah aman secara default. Semua panggilan API ke Kinesis menggunakan SSL, jadi tidak perlu opsi SSL tambahan di titik akhir. AWS DMS Anda dapat menempatkan data dengan aman dan mengambil data melalui titik akhir SSL menggunakan protokol HTTPS, yang AWS DMS digunakan secara default saat menghubungkan ke Kinesis Data Stream.
**Pengaturan titik akhir Kinesis Data Streams**
Saat Anda menggunakan titik akhir target Kinesis Data Streams, Anda bisa mendapatkan detail transaksi dan kontrol `KinesisSettings` menggunakan opsi di API. AWS DMS
Anda dapat mengatur pengaturan koneksi dengan cara berikut:
+ Di AWS DMS konsol, menggunakan pengaturan titik akhir.
+ Di CLI, menggunakan `kinesis-settings` opsi perintah. [CreateEndpoint](https://docs.aws.amazon.com/dms/latest/APIReference/API_CreateEndpoint.html)
Dalam CLI, gunakan parameter permintaan dari pilihan `kinesis-settings` berikut:
**catatan**
Support untuk pengaturan titik akhir `IncludeNullAndEmpty` tersedia pada AWS DMS versi 3.4.1 dan setelahnya. Tetapi dukungan untuk pengaturan titik akhir berikut lainnya untuk target Kinesis Data Streams tersedia di. AWS DMS
+ `MessageFormat` - Format keluaran untuk catatan yang dibuat pada titik akhir. Format pesan adalah `JSON` (default) atau `JSON_UNFORMATTED` (satu baris tanpa tab).
+ `IncludeControlDetails` - Menampilkan informasi kontrol terperinci untuk definisi tabel, definisi kolom, serta perubahan tabel dan kolom pada pesan keluaran Kinesis. Nilai default-nya `false`.
+ `IncludeNullAndEmpty` - Sertakan NULL dan kolom kosong dalam target. Nilai default-nya `false`.
+ `IncludePartitionValue` - Menampilkan nilai partisi dalam pesan keluaran Kinesis, kecuali tipe partisi `schema-table-type`. Nilai default-nya `false`.
+ `IncludeTableAlterOperations` - Termasuk setiap operasi bahasa definisi data (DDL) yang mengubah tabel dalam data kontrol, seperti `rename-table`, `drop-table`, `add-column`, `drop-column`, dan `rename-column`. Nilai default-nya `false`.
+ `IncludeTransactionDetails` - Menyediakan informasi transaksi detail dari basis data sumber. Informasi ini mencakup stempel waktu melakukan, posisi log, dan nilai-nilai untuk `transaction_id`, `previous_transaction_id`, dan `transaction_record_id `(catatan offset dalam transaksi). Nilai default-nya `false`.
+ `PartitionIncludeSchemaTable` - Skema prefiks dan nama tabel untuk nilai partisi, ketika tipe partisi `primary-key-type`. Melakukan hal ini meningkatkan distribusi data di antara serpihan Kinesis. Sebagai contoh, anggaplah bahwa skema `SysBench` memiliki ribuan tabel dan setiap tabel hanya memiliki rentang terbatas untuk kunci primer. Dalam kasus ini, kunci primer yang sama dikirim dari ribuan tabel ke serpihan yang sama, yang menyebabkan throttling. Nilai default-nya `false`.
+ `UseLargeIntegerValue`— Gunakan hingga 18 digit int alih-alih casting int sebagai ganda, tersedia dari AWS DMS versi 3.5.4. Default-nya adalah salah.
Contoh berikut menunjukkan bahwa `kinesis-settings` digunakan dengan sebuah contoh perintah `create-endpoint` yang dikeluarkan menggunakan perintah AWS CLI.
```
aws dms \
create-endpoint \
--region \
--endpoint-identifier \
--endpoint-type target \
--engine-name kinesis \
--kinesis-settings ServiceAccessRoleArn=arn:aws:iam:::role/,StreamArn=arn:aws:kinesis:::stream/,MessageFormat=json-unformatted,
IncludeControlDetails=true,IncludeTransactionDetails=true,IncludePartitionValue=true,PartitionIncludeSchemaTable=true,
IncludeTableAlterOperations=true
```
**Pengaturan tugas beban penuh multithread**
Untuk membantu meningkatkan kecepatan transfer, AWS DMS mendukung beban penuh multithreaded ke instance target Kinesis Data Streams. DMS mendukung multithreading ini dengan pengaturan tugas yang meliputi berikut ini:
+ `MaxFullLoadSubTasks` - Gunakan pilihan ini untuk menunjukkan jumlah maksimum tabel sumber yang dimuat secara paralel. DMS memuat setiap tabel ke dalam tabel target Kinesis yang sesuai menggunakan subtugas khusus. Default adalah 8; nilai maksimum adalah 49.
+ `ParallelLoadThreads`— Gunakan opsi ini untuk menentukan jumlah utas yang AWS DMS digunakan untuk memuat setiap tabel ke dalam tabel target Kinesis. Nilai maksimum untuk target Kinesis Data Streams adalah 32. Anda dapat meminta untuk meningkatkan batas maksimum ini.
+ `ParallelLoadBufferSize` - Gunakan pilihan ini untuk menentukan jumlah catatan maksimum yang disimpan di buffer yang digunakan oleh thread beban paralel untuk memuat data ke target Kinesis. Nilai default adalah 50. Nilai maksimumnya adalah 1.000. Gunakan pengaturan ini dengan `ParallelLoadThreads`. `ParallelLoadBufferSize` hanya berlaku bila ada lebih dari satu thread.
+ `ParallelLoadQueuesPerThread` - Gunakan pilihan ini untuk menentukan jumlah antrean yang diakses setiap thread secara bersamaan untuk mengambil catatan data dari antrean dan menghasilkan beban batch untuk target. Default adalah 1. Tetapi untuk target Kinesis dengan berbagai ukuran muatan, rentang yang valid adalah 5-512 antrean per thread.
**Pengaturan beban tugas CDC multithread**
Anda dapat meningkatkan performa perubahan pengambilan data (CDC) untuk titik akhir target streaming data secara langsung seperti Kinesis menggunakan pengaturan tugas untuk mengubah perilaku `PutRecords` Panggilan API. Untuk melakukan ini, Anda dapat menentukan jumlah thread yang terjadi bersamaan, antrean per thread, dan jumlah catatan yang disimpan dalam buffer menggunakan pengaturan tugas `ParallelApply*`. Misalnya, Anda ingin melakukan beban CDC dan menerapkan 128 thread secara paralel. Anda juga ingin mengakses 64 antrean per thread, dengan 50 catatan disimpan per buffer.
Untuk mempromosikan kinerja CDC, AWS DMS mendukung pengaturan tugas ini:
+ `ParallelApplyThreads`— Menentukan jumlah thread bersamaan yang AWS DMS digunakan selama beban CDC untuk mendorong catatan data ke titik akhir target Kinesis. Nilai default adalah nol (0) dan nilai maksimum adalah 32.
+ `ParallelApplyBufferSize` - Menentukan jumlah maksimum catatan yang disimpan di setiap antrean buffer untuk thread serentak untuk mendorong ke titik akhir target Kinesis selama beban CDC. Nilai default adalah 100 dan nilai maksimum adalah 1.000. Gunakan pilihan ini saat `ParallelApplyThreads` menentukan lebih dari satu thread.
+ `ParallelApplyQueuesPerThread` - Menentukan jumlah antrean yang diakses oleh setiap thread untuk mengambil catatan data dari antrean dan menghasilkan beban batch untuk titik akhir Kinesis selama CDC. Nilai default adalah 1 dan nilai maksimum adalah 512.
Saat menggunakan pengaturan tugas `ParallelApply*`, default `partition-key-type`-nya adalah `primary-key` dari tabel, bukan `schema-name.table-name`.
## Menggunakan citra sebelumnya untuk melihat nilai asli dari baris CDC untuk Kinesis data stream sebagai target
Ketika menulis pembaruan CDC ke target data-streaming seperti Kinesis Anda dapat melihat nilai asli baris basis data sumber sebelum diubah oleh pembaruan. Untuk memungkinkan hal ini, AWS DMS mengisi *gambar sebelum* peristiwa pembaruan berdasarkan data yang disediakan oleh mesin database sumber.
Mesin basis data sumber yang berbeda memberikan jumlah informasi yang berbeda untuk citra sebelum:
+ Oracle menyediakan update untuk kolom hanya jika mereka berubah.
+ PostgreSQL menyediakan data hanya untuk kolom yang merupakan bagian dari kunci primer (berubah atau tidak). Untuk menyediakan data untuk semua kolom (diubah atau tidak), Anda perlu mengatur `REPLICA_IDENTITY` ke `FULL` bukan`DEFAULT`. Perhatikan bahwa Anda harus memilih `REPLICA_IDENTITY` pengaturan dengan hati-hati untuk setiap tabel. Jika Anda menyetel `REPLICA_IDENTITY` ke`FULL`, semua nilai kolom ditulis ke write-ahead logging (WAL) secara terus menerus. Hal ini dapat menyebabkan masalah kinerja atau sumber daya dengan tabel yang sering diperbarui.
+ MySQL umumnya menyediakan data untuk semua kolom kecuali untuk tipe data BLOB dan CLOB (diubah atau tidak).
Untuk mengaktifkan pencitraan sebelumnya dengan tujuan menambahkan nilai asli dari basis data sumber untuk keluaran AWS DMS , gunakan pengaturan tugas `BeforeImageSettings` atau parameter `add-before-image-columns`. Parameter ini menerapkan aturan transformasi kolom.
`BeforeImageSettings` menambahkan atribut JSON baru untuk setiap operasi pembaruan dengan nilai yang dikumpulkan dari sistem basis data sumber, seperti yang ditunjukkan berikut.
```
"BeforeImageSettings": {
"EnableBeforeImage": boolean,
"FieldName": string,
"ColumnFilter": pk-only (default) / non-lob / all (but only one)
}
```
**catatan**
Hanya berlaku `BeforeImageSettings` untuk AWS DMS tugas yang berisi komponen CDC, seperti beban penuh ditambah tugas CDC (yang memigrasi data yang ada dan mereplikasi perubahan yang sedang berlangsung), atau ke tugas CDC saja (yang hanya mereplikasi perubahan data). Jangan terapkan `BeforeImageSettings` pada tugas-tugas yang beban penuh saja.
Untuk pilihan `BeforeImageSettings`, hal berikut berlaku:
+ Atur pilihan `EnableBeforeImage` ke `true` untuk mengaktifkan pencitraan sebelum. Nilai default-nya `false`.
+ Gunakan pilihan `FieldName` untuk memberikan nama ke atribut JSON baru. Ketika `EnableBeforeImage` adalah `true`, `FieldName` diperlukan dan tidak dapat kosong.
+ Pilihan `ColumnFilter` menentukan kolom untuk menambahkan dengan menggunakan pencitraan sebelumnya. Untuk menambahkan kolom yang hanya merupakan bagian dari kunci primer tabel saja, gunakan nilai default, `pk-only`. Untuk menambahkan kolom apa pun yang memiliki nilai citra sebelum, gunakan `all`. Perhatikan bahwa gambar sebelum tidak berisi kolom dengan tipe data LOB, seperti CLOB atau BLOB.
```
"BeforeImageSettings": {
"EnableBeforeImage": true,
"FieldName": "before-image",
"ColumnFilter": "pk-only"
}
```
**catatan**
Target Amazon S3 tidak mendukung `BeforeImageSettings`. Untuk target S3, gunakan hanya aturan transformasi `add-before-image-columns` untuk melakukan pencitraan sebelumnya selama CDC.
### Menggunakan aturan transformasi citra sebelumnya
Sebagai alternatif untuk pengaturan tugas, Anda dapat menggunakan parameter `add-before-image-columns`, yang menerapkan aturan transformasi kolom. Dengan parameter ini, Anda dapat mengaktifkan pencitraan sebelum selama CDC pada target data streaming seperti Kinesis.
Dengan menggunakan `add-before-image-columns` dalam aturan transformasi, Anda dapat menerapkan kontrol yang lebih halus dari hasil citra sebelum. Aturan transformasi memungkinkan Anda untuk menggunakan pencari objek yang memberikan Anda kontrol atas tabel yang dipilih untuk aturan tersebut. Dan juga, Anda dapat merangkai aturan transformasi, yang memungkinkan aturan yang berbeda untuk diterapkan ke tabel yang berbeda. Anda kemudian dapat memanipulasi kolom yang dihasilkan dengan menggunakan aturan lain.
**catatan**
Jangan gunakan parameter `add-before-image-columns` bersamaan dengan pengaturan tugas `BeforeImageSettings` dalam tugas yang sama. Sebaliknya, gunakan salah satu saja, parameter atau pengaturan, tetapi tidak keduanya, untuk satu tugas.
Sebuah tipe peraturan `transformation` dengan parameter `add-before-image-columns` untuk kolom harus menyediakan `before-image-def` bagian. Berikut ini adalah sebuah contoh.
```
{
"rule-type": "transformation",
…
"rule-target": "column",
"rule-action": "add-before-image-columns",
"before-image-def":{
"column-filter": one-of (pk-only / non-lob / all),
"column-prefix": string,
"column-suffix": string,
}
}
```
Nilai dari `column-prefix` ditambahkan sebelum nama kolom, dan nilai default `column-prefix` adalah `BI_`. Nilai dari `column-suffix` ditambahkan sebelum nama kolom, dan default kosong. Jangan atur `column-prefix` dan `column-suffix` ke string kosong.
Pilih satu nilai untuk `column-filter`. Untuk menambahkan kolom yang merupakan bagian dari kunci primer tabel saja, pilih `pk-only`. Untuk menambahkan kolom yang bukan tipe LOB saja, gunakan `non-lob`. Atau pilih `all` untuk menambahkan kolom yang memiliki nilai citra-sebelum.
### Contoh untuk aturan transformasi citra sebelumnya
Aturan transformasi dalam contoh berikut menambahkan kolom baru yang disebut `BI_emp_no` pada target. Jadi pernyataan seperti `UPDATE employees SET emp_no = 3 WHERE emp_no = 1;` mengisi `BI_emp_no` field dengan 1. Ketika Anda menulis pembaruan CDC untuk target Amazon S3, kolom `BI_emp_no` memungkinkan untuk memberitahu baris asli yang diperbarui.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-target": "column",
"object-locator": {
"schema-name": "%",
"table-name": "employees"
},
"rule-action": "add-before-image-columns",
"before-image-def": {
"column-prefix": "BI_",
"column-suffix": "",
"column-filter": "pk-only"
}
}
]
}
```
Untuk informasi tentang penggunaan peraturan tindakan `add-before-image-columns`, lihat [Aturan dan tindakan transformasi](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
## Prasyarat untuk menggunakan aliran data Kinesis sebagai target AWS Database Migration Service
### Peran IAM untuk menggunakan aliran data Kinesis sebagai target AWS Database Migration Service
Sebelum Anda mengatur aliran data Kinesis sebagai target AWS DMS, pastikan Anda membuat peran IAM. Peran ini harus memungkinkan AWS DMS untuk mengasumsikan dan memberikan akses ke aliran data Kinesis yang sedang dimigrasikan ke. Kumpulan izin akses minimum ditampilkan dalam kebijakan IAM berikut.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"Service": "dms.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Peran yang Anda gunakan untuk migrasi ke Kinesis data stream harus memiliki izin berikut.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kinesis:DescribeStream",
"kinesis:PutRecord",
"kinesis:PutRecords"
],
"Resource": "*"
}
]
}
```
------
### Mengakses aliran data Kinesis sebagai target AWS Database Migration Service
Di AWS DMS versi 3.4.7 dan yang lebih tinggi, untuk terhubung ke titik akhir Kinesis, Anda harus melakukan salah satu hal berikut:
+ Konfigurasikan DMS untuk menggunakan titik akhir VPC. Untuk informasi tentang mengonfigurasi DMS untuk menggunakan titik akhir VPC, lihat. [Mengkonfigurasi titik akhir VPC untuk AWS DMS](CHAP_VPC_Endpoints.md)
+ Konfigurasikan DMS untuk menggunakan rute publik, yaitu membuat instance replikasi Anda menjadi publik. Untuk informasi tentang contoh replikasi publik, lihat. [Instans replikasi publik dan privat](CHAP_ReplicationInstance.PublicPrivate.md)
## Keterbatasan saat menggunakan Kinesis Data Streams sebagai target AWS Database Migration Service
Batasan berikut berlaku saat menggunakan Kinesis Data Streams sebagai target:
+ AWS DMS menerbitkan setiap pembaruan ke satu catatan dalam database sumber sebagai satu catatan data dalam aliran data Kinesis tertentu terlepas dari transaksi. Namun, Anda dapat menyertakan detail transaksi untuk setiap data catatan dengan menggunakan parameter yang relevan dari API `KinesisSettings`.
+ Mode LOB penuh tidak didukung.
+ Ukuran LOB maksimum yang didukung adalah 1 MB.
+ Kinesis Data Streams tidak mendukung deduplikasi. Aplikasi yang mengonsumsi data dari aliran perlu menangani duplikasi catatan. Untuk informasi lebih lanjut, lihat [Menangani catatan duplikat](https://docs.aws.amazon.com/streams/latest/dev/kinesis-record-processor-duplicates.html) di *Panduan Developer Amazon Kinesis Data Streams.*
+ AWS DMS mendukung empat bentuk berikut untuk kunci partisi:
+ `SchemaName.TableName`: Kombinasi skema dan nama tabel.
+ `${AttributeName}`: Nilai salah satu field di JSON, atau kunci primer dari tabel dalam basis data sumber.
+ `transaction-id`: ID transaksi CDC. Semua catatan dalam transaksi yang sama masuk ke partisi yang sama.
+ `constant`: Nilai literal tetap untuk setiap catatan terlepas dari tabel atau data. Semua catatan dikirim ke nilai kunci partisi yang sama “konstan”, memberikan urutan global yang ketat di semua tabel.
```
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "PartitionKeyTypeExample",
"rule-action": "map-record-to-document",
"object-locator": {
"schema-name": "onprem",
"table-name": "it_system"
},
"mapping-parameters": {
"partition-key-type": "transaction-id | constant | attribute-name | schema-table"
}
}
```
+ Untuk informasi tentang mengenkripsi data at rest Anda saat berada dalam Kinesis Data Streams, lihat [Perlindungan data dalam Kinesis Data Streams](https://docs.aws.amazon.com/streams/latest/dev/server-side-encryption.html.html) di *Panduan Developer AWS Key Management Service *.
+ Pengaturan `IncludeTransactionDetails` endpoint hanya didukung ketika titik akhir sumber adalah Oracle, SQL Server, PostgreSQL, atau MySQL. Untuk jenis titik akhir sumber lainnya, detail transaksi tidak akan disertakan.
+ `BatchApply` tidak didukung untuk titik akhir Kinesis. Menggunakan Batch Apply (misalnya, pengaturan tugas metadata `BatchApplyEnabled` target) untuk target Kinesis menyebabkan kegagalan tugas dan kehilangan data. Jangan aktifkan `BatchApply` saat menggunakan Kinesis sebagai titik akhir target.
+ Target kinesis hanya didukung untuk aliran data Kinesis di AWS akun yang sama dan sama dengan instance replikasi Wilayah AWS .
+ Saat bermigrasi dari sumber MySQL, BeforeImage data tidak menyertakan tipe data CLOB dan BLOB. Untuk informasi selengkapnya, lihat [Menggunakan citra sebelumnya untuk melihat nilai asli dari baris CDC untuk Kinesis data stream sebagai target](#CHAP_Target.Kinesis.BeforeImage).
+ AWS DMS tidak mendukung migrasi nilai tipe `BigInt` data dengan lebih dari 16 digit. Untuk mengatasi batasan ini, Anda dapat menggunakan aturan transformasi berikut untuk mengonversi `BigInt` kolom menjadi string. Untuk informasi selengkapnya tentang aturan transformasi, lihat[Aturan dan tindakan transformasi](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
```
{
"rule-type": "transformation",
"rule-id": "id",
"rule-name": "name",
"rule-target": "column",
"object-locator": {
"schema-name": "valid object-mapping rule action",
"table-name": "",
"column-name": ""
},
"rule-action": "change-data-type",
"data-type": {
"type": "string",
"length": 20
}
}
```
+ Ketika beberapa operasi DHTML dalam satu transaksi memodifikasi kolom Objek Besar (LOB) pada database sumber, database target hanya mempertahankan nilai LOB akhir dari operasi terakhir dalam transaksi itu. Nilai LOB menengah yang ditetapkan oleh operasi sebelumnya dalam transaksi yang sama ditimpa, yang dapat mengakibatkan potensi kehilangan data atau ketidakkonsistenan. Perilaku ini terjadi karena bagaimana data LOB diproses selama replikasi.
+ AWS DMS tidak mendukung data sumber yang berisi `'\0'` karakter yang disematkan saat menggunakan Kinesis sebagai titik akhir target. Data yang berisi `'\0'` karakter tertanam akan terpotong pada karakter pertama`'\0'`.
## Menggunakan pemetaan objek untuk memigrasi data ke Kinesis data stream
AWS DMS menggunakan aturan pemetaan tabel untuk memetakan data dari sumber ke aliran data Kinesis target. Untuk memetakan data ke aliran target, Anda menggunakan jenis aturan pemetaan tabel yang disebut pemetaan objek. Anda menggunakan pemetaan objek untuk menentukan cara pencatatan data di peta sumber ke pencatatan data yang dipublikasikan ke Kinesis data stream.
Kinesis data stream tidak memiliki struktur preset selain memiliki kunci partisi. Dalam aturan pemetaan objek, nilai-nilai yang mungkin dari `partition-key-type` untuk catatan data adalah `schema-table`, `transaction-id`, `primary-key`, `constant`, dan `attribute-name`.
Untuk membuat aturan pemetaan objek, Anda tentukan `rule-type` sebagai `object-mapping`. Aturan ini menentukan jenis pemetaan objek yang ingin Anda gunakan.
Struktur untuk aturan tersebut adalah sebagai berikut.
```
{
"rules": [
{
"rule-type": "object-mapping",
"rule-id": "id",
"rule-name": "name",
"rule-action": "valid object-mapping rule action",
"object-locator": {
"schema-name": "case-sensitive schema name",
"table-name": ""
}
}
]
}
```
AWS DMS saat ini mendukung `map-record-to-record` dan `map-record-to-document` sebagai satu-satunya nilai yang valid untuk `rule-action` parameter. Pengaturan ini memengaruhi nilai yang tidak dikecualikan sebagai bagian dari daftar `exclude-columns` atribut. `map-record-to-document`Nilai `map-record-to-record` dan menentukan bagaimana AWS DMS menangani catatan ini secara default. Nilai-nilai ini tidak mempengaruhi pemetaan atribut dengan cara apapun.
Gunakan `map-record-to-record` saat bermigrasi dari basis data relasional ke Kinesis data stream. Jenis aturan ini menggunakan nilai `taskResourceId.schemaName.tableName` dari basis data relasional sebagai kunci partisi dalam Kinesis data stream dan membuat atribut untuk setiap kolom dalam basis data sumber.
Saat menggunakan`map-record-to-record`, perhatikan hal berikut:
+ Pengaturan ini hanya memengaruhi kolom yang dikecualikan oleh `exclude-columns` daftar.
+ Untuk setiap kolom tersebut, AWS DMS buat atribut yang sesuai dalam topik target.
+ AWS DMS menciptakan atribut yang sesuai ini terlepas dari apakah kolom sumber digunakan dalam pemetaan atribut.
Gunakan `map-record-to-document` untuk menempatkan kolom sumber ke dalam satu, dokumen datar dalam aliran target yang sesuai menggunakan nama atribut “\$1doc”. AWS DMS menempatkan data ke dalam satu peta datar pada sumber yang disebut ”`_doc`“. Penempatan ini berlaku untuk kolom mana pun di tabel sumber yang tidak tercantum dalam daftar atribut `exclude-columns`.
Salah satu cara untuk memahami `map-record-to-record` adalah melihatnya beraksi. Untuk contoh ini, anggaplah bahwa Anda memulai dengan baris tabel basis data relasional dengan struktur dan data berikut.
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateofBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
Untuk memigrasi informasi ini dari skema bernama `Test` ke Kinesis data stream, Anda membuat aturan untuk memetakan data ke aliran target. Aturan berikut menggambarkan pemetaan.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"rule-action": "include",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
}
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "DefaultMapToKinesis",
"rule-action": "map-record-to-record",
"object-locator": {
"schema-name": "Test",
"table-name": "Customers"
}
}
]
}
```
Berikut ini menggambarkan format catatan yang dihasilkan dalam Kinesis data stream:
+ StreamName: XXX
+ PartitionKey: Test.Customers //schmaname.TableName
+ Data: //Pesan JSON berikut
```
{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"HomeAddress": "221B Baker Street",
"HomePhone": "1234567890",
"WorkAddress": "31 Spooner Street, Quahog",
"WorkPhone": "9876543210",
"DateOfBirth": "02/29/1988"
}
```
Namun, anggaplah Anda menggunakan aturan yang sama tetapi mengubah parameter `rule-action` untuk `map-record-to-document` dan mengecualikan kolom tertentu. Aturan berikut menggambarkan pemetaan.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"rule-action": "include",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
}
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "DefaultMapToKinesis",
"rule-action": "map-record-to-document",
"object-locator": {
"schema-name": "Test",
"table-name": "Customers"
},
"mapping-parameters": {
"exclude-columns": [
"homeaddress",
"homephone",
"workaddress",
"workphone"
]
}
}
]
}
```
Dalam kasus ini, kolom tidak tercantum dalam parameter `exclude-columns`, `FirstName`, `LastName`, `StoreId` dan `DateOfBirth`, dipetakan ke `_doc`. Berikut ini menggambarkan format catatan yang dihasilkan.
```
{
"data":{
"_doc":{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"DateOfBirth": "02/29/1988"
}
}
}
```
### Restrukturisasi data dengan pemetaan atribut
Anda dapat merestrukturisasi data saat memigrasinya ke Kinesis data stream menggunakan peta atribut. Misalnya, Anda mungkin ingin menggabungkan beberapa field di sumber menjadi field tunggal dalam target. Peta atribut berikut menggambarkan bagaimana merestrukturisasi data.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"rule-action": "include",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
}
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "TransformToKinesis",
"rule-action": "map-record-to-record",
"target-table-name": "CustomerData",
"object-locator": {
"schema-name": "Test",
"table-name": "Customers"
},
"mapping-parameters": {
"partition-key-type": "attribute-name",
"partition-key-name": "CustomerName",
"exclude-columns": [
"firstname",
"lastname",
"homeaddress",
"homephone",
"workaddress",
"workphone"
],
"attribute-mappings": [
{
"target-attribute-name": "CustomerName",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${lastname}, ${firstname}"
},
{
"target-attribute-name": "ContactDetails",
"attribute-type": "document",
"attribute-sub-type": "json",
"value": {
"Home": {
"Address": "${homeaddress}",
"Phone": "${homephone}"
},
"Work": {
"Address": "${workaddress}",
"Phone": "${workphone}"
}
}
}
]
}
}
]
}
```
Untuk menetapkan nilai konstan untuk`partition-key`, tentukan`"partition-key-type: "constant"`, ini menetapkan nilai partisi ke`constant`. Misalnya, Anda mungkin melakukan ini untuk memaksa semua data untuk disimpan dalam serpihan tunggal. Pemetaan berikut menggambarkan pendekatan ini.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "TransformToKinesis",
"rule-action": "map-record-to-document",
"object-locator": {
"schema-name": "Test",
"table-name": "Customer"
},
"mapping-parameters": {
"partition-key-type": "constant",
"exclude-columns": [
"FirstName",
"LastName",
"HomeAddress",
"HomePhone",
"WorkAddress",
"WorkPhone"
],
"attribute-mappings": [
{
"target-attribute-name": "CustomerName",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${FirstName},${LastName}"
},
{
"target-attribute-name": "ContactDetails",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": {
"Home": {
"Address": "${HomeAddress}",
"Phone": "${HomePhone}"
},
"Work": {
"Address": "${WorkAddress}",
"Phone": "${WorkPhone}"
}
}
},
{
"target-attribute-name": "DateOfBirth",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${DateOfBirth}"
}
]
}
}
]
}
```
**catatan**
Nilai `partition-key` untuk catatan kontrol yang ditujukan khusus untuk tabel tertentu adalah `TaskId.SchemaName.TableName`. Nilai `partition-key` untuk catatan kontrol yang ditujukan untuk tugas tertentu adalah `TaskId` dari catatan tersebut. Menentukan nilai `partition-key` dalam pemetaan objek tidak berdampak pada `partition-key` untuk catatan kontrol.
Kapan `partition-key-type` diatur ke `attribute-name` dalam aturan pemetaan tabel, Anda harus menentukan`partition-key-name`, yang harus mereferensikan kolom dari tabel sumber atau kolom kustom yang ditentukan dalam pemetaan. Selain itu, `attribute-mappings` harus disediakan untuk menentukan bagaimana kolom sumber memetakan ke Aliran Kinesis target.
### Format pesan untuk Kinesis Data Streams
Keluaran JSON hanya berupa daftar pasangan nilai-kunci. Format pesan JSON\$1UNFORMATTED adalah string JSON baris tunggal dengan pembatas baris baru.
AWS DMS menyediakan bidang cadangan berikut untuk mempermudah penggunaan data dari Kinesis Data Streams:
**RecordType**
Jenis catatan dapat berupa data atau kontrol. *Catatan data* mewakili baris yang sebenarnya dalam sumber. *Kontrol catatan* adalah untuk peristiwa-peristiwa penting di aliran, misalnya restart tugas.
**Operasi**
Untuk catatan data, operasinya dapat `load`, `insert`, `update`, atau `delete`.
Untuk catatan kontrol, operasi dapat berupa`create-table`,`rename-table`,`drop-table`,`change-columns`,`add-column`,`drop-column`,`rename-column`, atau`column-type-change`.
**SchemaName**
Skema sumber untuk catatan. Field ini bisa kosong untuk catatan kontrol.
**TableName**
Tabel sumber untuk catatan. Field ini bisa kosong untuk catatan kontrol.
**Stempel waktu**
Stempel waktu untuk saat pesan JSON dibuat. Field ini diformat dengan format ISO 8601.
# Menggunakan Apache Kafka sebagai target AWS Database Migration Service
Anda dapat menggunakan AWS DMS untuk memigrasikan data ke cluster Apache Kafka. Apache Kafka adalah platform streaming terdistribusi. Anda dapat menggunakan Apache Kafka untuk menelan dan memproses data streaming secara langsung.
AWS juga menawarkan Amazon Managed Streaming for Apache Kafka (Amazon MSK) untuk digunakan sebagai target. AWS DMS Amazon MSK adalah layanan streaming Apache Kafka yang terkelola penuh yang menyederhanakan implementasi dan pengelolaan instans Apache Kafka. Ini bekerja dengan versi Apache Kafka open-source, dan Anda mengakses instans MSK Amazon sebagai AWS DMS target persis seperti instans Apache Kafka lainnya. Untuk informasi lebih lanjut, lihat [Apa itu Amazon MSK?](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html) dalam *Panduan Developer: Amazon Managed Streaming for Apache Kafka*.
Sebuah klaster Kafka menyimpan aliran catatan dalam kategori yang disebut topik yang dibagi menjadi partisi. *Partisi* adalah urutan catatan data (pesan) yang diidentifikasi secara unik secara unik dalam suatu topik. Partisi dapat didistribusikan ke beberapa broker dalam sebuah klaster untuk mengaktifkan pemrosesan paralel catatan topik. Untuk informasi lebih lanjut tentang topik dan partisi dan distribusi mereka di Apache Kafka, lihat [Topik dan log](https://kafka.apache.org/documentation/#intro_topics) dan [Distribusi](https://kafka.apache.org/documentation/#intro_distribution).
Kluster Kafka Anda dapat berupa instans MSK Amazon, klaster yang berjalan di instans Amazon EC2, atau kluster lokal. Instans MSK Amazon atau cluster pada instans Amazon EC2 dapat berada di VPC yang sama atau yang berbeda. Jika klaster Anda lokal, Anda dapat menggunakan server nama lokal Anda sendiri untuk instance replikasi untuk menyelesaikan nama host klaster. Untuk informasi tentang menyiapkan server nama untuk instance replikasi Anda, lihat[Menggunakan server nama on-premise Anda sendiri](CHAP_BestPractices.md#CHAP_BestPractices.Rte53DNSResolver). Untuk informasi selengkapnya tentang pengaturan jaringan, lihat[Menyiapkan jaringan untuk instans replikasi](CHAP_ReplicationInstance.VPC.md).
Saat menggunakan kluster MSK Amazon, pastikan grup keamanannya mengizinkan akses dari instance replikasi Anda. Untuk informasi tentang mengubah grup keamanan untuk klaster MSK Amazon, lihat [Mengubah grup keamanan klaster MSK Amazon](https://docs.aws.amazon.com/msk/latest/developerguide/change-security-group.html).
AWS Database Migration Service menerbitkan catatan ke topik Kafka menggunakan JSON. Selama konversi, AWS DMS membuat serial setiap catatan dari basis data sumber ke dalam pasangan atribut-nilai dalam format JSON.
Untuk memigrasikan data Anda dari sumber data apa pun yang didukung ke klaster Kafka target, Anda menggunakan pemetaan objek. Dengan pemetaan objek, Anda menentukan bagaimana struktur catatan data dalam topik target. Anda juga menentukan kunci partisi untuk setiap tabel, yang digunakan Apache Kafka untuk mengelompokkan data ke dalam partisi.
Saat ini, AWS DMS mendukung satu topik per tugas. Untuk satu tugas dengan beberapa tabel, semua pesan masuk ke satu topik. Setiap pesan menyertakan bagian metadata yang mengidentifikasi skema dan tabel target. AWS DMS versi 3.4.6 dan yang lebih tinggi mendukung replikasi multitopik menggunakan pemetaan objek. Untuk informasi selengkapnya, lihat [Replikasi multitopik menggunakan pemetaan objek](#CHAP_Target.Kafka.MultiTopic).
**Pengaturan titik akhir Apache Kafka**
Anda dapat menentukan detail koneksi melalui pengaturan titik akhir di AWS DMS konsol, atau `--kafka-settings` opsi di CLI. Persyaratan untuk setiap pengaturan:
+ `Broker` - Tentukan lokasi dari satu atau lebih broker di klaster Kafka Anda dalam bentuk daftar yang dipisahkan koma untuk masing-masing `broker-hostname:port`. Contohnya `"ec2-12-345-678-901.compute-1.amazonaws.com:2345,ec2-10-987-654-321.compute-1.amazonaws.com:9876"`. Pengaturan ini dapat menentukan lokasi dari salah satu atau semua broker dalam klaster. Semua Klaster broker berkomunikasi untuk menangani partisi catatan data yang dimigrasikan ke topik.
+ `Topic` - (Opsional) Tentukan nama topik dengan panjang maksimum 255 huruf dan simbol. Anda dapat menggunakan titik (.), garis bawah (\$1), dan minus (-). Nama topik dengan titik (.) atau garis bawah (\$1) dapat bertabrakan dalam struktur data internal. Gunakan salah satu, tetapi jangan kedua simbol ini sekaligus dalam nama topik. Jika Anda tidak menentukan nama topik, AWS DMS gunakan `"kafka-default-topic"` sebagai topik migrasi.
**catatan**
Untuk AWS DMS membuat topik migrasi yang Anda tentukan atau topik default, tetapkan `auto.create.topics.enable = true` sebagai bagian dari konfigurasi cluster Kafka Anda. Untuk informasi selengkapnya, lihat [Keterbatasan saat menggunakan Apache Kafka sebagai target AWS Database Migration Service](#CHAP_Target.Kafka.Limitations)
+ `MessageFormat` - Format keluaran untuk catatan yang dibuat pada titik akhir. Format pesan adalah `JSON` (default) atau `JSON_UNFORMATTED` (satu baris tanpa tab).
+ `MessageMaxBytes` - Ukuran maksimum dalam byte untuk catatan yang dibuat pada titik akhir. Default adalah 1.000.000.
**catatan**
Anda hanya dapat menggunakan AWS CLI/SDK untuk mengubah `MessageMaxBytes` ke nilai non-default. Misalnya, untuk memodifikasi titik akhir Kafka yang sudah ada dan mengubah `MessageMaxBytes`, gunakan perintah berikut.
```
aws dms modify-endpoint --endpoint-arn your-endpoint
--kafka-settings Broker="broker1-server:broker1-port,broker2-server:broker2-port,...",
Topic=topic-name,MessageMaxBytes=integer-of-max-message-size-in-bytes
```
+ `IncludeTransactionDetails` - Menyediakan informasi transaksi detail dari basis data sumber. Informasi ini mencakup stempel waktu melakukan, posisi log, dan nilai-nilai untuk `transaction_id`, `previous_transaction_id`, dan `transaction_record_id` (catatan offset dalam transaksi). Nilai default-nya `false`.
+ `IncludePartitionValue` - Menampilkan nilai partisi dalam pesan keluaran Kafka, kecuali jika tipe partisi adalah `schema-table-type`. Nilai default-nya `false`.
+ `PartitionIncludeSchemaTable` - Skema prefiks dan nama tabel untuk nilai partisi, ketika tipe partisi `primary-key-type`. Melakukan hal ini meningkatkan distribusi data antara partisi Kafka. Sebagai contoh, anggaplah bahwa skema `SysBench` memiliki ribuan tabel dan setiap tabel hanya memiliki rentang terbatas untuk kunci primer. Dalam kasus ini, kunci primer yang sama dikirim dari ribuan tabel ke partisi yang sama, sehingga menyebabkan throttling. Nilai default-nya `false`.
+ `IncludeTableAlterOperations` - Termasuk setiap operasi bahasa definisi data (DDL) yang mengubah tabel dalam data kontrol, seperti `rename-table`, `drop-table`, `add-column`, `drop-column`, dan `rename-column`. Nilai default-nya `false`.
+ `IncludeControlDetails` - Menunjukkan informasi kontrol detail untuk definisi tabel, definisi kolom, dan perubahan tabel dan kolom pada keluaran pesan Kafka. Nilai default-nya `false`.
+ `IncludeNullAndEmpty` - Sertakan NULL dan kolom kosong dalam target. Nilai default-nya `false`.
+ `SecurityProtocol` - Menyetel koneksi yang aman ke titik akhir target Kafka menggunakan Keamanan Lapisan Pengangkutan (TLS). Pilihan termasuk `ssl-authentication`, `ssl-encryption`, dan `sasl-ssl`. Menggunakan `sasl-ssl` membutuhkan `SaslUsername` dan `SaslPassword`.
+ `SslEndpointIdentificationAlgorithm`— Menetapkan verifikasi nama host untuk sertifikat. Pengaturan ini didukung di AWS DMS versi 3.5.1 dan yang lebih baru. Opsi mencakup hal berikut:
+ `NONE`: Nonaktifkan verifikasi nama host broker dalam koneksi klien.
+ `HTTPS`: Aktifkan verifikasi nama host broker dalam koneksi klien.
+ `useLargeIntegerValue`— Gunakan hingga 18 digit int alih-alih casting int sebagai ganda, tersedia dari AWS DMS versi 3.5.4. Default-nya adalah salah.
Anda dapat menggunakan pengaturan untuk membantu meningkatkan kecepatan transfer Anda. Untuk melakukannya, AWS DMS mendukung beban penuh multithread klaster target Apache Kafka. AWS DMS mendukung multithreading dengan pengaturan tugas yang meliputi hal berikut ini:
+ `MaxFullLoadSubTasks`— Gunakan opsi ini untuk menunjukkan jumlah maksimum tabel sumber untuk dimuat secara paralel. AWS DMS memuat setiap tabel ke dalam tabel target Kafka yang sesuai menggunakan subtugas khusus. Default adalah 8; nilai maksimum adalah 49.
+ `ParallelLoadThreads`— Gunakan opsi ini untuk menentukan jumlah utas yang AWS DMS digunakan untuk memuat setiap tabel ke dalam tabel target Kafka. Nilai maksimum untuk target Apache Kafka adalah 32. Anda dapat meminta untuk meningkatkan batas maksimum ini.
+ `ParallelLoadBufferSize` - Gunakan pilihan ini untuk menentukan jumlah maksimum catatan untuk disimpan di buffer yang digunakan oleh thread beban paralel untuk memuat data ke target Kafka. Nilai default adalah 50. Nilai maksimumnya adalah 1.000. Gunakan pengaturan ini dengan `ParallelLoadThreads`. `ParallelLoadBufferSize` hanya berlaku bila ada lebih dari satu thread.
+ `ParallelLoadQueuesPerThread` - Gunakan pilihan ini untuk menentukan jumlah antrean yang diakses setiap thread secara bersamaan untuk mengambil catatan data dari antrean dan menghasilkan beban batch untuk target. Default adalah 1. Maksimum adalah 512.
Anda dapat meningkatkan kinerja pengambilan data perubahan (CDC) untuk titik akhir Kafka dengan menyetel pengaturan tugas untuk thread paralel dan operasi massal. Untuk melakukan ini, Anda dapat menentukan jumlah thread yang terjadi bersamaan, antrean per thread, dan jumlah catatan yang disimpan dalam buffer menggunakan pengaturan tugas `ParallelApply*`. Misalnya, Anda ingin melakukan beban CDC dan menerapkan 128 thread secara paralel. Anda juga ingin mengakses 64 antrean per thread, dengan 50 catatan disimpan per buffer.
Untuk mempromosikan kinerja CDC, AWS DMS mendukung pengaturan tugas ini:
+ `ParallelApplyThreads`— Menentukan jumlah thread bersamaan yang AWS DMS digunakan selama beban CDC untuk mendorong catatan data ke titik akhir target Kafka. Nilai default adalah nol (0) dan nilai maksimum adalah 32.
+ `ParallelApplyBufferSize` - Menentukan jumlah maksimum catatan yang disimpan di setiap antrean buffer untuk thread serentak untuk mendorong ke titik akhir target Kinesis selama beban CDC. Nilai default adalah 100 dan nilai maksimum adalah 1.000. Gunakan pilihan ini saat `ParallelApplyThreads` menentukan lebih dari satu thread.
+ `ParallelApplyQueuesPerThread` - Menentukan jumlah antrean yang diakses oleh setiap thread untuk mengambil catatan data dari antrean dan menghasilkan beban batch untuk titik akhir Kafka selama CDC. Default-nya adalah 1. Maksimum adalah 512.
Saat menggunakan pengaturan tugas `ParallelApply*`, default `partition-key-type`-nya adalah `primary-key` dari tabel, bukan `schema-name.table-name`.
## Menghubungkan ke Kafka menggunakan Keamanan Lapisan Pengangkutan (TLS)
Sebuah klaster Kafka menerima koneksi aman menggunakan Keamanan Lapisan Pengangkutan (TLS). Dengan DMS, Anda dapat menggunakan salah satu dari tiga pilihan protokol keamanan berikut untuk mengamankan koneksi titik akhir Kafka.
**Enkripsi SSL (`server-encryption`)**
Klien memvalidasi identitas server melalui sertifikat server. Kemudian koneksi terenkripsi dibuat antara server dan klien.
**Autentikasi SSL (`mutual-authentication`)**
Server dan klien memvalidasi identitas dengan satu sama lain melalui sertifikat mereka sendiri. Kemudian koneksi terenkripsi dibuat antara server dan klien.
**SASL-SSL (`mutual-authentication`)**
Metode The Simple Authentication and Security Layer (SASL) menggantikan sertifikat klien dengan nama pengguna dan kata sandi untuk memvalidasi identitas klien. Secara spesifik, Anda memberikan nama pengguna dan kata sandi yang telah didaftarkan ke server sehingga server dapat memvalidasi identitas klien. Kemudian koneksi terenkripsi dibuat antara server dan klien.
**penting**
Apache Kafka dan Amazon MSK menerima sertifikat diselesaikan. Ini adalah keterbatasan yang sudah diketahui dari Kafka dan Amazon MSK yang harus ditangani. Untuk informasi lebih lanjut, lihat [Masalah Apache Kafka, KAFKA-3700](https://issues.apache.org/jira/browse/KAFKA-3700).
Jika Anda menggunakan Amazon MSK, pertimbangkan untuk menggunakan daftar kontrol akses (ACLs) sebagai solusi untuk batasan yang diketahui ini. Untuk informasi selengkapnya tentang penggunaan ACLs, lihat ACLs bagian [Apache Kafka](https://docs.aws.amazon.com//msk/latest/developerguide/msk-acls.html) dari *Amazon Managed Streaming for Apache Kafka Developer* Guide.
Jika Anda menggunakan klaster Kafka yang dikelola sendiri, lihat [Komentar tanggal 21/Oct/18](https://issues.apache.org/jira/browse/KAFKA-3700?focusedCommentId=16658376) untuk informasi tentang mengonfigurasi klaster Anda.
### Menggunakan enkripsi SSL dengan Amazon MSK atau klaster Kafka yang dikelola sendiri
Anda dapat menggunakan enkripsi SSL untuk mengamankan koneksi titik akhir ke Amazon MSK atau klaster Kafka yang dikelola sendiri. Saat Anda menggunakan metode autentikasi enkripsi SSL, klien memvalidasi identitas server melalui sertifikat server. Kemudian koneksi terenkripsi dibuat antara server dan klien.
**Menggunakan enkripsi SSL untuk terhubung ke Amazon MSK**
+ Tetapkan pengaturan titik akhir protokol keamanan (`SecurityProtocol`) menggunakan pilihan `ssl-encryption` ketika membuat titik akhir target Kafka Anda.
Contoh JSON berikut menetapkan protokol keamanan sebagai enkripsi SSL.
```
"KafkaSettings": {
"SecurityProtocol": "ssl-encryption",
}
```
**Untuk menggunakan enkripsi SSL sebagai klaster Kafka yang dikelola sendiri**
1. Jika Anda menggunakan Otoritas Sertifikasi (CA) pribadi di klaster Kafka on-premise Anda, unggahlah sertifikat CA pribadi dan dapatkan Amazon Resource Name (ARN).
1. Tetapkan pengaturan titik akhir protokol keamanan (`SecurityProtocol`) menggunakan pilihan `ssl-encryption` ketika membuat titik akhir target Kafka Anda. Contoh JSON berikut menetapkan protokol keamanan sebagai `ssl-encryption`.
```
"KafkaSettings": {
"SecurityProtocol": "ssl-encryption",
}
```
1. Jika Anda menggunakan CA pribadi, atur `SslCaCertificateArn` di ARN yang Anda dapatkan di langkah pertama di atas.
### Menggunakan autentikasi SSL
Anda dapat menggunakan autentikasi SSL untuk mengamankan koneksi titik akhir ke Amazon MSK atau klaster Kafka yang dikelola sendiri.
Untuk mengaktifkan autentikasi klien dan enkripsi menggunakan otentikasi SSL untuk menyambung ke Amazon MSK, lakukan hal berikut:
+ Siapkan kunci privat dan sertifikat publik untuk Kafka.
+ Unggah sertifikat ke DMS Certificate Manager .
+ Buat titik akhir target Kafka dengan sertifikat terkait yang ARNs ditentukan dalam pengaturan titik akhir Kafka.
**Untuk mempersiapkan kunci privat dan sertifikat publik untuk Amazon MSK**
1. Membuat instans EC2 dan atur klien untuk menggunakan autentikasi seperti yang dijelaskan dalam langkah 1 sampai 9 di [Autentikasi klien](https://docs.aws.amazon.com/msk/latest/developerguide/msk-authentication.html) Bagian dari *Panduan Developer Amazon Managed Streaming for Apache Kafka*.
Setelah Anda menyelesaikan langkah-langkah tersebut, Anda memiliki sertifikat-ARN (sertifikat publik ARN disimpan di ACM), dan kunci privat yang terdapat dalam file `kafka.client.keystore.jks`.
1. Dapatkan sertifikat publik dan salin sertifikat ke file `signed-certificate-from-acm.pem`, menggunakan perintah berikut:
```
aws acm-pca get-certificate --certificate-authority-arn Private_CA_ARN --certificate-arn Certificate_ARN
```
Perintah itu mengembalikan informasi yang serupa dengan contoh berikut:
```
{"Certificate": "123", "CertificateChain": "456"}
```
Anda kemudian menyalin yang setara dengan `"123"` ke file `signed-certificate-from-acm.pem`.
1. Dapatkan kunci privat dengan mengimpor kunci `msk-rsa` dari `kafka.client.keystore.jks to keystore.p12`, seperti yang ditunjukkan dalam contoh berikut.
```
keytool -importkeystore \
-srckeystore kafka.client.keystore.jks \
-destkeystore keystore.p12 \
-deststoretype PKCS12 \
-srcalias msk-rsa-client \
-deststorepass test1234 \
-destkeypass test1234
```
1. Gunakan perintah berikut untuk mengekspor `keystore.p12` ke format `.pem`.
```
Openssl pkcs12 -in keystore.p12 -out encrypted-private-client-key.pem –nocerts
```
Pesan **Masukkan frase PEM pass** muncul dan mengidentifikasi kunci yang diterapkan untuk mengenkripsi sertifikat.
1. Hapus atribut tas dan atribut kunci dari file `.pem` untuk memastikan bahwa baris pertama dimulai dengan string berikut.
```
---BEGIN ENCRYPTED PRIVATE KEY---
```
**Untuk mengunggah sertifikat publik dan kunci privat ke DMS certificate manager dan menguji sambungan ke Amazon MSK**
1. Unggah ke DMS Certificate Manager menggunakan perintah berikut.
```
aws dms import-certificate --certificate-identifier signed-cert --certificate-pem file://path to signed cert
aws dms import-certificate --certificate-identifier private-key —certificate-pem file://path to private key
```
1. Buat titik akhit target Amazon MSK dan uji koneksi untuk memastikan bahwa autentikasi TLS berfungsi.
```
aws dms create-endpoint --endpoint-identifier $endpoint-identifier --engine-name kafka --endpoint-type target --kafka-settings
'{"Broker": "b-0.kafka260.aaaaa1.a99.kafka.us-east-1.amazonaws.com:0000", "SecurityProtocol":"ssl-authentication",
"SslClientCertificateArn": "arn:aws:dms:us-east-1:012346789012:cert:",
"SslClientKeyArn": "arn:aws:dms:us-east-1:0123456789012:cert:","SslClientKeyPassword":"test1234"}'
aws dms test-connection -replication-instance-arn=$rep_inst_arn —endpoint-arn=$kafka_tar_arn_msk
```
**penting**
Anda dapat menggunakan autentikasi SSL untuk mengamankan koneksi ke klaster Kafka yang dikelola sendiri. Dalam beberapa kasus, Anda mungkin menggunakan Otoritas Sertifikasi (CA) pribadi di kluster Kafka on-premise Anda. Jika demikian, unggah rantai CA Anda, sertifikat publik, dan kunci privat ke DMS certificate manager. Kemudian, gunakan Amazon Resource Name (ARN) yang sesuai dalam pengaturan titik akhir Anda ketika Anda membuat titik akhir target Kafka on-premise.
**Untuk mempersiapkan kunci privat dan sertifikat yang sudah ditandatangani untuk klaster Kafka yang dikelola sendiri**
1. Buat pasangan kunci seperti yang ditunjukkan pada contoh berikut.
```
keytool -genkey -keystore kafka.server.keystore.jks -validity 300 -storepass your-keystore-password
-keypass your-key-passphrase -dname "CN=your-cn-name"
-alias alias-of-key-pair -storetype pkcs12 -keyalg RSA
```
1. Buat sertifikat tanda permintaan (CSR).
```
keytool -keystore kafka.server.keystore.jks -certreq -file server-cert-sign-request-rsa -alias on-premise-rsa -storepass your-key-store-password
-keypass your-key-password
```
1. Gunakan CA di trusstore klaster Anda untuk menandatangani CSR. Jika Anda tidak memiliki CA, Anda dapat membuat CA pribadi Anda sendiri.
```
openssl req -new -x509 -keyout ca-key -out ca-cert -days validate-days
```
1. Impor `ca-cert` ke dalam server truststore dan keystore. Jika Anda tidak memiliki truststore, gunakan perintah berikut untuk membuat truststore dan impor `ca-cert ` ke dalamnya.
```
keytool -keystore kafka.server.truststore.jks -alias CARoot -import -file ca-cert
keytool -keystore kafka.server.keystore.jks -alias CARoot -import -file ca-cert
```
1. Tanda tangani sertifikat.
```
openssl x509 -req -CA ca-cert -CAkey ca-key -in server-cert-sign-request-rsa -out signed-server-certificate.pem
-days validate-days -CAcreateserial -passin pass:ca-password
```
1. Impor sertifikat yang sudah ditandatangani ke keystore.
```
keytool -keystore kafka.server.keystore.jks -import -file signed-certificate.pem -alias on-premise-rsa -storepass your-keystore-password
-keypass your-key-password
```
1. Gunakan perintah berikut untuk mengimpor `on-premise-rsa` kunci dari `kafka.server.keystore.jks` ke `keystore.p12`.
```
keytool -importkeystore \
-srckeystore kafka.server.keystore.jks \
-destkeystore keystore.p12 \
-deststoretype PKCS12 \
-srcalias on-premise-rsa \
-deststorepass your-truststore-password \
-destkeypass your-key-password
```
1. Gunakan perintah berikut untuk mengekspor `keystore.p12` ke format `.pem`.
```
Openssl pkcs12 -in keystore.p12 -out encrypted-private-server-key.pem –nocerts
```
1. Unggah `encrypted-private-server-key.pem`, `signed-certificate.pem`, dan `ca-cert` untuk DMS certificate manager.
1. Buat titik akhir dengan menggunakan yang dikembalikan ARNs.
```
aws dms create-endpoint --endpoint-identifier $endpoint-identifier --engine-name kafka --endpoint-type target --kafka-settings
'{"Broker": "b-0.kafka260.aaaaa1.a99.kafka.us-east-1.amazonaws.com:9092", "SecurityProtocol":"ssl-authentication",
"SslClientCertificateArn": "your-client-cert-arn","SslClientKeyArn": "your-client-key-arn","SslClientKeyPassword":"your-client-key-password",
"SslCaCertificateArn": "your-ca-certificate-arn"}'
aws dms test-connection -replication-instance-arn=$rep_inst_arn —endpoint-arn=$kafka_tar_arn_msk
```
### Menggunakan autentikasi SASL-SSL untuk terhubung ke Amazon MSK
Metode The Simple Authentication and Security Layer (SASL) menggunakan nama pengguna dan kata sandi untuk memvalidasi identitas klien, dan membuat koneksi terenkripsi antara server dan klien.
Untuk menggunakan SASL, pertama-tama buat nama pengguna dan kata sandi yang aman ketika mengatur Amazon MSK klaster Anda. Untuk deskripsi cara mengatur nama pengguna dan kata sandi yang aman untuk klaster MSK Amazon, lihat [Menyiapkan SASL/SCRAM otentikasi untuk klaster MSK Amazon di Panduan Pengembang Amazon](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password.html#msk-password-tutorial) *Managed Streaming for* Apache Kafka.
Kemudian, ketika Anda membuat titik akhir target Kafka, setel pengaturan titik akhir protokol keamanan (`SecurityProtocol`) menggunakan pilihan `sasl-ssl`. Anda juga mengatur pilihan `SaslUsername` dan `SaslPassword`. Pastikan semua ini konsisten dengan nama pengguna dan kata sandi aman yang Anda buat ketika pertama kali menyiapkan klaster Amazon MSK Anda, seperti yang ditunjukkan dalam contoh JSON berikut.
```
"KafkaSettings": {
"SecurityProtocol": "sasl-ssl",
"SaslUsername":"Amazon MSK cluster secure user name",
"SaslPassword":"Amazon MSK cluster secure password"
}
```
**catatan**
Saat ini, hanya AWS DMS mendukung SASL-SSL yang didukung CA publik. DMS tidak mendukung SASL-SSL untuk digunakan dengan Kafka yang dikelola sendiri yang didukung oleh CA pribadi.
Untuk otentikasi SASL-SSL, AWS DMS mendukung mekanisme SCRAM-SHA-512 secara default. AWS DMS versi 3.5.0 dan yang lebih tinggi juga mendukung mekanisme Plain. Untuk mendukung mekanisme Plain, atur `SaslMechanism` parameter tipe data `KafkaSettings` API ke`PLAIN`. Jenis data didukung oleh Kafka, tetapi `PLAIN` tidak didukung oleh Amazon Kafka (MSK).
## Menggunakan citra sebelumnya untuk melihat nilai-nilai asli dari baris CDC untuk Apache Kafka sebagai target
Ketika menulis pembaruan CDC ke target data-streaming seperti Kafka Anda dapat melihat nilai asli baris basis data sumber sebelum diubah oleh pembaruan.. Untuk memungkinkan hal ini, AWS DMS mengisi *gambar sebelum* peristiwa pembaruan berdasarkan data yang disediakan oleh mesin database sumber.
Mesin basis data sumber yang berbeda memberikan jumlah informasi yang berbeda untuk citra sebelum:
+ Oracle menyediakan update untuk kolom hanya jika mereka berubah.
+ PostgreSQL menyediakan data hanya untuk kolom yang merupakan bagian dari kunci primer (berubah atau tidak). Jika replikasi logis sedang digunakan dan REPLICA IDENTITY FULL diatur untuk tabel sumber, Anda bisa mendapatkan seluruh informasi sebelum dan sesudah pada baris yang ditulis ke WALs dan tersedia di sini.
+ MySQL umumnya menyediakan data untuk semua kolom (berubah atau tidak).
Untuk mengaktifkan pencitraan sebelumnya dengan tujuan menambahkan nilai asli dari basis data sumber untuk keluaran AWS DMS , gunakan pengaturan tugas `BeforeImageSettings` atau parameter `add-before-image-columns`. Parameter ini menerapkan aturan transformasi kolom.
`BeforeImageSettings` menambahkan atribut JSON baru untuk setiap operasi pembaruan dengan nilai yang dikumpulkan dari sistem basis data sumber, seperti yang ditunjukkan berikut.
```
"BeforeImageSettings": {
"EnableBeforeImage": boolean,
"FieldName": string,
"ColumnFilter": pk-only (default) / non-lob / all (but only one)
}
```
**catatan**
Terapkan `BeforeImageSettings` pada beban penuh ditambah tugas CDC (yang memigrasikan data yang ada dan mereplikasi perubahan yang sedang berlangsung), atau ke tugas CDC saja (yang hanya mereplikasi perubahan data). Jangan terapkan `BeforeImageSettings` pada tugas-tugas yang beban penuh saja.
Untuk pilihan `BeforeImageSettings`, hal berikut berlaku:
+ Atur pilihan `EnableBeforeImage` ke `true` untuk mengaktifkan pencitraan sebelum. Nilai default-nya `false`.
+ Gunakan pilihan `FieldName` untuk memberikan nama ke atribut JSON baru. Ketika `EnableBeforeImage` adalah `true`, `FieldName` diperlukan dan tidak dapat kosong.
+ Pilihan `ColumnFilter` menentukan kolom untuk menambahkan dengan menggunakan pencitraan sebelumnya. Untuk menambahkan kolom yang hanya merupakan bagian dari kunci primer tabel saja, gunakan nilai default, `pk-only`. Untuk menambahkan hanya kolom yang bukan tipe LOB, gunakan `non-lob`. Untuk menambahkan kolom apa pun yang memiliki nilai citra sebelum, gunakan `all`.
```
"BeforeImageSettings": {
"EnableBeforeImage": true,
"FieldName": "before-image",
"ColumnFilter": "pk-only"
}
```
### Menggunakan aturan transformasi citra sebelumnya
Sebagai alternatif untuk pengaturan tugas, Anda dapat menggunakan parameter `add-before-image-columns`, yang menerapkan aturan transformasi kolom. Dengan parameter ini, Anda dapat mengaktifkan pencitraan sebelumnya selama CDC, pada target data streaming seperti Kinesis.
Dengan menggunakan `add-before-image-columns` dalam aturan transformasi, Anda dapat menerapkan kontrol yang lebih halus dari hasil citra sebelumnya. Aturan transformasi memungkinkan Anda untuk menggunakan pencari objek yang memberikan Anda kontrol atas tabel yang dipilih untuk aturan tersebut. Dan juga, Anda dapat merangkai aturan transformasi, yang memungkinkan aturan yang berbeda untuk diterapkan ke tabel yang berbeda. Anda kemudian dapat memanipulasi kolom yang dihasilkan dengan menggunakan aturan lain.
**catatan**
Jangan gunakan parameter `add-before-image-columns` bersamaan dengan pengaturan tugas `BeforeImageSettings` dalam tugas yang sama. Sebaliknya, gunakan salah satu saja, parameter atau pengaturan, tetapi tidak keduanya, untuk satu tugas.
Sebuah tipe peraturan `transformation` dengan parameter `add-before-image-columns` untuk kolom harus menyediakan `before-image-def` bagian. Berikut ini adalah sebuah contoh.
```
{
"rule-type": "transformation",
…
"rule-target": "column",
"rule-action": "add-before-image-columns",
"before-image-def":{
"column-filter": one-of (pk-only / non-lob / all),
"column-prefix": string,
"column-suffix": string,
}
}
```
Nilai dari `column-prefix` ditambahkan sebelum nama kolom, dan nilai default `column-prefix` adalah `BI_`. Nilai dari `column-suffix` ditambahkan sebelum nama kolom, dan default kosong. Jangan atur `column-prefix` dan `column-suffix` ke string kosong.
Pilih satu nilai untuk `column-filter`. Untuk menambahkan kolom yang merupakan bagian dari kunci primer tabel saja, pilih `pk-only`. Untuk menambahkan kolom yang bukan tipe LOB saja, gunakan `non-lob`. Atau pilih `all` untuk menambahkan kolom yang memiliki nilai citra-sebelum.
### Contoh untuk aturan transformasi citra sebelumnya
Aturan transformasi dalam contoh berikut menambahkan kolom baru yang disebut `BI_emp_no` pada target. Jadi pernyataan seperti `UPDATE employees SET emp_no = 3 WHERE emp_no = 1;` mengisi `BI_emp_no` field dengan 1. Ketika Anda menulis pembaruan CDC untuk target Amazon S3, kolom `BI_emp_no` memungkinkan untuk memberitahu baris asli yang diperbarui.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-target": "column",
"object-locator": {
"schema-name": "%",
"table-name": "employees"
},
"rule-action": "add-before-image-columns",
"before-image-def": {
"column-prefix": "BI_",
"column-suffix": "",
"column-filter": "pk-only"
}
}
]
}
```
Untuk informasi tentang penggunaan peraturan tindakan `add-before-image-columns`, lihat [Aturan dan tindakan transformasi](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
## Keterbatasan saat menggunakan Apache Kafka sebagai target AWS Database Migration Service
Batasan berikut berlaku saat menggunakan Apache Kafka sebagai target:
+ AWS DMS Titik akhir target Kafka tidak mendukung kontrol akses IAM untuk Amazon Managed Streaming for Apache Kafka (Amazon MSK).
+ Mode LOB penuh tidak didukung.
+ Tentukan file konfigurasi Kafka untuk klaster Anda dengan properti yang memungkinkan AWS DMS untuk membuat topik baru secara otomatis. Sertakan pengaturan, `auto.create.topics.enable = true`. Jika menggunakan Amazon MSK, Anda dapat menentukan konfigurasi default ketika membuat klaster Kafka Anda, kemudian mengubah pengaturan `auto.create.topics.enable` ke `true`. Untuk informasi lebih lanjut tentang pengaturan konfigurasi default, lihat [Konfigurasi Amazon MSK default](https://docs.aws.amazon.com/msk/latest/developerguide/msk-default-configuration.html) di *Panduan Developer Amazon Managed Streaming for Apache Kafka*. Jika Anda perlu memodifikasi cluster Kafka yang ada yang dibuat menggunakan Amazon MSK, jalankan AWS CLI perintah `aws kafka create-configuration` untuk memperbarui konfigurasi Kafka Anda, seperti pada contoh berikut:
```
14:38:41 $ aws kafka create-configuration --name "kafka-configuration" --kafka-versions "2.2.1" --server-properties file://~/kafka_configuration
{
"LatestRevision": {
"Revision": 1,
"CreationTime": "2019-09-06T14:39:37.708Z"
},
"CreationTime": "2019-09-06T14:39:37.708Z",
"Name": "kafka-configuration",
"Arn": "arn:aws:kafka:us-east-1:111122223333:configuration/kafka-configuration/7e008070-6a08-445f-9fe5-36ccf630ecfd-3"
}
```
Di sini, `//~/kafka_configuration` adalah file konfigurasi yang telah Anda buat dengan pengaturan properti yang diperlukan.
Jika Anda menggunakan instans Kafka Anda sendiri yang diinstal di Amazon EC2, ubah konfigurasi cluster Kafka dengan `auto.create.topics.enable = true` pengaturan untuk AWS DMS memungkinkan Anda membuat topik baru secara otomatis, menggunakan opsi yang disediakan bersama instans Anda.
+ AWS DMS menerbitkan setiap pembaruan ke satu catatan dalam database sumber sebagai satu catatan data (pesan) dalam topik Kafka tertentu terlepas dari transaksi.
+ AWS DMS mendukung empat bentuk berikut untuk kunci partisi:
+ `SchemaName.TableName`: Kombinasi skema dan nama tabel.
+ `${AttributeName}`: Nilai salah satu field di JSON, atau kunci primer dari tabel dalam basis data sumber.
+ `transaction-id`: ID transaksi CDC. Semua catatan dalam transaksi yang sama masuk ke partisi yang sama.
+ `constant`: Nilai literal tetap untuk setiap catatan terlepas dari tabel atau data. Semua catatan dikirim ke nilai kunci partisi yang sama “konstan”, memberikan urutan global yang ketat di semua tabel.
```
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "TransactionIdPartitionKey",
"rule-action": "map-record-to-document",
"object-locator": {
"schema-name": "onprem",
"table-name": "it_system"
},
"mapping-parameters": {
"partition-key-type": "transaction-id | constant | attribute-name | schema-table"
}
}
```
+ Pengaturan `IncludeTransactionDetails` endpoint hanya didukung ketika titik akhir sumber adalah Oracle, SQL Server, PostgreSQL, atau MySQL. Untuk jenis titik akhir sumber lainnya, detail transaksi tidak akan disertakan.
+ `BatchApply` Tidak didukung untuk titik akhir Kafka. Menggunakan penerapan Batch (misalnya, pengaturan tugas metadata target `BatchApplyEnabled`) untuk target Kafka dapat mengakibatkan hilangnya data.
+ AWS DMS tidak mendukung migrasi nilai tipe `BigInt` data dengan lebih dari 16 digit. Untuk mengatasi batasan ini, Anda dapat menggunakan aturan transformasi berikut untuk mengonversi `BigInt` kolom menjadi string. Untuk informasi selengkapnya tentang aturan transformasi, lihat[Aturan dan tindakan transformasi](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
```
{
"rule-type": "transformation",
"rule-id": "id",
"rule-name": "name",
"rule-target": "column",
"object-locator": {
"schema-name": "valid object-mapping rule action",
"table-name": "",
"column-name": ""
},
"rule-action": "change-data-type",
"data-type": {
"type": "string",
"length": 20
}
}
```
+ AWS DMS Titik akhir target Kafka tidak mendukung Amazon MSK tanpa servless.
+ Saat mendefinisikan aturan pemetaan, memiliki keduanya, aturan pemetaan objek dan aturan transformasi tidak didukung. Anda harus menetapkan hanya satu aturan.
+ AWS DMS mendukung Otentikasi SASL untuk versi Apache Kafka hingga 3.8. Jika Anda menggunakan Kafka 4.0 atau lebih tinggi, Anda hanya dapat terhubung tanpa otentikasi SASL.
+ AWS DMS tidak mendukung data sumber yang berisi `'\0'` karakter yang disematkan saat menggunakan Kafka sebagai titik akhir target. Data yang berisi `'\0'` karakter tertanam akan terpotong pada karakter pertama`'\0'`.
## Menggunakan pemetaan objek untuk bermigrasi data ke topik Kafka
AWS DMS menggunakan aturan pemetaan tabel untuk memetakan data dari sumber ke topik Kafka target. Untuk memetakan data ke topik target, Anda menggunakan jenis aturan pemetaan tabel yang disebut pemetaan objek. Anda menggunakan pemetaan objek untuk menentukan cara pencatatan data di peta sumber ke catatan data yang dipublikasikan ke topik Kafka.
topik Kafka tidak memiliki struktur preset selain memiliki kunci partisi.
**catatan**
Anda tidak perlu menggunakan pemetaan objek. Anda dapat menggunakan pemetaan tabel biasa untuk berbagai transformasi. Namun, jenis kunci partisi akan mengikuti perilaku default ini:
Primary Key digunakan sebagai kunci partisi untuk Full Load.
Jika tidak ada pengaturan tugas penerapan paralel yang digunakan, `schema.table` digunakan sebagai kunci partisi untuk CDC.
Jika pengaturan tugas penerapan paralel digunakan, kunci utama digunakan sebagai kunci partisi untuk CDC.
Untuk membuat aturan pemetaan objek, tetapkan `rule-type` sebagai `object-mapping`. Aturan ini menentukan jenis pemetaan objek yang ingin Anda gunakan.
Struktur untuk aturan tersebut adalah sebagai berikut.
```
{
"rules": [
{
"rule-type": "object-mapping",
"rule-id": "id",
"rule-name": "name",
"rule-action": "valid object-mapping rule action",
"object-locator": {
"schema-name": "case-sensitive schema name",
"table-name": ""
}
}
]
}
```
AWS DMS saat ini mendukung `map-record-to-record` dan `map-record-to-document` sebagai satu-satunya nilai yang valid untuk `rule-action` parameter. Pengaturan ini memengaruhi nilai yang tidak dikecualikan sebagai bagian dari daftar `exclude-columns` atribut. `map-record-to-document`Nilai `map-record-to-record` dan menentukan bagaimana AWS DMS menangani catatan ini secara default. Nilai-nilai ini tidak mempengaruhi pemetaan atribut dengan cara apapun.
Gunakan `map-record-to-record` ketika bermigrasi dari basis data relasional ke sebuah topik Kafka. Jenis aturan ini menggunakan nilai `taskResourceId.schemaName.tableName` dari basis data relasional sebagai kunci partisi dalam topik Kafka dan membuat atribut untuk masing-masing kolom dalam basis data sumber.
Saat menggunakan`map-record-to-record`, perhatikan hal berikut:
+ Pengaturan ini hanya memengaruhi kolom yang dikecualikan oleh `exclude-columns` daftar.
+ Untuk setiap kolom tersebut, AWS DMS buat atribut yang sesuai dalam topik target.
+ AWS DMS menciptakan atribut yang sesuai ini terlepas dari apakah kolom sumber digunakan dalam pemetaan atribut.
Salah satu cara untuk memahami `map-record-to-record` adalah melihatnya beraksi. Untuk contoh ini, anggaplah bahwa Anda memulai dengan baris tabel basis data relasional dengan struktur dan data berikut.
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateofBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
Untuk memigrasi informasi ini dari skema bernama `Test` ke topik Kafka, buatlah aturan untuk memetakan data ke topik target. Aturan berikut menggambarkan pemetaan.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"rule-action": "include",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
}
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "DefaultMapToKafka",
"rule-action": "map-record-to-record",
"object-locator": {
"schema-name": "Test",
"table-name": "Customers"
}
}
]
}
```
Mengingat topik Kafka dan kunci partisi (dalam hal ini, `taskResourceId.schemaName.tableName`), berikut ini menggambarkan format catatan yang dihasilkan menggunakan data sampel kami di topik target Kafka:
```
{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"HomeAddress": "221B Baker Street",
"HomePhone": "1234567890",
"WorkAddress": "31 Spooner Street, Quahog",
"WorkPhone": "9876543210",
"DateOfBirth": "02/29/1988"
}
```
**Topics**
+ [Restrukturisasi data dengan pemetaan atribut](#CHAP_Target.Kafka.AttributeMapping)
+ [Replikasi multitopik menggunakan pemetaan objek](#CHAP_Target.Kafka.MultiTopic)
+ [Format pesan untuk Apache Kafka](#CHAP_Target.Kafka.Messageformat)
### Restrukturisasi data dengan pemetaan atribut
Anda dapat merestrukturisasi data saat migrasi ke topik kafka berlangsung menggunakan peta atribut. Misalnya, Anda mungkin ingin menggabungkan beberapa field di sumber menjadi field tunggal dalam target. Peta atribut berikut menggambarkan bagaimana merestrukturisasi data.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"rule-action": "include",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
}
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "TransformToKafka",
"rule-action": "map-record-to-record",
"target-table-name": "CustomerData",
"object-locator": {
"schema-name": "Test",
"table-name": "Customers"
},
"mapping-parameters": {
"partition-key-type": "attribute-name",
"partition-key-name": "CustomerName",
"exclude-columns": [
"firstname",
"lastname",
"homeaddress",
"homephone",
"workaddress",
"workphone"
],
"attribute-mappings": [
{
"target-attribute-name": "CustomerName",
"attribute-type": "scalar",
"attribute-sub-type": "string",
"value": "${lastname}, ${firstname}"
},
{
"target-attribute-name": "ContactDetails",
"attribute-type": "document",
"attribute-sub-type": "json",
"value": {
"Home": {
"Address": "${homeaddress}",
"Phone": "${homephone}"
},
"Work": {
"Address": "${workaddress}",
"Phone": "${workphone}"
}
}
}
]
}
}
]
}
```
Untuk menetapkan nilai konstan untuk`partition-key`, tentukan`"partition-key-type: "constant"`, ini menetapkan nilai partisi ke`constant`. Sebagai contoh, Anda mungkin melakukan ini untuk memaksa semua data untuk disimpan dalam partisi tunggal. Pemetaan berikut menggambarkan pendekatan ini.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "object-mapping",
"rule-id": "1",
"rule-name": "TransformToKafka",
"rule-action": "map-record-to-document",
"object-locator": {
"schema-name": "Test",
"table-name": "Customer"
},
"mapping-parameters": {
"partition-key-type": "constant",
"exclude-columns": [
"FirstName",
"LastName",
"HomeAddress",
"HomePhone",
"WorkAddress",
"WorkPhone"
],
"attribute-mappings": [
{
"attribute-name": "CustomerName",
"value": "${FirstName},${LastName}"
},
{
"attribute-name": "ContactDetails",
"value": {
"Home": {
"Address": "${HomeAddress}",
"Phone": "${HomePhone}"
},
"Work": {
"Address": "${WorkAddress}",
"Phone": "${WorkPhone}"
}
}
},
{
"attribute-name": "DateOfBirth",
"value": "${DateOfBirth}"
}
]
}
}
]
}
```
**catatan**
Nilai `partition-key` untuk catatan kontrol yang ditujukan khusus untuk tabel tertentu adalah `TaskId.SchemaName.TableName`. Nilai `partition-key` untuk catatan kontrol yang ditujukan untuk tugas tertentu adalah `TaskId` dari catatan tersebut. Menentukan nilai `partition-key` dalam pemetaan objek tidak berdampak pada `partition-key` untuk catatan kontrol.
Kapan `partition-key-type` diatur ke `attribute-name` dalam aturan pemetaan tabel, Anda harus menentukan`partition-key-name`, yang harus mereferensikan kolom dari tabel sumber atau kolom kustom yang ditentukan dalam pemetaan. Selain itu, `attribute-mappings` harus disediakan untuk menentukan bagaimana kolom sumber memetakan ke topik target Kafka.
### Replikasi multitopik menggunakan pemetaan objek
Secara default, AWS DMS tugas memigrasikan semua data sumber ke salah satu topik Kafka berikut:
+ Seperti yang ditentukan dalam bidang **Topik** dari titik akhir AWS DMS target.
+ Seperti yang ditentukan oleh `kafka-default-topic` jika bidang **Topik** dari titik akhir target tidak diisi dan `auto.create.topics.enable` pengaturan Kafka diatur ke. `true`
Dengan versi AWS DMS engine 3.4.6 dan yang lebih tinggi, Anda dapat menggunakan `kafka-target-topic` atribut untuk memetakan setiap tabel sumber yang dimigrasi ke topik terpisah. Misalnya, aturan pemetaan objek berikut memigrasikan tabel sumber `Customer` dan `Address` ke topik Kafka `customer_topic` dan`address_topic`, masing-masing. Pada saat yang sama, AWS DMS memigrasikan semua tabel sumber lainnya, termasuk `Bills` tabel dalam `Test` skema, ke topik yang ditentukan di titik akhir target.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"rule-action": "include",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
}
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "MapToKafka1",
"rule-action": "map-record-to-record",
"kafka-target-topic": "customer_topic",
"object-locator": {
"schema-name": "Test",
"table-name": "Customer"
},
"partition-key-type": "constant"
},
{
"rule-type": "object-mapping",
"rule-id": "3",
"rule-name": "MapToKafka2",
"rule-action": "map-record-to-record",
"kafka-target-topic": "address_topic",
"object-locator": {
"schema-name": "Test",
"table-name": "Address"
},
"partition-key-type": "constant"
},
{
"rule-type": "object-mapping",
"rule-id": "4",
"rule-name": "DefaultMapToKafka",
"rule-action": "map-record-to-record",
"object-locator": {
"schema-name": "Test",
"table-name": "Bills"
}
}
]
}
```
Dengan menggunakan replikasi multitopik Kafka, Anda dapat mengelompokkan dan memigrasikan tabel sumber untuk memisahkan topik Kafka menggunakan satu tugas replikasi.
### Format pesan untuk Apache Kafka
Keluaran JSON hanya berupa daftar pasangan nilai-kunci.
**RecordType**
Jenis catatan dapat berupa data atau kontrol. *Catatan data* mewakili baris yang sebenarnya dalam sumber. *Kontrol catatan* adalah untuk peristiwa-peristiwa penting di aliran, misalnya restart tugas.
**Operasi**
Untuk catatan data, operasinya dapat `load`, `insert`, `update`, atau `delete`.
Untuk catatan kontrol, operasi dapat berupa`create-table`,`rename-table`,`drop-table`,`change-columns`,`add-column`,`drop-column`,`rename-column`, atau`column-type-change`.
**SchemaName**
Skema sumber untuk catatan. Field ini bisa kosong untuk catatan kontrol.
**TableName**
Tabel sumber untuk catatan. Field ini bisa kosong untuk catatan kontrol.
**Stempel waktu**
Stempel waktu untuk saat pesan JSON dibuat. Field ini diformat dengan format ISO 8601.
Contoh pesan JSON berikut menggambarkan pesan tipe data dengan semua metadata tambahan.
```
{
"data":{
"id":100000161,
"fname":"val61s",
"lname":"val61s",
"REGION":"val61s"
},
"metadata":{
"timestamp":"2019-10-31T22:53:59.721201Z",
"record-type":"data",
"operation":"insert",
"partition-key-type":"primary-key",
"partition-key-value":"sbtest.sbtest_x.100000161",
"schema-name":"sbtest",
"table-name":"sbtest_x",
"transaction-id":9324410911751,
"transaction-record-id":1,
"prev-transaction-id":9324410910341,
"prev-transaction-record-id":10,
"commit-timestamp":"2019-10-31T22:53:55.000000Z",
"stream-position":"mysql-bin-changelog.002171:36912271:0:36912333:9324410911751:mysql-bin-changelog.002171:36912209"
}
}
```
Contoh pesan JSON berikut menggambarkan pesan tipe kontrol.
```
{
"control":{
"table-def":{
"columns":{
"id":{
"type":"WSTRING",
"length":512,
"nullable":false
},
"fname":{
"type":"WSTRING",
"length":255,
"nullable":true
},
"lname":{
"type":"WSTRING",
"length":255,
"nullable":true
},
"REGION":{
"type":"WSTRING",
"length":1000,
"nullable":true
}
},
"primary-key":[
"id"
],
"collation-name":"latin1_swedish_ci"
}
},
"metadata":{
"timestamp":"2019-11-21T19:14:22.223792Z",
"record-type":"control",
"operation":"create-table",
"partition-key-type":"task-id",
"schema-name":"sbtest",
"table-name":"sbtest_t1"
}
}
```
# Menggunakan kluster OpenSearch Layanan Amazon sebagai target AWS Database Migration Service
Anda dapat menggunakan AWS DMS untuk memigrasikan data ke Amazon OpenSearch Service (OpenSearch Layanan). OpenSearch Layanan adalah layanan terkelola yang memudahkan penerapan, pengoperasian, dan skala kluster OpenSearch Layanan.
Di OpenSearch Layanan, Anda bekerja dengan indeks dan dokumen. *Indeks* adalah kumpulan dokumen, dan *dokumen* adalah objek JSON yang berisi nilai skalar, array, dan objek lainnya. OpenSearch menyediakan bahasa query berbasis JSON, sehingga Anda dapat query data dalam indeks dan mengambil dokumen yang sesuai.
Saat AWS DMS membuat indeks untuk titik akhir target untuk OpenSearch Service, itu membuat satu indeks untuk setiap tabel dari titik akhir sumber. Biaya untuk membuat indeks OpenSearch Layanan tergantung pada beberapa faktor. Ini adalah jumlah indeks yang dibuat, jumlah total data dalam indeks ini, dan sejumlah kecil metadata yang OpenSearch disimpan untuk setiap dokumen.
Konfigurasikan kluster OpenSearch Layanan Anda dengan sumber daya komputasi dan penyimpanan yang sesuai untuk cakupan migrasi Anda. Kami menyarankan agar Anda mempertimbangkan faktor-faktor berikut, tergantung pada tugas replikasi yang ingin Anda gunakan:
+ Untuk beban data penuh, pertimbangkan jumlah total data yang ingin Anda migrasikan, dan juga kecepatan transfer.
+ Untuk mereplikasi perubahan yang sedang berlangsung, pertimbangkan frekuensi pembaruan, dan persyaratan end-to-end latensi Anda.
Juga, konfigurasikan pengaturan indeks pada OpenSearch cluster Anda, perhatikan jumlah dokumen.
**Pengaturan tugas beban penuh multithread**
Untuk membantu meningkatkan kecepatan transfer, AWS DMS mendukung beban penuh multithreaded ke kluster target OpenSearch Service. AWS DMS mendukung multithreading ini dengan pengaturan tugas yang mencakup yang berikut:
+ `MaxFullLoadSubTasks` - Gunakan pilihan ini untuk menunjukkan jumlah maksimum tabel sumber yang dimuat secara paralel. DMS memuat setiap tabel ke indeks target OpenSearch Layanan yang sesuai menggunakan subtugas khusus. Default adalah 8; nilai maksimum adalah 49.
+ `ParallelLoadThreads`— Gunakan opsi ini untuk menentukan jumlah utas yang AWS DMS digunakan untuk memuat setiap tabel ke indeks target OpenSearch Layanannya. Nilai maksimum untuk target OpenSearch Layanan adalah 32. Anda dapat meminta untuk meningkatkan batas maksimum ini.
**catatan**
Jika Anda tidak mengubah `ParallelLoadThreads` dari default (0), AWS DMS mentransfer satu catatan pada satu waktu. Pendekatan ini menempatkan beban yang tidak semestinya pada kluster OpenSearch Service Anda. Pastikan bahwa Anda menetapkan pilihan ini ke 1 atau lebih.
+ `ParallelLoadBufferSize`— Gunakan opsi ini untuk menentukan jumlah maksimum catatan yang akan disimpan dalam buffer yang digunakan thread beban paralel untuk memuat data ke target OpenSearch Layanan. Nilai default adalah 50. Nilai maksimumnya adalah 1.000. Gunakan pengaturan ini dengan `ParallelLoadThreads`. `ParallelLoadBufferSize` hanya berlaku bila ada lebih dari satu thread.
Untuk informasi selengkapnya tentang cara DMS memuat kluster OpenSearch Layanan menggunakan multithreading, lihat AWS posting blog Menskalakan [ OpenSearch Layanan Amazon](https://aws.amazon.com/blogs/database/scale-amazon-elasticsearch-service-for-aws-database-migration-service-migrations/) untuk migrasi. AWS Database Migration Service
**Pengaturan beban tugas CDC multithread**
Anda dapat meningkatkan performa change data capture (CDC) untuk kluster target OpenSearch Service menggunakan pengaturan tugas untuk mengubah perilaku panggilan `PutRecords` API. Untuk melakukan ini, Anda dapat menentukan jumlah thread yang terjadi bersamaan, antrean per thread, dan jumlah catatan yang disimpan dalam buffer menggunakan pengaturan tugas `ParallelApply*`. Misalnya, Anda ingin melakukan beban CDC dan menerapkan 32 thread secara paralel. Anda juga ingin mengakses 64 antrean per thread, dengan 50 catatan disimpan per buffer.
**catatan**
Support untuk penggunaan pengaturan `ParallelApply*` tugas selama titik akhir target CDC ke Amazon OpenSearch Service tersedia di AWS DMS versi 3.4.0 dan yang lebih tinggi.
Untuk mempromosikan kinerja CDC, AWS DMS mendukung pengaturan tugas ini:
+ `ParallelApplyThreads`— Menentukan jumlah thread bersamaan yang AWS DMS digunakan selama beban CDC untuk mendorong catatan data ke titik akhir target OpenSearch Service. Nilai default adalah nol (0) dan nilai maksimum adalah 32.
+ `ParallelApplyBufferSize`— Menentukan jumlah maksimum catatan yang akan disimpan di setiap antrian buffer untuk thread bersamaan untuk mendorong ke titik akhir target OpenSearch Service selama pemuatan CDC. Nilai default adalah 100 dan nilai maksimum adalah 1.000. Gunakan pilihan ini saat `ParallelApplyThreads` menentukan lebih dari satu thread.
+ `ParallelApplyQueuesPerThread`— Menentukan jumlah antrian yang diakses setiap thread untuk mengeluarkan catatan data dari antrian dan menghasilkan beban batch untuk titik akhir Service selama CDC. OpenSearch
Saat menggunakan pengaturan tugas `ParallelApply*`, default `partition-key-type`-nya adalah `primary-key` dari tabel, bukan `schema-name.table-name`.
## Migrasi dari tabel database relasional ke indeks Layanan OpenSearch
AWS DMS mendukung migrasi data ke tipe data skalar OpenSearch Layanan. Saat bermigrasi dari database relasional seperti Oracle atau MySQL ke OpenSearch Service, Anda mungkin ingin merestrukturisasi cara menyimpan data ini.
AWS DMS mendukung tipe data skalar OpenSearch Layanan berikut:
+ Boolean
+ Date
+ Float
+ Int
+ String
AWS DMS mengubah data tipe Tanggal menjadi tipe String. Anda dapat menentukan pemetaan kustom untuk menafsirkan tanggal ini.
AWS DMS tidak mendukung migrasi tipe data LOB.
## Prasyarat untuk menggunakan OpenSearch Layanan Amazon sebagai target untuk AWS Database Migration Service
Sebelum Anda mulai bekerja dengan database OpenSearch Layanan sebagai target AWS DMS, pastikan Anda membuat peran AWS Identity and Access Management (IAM). Peran ini harus memungkinkan AWS DMS akses indeks OpenSearch Layanan di titik akhir target. Kumpulan izin akses minimum ditampilkan dalam kebijakan IAM berikut.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"Service": "dms.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Peran yang Anda gunakan untuk migrasi ke OpenSearch Layanan harus memiliki izin berikut.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"es:ESHttpDelete",
"es:ESHttpGet",
"es:ESHttpHead",
"es:ESHttpPost",
"es:ESHttpPut"
],
"Resource": "*"
}
]
}
```
------
Pada contoh sebelumnya, ganti `region` dengan pengenal AWS Wilayah, *`account-id`* dengan ID AWS akun Anda, dan `domain-name` dengan nama domain Layanan Amazon OpenSearch Anda. Contohnya `arn:aws:es:us-west-2:123456789012:domain/my-es-domain`
## Pengaturan titik akhir saat menggunakan OpenSearch Layanan sebagai target untuk AWS DMS
Anda dapat menggunakan pengaturan titik akhir untuk mengonfigurasi basis data target OpenSearch Layanan mirip dengan menggunakan atribut koneksi tambahan. Anda menentukan pengaturan saat Anda membuat titik akhir target menggunakan AWS DMS konsol, atau dengan menggunakan `create-endpoint` perintah di [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), dengan sintaks `--elasticsearch-settings '{"EndpointSetting": "value", ...}'` JSON.
Tabel berikut menunjukkan pengaturan endpoint yang dapat Anda gunakan dengan OpenSearch Service sebagai target.
| Nama atribut | Nilai valid | Nilai dan deskripsi default |
| --- | --- | --- |
| `FullLoadErrorPercentage` | Sebuah integer positif lebih besar dari 0 tetapi tidak lebih besar dari 100. | 10 - Untuk tugas beban penuh, atribut ini menentukan ambang batas kesalahan yang diizinkan sebelum tugas gagal. Sebagai contoh, ada 1.500 baris di titik akhir sumber dan parameter ini diatur ke 10. Kemudian tugas gagal jika AWS DMS menemukan lebih dari 150 kesalahan (10 persen dari jumlah baris) saat menulis ke titik akhir target. |
| `ErrorRetryDuration` | Sebuah integer positif lebih besar dari 0. | 300 - Jika terjadi kesalahan pada titik akhir target, AWS DMS coba lagi selama beberapa detik ini. Jika tidak, tugas gagal. |
| `UseNewMappingType` | true atau false | `false`, tetapi untuk bekerja menggunakan opensearch v2.x itu harus disetel ke. `true` |
## Keterbatasan saat menggunakan OpenSearch Layanan Amazon sebagai target AWS Database Migration Service
Batasan berikut berlaku saat menggunakan OpenSearch Layanan Amazon sebagai target:
+ OpenSearch Layanan menggunakan pemetaan dinamis (tebakan otomatis) untuk menentukan tipe data yang akan digunakan untuk data yang dimigrasi.
+ OpenSearch Layanan menyimpan setiap dokumen dengan ID unik. Berikut adalah contoh ID.
```
"_id": "D359F8B537F1888BC71FE20B3D79EAE6674BE7ACA9B645B0279C7015F6FF19FD"
```
Setiap ID dokumen adalah panjangnya 64 byte, jadi antisipasi ini sebagai syarat penyimpanan. Misalnya, jika Anda memigrasikan 100.000 baris dari AWS DMS sumber, indeks OpenSearch Layanan yang dihasilkan memerlukan penyimpanan untuk 6.400.000 byte tambahan.
+ Dengan OpenSearch Layanan, Anda tidak dapat melakukan pembaruan pada atribut kunci utama. Pembatasan ini penting ketika menggunakan replikasi berkelanjutan dengan perubahan pengambilan data (CDC) karena dapat mengakibatkan data yang tidak diinginkan dalam target. Dalam mode CDC, kunci primer dipetakan ke SHA256 nilai, yang panjangnya 32 byte. Ini dikonversi ke string 64-byte yang dapat dibaca manusia, dan digunakan sebagai dokumen Layanan. OpenSearch IDs
+ Jika AWS DMS menemukan item apa pun yang tidak dapat dimigrasikan, ia akan menulis pesan kesalahan ke Amazon CloudWatch Logs. Perilaku ini berbeda dari titik akhir AWS DMS target lainnya, yang menulis kesalahan ke tabel pengecualian.
+ AWS DMS tidak mendukung koneksi ke klaster Amazon ES yang mengaktifkan Kontrol Akses berbutir halus dengan pengguna utama dan kata sandi.
+ AWS DMS tidak mendukung OpenSearch Layanan tanpa server.
+ OpenSearch Layanan tidak mendukung penulisan data ke indeks yang sudah ada sebelumnya.
+ Pengaturan tugas replikasi, tidak `TargetTablePrepMode:TRUNCATE_BEFORE_LOAD` didukung untuk digunakan dengan titik akhir OpenSearch target.
+ Saat memigrasikan data ke Amazon Elasticsearch menggunakan AWS DMS, data sumber harus memiliki kunci utama atau kolom pengenal unik. Jika data sumber tidak memiliki kunci primer atau pengidentifikasi unik, Anda perlu mendefinisikannya menggunakan aturan define-primary-key transformasi.
## Jenis data target untuk Amazon OpenSearch Service
Saat AWS DMS memigrasikan data dari database heterogen, layanan memetakan tipe data dari database sumber ke tipe data perantara yang disebut AWS DMS tipe data. Layanan kemudian memetakan tipe data perantara ke tipe data target. Tabel berikut menunjukkan setiap tipe AWS DMS data dan tipe data yang dipetakan dalam OpenSearch Layanan.
| AWS DMS tipe data | OpenSearch Jenis data layanan |
| --- | --- |
| Boolean | boolean |
| Date | string |
| Time | date |
| Timestamp | date |
| INT4 | integer |
| Real4 | float |
| UINT4 | integer |
Untuk informasi tambahan tentang tipe AWS DMS data, lihat[Tipe data untuk AWS Database Migration Service](CHAP_Reference.DataTypes.md).
# Menggunakan Amazon DocumentDB sebagai target AWS untuk Database Migration Service
Untuk informasi tentang versi Amazon DocumentDB (dengan kompatibilitas MongoDB) yang mendukung, lihat. AWS DMS [Target untuk AWS DMS](CHAP_Introduction.Targets.md) Anda dapat menggunakan AWS DMS untuk memigrasikan data ke Amazon DocumentDB (dengan kompatibilitas MongoDB) dari salah satu mesin data sumber yang didukung AWS DMS . Mesin sumber dapat berada di layanan AWS terkelola seperti Amazon RDS, Aurora, atau Amazon S3. Atau mesin dapat berada di basis data terkelola mandiri, seperti MongoDB yang berjalan di Amazon EC2 atau on-premise.
Anda dapat menggunakan AWS DMS untuk mereplikasi data sumber ke database, koleksi, atau dokumen Amazon DocumentDB.
**catatan**
Jika titik akhir sumber adalah MongoDB atau Amazon DocumentDB, jalankan migrasi dalam **Mode dokumen**.
MongoDB menyimpan data dalam format JSON biner (BSON). AWS DMS mendukung semua tipe data BSON yang didukung oleh Amazon DocumentDB. Untuk daftar tipe data ini, lihat [ APIsMongoDB, operasi, dan tipe data yang didukung di Panduan Pengembang](https://docs.aws.amazon.com/documentdb/latest/developerguide/mongo-apis.html) *Amazon DocumentDB*.
Jika titik akhir sumber adalah database relasional, AWS DMS memetakan objek database ke Amazon DocumentDB sebagai berikut:
+ Sebuah basis data relasional, atau skema basis data, dipetakan ke Amazon DocumentDB *basis data*.
+ Tabel di dalam peta basis data relasional dipetakan ke *Koleksi* di Amazon DocumentDB.
+ Catatan dalam peta tabel relasional dipetakan ke *Dokumen* di Amazon DocumentDB. Setiap dokumen disusun dari data dalam catatan sumber.
Jika titik akhir sumber adalah Amazon S3, maka objek Amazon DocumentDB yang dihasilkan sesuai dengan AWS DMS aturan pemetaan untuk Amazon S3. Contohnya, perhatikan URI berikut ini.
```
s3://amzn-s3-demo-bucket/hr/employee
```
Dalam hal ini, AWS DMS memetakan objek `amzn-s3-demo-bucket` ke Amazon DocumentDB sebagai berikut:
+ Bagian URI tingkat atas (`hr`) dipetakan ke basis data Amazon DocumentDB.
+ Bagian URI berikutnya (`employee`) dipetakan ke koleksi Amazon DocumentDB.
+ Setiap objek dalam `employee` dipetakan ke dokumen di Amazon DocumentDB.
Untuk informasi lebih lanjut tentang aturan pemetaan untuk Amazon S3, lihat [Menggunakan Amazon S3 sebagai sumber AWS DMS](CHAP_Source.S3.md).
**Pengaturan titik akhir Amazon DocumentDB**
Di AWS DMS versi 3.5.0 dan yang lebih tinggi, Anda dapat meningkatkan kinerja change data capture (CDC) untuk endpoint Amazon DocumentDB dengan menyetel pengaturan tugas untuk thread paralel dan operasi massal. Untuk melakukan ini, Anda dapat menentukan jumlah thread yang terjadi bersamaan, antrean per thread, dan jumlah catatan yang disimpan dalam buffer menggunakan pengaturan tugas `ParallelApply*`. Misalnya, Anda ingin melakukan beban CDC dan menerapkan 128 thread secara paralel. Anda juga ingin mengakses 64 antrean per thread, dengan 50 catatan disimpan per buffer.
Untuk mempromosikan kinerja CDC, AWS DMS mendukung pengaturan tugas ini:
+ `ParallelApplyThreads`— Menentukan jumlah thread bersamaan yang AWS DMS digunakan selama pemuatan CDC untuk mendorong catatan data ke titik akhir target Amazon DocumentDB. Nilai default adalah nol (0) dan nilai maksimum adalah 32.
+ `ParallelApplyBufferSize`— Menentukan jumlah maksimum catatan yang akan disimpan di setiap antrian buffer untuk thread bersamaan untuk mendorong ke titik akhir target Amazon DocumentDB selama pemuatan CDC. Nilai default adalah 100 dan nilai maksimum adalah 1.000. Gunakan pilihan ini saat `ParallelApplyThreads` menentukan lebih dari satu thread.
+ `ParallelApplyQueuesPerThread`— Menentukan jumlah antrian yang diakses setiap thread untuk mengeluarkan catatan data dari antrian dan menghasilkan pemuatan batch untuk titik akhir Amazon DocumentDB selama CDC. Default-nya adalah 1. Maksimum adalah 512.
**catatan**
Untuk target Amazon DocumentDB, penerapan CDC paralel dapat menyebabkan kesalahan kunci duplikat atau penerapan CDC yang macet untuk beban kerja yang menggunakan indeks unik sekunder atau memerlukan urutan perubahan yang ketat. Gunakan konfigurasi penerapan CDC single-threaded default untuk beban kerja ini.
Untuk detail tambahan tentang bekerja dengan Amazon DocumentDB sebagai target, lihat AWS DMS bagian berikut:
**Topics**
+ [Pemetaan data dari sumber ke target Amazon DocumentDB](#CHAP_Target.DocumentDB.data-mapping)
+ [Menghubungkan ke Amazon DocumentDB Elastic Clusters sebagai target](#CHAP_Target.DocumentDB.data-mapping.elastic-cluster-connect)
+ [Replikasi berkelanjutan dengan Amazon DocumentDB sebagai target](#CHAP_Target.DocumentDB.data-mapping.ongoing-replication)
+ [Keterbatasan penggunaan Amazon DocumentDB sebagai target](#CHAP_Target.DocumentDB.limitations)
+ [Menggunakan pengaturan titik akhir dengan Amazon DocumentDB sebagai target](#CHAP_Target.DocumentDB.ECAs)
+ [Target tipe data untuk Amazon DocumentDB](#CHAP_Target.DocumentDB.datatypes)
**catatan**
Untuk step-by-step panduan proses migrasi, lihat [Memigrasi dari MongoDB ke Amazon DocumentDB](https://docs.aws.amazon.com/dms/latest/sbs/CHAP_MongoDB2DocumentDB.html) di Panduan Migrasi. AWS Database Migration Service Step-by-Step
## Pemetaan data dari sumber ke target Amazon DocumentDB
AWS DMS membaca catatan dari titik akhir sumber, dan membangun dokumen JSON berdasarkan data yang dibacanya. Untuk setiap dokumen JSON, AWS DMS harus menentukan `_id` bidang untuk bertindak sebagai pengidentifikasi unik. Kemudian menulis dokumen JSON ke koleksi Amazon DocumentDB, menggunakan `_id` sebagai kunci primer.
### Sumber data yang berupa kolom tunggal
Jika sumber data terdiri dari satu kolom, data harus bertipe string. (Tergantung pada mesin sumber, tipe data sebenarnya mungkin VARCHAR, NVARCHAR, TEXT, LOB, CLOB, atau serupa.) AWS DMS mengasumsikan bahwa data adalah dokumen JSON yang valid, dan mereplikasi data ke Amazon DocumentDB apa adanya.
Jika dokumen JSON yang dihasilkan berisi field bernama `_id`, maka field tersebut digunakan sebagai unik `_id` di Amazon DocumentDB.
Jika JSON tidak berisi field `_id`, maka Amazon DocumentDB menghasilkan nilai `_id` secara otomatis.
### Sumber data yang terdiri dari beberapa kolom
Jika data sumber terdiri dari beberapa kolom, kemudian AWS DMS membangun dokumen JSON dari semua kolom ini. Untuk menentukan `_id` bidang dokumen, lakukan AWS DMS sebagai berikut:
+ Jika salah satu kolom bernama `_id`, maka data dalam kolom tersebut yang digunakan sebagai target `_id`.
+ Jika tidak ada `_id` kolom, tetapi data sumber memiliki kunci primer atau indeks unik, maka AWS DMS gunakan kunci atau nilai indeks itu sebagai `_id` nilainya. Data dari kunci primer atau indeks unik juga muncul sebagai field eksplisit dalam dokumen JSON.
+ Jika tidak ada kolom `_id`, dan tidak ada kunci primer atau indeks unik, maka Amazon DocumentDB menghasilkan nilai `_id` secara otomatis.
### Memaksakan tipe data pada titik akhir target
AWS DMS dapat memodifikasi struktur data saat menulis ke titik akhir target Amazon DocumentDB. Anda dapat meminta perubahan ini dengan mengubah nama kolom dan tabel di titik akhir sumber, atau dengan menyediakan aturan transformasi yang diterapkan ketika tugas berjalan.
#### Menggunakan dokumen JSON nested (json\$1prefix)
Untuk memaksakan tipe data, Anda dapat mengawali nama kolom sumber dengan `json_` (yaitu, `json_columnName`) baik secara manual atau menggunakan transformasi. Dalam kasus ini, kolom dibuat sebagai dokumen JSON nested dalam dokumen target, bukan sebagai field string.
Misalnya, anggaplah Anda ingin memigrasikan dokumen berikut dari titik akhir sumber MongoDB.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactDetails": "{"Home": {"Address": "Boston","Phone": "1111111"},"Work": { "Address": "Boston", "Phone": "2222222222"}}"
}
```
Jika Anda tidak memaksa salah satu tipe sumber data, dokumen `ContactDetails` yang tertanam akan dimigrasi sebagai string.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactDetails": "{\"Home\": {\"Address\": \"Boston\",\"Phone\": \"1111111\"},\"Work\": { \"Address\": \"Boston\", \"Phone\": \"2222222222\"}}"
}
```
Namun, Anda dapat menambahkan aturan transformasi untuk memaksa `ContactDetails`menjadi objek JSON. Misalnya, anggaplah bahwa nama kolom sumber asli adalah `ContactDetails`. Untuk memaksa tipe data sebagai Nested JSON, kolom di titik akhir sumber perlu diganti namanya menjadi json\$1ContactDetails” baik dengan menambahkan awalan “\$1json\$1\$1” pada sumber secara manual atau melalui aturan transformasi. Misalnya, Anda dapat menggunakan aturan transformasi di bawah ini:
```
{
"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 mereplikasi ContactDetails bidang sebagai JSON bersarang, sebagai berikut.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactDetails": {
"Home": {
"Address": "Boston",
"Phone": "1111111111"
},
"Work": {
"Address": "Boston",
"Phone": "2222222222"
}
}
}
```
#### Menggunakan array JSON (array\$1prefix)
Untuk memaksakan tipe data, Anda dapat mengawali nama kolom dengan `array_` (yaitu, `array_columnName`), baik secara manual maupun menggunakan transformasi. Dalam hal ini, AWS DMS pertimbangkan kolom sebagai array JSON, dan membuatnya seperti itu dalam dokumen target.
Misalnya Anda ingin memigrasikan dokumen berikut dari titik akhir sumber MongoDB.
```
{
"_id" : "1",
"FirstName": "John",
"LastName": "Doe",
"ContactAddresses": ["Boston", "New York"],
"ContactPhoneNumbers": ["1111111111", "2222222222"]
}
```
Jika Anda tidak memaksakan salah satu tipe sumber data, dokumen `ContactDetails` yang tertanam akan dimigrasi sebagai string.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactAddresses": "[\"Boston\", \"New York\"]",
"ContactPhoneNumbers": "[\"1111111111\", \"2222222222\"]"
}
```
Namun, Anda dapat menambahkan aturan transformasi untuk memaksa `ContactAddress` dan `ContactPhoneNumbers` ke array JSON, seperti yang ditunjukkan pada tabel berikut.
****
| Nama kolom sumber asli | Kolom sumber berganti nama |
| --- | --- |
| ContactAddress | array\$1ContactAddress |
| ContactPhoneNumbers | array\$1ContactPhoneNumbers |
AWS DMS mereplikasi `ContactAddress` dan `ContactPhoneNumbers` sebagai berikut.
```
{
"_id": "1",
"FirstName": "John",
"LastName": "Doe",
"ContactAddresses": [
"Boston",
"New York"
],
"ContactPhoneNumbers": [
"1111111111",
"2222222222"
]
}
```
### Menghubungkan ke Amazon DocumentDB menggunakan TLS
Secara default, klaster Amazon DocumentDB yang baru dibuat hanya menerima sambungan aman menggunakan Keamanan Lapisan Pengangkutan (TLS). Ketika TLS diaktifkan, setiap sambungan ke Amazon DocumentDB memerlukan kunci publik.
Anda dapat mengambil kunci publik untuk Amazon DocumentDB dengan mengunduh `rds-combined-ca-bundle.pem` file,, dari bucket Amazon S3 yang AWS dihosting. Untuk informasi lebih lanjut tentang mengunduh file ini, lihat [Mengenkripsi sambungan menggunakan TLS](https://docs.aws.amazon.com/documentdb/latest/developerguide/security.encryption.ssl.html) dalam *Panduan Developer Amazon DocumentDB*
Setelah mengunduh file.pem ini, Anda dapat mengimpor kunci publik yang dikandungnya AWS DMS seperti yang dijelaskan berikut.
#### Konsol Manajemen AWS
**Untuk mengimpor file kunci publik (.pem)**
1. Buka AWS DMS konsol di [https://console.aws.amazon.com/dms](https://console.aws.amazon.com/dms).
1. Pilih **Sertifikat** di panel navigasi.
1. Pilih **Impor Sertifikat** dan lakukan hal berikut:
+ Untuk **Pengenal sertifikat**, masukkan nama unik untuk sertifikat tersebut, contohnya `docdb-cert`.
+ Untuk **Impor file**, arahkan ke lokasi tempat Anda menyimpan file .pem.
Jika pengaturan sudah sesuai keinginan Anda, pilih **Tambahkan Sertifikat CA baru**.
#### AWS CLI
Gunakan perintah `aws dms import-certificate` seperti pada contoh berikut.
```
aws dms import-certificate \
--certificate-identifier docdb-cert \
--certificate-pem file://./rds-combined-ca-bundle.pem
```
Saat Anda membuat titik akhir AWS DMS target, berikan pengenal sertifikat (misalnya,`docdb-cert`). Juga, tetapkan parameter mode SSL ke `verify-full`.
## Menghubungkan ke Amazon DocumentDB Elastic Clusters sebagai target
Di AWS DMS versi 3.4.7 dan yang lebih tinggi, Anda dapat membuat titik akhir target Amazon DocumentDB sebagai Elastic Cluster. Jika Anda membuat titik akhir target sebagai Elastic Cluster, Anda harus melampirkan sertifikat SSL baru ke titik akhir Amazon DocumentDB Elastic Cluster karena sertifikat SSL yang ada tidak akan berfungsi.
**Untuk melampirkan sertifikat SSL baru ke titik akhir Amazon DocumentDB Elastic Cluster Anda**
1. Di browser, buka [ https://www.amazontrust.com/repository/SFSRootCAG2.pem](https://www.amazontrust.com/repository/SFSRootCAG2.pem) dan simpan konten ke `.pem` file dengan nama file unik, misalnya. `SFSRootCAG2.pem` Ini adalah file sertifikat yang perlu Anda impor pada langkah selanjutnya.
1. Buat titik akhir Elastic Cluster dan atur opsi berikut:
1. Di bawah **Konfigurasi Titik Akhir**, pilih **Tambahkan sertifikat CA baru**.
1. Untuk **pengenal Sertifikat**, masukkan**SFSRootCAG2.pem**.
1. Untuk **Impor file sertifikat**, **pilih Pilih file**, lalu navigasikan ke `SFSRootCAG2.pem` file yang sebelumnya Anda unduh.
1. Pilih dan buka `SFSRootCAG2.pem` file yang diunduh.
1. Pilih **Impor sertifikat**.
1. Dari drop-down **Pilih sertifikat**, pilih **SFSRootCAG2.pem.**
Sertifikat SSL baru dari `SFSRootCAG2.pem` file yang diunduh sekarang dilampirkan ke titik akhir Amazon DocumentDB Elastic Cluster Anda.
## Replikasi berkelanjutan dengan Amazon DocumentDB sebagai target
Jika replikasi yang sedang berlangsung (ubah pengambilan data, CDC) diaktifkan untuk Amazon DocumentDB sebagai target AWS DMS , versi 3.5.0 dan yang lebih tinggi memberikan peningkatan kinerja yang dua puluh kali lebih besar daripada rilis sebelumnya. Dalam rilis sebelumnya di mana AWS DMS menangani hingga 250 catatan per detik, AWS DMS sekarang secara efisien memproses lebih dari 5000 catatan per detik. AWS DMS juga memastikan bahwa dokumen di Amazon DocumentDB tetap sinkron dengan sumbernya. Ketika rekaman sumber dibuat atau diperbarui, pertama-tama AWS DMS harus menentukan data Amazon DocumentDB mana yang terpengaruh dengan melakukan hal berikut:
+ Jika catatan sumber memiliki kolom bernama `_id`, nilai kolom tersebut menentukan `_id` yang sesuai dalam koleksi Amazon DocumentDB.
+ Jika tidak ada `_id` kolom, tetapi data sumber memiliki kunci primer atau indeks unik, maka AWS DMS gunakan kunci atau nilai indeks tersebut `_id` sebagai koleksi Amazon DocumentDB.
+ Jika rekaman sumber tidak memiliki `_id` kolom, kunci utama, atau indeks unik, maka AWS DMS cocokkan semua kolom sumber dengan bidang yang sesuai dalam koleksi Amazon DocumentDB.
Saat catatan sumber baru dibuat, AWS DMS tulis dokumen yang sesuai ke Amazon DocumentDB. Jika catatan sumber yang ada diperbarui, AWS DMS perbarui bidang terkait dalam dokumen target di Amazon DocumentDB. Setiap field yang ada di dokumen target tetapi tidak ada di catatan sumber tetap tak tersentuh.
Ketika catatan sumber dihapus, AWS DMS menghapus dokumen yang sesuai dari Amazon DocumentDB.
### Perubahan struktural (DDL) pada sumbernya
Dengan replikasi berkelanjutan, setiap perubahan pad struktur data sumber (seperti tabel, kolom, dan sebagainya) disebarkan ke rekan-rekan mereka di Amazon DocumentDB. Dalam basis data relasional, perubahan ini dimulai dengan menggunakan pernyataan bahasa definisi data (DDL). Anda dapat melihat bagaimana AWS DMS menyebarkan perubahan ini ke Amazon DocumentDB di tabel berikut.
****
| DDL di sumber | Efek pada target Amazon DocumentDB |
| --- | --- |
| CREATE TABLE | Membuat koleksi kosong. |
| Pernyataan yang mengganti nama tabel (RENAME TABLE, ALTER TABLE...RENAME, dan sejenisnya) | Mengganti nama koleksi. |
| TRUNCATE TABLE | Menghapus semua dokumen dari koleksi, tetapi hanya jika HandleSourceTableTruncated adalah true. Untuk informasi lebih lanjut, lihat [Pengaturan tugas untuk perubahan pengolahan DDL penanganan](CHAP_Tasks.CustomizingTasks.TaskSettings.DDLHandling.md). |
| DROP TABLE | Menghapus koleksi, tetapi hanya jika HandleSourceTableDropped adalah true. Untuk informasi lebih lanjut, lihat [Pengaturan tugas untuk perubahan pengolahan DDL penanganan](CHAP_Tasks.CustomizingTasks.TaskSettings.DDLHandling.md). |
| Pernyataan yang menambahkan kolom ke tabel (ALTER TABLE...ADD dan sejenisnya) | Pernyataan DDL diabaikan, dan peringatan dikeluarkan. Ketika INSERT pertama kali dilakukan pada sumber, field baru ditambahkan ke dokumen target. |
| ALTER TABLE...RENAME COLUMN | Pernyataan DDL diabaikan, dan peringatan dikeluarkan. Ketika INSERT pertama kali dilakukan pada sumber, field baru ditambahkan ke dokumen target. |
| ALTER TABLE...DROP COLUMN | Pernyataan DDL diabaikan, dan peringatan dikeluarkan. |
| Pernyataan yang mengubah tipe data kolom (ALTER COLUMN...MODIFY dan sejenisnya) | Pernyataan DDL diabaikan, dan peringatan dikeluarkan. Ketika INSERT pertama kali dilakukan pada sumber dengan tipe data baru, dokumen target dibuat dengan field tipe data baru tersebut. |
## Keterbatasan penggunaan Amazon DocumentDB sebagai target
Batasan berikut berlaku saat menggunakan Amazon DocumentDB sebagai target untuk: AWS DMS
+ Di Amazon DocumentDB, nama koleksi tidak dapat berisi simbol dolar (\$1). Selain itu, nama basis data tidak dapat berisi karakter Unicode.
+ AWS DMS tidak mendukung penggabungan beberapa tabel sumber menjadi satu koleksi Amazon DocumentDB.
+ Ketika AWS DMS proses berubah dari tabel sumber yang tidak memiliki kunci primer, kolom LOB apa pun dalam tabel tersebut akan diabaikan.
+ Jika piliha **Ubah tabel** diaktifkan dan AWS DMS menemukan kolom sumber bernama ”*\$1id*“, maka kolom tersebut muncul sebagai ”*\$1\$1id*“ (dua garis bawah) di tabel perubahan.
+ Jika Anda memilih Oracle sebagai titik akhir sumber, maka sumber Oracle harus memiliki pencatatan tambahan penuh diaktifkan. Jika tidak, ketika ada kolom pada sumber yang tidak berubah, maka data dimuat ke Amazon DocumentDB sebagai nilai null.
+ Pengaturan tugas replikasi, `TargetTablePrepMode:TRUNCATE_BEFORE_LOAD` tidak didukung untuk digunakan dengan titik akhir target DocumentDB.
+ Koleksi terbatas MongoDB tidak didukung di Amazon DocumentDB. Namun, AWS DMS secara otomatis memigrasikan objek seperti koleksi yang tidak dibatasi pada DocumentDB target.
+ CDC paralel yang diterapkan ke target Amazon DocumentDB dapat menyebabkan kesalahan kunci duplikat atau penerapan CDC yang macet untuk beban kerja yang menggunakan indeks unik sekunder atau memerlukan urutan perubahan yang ketat. Untuk beban kerja seperti itu, gunakan konfigurasi penerapan CDC single-threaded default.
## Menggunakan pengaturan titik akhir dengan Amazon DocumentDB sebagai target
Anda dapat menggunakan pengaturan titik akhir untuk mengonfigurasi basis data target Amazon DocumentDB mirip dengan menggunakan atribut koneksi tambahan. Anda menentukan pengaturan saat Anda membuat titik akhir target menggunakan AWS DMS konsol, atau dengan menggunakan `create-endpoint` perintah di [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), dengan sintaks `--doc-db-settings '{"EndpointSetting": "value", ...}'` JSON.
Tabel berikut menunjukkan pengaturan titik akhir yang dapat Anda gunakan dengan Amazon DocumentDB sebagai target.
| Nama atribut | Nilai valid | Nilai dan deskripsi default |
| --- | --- | --- |
| `replicateShardCollections` | boolean `true` `false` | Kapan`true`, pengaturan titik akhir ini memiliki efek berikut dan memberlakukan batasan berikut: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/CHAP_Target.DocumentDB.html) |
## Target tipe data untuk Amazon DocumentDB
Dalam tabel berikut, Anda dapat menemukan tipe data target Amazon DocumentDB yang didukung saat AWS menggunakan DMS, dan pemetaan AWS default dari tipe data DMS. Untuk informasi selengkapnya tentang tipe data AWS DMS, lihat[Tipe data untuk AWS Database Migration Service](CHAP_Reference.DataTypes.md).
| AWS Tipe data DMS | Tipe data Amazon DocumentDB |
| --- | --- |
| BOOLEAN | Boolean |
| BYTES | Binary data |
| DATE | Date |
| TIME | Tali (UTF8) |
| DATETIME | Date |
| INT1 | 32-bit integer |
| INT2 | 32-bit integer |
| INT4 | 32-bit integer |
| INT8 | 64-bit integer |
| NUMERIC | Tali (UTF8) |
| REAL4 | Ganda |
| REAL8 | Dua Kali |
| STRING | Jika data dikenali sebagai JSON, maka AWS DMS migrasikan ke Amazon DocumentDB sebagai dokumen. Jika tidak, data dipetakan ke String (UTF8). |
| UINT1 | 32-bit integer |
| UINT2 | 32-bit integer |
| UINT4 | 64-bit integer |
| UINT8 | Tali (UTF8) |
| WSTRING | Jika data dikenali sebagai JSON, maka AWS DMS migrasikan ke Amazon DocumentDB sebagai dokumen. Jika tidak, data dipetakan ke String (UTF8). |
| BLOB | Binary |
| CLOB | Jika data dikenali sebagai JSON, maka AWS DMS migrasikan ke Amazon DocumentDB sebagai dokumen. Jika tidak, data dipetakan ke String (UTF8). |
| NCLOB | Jika data dikenali sebagai JSON, maka AWS DMS migrasikan ke Amazon DocumentDB sebagai dokumen. Jika tidak, data dipetakan ke String (UTF8). |
# Menggunakan Amazon Neptunus sebagai target AWS Database Migration Service
Amazon Neptune adalah layanan basis data grafik yang cepat, andal, terkelola penuh yang memudahkan membangun dan menjalankan aplikasi yang bekerja dengan set data yang sangat terhubung. Inti dari Neptune adalah mesin basis data grafik berperforma tinggi yang dibuat khusus. Mesin ini dioptimalkan untuk menyimpan miliaran hubungan dan membuat kueri grafik dengan latensi milidetik. Neptunus mendukung bahasa kueri grafik populer TinkerPop Apache Gremlin dan SPARQL W3C. Untuk informasi lebih lanjut tentang Amazon Neptune, lihat [Apa itu Amazon Neptune?](https://docs.aws.amazon.com/neptune/latest/userguide/intro.html) di *Panduan Pengguna Amazon Neptune*.
Tanpa basis data grafik seperti Neptune, Anda mungkin memodelkan data yang sangat terhubung dalam basis data relasional. Karena data memiliki koneksi dengan berpotensi dinamis, aplikasi yang menggunakan sumber data tersebut harus memodelkan kueri data terhubung di SQL. Pendekatan ini mengharuskan Anda menulis sebuah lapisan tambahan untuk mengonversi kueri grafik ke SQL. Dan juga, basis data relasional tersedia dengan skema kekakuan. Setiap perubahan dalam skema untuk memodelkan koneksi yang berubah memerlukan downtime dan pemeliharaan tambahan dari konversi kueri untuk mendukung skema baru. Performa kueri juga merupakan hambatan besar lain yang harus dipertimbangkan saat merancang aplikasi Anda.
Basis data grafik dapat menyederhanakan situasi seperti itu secara signifikan. Tidak terikat skema, lapisan kueri yang kaya akan grafik (Gremlin atau SPARQL) dan indeks yang dioptimalkan untuk kueri grafik akan meningkatkan fleksibilitas dan performa. Basis data grafik Amazon Neptune juga memiliki fitur untuk korporasi seperti encryption at rest, lapisan otorisasi aman, backup default, dukungan Multi-AZ, support replika baca, dan lain-lain.
Dengan menggunakan AWS DMS, Anda dapat memigrasikan data relasional yang memodelkan grafik yang sangat terhubung ke titik akhir target Neptunus dari titik akhir sumber DMS untuk database SQL yang didukung.
Untuk detailnya, lihat berikut ini.
**Topics**
+ [Gambaran umum tentang migrasi ke Amazon Neptune sebagai target](#CHAP_Target.Neptune.MigrationOverview)
+ [Menentukan pengaturan titik akhir untuk Amazon Neptune sebagai target](#CHAP_Target.Neptune.EndpointSettings)
+ [Membuat peran layanan IAM untuk mengakses Amazon Neptune sebagai target](#CHAP_Target.Neptune.ServiceRole)
+ [Menentukan aturan pemetaan grafik menggunakan Gremlin dan R2RLL untuk Amazon Neptune sebagai target](#CHAP_Target.Neptune.GraphMapping)
+ [Tipe data untuk migrasi Gremlin dan R2RLL ke Amazon Neptune sebagai target](#CHAP_Target.Neptune.DataTypes)
+ [Keterbatasan menggunakan Amazon Neptune sebagai target](#CHAP_Target.Neptune.Limitations)
## Gambaran umum tentang migrasi ke Amazon Neptune sebagai target
Sebelum memulai migrasi ke target Neptunus, buat sumber daya berikut di akun Anda: AWS
+ Sebuah klaster Neptune untuk titik akhir target.
+ Database relasional SQL didukung oleh AWS DMS untuk titik akhir sumber.
+ Bucket Amazon S3 untuk titik akhir target. Buat bucket S3 ini di AWS Wilayah yang sama dengan cluster Neptunus Anda. AWS DMS menggunakan bucket S3 ini sebagai penyimpanan file perantara untuk data target yang dimuat secara massal ke database Neptunus. Untuk informasi selengkapnya tentang membuat bucket S3, lihat [Membuat bucket](https://docs.aws.amazon.com/AmazonS3/latest/gsg/CreatingABucket.html) di *Panduan Pengguna Layanan Penyimpanan Sederhana Amazon*.
+ titik akhir virtual private cloud (VPC) untuk S3 di VPC yang sama seperti klaster Neptune.
+ Peran AWS Identity and Access Management (IAM) yang mencakup kebijakan IAM. Kebijakan ini harus menentukan izin `GetObject`, `PutObject`, `DeleteObject` dan `ListObject` ke bucket S3 untuk titik akhir target Anda. Peran ini diasumsikan oleh keduanya AWS DMS dan Neptunus dengan akses IAM ke bucket S3 target dan database Neptunus. Untuk informasi selengkapnya, lihat [Membuat peran layanan IAM untuk mengakses Amazon Neptune sebagai target](#CHAP_Target.Neptune.ServiceRole).
Setelah Anda memiliki sumber daya ini, menyiapkan dan memulai migrasi ke target Neptune intinya sama dengan semua migrasi beban penuh menggunakan konsol atau API DMS. Namun, migrasi ke target Neptune memerlukan beberapa langkah unik.
**Untuk memigrasikan database AWS DMS relasional ke Neptunus**
1. Buat instans replikasi seperti yang dijelaskan dalam [Membuat instans replikasi](CHAP_ReplicationInstance.Creating.md).
1. Buat dan uji database relasional SQL yang didukung oleh AWS DMS untuk titik akhir sumber.
1. Buat dan uji titik akhir target untuk basis data Neptune Anda.
Untuk menghubungkan titik akhir target ke basis data Neptune, tentukan nama server untuk titik akhir klaster Neptune atau titik akhir instans penulis Neptune. Juga, tentukan folder bucket S3 untuk menyimpan file perantara AWS DMS untuk pemuatan massal ke database Neptunus.
Selama migrasi, AWS DMS menyimpan semua data target yang dimigrasi di folder bucket S3 ini hingga ukuran file maksimum yang Anda tentukan. Ketika penyimpanan file ini mencapai ukuran maksimum ini, AWS DMS massal memuat data S3 yang disimpan ke dalam database target. Ia membersihkan folder untuk mengaktifkan penyimpanan data target tambahan apa pun untuk pemuatan berikutnya ke basis data target. Untuk informasi lebih lanjut tentang menentukan pengaturan ini, lihat [Menentukan pengaturan titik akhir untuk Amazon Neptune sebagai target](#CHAP_Target.Neptune.EndpointSettings).
1. Buat tugas replikasi beban penuh dengan sumber daya yang dibuat dalam langkah 1-3 dan lakukan hal berikut:
1. Gunakan pemetaan tabel tugas seperti biasa untuk mengidentifikasi skema sumber tertentu, tabel, dan views untuk bermigrasi dari basis data relasional Anda menggunakan pilihan yang tepat dan aturan transformasi. Untuk informasi lebih lanjut, lihat [Menggunakan pemetaan tabel untuk menentukan pengaturan tugas](CHAP_Tasks.CustomizingTasks.TableMapping.md).
1. Tentukan pemetaan target dengan memilih salah satu dari berikut ini untuk menentukan aturan pemetaan dari tabel sumber dan tampilan ke grafik basis data target Neptune Anda:
+ Gremlin JSON - Untuk informasi tentang penggunaan Gremlin JSON untuk memuat basis data Neptune, lihat [Format memuat data Gremlin](https://docs.aws.amazon.com/neptune/latest/userguide/bulk-load-tutorial-format-gremlin.html) di *Panduan Pengguna Amazon Neptune*.
+ SPARQL RDB to Resource Description Framework Mapping Language (R2RLL) - Untuk informasi tentang menggunakan SPARQL R2RLL, lihat spesifikasi W3C [R2RLL: RDB ke bahasa pemetaan RDF](https://www.w3.org/TR/r2rml/).
1. Lakukan salah satu tindakan berikut:
+ Menggunakan AWS DMS konsol, tentukan opsi pemetaan grafik menggunakan **Aturan pemetaan grafik** di halaman tugas **Buat migrasi database**.
+ Menggunakan AWS DMS API, tentukan opsi ini menggunakan parameter `TaskData` permintaan panggilan `CreateReplicationTask` API.
Untuk informasi lebih lanjut dan contoh penggunaanGremlin JSON dan SPARQL R2RLL dalam menentukan aturan pemetaan grafik, lihat [Menentukan aturan pemetaan grafik menggunakan Gremlin dan R2RLL untuk Amazon Neptune sebagai target](#CHAP_Target.Neptune.GraphMapping).
1. Mulai replikasi untuk tugas migrasi Anda.
## Menentukan pengaturan titik akhir untuk Amazon Neptune sebagai target
Untuk membuat atau mengubah titik akhir target, Anda dapat menggunakan konsol atau `CreateEndpoint` atau Operasi API `ModifyEndpoint`.
**Untuk target Neptunus di AWS DMS konsol, **tentukan pengaturan khusus titik akhir pada halaman Buat titik akhir** **atau Ubah konsol titik akhir**.** Untuk `CreateEndpoint` dan `ModifyEndpoint`, tentukan parameter permintaan untuk pilihan `NeptuneSettings`. Contoh berikut menunjukkan cara melakukannya dengan menggunakan CLI.
```
dms create-endpoint --endpoint-identifier my-neptune-target-endpoint
--endpoint-type target --engine-name neptune
--server-name my-neptune-db.cluster-cspckvklbvgf.us-east-1.neptune.amazonaws.com
--port 8192
--neptune-settings
'{"ServiceAccessRoleArn":"arn:aws:iam::123456789012:role/myNeptuneRole",
"S3BucketName":"amzn-s3-demo-bucket",
"S3BucketFolder":"amzn-s3-demo-bucket-folder",
"ErrorRetryDuration":57,
"MaxFileSize":100,
"MaxRetryCount": 10,
"IAMAuthEnabled":false}‘
```
Di sini, pilihan CLI `--server-name` menentukan nama server untuk titik akhir penulis klaster Neptune. Atau Anda dapat menentukan nama server untuk instans titik akhir penulis Neptune.
Berikut adalah parameter permintaan pilihan `--neptune-settings`:
+ `ServiceAccessRoleArn` - (Wajib) Amazon Resource Name (ARN) dari peran layanan yang Anda buat untuk titik akhir target Neptune. Untuk informasi lebih lanjut, lihat [Membuat peran layanan IAM untuk mengakses Amazon Neptune sebagai target](#CHAP_Target.Neptune.ServiceRole).
+ `S3BucketName` - (Wajib) Nama bucket S3 tempat DMS dapat menyimpan sementara data grafik yang dimigrasikan dalam file .csv sebelum memuatnya secara massal ke basis data target Neptune. DMS memetakan data sumber SQL data grafik sebelum menyimpannya dalam file .csv.
+ `S3BucketFolder` - (Wajib) Jalur folder tempat Anda menginginkan DMS untuk menyimpan data grafik yang dimigrasikan di bucket S3 yang ditentukan oleh `S3BucketName`.
+ `ErrorRetryDuration` - (Opsional) Jumlah milidetik waktu tunggu DMS untuk mencoba kembali muatan massal data grafik yang dimigrasikan ke basis data target Neptune sebelum dinyatakan error. Default adalah 250.
+ `MaxFileSize` - (Opsional) Ukuran maksimum dalam KB dari data grafik yang dimigrasikan lalu disimpan ke dalam file .csv sebelum DMS memuat data secara massal ke basis data target Neptune. Default adalah 1.048.576 KB (1 GB). Jika berhasil, DMS akan membersihkan bucket, siap untuk menyimpan batch berikutnya dari data grafik yang dimigrasi.
+ `MaxRetryCount` - (Opsional) Frekuensi DMS mencoba kembali muatan massal data grafik yang dimigrasikan ke basis data target Neptune sebelum memunculkan error. Default adalah 5.
+ `IAMAuthEnabled` - (Opsional) Jika Anda ingin mengaktifkan otorisasi IAM untuk titik akhir ini, atur parameter ini ke `true` dan lampirkan dokumen kebijakan IAM yang tepat ke peran layanan Anda yang ditentukan oleh `ServiceAccessRoleArn`. Nilai default-nya `false`.
## Membuat peran layanan IAM untuk mengakses Amazon Neptune sebagai target
Untuk mengakses Neptune sebagai target, buat peran layanan menggunakan IAM. Tergantung pada konfigurasi titik akhir Neptune Anda, lampirkan peran ini pada beberapa atau semua dokumen kepercayaan dan kebijakan IAM berikut. Ketika Anda membuat titik akhir Neptune, peran layanan ini diberikan pada ARN. Melakukannya memungkinkan AWS DMS dan Amazon Neptunus untuk menerima izin untuk mengakses Neptunus dan bucket Amazon S3 terkait.
Jika Anda mengatur parameter `IAMAuthEnabled` dalam `NeptuneSettings` ke `true` di konfigurasi titik akhir Neptune Anda, lampirkan kebijakan IAM seperti berikut ke peran layanan Anda. Jika Anda mengatur `IAMAuthEnabled` ke `false`, Anda dapat mengabaikan kebijakan ini.
```
// Policy to access Neptune
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "neptune-db:*",
"Resource": "arn:aws:neptune-db:us-east-1:123456789012:cluster-CLG7H7FHK54AZGHEH6MNS55JKM/*"
}
]
}
```
Kebijakan IAM sebelumnya memungkinkan akses penuh ke klaster target Neptune yang ditentukan oleh `Resource`.
Lampirkan kebijakan IAM seperti berikut ke peran layanan Anda. Kebijakan ini memungkinkan DMS untuk secara sementara menyimpan data grafik yang dimigrasi di bucket S3 yang Anda buat untuk pemuatan massal ke basis data target Neptune.
```
//Policy to access S3 bucket
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "ListObjectsInBucket0",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket"
]
},
{
"Sid": "AllObjectActions",
"Effect": "Allow",
"Action": ["s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/"
]
},
{
"Sid": "ListObjectsInBucket1",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/"
]
}
]
}
```
Kebijakan IAM sebelumnya memungkinkan akun Anda untuk meminta isi bucket S3 (`arn:aws:s3:::amzn-s3-demo-bucket`) yang dibuat untuk target Neptune Anda. Hal ini juga memungkinkan akun Anda untuk beroperasi sepenuhnya pada isi semua file bucket dan folder (`arn:aws:s3:::amzn-s3-demo-bucket/`).
Edit hubungan kepercayaan dan lampirkan peran IAM berikut ke peran layanan Anda untuk memungkinkan keduanya AWS DMS dan layanan database Amazon Neptunus mengambil peran tersebut.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "dms.amazonaws.com"
},
"Action": "sts:AssumeRole"
},
{
"Sid": "neptune",
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Untuk informasi tentang penentuan peran layanan ini pada titik akhir target Neptune, lihat [Menentukan pengaturan titik akhir untuk Amazon Neptune sebagai target](#CHAP_Target.Neptune.EndpointSettings).
## Menentukan aturan pemetaan grafik menggunakan Gremlin dan R2RLL untuk Amazon Neptune sebagai target
Aturan pemetaan grafik yang Anda buat menentukan bagaimana data yang diekstrak dari sumber basis data relasional SQL kemudian dimuat ke target klaster basis data Neptune. Format aturan pemetaan ini berbeda tergantung pada apakah aturannya untuk memuat data grafik properti menggunakan data Apache TinkerPop Gremlin atau Resource Description Framework (RDF) menggunakan R2RML.4. Setelah itu, Anda dapat menemukan informasi tentang format ini dan tempat untuk mempelajari selengkapnya.
Anda dapat menentukan aturan pemetaan ini ketika membuat tugas migrasi menggunakan konsol atau API DMS.
Menggunakan konsol, tentukan aturan pemetaan ini dengan menggunakan **Aturan pemetaan grafik** pada halaman **Buat tugas migrasi basisdata**. Di **Aturan pemetaan grafik**, Anda dapat memasukkan dan mengedit aturan pemetaan secara langsung menggunakan editor yang disediakan. Atau Anda dapat menelusuri file yang berisi aturan pemetaan dalam format pemetaan grafik yang sesuai.
Menggunakan API, tentukan pilihan ini berdasarkan permintaan parameter `TaskData` dari Panggilan API `CreateReplicationTask`. Atur `TaskData` ke jalur file yang berisi aturan pemetaan dalam format pemetaan grafik yang sesuai.
### Aturan pemetaan grafik untuk menghasilkan data property-graph menggunakan Gremlin
Menggunakan Gremlin untuk menghasilkan data property-graph, menentukan objek JSON dengan aturan pemetaan untuk setiap entitas grafik yang akan dihasilkan dari data sumber. Format JSON ini ditetapkan secara khusus untuk pemuatan massal Amazon Neptune. Templat berikut menunjukkan nampak seperti apa setiap aturan dalam objek ini.
```
{
"rules": [
{
"rule_id": "(an identifier for this rule)",
"rule_name": "(a name for this rule)",
"table_name": "(the name of the table or view being loaded)",
"vertex_definitions": [
{
"vertex_id_template": "{col1}",
"vertex_label": "(the vertex to create)",
"vertex_definition_id": "(an identifier for this vertex)",
"vertex_properties": [
{
"property_name": "(name of the property)",
"property_value_template": "{col2} or text",
"property_value_type": "(data type of the property)"
}
]
}
]
},
{
"rule_id": "(an identifier for this rule)",
"rule_name": "(a name for this rule)",
"table_name": "(the name of the table or view being loaded)",
"edge_definitions": [
{
"from_vertex": {
"vertex_id_template": "{col1}",
"vertex_definition_id": "(an identifier for the vertex referenced above)"
},
"to_vertex": {
"vertex_id_template": "{col3}",
"vertex_definition_id": "(an identifier for the vertex referenced above)"
},
"edge_id_template": {
"label": "(the edge label to add)",
"template": "{col1}_{col3}"
},
"edge_properties":[
{
"property_name": "(the property to add)",
"property_value_template": "{col4} or text",
"property_value_type": "(data type like String, int, double)"
}
]
}
]
}
]
}
```
Kehadiran label vertex menyiratkan bahwa pembuatan vertex sedang terjadi di sini. Ketiadaannya menyiratkan bahwa vertex dibuat oleh sumber yang berbeda, dan definisi ini hanya menambahkan sifat vertex. Tentukan sebanyak mungkin definisi vertex dan edge yang diperlukan untuk menentukan pemetaan untuk seluruh sumber basis data relasional Anda.
Contoh aturan untuk tabel `employee` berikut.
```
{
"rules": [
{
"rule_id": "1",
"rule_name": "vertex_mapping_rule_from_nodes",
"table_name": "nodes",
"vertex_definitions": [
{
"vertex_id_template": "{emp_id}",
"vertex_label": "employee",
"vertex_definition_id": "1",
"vertex_properties": [
{
"property_name": "name",
"property_value_template": "{emp_name}",
"property_value_type": "String"
}
]
}
]
},
{
"rule_id": "2",
"rule_name": "edge_mapping_rule_from_emp",
"table_name": "nodes",
"edge_definitions": [
{
"from_vertex": {
"vertex_id_template": "{emp_id}",
"vertex_definition_id": "1"
},
"to_vertex": {
"vertex_id_template": "{mgr_id}",
"vertex_definition_id": "1"
},
"edge_id_template": {
"label": "reportsTo",
"template": "{emp_id}_{mgr_id}"
},
"edge_properties":[
{
"property_name": "team",
"property_value_template": "{team}",
"property_value_type": "String"
}
]
}
]
}
]
}
```
Di sini, definisi vertex dan edge memetakan hubungan pelaporan dari node `employee` dengan ID karyawan (`EmpID`) dan node `employee` dengan ID manajer (`managerId`).
Untuk informasi lebih lanjut tentang cara membuat aturan pemetaan grafik menggunakan Gremlin JSON, lihat [Format memuat data Gremlin](https://docs.aws.amazon.com/neptune/latest/userguide/bulk-load-tutorial-format-gremlin.html) di *Panduan Pengguna Amazon Neptune*.
### Aturan pemetaan grafik untuk menghasilkan data RDF/SPARQL
Jika Anda memuat data RDF untuk dikueri menggunakan SPARQL, tuliskan aturan pemetaan grafik di R2RLL. R2RLL adalah bahasa W3C standar untuk pemetaan data relasional untuk RDF. Dalam satu file R2RMM, sebuah *Peta tiga kali lipat* (misalnya, pada `<#TriplesMap1>` berikut) menentukan aturan untuk menerjemahkan setiap baris dari tabel logis ke nol atau lebih tiga kali lipat RDF. Sebuah *Peta subjek* (misalnya, apa pun dari `rr:subjectMap` berikut) menentukan aturan untuk menghasilkan subyek dari tiga kali lipat RDF yang dihasilkan oleh peta tiga kali lipat. Sebuah *peta predikat-objek* (misalnya, apa pun dari `rr:predicateObjectMap` berikut) adalah fungsi yang menciptakan satu atau lebih pasangan predikat-objek untuk setiap baris tabel logis dari tabel logis.
Contoh sederhana untuk tabel `nodes` berikut.
```
@prefix rr: .
@prefix ex: .
<#TriplesMap1>
rr:logicalTable [ rr:tableName "nodes" ];
rr:subjectMap [
rr:template "http://data.example.com/employee/{id}";
rr:class ex:Employee;
];
rr:predicateObjectMap [
rr:predicate ex:name;
rr:objectMap [ rr:column "label" ];
]
```
Pada contoh sebelumnya, pemetaan mendefinisikan node grafik terpetakan dari tabel karyawan.
Contoh sederhana lain untuk tabel `Student` berikut.
```
@prefix rr: .
@prefix ex: .
@prefix foaf: .
@prefix xsd: .
<#TriplesMap2>
rr:logicalTable [ rr:tableName "Student" ];
rr:subjectMap [ rr:template "http://example.com/{ID}{Name}";
rr:class foaf:Person ];
rr:predicateObjectMap [
rr:predicate ex:id ;
rr:objectMap [ rr:column "ID";
rr:datatype xsd:integer ]
];
rr:predicateObjectMap [
rr:predicate foaf:name ;
rr:objectMap [ rr:column "Name" ]
].
```
Dalam contoh sebelumnya, pemetaan mendefinisikan node grafik pemetaan friend-of-a-friend hubungan antara orang-orang dalam sebuah tabel. `Student`
Untuk informasi lebih lanjut tentang membuat aturan pemetaan grafik menggunakan SPARQL R2RLL, lihat spesifikasi W3C [R2RLL: RDB ke bahasa pemetaan RDF](https://www.w3.org/TR/r2rml/).
## Tipe data untuk migrasi Gremlin dan R2RLL ke Amazon Neptune sebagai target
AWS DMS melakukan pemetaan tipe data dari titik akhir sumber SQL Anda ke target Neptunus Anda dengan salah satu dari dua cara. Cara yang digunakan tergantung pada format pemetaan grafik yang Anda gunakan untuk memuat basis data Neptune:
+ Apache TinkerPop Gremlin, menggunakan representasi JSON dari data migrasi.
+ SPARQL W3C menggunakan representasi R2RLL dari data migrasi.
Untuk informasi lebih lanjut tentang dua format pemetaan grafik ini, lihat [Menentukan aturan pemetaan grafik menggunakan Gremlin dan R2RLL untuk Amazon Neptune sebagai target](#CHAP_Target.Neptune.GraphMapping).
Selanjutnya, Anda dapat menemukan deskripsi dari pemetaan tipe data untuk setiap format.
### Sumber SQL untuk pemetaan ke tipe data target Gremlin
Tabel berikut menunjukkan pemetaan tipe data dari sumber SQL ke target yang sudah diformat GREMLIN.
AWS DMS memetakan semua tipe data sumber SQL yang tidak terdaftar ke Gremlin. `String`
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/CHAP_Target.Neptune.html)
Untuk informasi lebih lanjut tentang tipe data Gremlin untuk memuat Neptune, lihat [Jenis data Gremlin](https://docs.aws.amazon.com//neptune/latest/userguide/bulk-load-tutorial-format-gremlin.html#bulk-load-tutorial-format-gremlin-datatypes) di *Panduan Pengguna Neptune.*
### Sumber SQL untuk pemetaan ke tipe data target R2RML (RDF)
Tabel berikut menunjukkan pemetaan tipe data dari sumber SQL ke target yang diformat R2RML.
Semua tipe data RDF yang terdaftar peka huruf besar/kecil, kecuali RDF literal. AWS DMS memetakan semua tipe data sumber SQL yang tidak terdaftar ke literal RDF.
Sebuah *RDF literal* adalah salah satu dari berbagai bentuk leksikal literal dan tipe data. Untuk informasi lebih lanjut, lihat [literal RDF](https://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-Graph-Literal) dalam spesifikasi W3C *Resource Description Framework (RDF): Konsep dan Abstrak*.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/CHAP_Target.Neptune.html)
Untuk informasi lebih lanjut tentang tipe data RDF yang digunakan memuat Neptune dan pemetaan mereka ke tipe data sumber SQL, lihat [Konversi datatype](https://www.w3.org/TR/r2rml/#datatype-conversions) dalam spesifikasi W3C *R2RLL: RDB ke Pemetaan Bahasa RDF*.
## Keterbatasan menggunakan Amazon Neptune sebagai target
Batasan berikut berlaku saat menggunakan Amazon Neptune sebagai target:
+ AWS DMS saat ini mendukung tugas pemuatan penuh hanya untuk migrasi ke target Neptunus. Migrasi Perubahan pengambilan data (CDC) ke target Neptune tidak didukung.
+ Pastikan basis data Neptune target Anda dihapus secara manual dari semua data sebelum memulai tugas migrasi, seperti pada contoh berikut.
Untuk drop semua data (vertex dan edge) dalam grafik, jalankan perintah Gremlin berikut.
```
gremlin> g.V().drop().iterate()
```
Untuk drop vertex yang memiliki label `'customer'`, jalankan perintah Gremlin berikut.
```
gremlin> g.V().hasLabel('customer').drop()
```
**catatan**
Dibutuhkan beberapa waktu untuk menjatuhkan set data besar. Anda mungkin ingin mengulangi `drop()` dengan batas, misalnya, `limit(1000)`.
Untuk drop edge yang memiliki label `'rated'`, jalankan perintah Gremlin berikut.
```
gremlin> g.E().hasLabel('rated').drop()
```
**catatan**
Dibutuhkan beberapa waktu untuk menjatuhkan set data besar. Anda mungkin ingin mengulangi `drop()` dengan batas, misalnya `limit(1000)`.
+ Operasi API DMS `DescribeTableStatistics` dapat mengembalikan hasil yang tidak akurat tentang tabel yang diberikan karena sifat struktur data grafik Neptune.
Selama migrasi, AWS DMS memindai setiap tabel sumber dan menggunakan pemetaan grafik untuk mengubah data sumber menjadi grafik Neptunus. Data yang dikonversi pertama kali disimpan dalam folder bucket S3 yang ditentukan untuk titik akhir target. Jika sumbernya dipindai dan data S3 perantara ini berhasil dibuat, `DescribeTableStatistics` mengasumsikan bahwa data berhasil dimuat ke dalam basis data target Neptune. Tapi ini tidak selalu benar. Untuk memverifikasi bahwa data dimuat dengan benar untuk tabel tertentu, bandingkan nilai kembalian `count()` di kedua ujung migrasi untuk tabel tersebut.
Dalam contoh berikut, AWS DMS telah memuat `customer` tabel dari database sumber, yang diberi label `'customer'` dalam grafik database Neptunus target. Anda dapat memastikan bahwa label ini ditulis ke basis data target. Untuk melakukannya bandingkan jumlah `customer` baris yang tersedia dari basis data sumber dengan jumlah `'customer'` baris berlabel yang dimuat dalam basis data target Neptune setelah tugas selesai.
Untuk mendapatkan jumlah baris pelanggan yang tersedia dari basis data sumber menggunakan SQL, jalankan perintah berikut.
```
select count(*) from customer;
```
Untuk mendapatkan jumlah `'customer'` baris berlabel yang dimuat ke dalam grafik basis data target menggunakan Gremlin, jalankan yang berikut ini.
```
gremlin> g.V().hasLabel('customer').count()
```
+ Saat ini, jika ada satu tabel tunggal yang gagal memuat, maka seluruh tugas gagal. Tidak seperti dalam target basis data relasional, data di Neptune sangat terhubung, yang dalam banyak kasus membuatnya tidak mungkin untuk melanjutkan tugas. Jika tugas tidak dapat dilanjutkan dengan sukses karena tipe kegagalan memuat data seperti ini, maka buatlah tugas baru untuk memuat tabel yang gagal dimuat. Sebelum menjalankan tugas baru ini, secara manual kosongkan tabel sebagian dimuat dari target Neptune.
**catatan**
Anda dapat melanjutkan tugas yang gagal migrasi ke target Neptune jika kegagalan masih dapat dipulihkan (misalnya, kesalahan transit jaringan).
+ AWS DMS mendukung sebagian besar standar untuk R2RML. Namun, AWS DMS tidak mendukung standar R2RML tertentu, termasuk ekspresi terbalik, gabungan, dan tampilan. Sebuah solusi untuk view R2RLL adalah dengan membuat view SQL kustom yang sesuai dalam basis data sumber. Dalam tugas migrasi, gunakan pemetaan tabel untuk memilih view sebagai masukan. Kemudian petakantampilan ke tabel yang kemudian dikonsumsi oleh R2RLM untuk menghasilkan data grafik.
+ Ketika Anda memigrasi data sumber dengan tipe data SQL yang tidak didukung, data target yang dihasilkan dapat kehilangan ketepatan. Untuk informasi selengkapnya, lihat [Tipe data untuk migrasi Gremlin dan R2RLL ke Amazon Neptune sebagai target](#CHAP_Target.Neptune.DataTypes).
+ AWS DMS tidak mendukung migrasi data LOB ke target Neptunus.
# Menggunakan Redis OSS sebagai target AWS Database Migration Service
Redis OSS adalah penyimpanan struktur data dalam memori sumber terbuka yang digunakan sebagai database, cache, dan broker pesan. Mengelola data dalam memori dapat menghasilkan operasi baca atau tulis yang memakan waktu kurang dari satu milidetik, dan ratusan juta operasi dilakukan setiap detik. Sebagai penyimpanan data dalam memori, Redis OSS memberi daya pada aplikasi yang paling menuntut yang membutuhkan waktu respons sub-milidetik.
Dengan menggunakan AWS DMS, Anda dapat memigrasikan data dari database sumber apa pun yang didukung ke penyimpanan data Redis OSS target dengan waktu henti minimal. Untuk informasi tambahan tentang Redis OSS lihat, [Redis](https://redis.io/documentation) OSS Dokumentasi.
Selain Redis OSS lokal, AWS Database Migration Service mendukung hal berikut:
+ [Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/elasticache/redis/) sebagai penyimpanan data target. ElastiCache (Redis OSS) bekerja dengan klien Redis OSS Anda dan menggunakan format data Redis OSS terbuka untuk menyimpan data Anda.
+ [Amazon MemoryDB](https://aws.amazon.com/memorydb/) sebagai penyimpanan data target. MemoryDB kompatibel dengan Redis OSS dan memungkinkan Anda untuk membangun aplikasi menggunakan semua struktur data Redis OSS, APIs, dan perintah yang digunakan saat ini.
Untuk informasi tambahan tentang bekerja dengan Redis OSS sebagai target AWS DMS, lihat bagian berikut:
**Topics**
+ [Prasyarat untuk menggunakan cluster Redis OSS sebagai target AWS DMS](#CHAP_Target.Redis.Prerequisites)
+ [Keterbatasan saat menggunakan Redis sebagai target AWS Database Migration Service](#CHAP_Target.Redis.Limitations)
+ [Migrasi data dari database relasional atau non-relasional ke target Redis OSS](#CHAP_Target.Redis.Migrating)
+ [Menentukan pengaturan titik akhir untuk Redis OSS sebagai target](#CHAP_Target.Redis.EndpointSettings)
## Prasyarat untuk menggunakan cluster Redis OSS sebagai target AWS DMS
*DMS mendukung target Redis OSS lokal dalam konfigurasi mandiri, atau sebagai kluster Redis OSS di mana data secara otomatis di-sharded di beberapa node.* Sharding adalah proses memisahkan data menjadi potongan-potongan kecil yang disebut pecahan yang tersebar di beberapa server atau node. Akibatnya, pecahan adalah partisi data yang berisi subset dari total kumpulan data, dan melayani sepotong beban kerja keseluruhan.
**Karena Redis OSS adalah penyimpanan data NoSQL nilai-kunci, konvensi penamaan kunci Redis OSS untuk digunakan ketika sumber Anda adalah database relasional, adalah schema-name.table-name.primary-key.** Dalam Redis OSS, kunci dan nilai tidak boleh mengandung karakter khusus%. Jika tidak, DMS melewatkan catatan.
**catatan**
Jika Anda menggunakan ElastiCache (Redis OSS) sebagai target, DMS hanya mendukung konfigurasi yang *diaktifkan mode cluster*. Untuk informasi selengkapnya tentang penggunaan ElastiCache (Redis OSS) versi 6.x atau yang lebih tinggi untuk membuat penyimpanan data target yang diaktifkan mode cluster, lihat [Memulai di Panduan](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/GettingStarted.html) Pengguna *Amazon ElastiCache (Redis OSS*).
Sebelum Anda memulai migrasi database, luncurkan cluster Redis OSS Anda dengan kriteria berikut.
+ Cluster Anda memiliki satu atau lebih pecahan.
+ Jika Anda menggunakan target ElastiCache (Redis OSS), pastikan klaster Anda tidak menggunakan kontrol akses berbasis peran IAM. Sebagai gantinya, gunakan Redis OSS Auth untuk mengautentikasi pengguna.
+ Aktifkan Multi-AZ (Availability Zones).
+ Pastikan klaster memiliki memori yang cukup yang tersedia agar sesuai dengan data yang akan dimigrasi dari database Anda.
+ Pastikan bahwa kluster Redis OSS target Anda bersih dari semua data sebelum memulai tugas migrasi awal.
Anda harus menentukan persyaratan keamanan untuk migrasi data sebelum membuat konfigurasi klaster. DMS mendukung migrasi untuk menargetkan grup replikasi terlepas dari konfigurasi enkripsi mereka. Tetapi Anda dapat mengaktifkan atau menonaktifkan enkripsi hanya ketika Anda membuat konfigurasi cluster Anda.
## Keterbatasan saat menggunakan Redis sebagai target AWS Database Migration Service
Keterbatasan berikut berlaku saat menggunakan Redis OSS sebagai target:
+ Karena Redis OSS adalah penyimpanan data no-sql nilai-kunci, konvensi penamaan kunci Redis OSS untuk digunakan ketika sumber Anda adalah database relasional, adalah. `schema-name.table-name.primary-key`
+ Di Redis OSS, nilai kunci tidak dapat berisi karakter khusus. `%` Jika tidak, DMS melewatkan catatan.
+ DMS tidak akan memigrasikan baris yang berisi karakter. `%`
+ DMS tidak akan memigrasikan bidang yang berisi `%` karakter dalam nama bidang.
+ Mode LOB penuh tidak didukung.
+ Private Certificate Authority (CA) tidak didukung saat menggunakan ElastiCache (Redis OSS) sebagai target.
+ AWS DMS tidak mendukung data sumber yang berisi `'\0'` karakter yang disematkan saat menggunakan Redis sebagai titik akhir target. Data yang berisi `'\0'` karakter tertanam akan terpotong pada karakter pertama`'\0'`.
## Migrasi data dari database relasional atau non-relasional ke target Redis OSS
Anda dapat memigrasikan data dari sumber SQL atau penyimpanan data NoSQL langsung ke target Redis OSS. Menyiapkan dan memulai migrasi ke target Redis OSS mirip dengan pemuatan penuh dan mengubah migrasi pengambilan data menggunakan konsol DMS atau API. Untuk melakukan migrasi database ke target Redis OSS, Anda melakukan hal berikut.
+ Membuat instans replikasi untuk melakukan semua proses untuk migrasi. Untuk informasi selengkapnya, lihat [Membuat instans replikasi](CHAP_ReplicationInstance.Creating.md).
+ Tentukan titik akhir sumber. Untuk informasi selengkapnya, lihat [Membuat titik akhir sumber dan target](CHAP_Endpoints.Creating.md).
+ Temukan nama DNS dan nomor port cluster Anda.
+ Unduh bundel sertifikat yang dapat Anda gunakan untuk memverifikasi koneksi SSL.
+ Tentukan titik akhir target, seperti yang dijelaskan di bawah ini.
+ Buat tugas atau serangkaian tugas untuk menentukan tabel dan proses replikasi apa yang ingin Anda gunakan. Untuk informasi selengkapnya, lihat [Membuat tugas](CHAP_Tasks.Creating.md).
+ Migrasikan data dari database sumber Anda ke kluster target Anda.
Anda memulai migrasi database dengan salah satu dari dua cara:
1. Anda dapat memilih AWS DMS konsol dan melakukan setiap langkah di sana.
1. Anda dapat menggunakan AWS Command Line Interface (AWS CLI). [Untuk informasi lebih lanjut tentang menggunakan CLI dengan AWS DMS, lihat AWS CLI untuk. AWS DMS](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html)
**Untuk menemukan nama DNS dan nomor port cluster Anda**
+ Gunakan AWS CLI perintah berikut untuk memberikan nama grup replikasi Anda. `replication-group-id`
```
aws elasticache describe-replication-groups --replication-group-id myreplgroup
```
Di sini, output menunjukkan nama DNS dalam `Address` atribut dan nomor port dalam `Port` atribut node utama di cluster.
```
...
"ReadEndpoint": {
"Port": 6379,
"Address": "myreplgroup-
111.1abc1d.1111.uuu1.cache.example.com"
}
...
```
Jika Anda menggunakan MemoryDB sebagai target Anda, gunakan AWS CLI perintah berikut untuk memberikan alamat endpoint ke cluster Redis OSS Anda.
```
aws memorydb describe-clusters --clusterid clusterid
```
**Unduh bundel sertifikat untuk digunakan untuk memverifikasi koneksi SSL**
+ Masukkan `wget` perintah berikut di baris perintah. Wget adalah alat utilitas baris perintah GNU gratis yang digunakan untuk mengunduh file dari internet.
```
wget https://s3.aws-api-domain/rds-downloads/rds-combined-ca-bundle.pem
```
Di sini, `aws-api-domain` lengkapi domain Amazon S3 di Wilayah AWS Anda yang diperlukan untuk mengakses bucket S3 tertentu dan rds-combined-ca-bundle file.pem yang disediakannya.
**Untuk membuat titik akhir target menggunakan konsol AWS DMS**
Titik akhir ini untuk target Redis OSS Anda yang sudah berjalan.
+ Pada konsol tersebut, memilih **Titik Akhir** dari panel navigasi dan kemudian memilih **Membuat Titik Akhir**. Tabel berikut menjelaskan pengaturan.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/CHAP_Target.Redis.html)
Setelah Anda selesai memberikan semua informasi untuk titik akhir Anda, AWS DMS buat titik akhir target Redis OSS Anda untuk digunakan selama migrasi database.
Untuk informasi tentang membuat tugas migrasi dan memulai migrasi database, lihat[Membuat tugas](CHAP_Tasks.Creating.md).
## Menentukan pengaturan titik akhir untuk Redis OSS sebagai target
Untuk membuat atau mengubah titik akhir target, Anda dapat menggunakan konsol atau `CreateEndpoint` atau Operasi API `ModifyEndpoint`.
**Untuk target Redis OSS di AWS DMS konsol, tentukan **pengaturan khusus titik akhir pada halaman Buat titik akhir** **atau Ubah konsol titik akhir**.**
Saat menggunakan `CreateEndpoint` dan operasi `ModifyEndpoint` API, tentukan parameter permintaan untuk `RedisSettings` opsi tersebut. Contoh berikut menunjukkan bagaimana melakukan ini menggunakan AWS CLI.
```
aws dms create-endpoint --endpoint-identifier my-redis-target
--endpoint-type target --engine-name redis --redis-settings
'{"ServerName":"sample-test-sample.zz012zz.cluster.eee1.cache.bbbxxx.com","Port":6379,"AuthType":"auth-token",
"SslSecurityProtocol":"ssl-encryption", "AuthPassword":"notanactualpassword"}'
{
"Endpoint": {
"EndpointIdentifier": "my-redis-target",
"EndpointType": "TARGET",
"EngineName": "redis",
"EngineDisplayName": "Redis",
"TransferFiles": false,
"ReceiveTransferredFiles": false,
"Status": "active",
"KmsKeyId": "arn:aws:kms:us-east-1:999999999999:key/x-b188188x",
"EndpointArn": "arn:aws:dms:us-east-1:555555555555:endpoint:ABCDEFGHIJKLMONOPQRSTUVWXYZ",
"SslMode": "none",
"RedisSettings": {
"ServerName": "sample-test-sample.zz012zz.cluster.eee1.cache.bbbxxx.com",
"Port": 6379,
"SslSecurityProtocol": "ssl-encryption",
"AuthType": "auth-token"
}
}
}
```
`--redis-settings`Parameternya mengikuti:
+ `ServerName`— (Wajib) Jenis`string`, menentukan cluster Redis OSS tempat data akan dimigrasi, dan berada di VPC Anda yang sama.
+ `Port`— (Wajib) Dari jenis`number`, nilai port yang digunakan untuk mengakses titik akhir.
+ `SslSecurityProtocol`— (Opsional) Nilai yang valid termasuk `plaintext` dan`ssl-encryption`. Nilai default-nya `ssl-encryption`.
`plaintext`Opsi ini tidak menyediakan enkripsi Transport Layer Security (TLS) untuk lalu lintas antara endpoint dan database.
Gunakan `ssl-encryption` untuk membuat koneksi terenkripsi. `ssl-encryption`tidak memerlukan SSL Certificate Authority (CA) ARN untuk memverifikasi sertifikat server, tetapi dapat diidentifikasi secara opsional menggunakan pengaturan. `SslCaCertificateArn` Jika ARN otoritas sertifikat tidak diberikan, DMS menggunakan root CA Amazon.
Saat menggunakan target Redis OSS lokal, Anda dapat menggunakan `SslCaCertificateArn` untuk mengimpor Otoritas Sertifikat (CA) publik atau pribadi ke dalam DMS, dan menyediakan ARN tersebut untuk otentikasi server. CA pribadi tidak didukung saat menggunakan ElastiCache (Redis OSS) sebagai target.
+ `AuthType`— (Wajib) Menunjukkan jenis otentikasi yang harus dilakukan saat menghubungkan ke Redis OSS. Nilai yang valid termasuk `none`, `auth-token`, dan `auth-role`.
`auth-token`Opsi ini membutuhkan "*AuthPassword*" disediakan, sedangkan `auth-role` opsi membutuhkan "*AuthUserName*" dan "*AuthPassword*" disediakan.
# Menggunakan Babelfish sebagai target AWS Database Migration Service
Anda dapat memigrasikan data dari database sumber Microsoft SQL Server ke target Babelfish menggunakan. AWS Database Migration Service
Babelfish for Aurora PostgreSQL memperluas basis data Edisi yang Kompatibel dengan Amazon Aurora PostgreSQL Anda dengan kemampuan menerima koneksi basis data dari klien Server SQL Microsoft. Melakukan hal ini memungkinkan aplikasi awalnya dibangun untuk SQL Server untuk bekerja secara langsung dengan Aurora PostgreSQL dengan beberapa perubahan kode dibandingkan dengan migrasi tradisional, dan tanpa mengubah driver database.
Untuk informasi tentang versi Babelfish yang AWS DMS mendukung sebagai target, lihat. [Target untuk AWS DMS](CHAP_Introduction.Targets.md) Versi Babelfish sebelumnya di Aurora PostgreSQL memerlukan peningkatan sebelum menggunakan titik akhir Babelfish.
**catatan**
Titik akhir target PostgreSQL Aurora adalah cara yang lebih disukai untuk memigrasikan data ke Babelfish. Untuk informasi selengkapnya, lihat [Menggunakan Babelfish untuk Aurora PostgreSQL sebagai target](CHAP_Target.PostgreSQL.md#CHAP_Target.PostgreSQL.Babelfish).
*Untuk informasi tentang menggunakan Babelfish sebagai titik akhir database, lihat [Babelfish for Aurora PostgreSQL di Panduan Pengguna Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html) untuk Aurora*
## Prasyarat untuk menggunakan Babelfish sebagai target AWS DMS
Anda harus membuat tabel sebelum memigrasi data untuk memastikannya AWS DMS menggunakan tipe data dan metadata tabel yang benar. Jika Anda tidak membuat tabel pada target sebelum menjalankan migrasi, AWS DMS dapat membuat tabel dengan tipe data dan izin yang salah. Misalnya, AWS DMS membuat kolom stempel waktu sebagai biner (8) sebagai gantinya, dan tidak menyediakan fungsionalitas yang diharapkan timestamp/rowversion .
**Untuk mempersiapkan dan membuat tabel Anda sebelum migrasi**
1. Jalankan pernyataan DDL tabel buat Anda yang menyertakan batasan unik, kunci utama, atau batasan default.
Jangan menyertakan batasan kunci asing, atau pernyataan DDL apa pun untuk objek seperti tampilan, prosedur tersimpan, fungsi, atau pemicu. Anda dapat menerapkannya setelah memigrasi basis data sumber Anda.
1. Identifikasi kolom identitas, kolom yang dihitung, atau kolom yang berisi tipe data versi baris atau stempel waktu untuk tabel Anda. Kemudian, buat aturan transformasi yang diperlukan untuk menangani masalah yang diketahui saat menjalankan tugas migrasi. Untuk informasi selengkapnya, lihat [Aturan dan tindakan transformasi](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
1. Identifikasi kolom dengan tipe data yang tidak didukung Babelfish. Kemudian, ubah kolom yang terpengaruh dalam tabel target untuk menggunakan tipe data yang didukung, atau buat aturan transformasi yang menghapusnya selama tugas migrasi. Untuk informasi selengkapnya, lihat [Aturan dan tindakan transformasi](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
Tabel berikut mencantumkan tipe data sumber yang tidak didukung oleh Babelfish, dan jenis data target yang direkomendasikan untuk digunakan.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/CHAP_Target.Babelfish.html)
**Untuk mengatur tingkat unit kapasitas Aurora (ACUs) untuk basis data sumber Aurora PostgreSQL Serverless V2 Anda**
Anda dapat meningkatkan kinerja tugas AWS DMS migrasi Anda sebelum menjalankannya dengan menetapkan nilai ACU minimum.
+ Dari jendela **pengaturan kapasitas Severless v2**, atur **Minimum ACUs** ke**2**, atau level yang wajar untuk cluster Aurora DB Anda.
*Untuk informasi tambahan tentang pengaturan unit kapasitas Aurora, lihat [Memilih rentang kapasitas v2 Tanpa Server Aurora untuk klaster Aurora di Panduan Pengguna Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html)*
Setelah menjalankan tugas AWS DMS migrasi, Anda dapat mengatur ulang nilai minimum Anda ke tingkat yang wajar ACUs untuk basis data sumber Aurora PostgreSQL Serverless V2 Anda.
## Persyaratan keamanan saat menggunakan Babelfish sebagai target AWS Database Migration Service
Berikut ini menjelaskan persyaratan keamanan untuk menggunakan AWS DMS dengan target Babelfish:
+ Nama pengguna administrator (pengguna Admin) digunakan untuk membuat database.
+ Login PSQL dan pengguna dengan izin SELECT, INSERT, UPDATE, DELETE, dan REFERENCES yang memadai.
## Izin pengguna untuk menggunakan Babelfish sebagai target AWS DMS
**penting**
Untuk tujuan keamanan, akun pengguna yang digunakan untuk migrasi data harus merupakan pengguna terdaftar dalam database Babelfish yang Anda gunakan sebagai target.
Titik akhir target Babelfish Anda memerlukan izin pengguna minimum untuk menjalankan migrasi. AWS DMS
**Untuk membuat login dan pengguna Transact-SQL (T-SQL) dengan hak istimewa rendah**
1. Buat login dan kata sandi untuk digunakan saat menghubungkan ke server.
```
CREATE LOGIN dms_user WITH PASSWORD = 'password';
GO
```
1. Buat database virtual untuk cluster Babelfish Anda.
```
CREATE DATABASE my_database;
GO
```
1. Buat pengguna T-SQL untuk database target Anda.
```
USE my_database
GO
CREATE USER dms_user FOR LOGIN dms_user;
GO
```
1. Untuk setiap tabel dalam database Babelfish Anda, BERIKAN izin ke tabel.
```
GRANT SELECT, DELETE, INSERT, REFERENCES, UPDATE ON [dbo].[Categories] TO dms_user;
```
## Keterbatasan penggunaan Babelfish sebagai target AWS Database Migration Service
Batasan berikut berlaku saat menggunakan database Babelfish sebagai target untuk: AWS DMS
+ Hanya mode persiapan meja “**Do Nothing** “yang didukung.
+ Tipe data ROWVERSION memerlukan aturan pemetaan tabel yang menghapus nama kolom dari tabel selama tugas migrasi.
+ Jenis data sql\$1variant tidak didukung.
+ Mode LOB penuh didukung. Menggunakan SQL Server sebagai titik akhir sumber memerlukan pengaturan Atribut Koneksi Titik Akhir SQL Server `ForceFullLob=True` untuk disetel agar dapat dimigrasi LOBs ke titik akhir target.
+ Pengaturan tugas replikasi memiliki batasan berikut:
```
{
"FullLoadSettings": {
"TargetTablePrepMode": "DO_NOTHING",
"CreatePkAfterFullLoad": false,
}.
}
```
+ Tipe data TIME (7), DATETIME2 (7), dan DATETIMEOFFSET (7) di Babelfish membatasi nilai presisi untuk porsi detik waktu menjadi 6 digit. Pertimbangkan untuk menggunakan nilai presisi 6 untuk tabel target Anda saat menggunakan tipe data ini. Untuk Babelfish versi 2.2.0 dan lebih tinggi, saat menggunakan TIME (7) dan DATETIME2 (7), digit presisi ketujuh selalu nol.
+ Dalam mode DO\$1NOTHING, DMS memeriksa untuk melihat apakah tabel sudah ada. Jika tabel tidak ada dalam skema target, DMS membuat tabel berdasarkan definisi tabel sumber, dan memetakan setiap tipe data yang ditentukan pengguna ke tipe data dasarnya.
+ Tugas AWS DMS migrasi ke target Babelfish tidak mendukung tabel yang memiliki kolom menggunakan tipe data ROWVERSION atau TIMESTAMP. Anda dapat menggunakan aturan pemetaan tabel yang menghapus nama kolom dari tabel selama proses transfer. Dalam contoh aturan transformasi berikut, tabel bernama `Actor` di sumber Anda diubah untuk menghapus semua kolom yang dimulai dengan karakter `col` dari `Actor` tabel di target Anda.
```
{
"rules": [{
"rule-type": "selection",is
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "test",
"table-name": "%"
},
"rule-action": "include"
}, {
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-action": "remove-column",
"rule-target": "column",
"object-locator": {
"schema-name": "test",
"table-name": "Actor",
"column-name": "col%"
}
}]
}
```
+ Untuk tabel dengan identitas atau kolom terhitung, di mana tabel target menggunakan nama kasus campuran seperti Kategori, Anda harus membuat tindakan aturan transformasi yang mengubah nama tabel menjadi huruf kecil untuk tugas DMS Anda. Contoh berikut menunjukkan cara membuat tindakan aturan transformasi, **Buat huruf kecil** menggunakan konsol. AWS DMS Untuk informasi selengkapnya, lihat [Aturan dan tindakan transformasi](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
![\[Aturan transformasi babelfish\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/images/datarep-babelfish-transform-1.png)
+ Sebelum Babelfish versi 2.2.0, DMS membatasi jumlah kolom yang dapat Anda replikasi ke titik akhir target Babelfish menjadi dua puluh (20) kolom. Dengan Babelfish 2.2.0 batasnya meningkat menjadi 100 kolom. Tetapi dengan Babelfish versi 2.4.0 dan lebih tinggi, jumlah kolom yang dapat Anda tiru meningkat lagi. Anda dapat menjalankan contoh kode berikut terhadap database SQL Server Anda untuk menentukan tabel mana yang terlalu panjang.
```
USE myDB;
GO
DECLARE @Babelfish_version_string_limit INT = 8000; -- Use 380 for Babelfish versions before 2.2.0
WITH bfendpoint
AS (
SELECT
[TABLE_SCHEMA]
,[TABLE_NAME]
, COUNT( [COLUMN_NAME] ) AS NumberColumns
, ( SUM( LEN( [COLUMN_NAME] ) + 3)
+ SUM( LEN( FORMAT(ORDINAL_POSITION, 'N0') ) + 3 )
+ LEN( TABLE_SCHEMA ) + 3
+ 12 -- INSERT INTO string
+ 12) AS InsertIntoCommandLength -- values string
, CASE WHEN ( SUM( LEN( [COLUMN_NAME] ) + 3)
+ SUM( LEN( FORMAT(ORDINAL_POSITION, 'N0') ) + 3 )
+ LEN( TABLE_SCHEMA ) + 3
+ 12 -- INSERT INTO string
+ 12) -- values string
>= @Babelfish_version_string_limit
THEN 1
ELSE 0
END AS IsTooLong
FROM [INFORMATION_SCHEMA].[COLUMNS]
GROUP BY [TABLE_SCHEMA], [TABLE_NAME]
)
SELECT *
FROM bfendpoint
WHERE IsTooLong = 1
ORDER BY TABLE_SCHEMA, InsertIntoCommandLength DESC, TABLE_NAME
;
```
## Tipe data target untuk Babelfish
Tabel berikut menunjukkan tipe data target Babelfish yang didukung saat menggunakan AWS DMS dan pemetaan default dari AWS DMS tipe data.
Untuk informasi tambahan tentang tipe AWS DMS data, lihat[Tipe data untuk AWS Database Migration Service](CHAP_Reference.DataTypes.md).
| AWS DMS tipe data | Tipe data Babelfish |
| --- | --- |
| BOOLEAN | TINYINT |
| BYTES | VARBINARY(length) |
| DATE | DATE |
| TIME | TIME |
| INT1 | SMALLINT |
| INT2 | SMALLINT |
| INT4 | INT |
| INT8 | BIGINT |
| NUMERIC | NUMERIK (p, s) |
| REAL4 | REAL |
| REAL8 | FLOAT |
| STRING | Jika kolom berupa kolom tanggal atau waktu, lakukan hal berikut: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/CHAP_Target.Babelfish.html) Jika kolom bukan berupa kolom tanggal atau waktu, gunakan VARCHAR (length). |
| UINT1 | TINYINT |
| UINT2 | SMALLINT |
| UINT4 | INT |
| UINT8 | BIGINT |
| WSTRING | NVARCHAR (panjang) |
| BLOB | VARBINARY(max) Untuk menggunakan tipe data ini dengan DMS, Anda harus mengaktifkan penggunaan BLOBs untuk tugas tertentu. DMS mendukung tipe data BLOB hanya dalam tabel yang menyertakan kunci primer. |
| CLOB | VARCHAR(max) Untuk menggunakan tipe data ini dengan DMS, Anda harus mengaktifkan penggunaan CLOBs untuk tugas tertentu. |
| NCLOB | NVARCHAR(max) Untuk menggunakan tipe data ini dengan DMS, Anda harus mengaktifkan penggunaan NCLOBs untuk tugas tertentu. Selama CDC, DMS mendukung tipe data NCLOB hanya dalam tabel yang menyertakan kunci utama. |
# Menggunakan Amazon Timestream sebagai target untuk AWS Database Migration Service
Anda dapat menggunakan AWS Database Migration Service untuk memigrasikan data dari database sumber ke titik akhir target Amazon Timestream, dengan dukungan untuk migrasi data Beban Penuh dan CDC.
Amazon Timestream adalah layanan database deret waktu yang cepat, terukur, dan tanpa server yang dibuat untuk konsumsi data volume tinggi. Data deret waktu adalah urutan titik data yang dikumpulkan selama interval waktu, dan digunakan untuk mengukur peristiwa yang berubah seiring waktu. Ini digunakan untuk mengumpulkan, menyimpan, dan menganalisis metrik dari aplikasi IoT DevOps , aplikasi, dan aplikasi analitik. Setelah Anda memiliki data di Timestream, Anda dapat memvisualisasikan dan mengidentifikasi tren dan pola dalam data Anda dalam waktu dekat. Untuk informasi tentang Amazon Timestream, lihat [Apa itu Amazon Timestream?](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html) di Panduan *Pengembang Amazon Timestream*.
**Topics**
+ [Prasyarat untuk menggunakan Amazon Timestream sebagai target untuk AWS Database Migration Service](#CHAP_Target.Timestream.Prerequisites)
+ [Pengaturan tugas beban penuh multithread](#CHAP_Target.Timestream.FLTaskSettings)
+ [Pengaturan beban tugas CDC multithread](#CHAP_Target.Timestream.CDCTaskSettings)
+ [Pengaturan titik akhir saat menggunakan Timestream sebagai target untuk AWS DMS](#CHAP_Target.Timestream.ConnectionAttrib)
+ [Membuat dan memodifikasi titik akhir target Amazon Timestream](#CHAP_Target.Timestream.CreateModifyEndpoint)
+ [Menggunakan pemetaan objek untuk memigrasikan data ke topik Timestream](#CHAP_Target.Timestream.ObjectMapping)
+ [Batasan saat menggunakan Amazon Timestream sebagai target AWS Database Migration Service](#CHAP_Target.Timestream.Limitations)
## Prasyarat untuk menggunakan Amazon Timestream sebagai target untuk AWS Database Migration Service
Sebelum Anda mengatur Amazon Timestream sebagai target AWS DMS, pastikan Anda membuat peran IAM. Peran ini harus memungkinkan AWS DMS untuk mendapatkan akses ke data yang sedang dimigrasikan ke Amazon Timestream. Set minimum izin akses untuk peran yang Anda gunakan untuk bermigrasi ke Timestream ditampilkan dalam kebijakan IAM berikut.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowDescribeEndpoints",
"Effect": "Allow",
"Action": [
"timestream:DescribeEndpoints"
],
"Resource": "*"
},
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"timestream:ListTables",
"timestream:DescribeDatabase"
],
"Resource": "arn:aws:timestream:us-east-1:123456789012:database/DATABASE_NAME"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"timestream:DeleteTable",
"timestream:WriteRecords",
"timestream:UpdateTable",
"timestream:CreateTable"
],
"Resource": "arn:aws:timestream:us-east-1:123456789012:database/DATABASE_NAME/table/TABLE_NAME"
}
]
}
```
------
Jika Anda berniat untuk memigrasikan semua tabel, gunakan `*` for *TABLE\$1NAME* dalam contoh di atas.
Perhatikan hal berikut tentang penggunaan Timestream sebagai target:
+ Jika Anda bermaksud untuk menelan data historis dengan stempel waktu melebihi 1 tahun, sebaiknya gunakan untuk menulis data AWS DMS ke Amazon S3 dalam format nilai dipisahkan koma (csv). Kemudian, gunakan pemuatan batch Timestream untuk menyerap data ke Timestream. Untuk informasi selengkapnya, lihat [Menggunakan pemuatan batch di Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/batch-load.html) dalam panduan pengembang [Amazon Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html).
+ Untuk migrasi data beban penuh data yang berusia kurang dari 1 tahun, sebaiknya setel periode penyimpanan penyimpanan memori tabel Timestream lebih besar dari atau sama dengan stempel waktu tertua. Kemudian, setelah migrasi selesai, edit penyimpanan penyimpanan memori tabel ke nilai yang diinginkan. Misalnya, untuk memigrasikan data dengan stempel waktu tertua berusia 2 bulan, lakukan hal berikut:
+ Setel retensi penyimpanan memori tabel target Timestream menjadi 2 bulan.
+ Mulai migrasi data menggunakan AWS DMS.
+ Setelah migrasi data selesai, ubah periode retensi tabel Timestream target ke nilai yang Anda inginkan.
Kami merekomendasikan untuk memperkirakan biaya penyimpanan memori sebelum migrasi, menggunakan informasi pada halaman berikut:
+ [Harga Amazon Timestream](https://aws.amazon.com/timestream/pricing)
+ [AWS kalkulator harga](https://calculator.aws/#/addService)
+ Untuk migrasi data CDC, sebaiknya atur periode retensi penyimpanan memori dari tabel target sehingga data yang tertelan berada dalam batas retensi penyimpanan memori. Untuk informasi selengkapnya, lihat [Menulis Praktik Terbaik](https://docs.aws.amazon.com/timestream/latest/developerguide/data-ingest.html) di panduan [pengembang Amazon Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html).
## Pengaturan tugas beban penuh multithread
Untuk membantu meningkatkan kecepatan transfer data, AWS DMS mendukung tugas migrasi beban penuh multithreaded ke titik akhir target Timestream dengan pengaturan tugas ini:
+ `MaxFullLoadSubTasks` - Gunakan pilihan ini untuk menunjukkan jumlah maksimum tabel sumber yang dimuat secara paralel. DMS memuat setiap tabel ke dalam tabel target Amazon Timestream yang sesuai menggunakan subtugas khusus. Default adalah 8; nilai maksimum adalah 49.
+ `ParallelLoadThreads`— Gunakan opsi ini untuk menentukan jumlah utas yang AWS DMS digunakan untuk memuat setiap tabel ke dalam tabel target Amazon Timestream. Nilai maksimum untuk target Timestream adalah 32. Anda dapat meminta untuk meningkatkan batas maksimum ini.
+ `ParallelLoadBufferSize`— Gunakan opsi ini untuk menentukan jumlah maksimum catatan yang akan disimpan dalam buffer yang digunakan thread beban paralel untuk memuat data ke target Amazon Timestream. Nilai default adalah 50. Nilai maksimumnya adalah 1.000. Gunakan pengaturan ini dengan `ParallelLoadThreads`. `ParallelLoadBufferSize` hanya berlaku bila ada lebih dari satu thread.
+ `ParallelLoadQueuesPerThread` - Gunakan pilihan ini untuk menentukan jumlah antrean yang diakses setiap thread secara bersamaan untuk mengambil catatan data dari antrean dan menghasilkan beban batch untuk target. Default adalah 1. Namun, untuk target Amazon Timestream dengan berbagai ukuran muatan, rentang yang valid adalah 5—512 antrian per utas.
## Pengaturan beban tugas CDC multithread
Untuk mempromosikan kinerja CDC, AWS DMS mendukung pengaturan tugas ini:
+ `ParallelApplyThreads`— Menentukan jumlah thread bersamaan yang AWS DMS digunakan selama beban CDC untuk mendorong catatan data ke titik akhir target Timestream. Nilai default adalah 0 dan nilai maksimum adalah 32.
+ `ParallelApplyBufferSize`— Menentukan jumlah maksimum catatan untuk disimpan di setiap antrian buffer untuk thread bersamaan untuk mendorong ke titik akhir target Timestream selama beban CDC. Nilai default adalah 100 dan nilai maksimum adalah 1.000. Gunakan pilihan ini saat `ParallelApplyThreads` menentukan lebih dari satu thread.
+ `ParallelApplyQueuesPerThread`— Menentukan jumlah antrian yang diakses setiap thread untuk mengeluarkan catatan data dari antrian dan menghasilkan beban batch untuk titik akhir Timestream selama CDC. Nilai default adalah 1 dan nilai maksimum adalah 512.
## Pengaturan titik akhir saat menggunakan Timestream sebagai target untuk AWS DMS
Anda dapat menggunakan pengaturan titik akhir untuk mengonfigurasi database target Timestream Anda mirip dengan menggunakan atribut koneksi tambahan. Anda menentukan pengaturan saat Anda membuat titik akhir target menggunakan AWS DMS konsol, atau dengan menggunakan `create-endpoint` perintah di [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), dengan sintaks `--timestream-settings '{"EndpointSetting": "value", ...}'` JSON.
Tabel berikut menunjukkan pengaturan endpoint yang dapat Anda gunakan dengan Timestream sebagai target.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/dms/latest/userguide/CHAP_Target.Timestream.html)
## Membuat dan memodifikasi titik akhir target Amazon Timestream
Setelah Anda membuat peran IAM dan menetapkan set minimum izin akses, Anda dapat membuat titik akhir target Amazon Timestream menggunakan konsol, atau dengan menggunakan AWS DMS perintah di, dengan `create-endpoint` sintaks [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html)JSON. `--timestream-settings '{"EndpointSetting": "value", ...}'`
Contoh berikut menunjukkan cara membuat dan memodifikasi titik akhir target Timestream menggunakan. AWS CLI
**Buat perintah titik akhir target Timestream**
```
aws dms create-endpoint —endpoint-identifier timestream-target-demo
--endpoint-type target —engine-name timestream
--service-access-role-arn arn:aws:iam::123456789012:role/my-role
--timestream-settings
{
"MemoryDuration": 20,
"DatabaseName":"db_name",
"MagneticDuration": 3,
"CdcInsertsAndUpdates": true,
"EnableMagneticStoreWrites": true,
}
```
**Ubah perintah titik akhir target Timestream**
```
aws dms modify-endpoint —endpoint-identifier timestream-target-demo
--endpoint-type target —engine-name timestream
--service-access-role-arn arn:aws:iam::123456789012:role/my-role
--timestream-settings
{
"MemoryDuration": 20,
"MagneticDuration": 3,
}
```
## Menggunakan pemetaan objek untuk memigrasikan data ke topik Timestream
AWS DMS menggunakan aturan pemetaan tabel untuk memetakan data dari sumber ke topik Timestream target. Untuk memetakan data ke topik target, Anda menggunakan jenis aturan pemetaan tabel yang disebut pemetaan objek. Anda menggunakan pemetaan objek untuk menentukan bagaimana catatan data dalam peta sumber ke catatan data yang dipublikasikan ke topik Timestream.
Topik Timestream tidak memiliki struktur preset selain memiliki kunci partisi.
**catatan**
Anda tidak perlu menggunakan pemetaan objek. Anda dapat menggunakan pemetaan tabel biasa untuk berbagai transformasi. Namun, jenis kunci partisi akan mengikuti perilaku default ini:
Primary Key digunakan sebagai kunci partisi untuk Full Load.
Jika tidak ada pengaturan tugas penerapan paralel yang digunakan, `schema.table` digunakan sebagai kunci partisi untuk CDC.
Jika pengaturan tugas penerapan paralel digunakan, kunci utama digunakan sebagai kunci partisi untuk CDC.
Untuk membuat aturan pemetaan objek, tetapkan `rule-type` sebagai `object-mapping`. Aturan ini menentukan jenis pemetaan objek yang ingin Anda gunakan. Struktur untuk aturan tersebut adalah sebagai berikut.
```
{
"rules": [
{
"rule-type": "object-mapping",
"rule-id": "id",
"rule-name": "name",
"rule-action": "valid object-mapping rule action",
"object-locator": {
"schema-name": "case-sensitive schema name",
"table-name": ""
}
}
]
}
```
```
{
"rules": [
{
"rule-type": "object-mapping",
"rule-id": "1",
"rule-name": "timestream-map",
"rule-action": "map-record-to-record",
"target-table-name": "tablename",
"object-locator": {
"schema-name": "",
"table-name": ""
},
"mapping-parameters": {
"timestream-dimensions": [
"column_name1",
"column_name2"
],
"timestream-timestamp-name": "time_column_name",
"timestream-multi-measure-name": "column_name1or2",
"timestream-hash-measure-name": true or false,
"timestream-memory-duration": x,
"timestream-magnetic-duration": y
}
}
]
}
```
AWS DMS saat ini mendukung `map-record-to-record` dan `map-record-to-document` sebagai satu-satunya nilai yang valid untuk `rule-action` parameter. `map-record-to-document`Nilai `map-record-to-record` dan menentukan AWS DMS apa yang dilakukan secara default ke catatan yang tidak dikecualikan sebagai bagian dari daftar `exclude-columns` atribut. Nilai-nilai ini tidak mempengaruhi pemetaan atribut dengan cara apapun.
Gunakan `map-record-to-record` saat bermigrasi dari database relasional ke topik Timestream. Jenis aturan ini menggunakan `taskResourceId.schemaName.tableName` nilai dari database relasional sebagai kunci partisi dalam topik Timestream dan menciptakan atribut untuk setiap kolom dalam database sumber. Saat menggunakan`map-record-to-record`, untuk kolom apa pun di tabel sumber yang tidak tercantum dalam daftar `exclude-columns` atribut, AWS DMS buat atribut yang sesuai dalam topik target. Atribut yang sesuai ini dibuat terlepas dari apakah kolom sumber tersebut digunakan dalam pemetaan atribut.
Salah satu cara untuk memahami `map-record-to-record` adalah melihatnya beraksi. Untuk contoh ini, anggaplah bahwa Anda memulai dengan baris tabel basis data relasional dengan struktur dan data berikut.
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateofBirth |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
Untuk memigrasikan informasi ini dari skema bernama `Test` ke topik Timestream, Anda membuat aturan untuk memetakan data ke topik target. Aturan berikut menggambarkan pemetaan.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"rule-action": "include",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
}
},
{
"rule-type": "object-mapping",
"rule-id": "2",
"rule-name": "DefaultMapToTimestream",
"rule-action": "map-record-to-record",
"object-locator": {
"schema-name": "Test",
"table-name": "Customers"
}
}
]
}
```
Diberikan topik Timestream dan kunci partisi (dalam hal ini,`taskResourceId.schemaName.tableName`), berikut ini menggambarkan format rekaman yang dihasilkan menggunakan data sampel kami dalam topik target Timestream:
```
{
"FirstName": "Randy",
"LastName": "Marsh",
"StoreId": "5",
"HomeAddress": "221B Baker Street",
"HomePhone": "1234567890",
"WorkAddress": "31 Spooner Street, Quahog",
"WorkPhone": "9876543210",
"DateOfBirth": "02/29/1988"
}
```
## Batasan saat menggunakan Amazon Timestream sebagai target AWS Database Migration Service
Batasan berikut berlaku saat menggunakan Amazon Timestream sebagai target:
+ **Dimensi dan Stempel Waktu:** Timestream menggunakan dimensi dan stempel waktu dalam data sumber seperti kunci primer komposit, dan juga tidak memungkinkan Anda untuk meningkatkan nilai-nilai ini. Ini berarti bahwa jika Anda mengubah stempel waktu atau dimensi untuk catatan dalam database sumber, database Timestream akan mencoba membuat catatan baru. Dengan demikian mungkin bahwa jika Anda mengubah dimensi atau stempel waktu rekaman sedemikian rupa sehingga cocok dengan catatan lain yang ada, maka AWS DMS perbarui nilai catatan lain alih-alih membuat catatan baru atau memperbarui catatan terkait sebelumnya.
+ **Perintah DDL:** Rilis saat ini AWS DMS hanya mendukung `CREATE TABLE` dan perintah `DROP TABLE` DDL.
+ **Batasan Rekam:** Timestream memiliki batasan untuk catatan seperti ukuran rekaman dan ukuran ukuran. Untuk informasi selengkapnya, lihat [Kuota](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html) di [Panduan Developer Amazon Timestream](https://docs.aws.amazon.com/).
+ **Menghapus Catatan dan Nilai Null:** Timestream tidak mendukung penghapusan catatan. Untuk mendukung migrasi catatan yang dihapus dari sumber, AWS DMS menghapus bidang terkait dalam catatan dalam database target Timestream. AWS DMS mengubah nilai di bidang catatan target yang sesuai dengan **0** untuk bidang numerik, **null** untuk bidang teks, dan **false** untuk bidang boolean.
+ Timestream sebagai target tidak mendukung sumber yang bukan database relasional (RDBMS).
+ AWS DMS hanya mendukung Timestream sebagai target di wilayah berikut:
+ Timur AS (N. Virginia)
+ AS Timur (Ohio)
+ AS Barat (Oregon)
+ Europe (Ireland)
+ Europe (Frankfurt)
+ Asia Pasifik (Sydney)
+ Asia Pasifik (Tokyo)
+ Timestream sebagai target tidak mendukung pengaturan `TargetTablePrepMode` ke`TRUNCATE_BEFORE_LOAD`. Kami merekomendasikan penggunaan `DROP_AND_CREATE` untuk pengaturan ini.
# Menggunakan Amazon RDS untuk Db2 dan IBM Db2 LUW sebagai target AWS DMS
Anda dapat memigrasikan data ke Amazon RDS untuk Db2 atau database Db2 lokal dari database Db2 LUW menggunakan (). AWS Database Migration Service AWS DMS
Untuk informasi tentang versi Db2 LUW yang AWS DMS mendukung sebagai target, lihat. [Target untuk AWS DMS](CHAP_Introduction.Targets.md)
Anda dapat menggunakan Lapisan Soket Aman (SSL) untuk mengenkripsi sambungan antara titik akhir Db2 LUW dan instans replikasi. Untuk informasi selengkapnya tentang penggunaan SSL dengan titik akhir Db2 LUW, lihat. [Menggunakan SSL dengan AWS Database Migration Service](CHAP_Security.SSL.md)
## Keterbatasan saat menggunakan Db2 LUW sebagai target AWS DMS
Keterbatasan berikut berlaku saat menggunakan database Db2 LUW sebagai target untuk. AWS DMS Untuk batasan penggunaan Db2 LUW sebagai sumber, lihat. [Keterbatasan saat menggunakan Db2 LUW sebagai sumber untuk AWS DMS](CHAP_Source.DB2.md#CHAP_Source.DB2.Limitations)
+ AWS DMS hanya mendukung Db2 LUW sebagai target ketika sumbernya adalah Db2 LUW atau Db2 untuk z/OS.
+ Menggunakan Db2 LUW sebagai target tidak mendukung replikasi dengan mode LOB penuh.
+ Menggunakan Db2 LUW sebagai target tidak mendukung tipe data XMLdalam fase beban penuh. Ini adalah batasan utilitas IBM dbload. Untuk informasi selengkapnya, lihat [Utilitas dbload dalam dokumentasi](https://www.ibm.com/docs/en/informix-servers/14.10?topic=utilities-dbload-utility) *IBM Informix* Servers.
+ AWS DMS memotong bidang BLOB dengan nilai yang sesuai dengan karakter kutipan ganda (“). Ini adalah batasan utilitas IBM dbload.
+ AWS DMS tidak mendukung opsi beban penuh paralel saat bermigrasi ke target Db2 LUW di DMS versi 3.5.3. Opsi ini tersedia dari DMS versi 3.5.4 atau yang lebih baru.
## Pengaturan titik akhir saat menggunakan Db2 LUW sebagai target AWS DMS
Anda dapat menggunakan pengaturan titik akhir untuk mengonfigurasi basis data target Db2 LUW Anda mirip dengan menggunakan atribut koneksi tambahan. Anda menentukan pengaturan saat Anda membuat titik akhir target menggunakan AWS DMS konsol, atau dengan menggunakan `create-endpoint` perintah di [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), dengan sintaks `--ibm-db2-settings '{"EndpointSetting": "value", ...}'` JSON.
Tabel berikut menunjukkan pengaturan endpoint yang dapat Anda gunakan dengan Db2 LUW sebagai target.
| Nama | Deskripsi |
| --- | --- |
| `KeepCsvFiles` | Jika benar, AWS DMS menyimpan file.csv apa pun ke target Db2 LUW yang digunakan untuk mereplikasi data. DMS menggunakan file-file ini untuk analisis dan pemecahan masalah.. |
| `LoadTimeout` | Jumlah waktu (dalam milidetik) sebelum AWS DMS waktu habis operasi yang dilakukan oleh DMS pada target Db2. Nilai defaultnya adalah 1200 (20 menit). |
| `MaxFileSize` | Menentukan ukuran maksimum (dalam KB) dari file.csv yang digunakan untuk mentransfer data ke Db2 LUW. |
| `WriteBufferSize` | Ukuran (dalam KB) buffer tulis file dalam memori yang digunakan saat membuat file.csv pada disk lokal pada instance replikasi DMS. Nilai defaultnya adalah 1024 (1 MB). |