Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Amazon DynamoDB Transactions: Cara kerjanya
Dengan transaksi Amazon DynamoDB, Anda dapat mengelompokkan beberapa tindakan bersama-sama dan mengirimkannya sebagai satu atau all-or-nothing `TransactWriteItems` operasi. `TransactGetItems` Bagian berikut menjelaskan operasi API, manajemen kapasitas, praktik terbaik, dan detail lainnya tentang menggunakan operasi transaksional di DynamoDB.
**Topics**
+ [TransactWriteItems API](#transaction-apis-txwriteitems)
+ [TransactGetItems API](#transaction-apis-txgetitems)
+ [Tingkat isolasi untuk DynamoDB transactions](#transaction-isolation)
+ [Penanganan konflik transaksi di DynamoDB](#transaction-conflict-handling)
+ [Menggunakan transaksional di APIs DynamoDB Accelerator (DAX)](#transaction-apis-dax)
+ [Manajemen kapasitas untuk transaksi](#transaction-capacity-handling)
+ [Praktik terbaik untuk transactions](#transaction-best-practices)
+ [Menggunakan transaksional APIs dengan tabel global](#transaction-integration)
+ [Transaksi DynamoDB AWSLabs vs. perpustakaan klien transaksi](#transaction-vs-library)
## TransactWriteItems API
`TransactWriteItems`adalah operasi penulisan sinkron dan idempoten yang mengelompokkan hingga 100 tindakan penulisan dalam satu operasi. all-or-nothing Tindakan ini dapat menargetkan hingga 100 item berbeda dalam satu atau lebih tabel DynamoDB dalam akun AWS yang sama dan di Wilayah yang sama. Ukuran agregat item dalam transaksi tidak dapat melebihi 4 MB. Tindakan tersebut diselesaikan secara atomik, sehingga semuanya berhasil atau tidak satu pun yang berhasil.
**catatan**
Operasi `TransactWriteItems` berbeda dari operasi `BatchWriteItem` dalam hal semua tindakan yang di dalamnya harus berhasil diselesaikan, atau tidak ada perubahan yang dibuat sama sekali. Dengan operasi `BatchWriteItem`, mungkin bahwa hanya beberapa tindakan dalam batch yang berhasil sementara yang lain tidak.
Transaksi tidak dapat dilakukan dengan menggunakan indeks.
Anda tidak dapat menargetkan item yang sama dengan beberapa operasi dalam transaksi yang sama. Misalnya, Anda tidak dapat melakukan `ConditionCheck` dan juga tindakan `Update` pada item yang sama dalam transaksi yang sama.
Anda dapat menambahkan jenis tindakan berikut pada transaksi:
+ `Put` — Memulai operasi `PutItem` untuk membuat item baru atau mengganti item lama dengan item baru, kondisional atau tanpa menentukan syarat apa pun.
+ `Update` — Memulai operasi `UpdateItem` untuk mengedit atribut item yang ada atau menambahkan item baru ke tabel jika belum ada. Gunakan tindakan ini untuk menambah, menghapus, atau memperbarui atribut pada item yang ada secara dengan syarat maupun tanpa syarat.
+ `Delete` — Memulai operasi `DeleteItem` untuk menghapus satu item dalam tabel yang diidentifikasi oleh kunci primernya.
+ `ConditionCheck` — Memeriksa bahwa item ada atau periksa kondisi atribut tertentu dari item.
Ketika transaksi selesai di DynamoDB, perubahannya mulai menyebar ke indeks sekunder global GSIs (), aliran, dan cadangan. Propagasi ini terjadi secara bertahap: catatan aliran dari transaksi yang sama mungkin muncul pada waktu yang berbeda dan dapat disisipkan dengan catatan dari transaksi lain. Konsumen streaming tidak boleh menganggap atomisitas transaksi atau jaminan pemesanan.
Untuk memastikan snapshot atom dari item yang dimodifikasi dalam transaksi, gunakan TransactGetItems operasi untuk membaca semua item yang relevan bersama-sama. Operasi ini memberikan tampilan data yang konsisten, memastikan Anda melihat semua perubahan dari transaksi yang diselesaikan atau tidak sama sekali.
Karena propagasi tidak langsung, jika tabel dipulihkan dari backup ([RestoreTableFromBackup](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_RestoreTableFromBackup.html)) atau diekspor ke titik waktu ([ExportTableToPointInTime](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ExportTableToPointInTime.html)) pertengahan propagasi, itu hanya dapat berisi beberapa perubahan yang dibuat selama transaksi baru-baru ini.
### Idempotensi
Anda dapat menyertakan token klien ketika Anda membuat panggilan `TransactWriteItems` untuk memastikan bahwa permintaan tersebut *idempoten*. Menjadikan transaksi Anda idempoten membantu mencegah kesalahan aplikasi jika operasi yang sama diajukan beberapa kali karena waktu habis koneksi atau masalah konektivitas lainnya.
Jika panggilan `TransactWriteItems` asli berhasil, panggilan `TransactWriteItems` berikutnya dengan token klien yang sama berhasil kembali tanpa membuat perubahan apa pun. Jika parameter `ReturnConsumedCapacity` diatur, panggilan `TransactWriteItems` awal mengembalikan jumlah unit kapasitas tulis yang dikonsumsi dalam membuat perubahan. Panggilan `TransactWriteItems` selanjutnya dengan token klien yang sama mengembalikan jumlah unit kapasitas baca yang dikonsumsi dalam membaca item.
**Poin penting tentang idempotensi**
+ Token klien berlaku selama 10 menit setelah permintaan yang menggunakannya selesai. Setelah 10 menit, setiap permintaan yang menggunakan token klien yang sama diperlakukan sebagai permintaan baru. Anda tidak boleh menggunakan kembali token klien yang sama untuk permintaan yang sama setelah 10 menit.
+ Jika Anda mengulangi permintaan dengan token klien yang sama dalam jendela idempotensi 10 menit tetapi mengubah beberapa parameter permintaan lainnya, DynamoDB mengembalikan pengecualian `IdempotentParameterMismatch`.
### Penanganan kesalahan untuk penulisan
Transaksi tulis tidak berhasil dalam situasi berikut:
+ Ketika syarat di salah satu ekspresisyarat tidak terpenuhi.
+ Ketika kesalahan validasi transaksi terjadi karena lebih dari satu tindakan dalam operasi `TransactWriteItems` yang sama menargetkan item yang sama.
+ Saat permintaan `TransactWriteItems` bertentangan dengan operasi `TransactWriteItems` yang sedang berlangsung pada satu atau lebih item dalam permintaan `TransactWriteItems`. Dalam kasus ini, permintaan gagal dengan `TransactionCanceledException`.
+ Ketika ada kapasitas yang ditetapkan tidak mencukupi untuk penyelesaian transaksi.
+ Ketika ukuran item menjadi terlalu besar (lebih besar dari 400 KB), atau indeks sekunder lokal (LSI) menjadi terlalu besar, atau kesalahan validasi serupa terjadi karena perubahan yang dilakukan oleh transaksi.
+ Ketika ada kesalahan pengguna, seperti format data yang tidak valid.
Untuk informasi selengkapnya tentang bagaimana pertentangan dengan operasi `TransactWriteItems` ditangani, lihat [Penanganan konflik transaksi di DynamoDB](#transaction-conflict-handling).
## TransactGetItems API
`TransactGetItems` adalah operasi baca sinkron yang mengelompokkan hingga 100 tindakan `Get` menjadi satu. Tindakan ini dapat menargetkan hingga 100 item berbeda dalam satu atau lebih tabel DynamoDB dalam akun dan Wilayah yang AWS sama. Ukuran agregat item dalam transaksi tidak dapat melebihi 4 MB.
Tindakan `Get` dilakukan secara atom sehingga semuanya berhasil atau semuanya gagal:
+ `Get` — Memulai operasi `GetItem` untuk mengambil satu set atribut untuk item dengan kunci primer yang diberikan. Jika tidak ditemukan item yang cocok, `Get` tidak mengembalikan data apa pun.
### Penanganan kesalahan untuk pembacaan
Transaksi baca tidak berhasil dalam situasi berikut:
+ Saat permintaan `TransactGetItems` bertentangan dengan operasi `TransactWriteItems` yang sedang berlangsung pada satu atau lebih item dalam permintaan `TransactGetItems`. Dalam kasus ini, permintaan gagal dengan `TransactionCanceledException`.
+ Ketika ada kapasitas yang ditetapkan tidak mencukupi untuk penyelesaian transaksi.
+ Ketika ada kesalahan pengguna, seperti format data yang tidak valid.
Untuk informasi selengkapnya tentang bagaimana pertentangan dengan operasi `TransactGetItems` ditangani, lihat [Penanganan konflik transaksi di DynamoDB](#transaction-conflict-handling).
## Tingkat isolasi untuk DynamoDB transactions
Tingkat isolasi operasi transaksional (`TransactWriteItems` atau `TransactGetItems`) dan operasi lainnya adalah sebagai berikut.
### DAPAT DISERIALKAN
Isolasi yang *dapat diserialkan* memastikan bahwa hasil dari beberapa operasi bersamaan sama seperti jika tidak ada operasi dimulai hingga operasi sebelumnya telah selesai.
Ada isolasi serialisasi antara jenis operasi berikut:
+ Antara operasi transaksional dan operasi tulis standar (`PutItem`, `UpdateItem`, atau `DeleteItem`).
+ Antara operasi transaksional dan operasi baca standar (`GetItem`).
+ Antara operasi `TransactWriteItems` dan operasi `TransactGetItems`.
Meskipun ada isolasi serialisasi antara operasi transaksional, dan setiap standar individu menulis dalam suatu `BatchWriteItem` operasi, tidak ada isolasi serial antara transaksi dan operasi sebagai satu unit. `BatchWriteItem`
Demikian pula, tingkat isolasi antara operasi transaksional dan individu `GetItems` dalam operasi `BatchGetItem` dapat diserialisasikan. Tetapi tahap isolasi antara transaksi dan operasi `BatchGetItem` sebagai unit adalah *read-committed*.
Permintaan `GetItem` tunggal dapat diserialisasikan sehubungan dengan permintaan `TransactWriteItems` dalam salah satu dari dua cara, baik sebelum atau setelah permintaan `TransactWriteItems`. Beberapa permintaan `GetItem`, terhadap kunci dalam permintaan `TransactWriteItems` bersamaan dapat dijalankan dalam urutan apa pun, dan karena itu hasilnya *read-committed*.
Misalnya, jika permintaan `GetItem` untuk item A dan item B dijalankan bersamaan dengan permintaan `TransactWriteItems` yang memodifikasi item A dan item B, ada empat kemungkinan:
+ Kedua permintaan `GetItem` dijalankan sebelum permintaan `TransactWriteItems`.
+ Kedua permintaan `GetItem` dijalankan setelah permintaan `TransactWriteItems`.
+ Permintaan `GetItem` untuk item A dijalankan sebelum permintaan `TransactWriteItems`. Untuk item B, `GetItem` dijalankan setelah `TransactWriteItems`.
+ Permintaan `GetItem` untuk item B dijalankan sebelum permintaan `TransactWriteItems`. Untuk item A, `GetItem` dijalankan setelah `TransactWriteItems`.
Anda harus menggunakan `TransactGetItems` jika Anda lebih suka tingkat isolasi serializable untuk beberapa permintaan. `GetItem`
Jika pembacaan non-transaksional dilakukan pada beberapa item yang merupakan bagian dari permintaan penulisan transaksi yang sama dalam penerbangan, Anda mungkin dapat membaca status baru dari beberapa item dan status lama item lainnya. Anda akan dapat membaca status baru dari semua item yang merupakan bagian dari permintaan tulis transaksi hanya ketika respons berhasil diterima untuk penulisan transaksional, yang menunjukkan bahwa transaksi telah selesai.
Setelah transaksi berhasil diselesaikan dan respons diterima, operasi baca yang *konsisten* selanjutnya mungkin masih mengembalikan status lama untuk waktu yang singkat karena model konsistensi DynamoDB akhirnya. Untuk menjamin membaca sebagian besar up-to-date data segera setelah transaksi, Anda harus menggunakan pembacaan yang [*sangat konsisten*](HowItWorks.ReadConsistency.md#HowItWorks.ReadConsistency.Strongly) dengan menyetel `ConsistentRead` ke true.
### READ-COMMITTED
Isolasi *read-commit* memastikan bahwa operasi baca selalu mengembalikan komitmen untuk suatu item - pembacaan tidak akan pernah menampilkan tampilan ke item yang mewakili keadaan dari penulisan transaksional yang pada akhirnya tidak berhasil. Isolasi komitmen baca tidak mencegah modifikasi item segera setelah operasi baca.
Tingkat isolasi read-committed antara operasi transaksional dan operasi baca yang melibatkan beberapa baca standar (`BatchGetItem`, `Query`, atau `Scan`). Jika transaksional tulis memperbarui item di tengah operasi `BatchGetItem`, `Query`, atau `Scan`, bagian selanjutnya dari operasi baca mengembalikan nilai berkomitmen baru (dengan `ConsistentRead)` atau mungkin nilai berkomitmen sebelumnya (bacaan akhir konsisten).
### Ringkasan operasi
Untuk meringkas, tabel berikut menunjukkan tingkat isolasi antara operasi transaksi (`TransactWriteItems` atau `TransactGetItems`) dan operasi lainnya.
| Operasi | Tingkat Isolasi |
| --- | --- |
| `DeleteItem` | *Dapat diserialkan* |
| `PutItem` | *Dapat diserialkan* |
| `UpdateItem` | *Dapat diserialkan* |
| `GetItem` | *Dapat diserialkan* |
| `BatchGetItem` | *Read-committed*\* |
| `BatchWriteItem` | *Tidak Dapat Diserialkan*\* |
| `Query` | *Read-committed* |
| `Scan` | *Read-committed* |
| Operasi transaksional lainnya | *Dapat diserialkan* |
Tingkat yang ditandai dengan tanda bintang (\*) berlaku untuk operasi sebagai sebuah unit. Namun, tindakan individu dalam operasi tersebut memiliki tingkat isolasi yang *dapat diserialkan*.
## Penanganan konflik transaksi di DynamoDB
Konflik transaksional dapat terjadi selama permintaan tingkat item bersamaan pada item dalam transaksi. Konflik transaksi dapat terjadi dalam skenario berikut:
+ Permintaan `PutItem`, `UpdateItem`, atau `DeleteItem` untuk item yang bertentangan dengan permintaan `TransactWriteItems` yang sedang berlangsung yang mencakup item yang sama.
+ Item dalam permintaan `TransactWriteItems` adalah bagian dari permintaan `TransactWriteItems` lain yang sedang berlangsung.
+ Item dalam permintaan `TransactGetItems` adalah bagian dari permintaan `TransactWriteItems`, `BatchWriteItem`, `PutItem`, `UpdateItem`, atau `DeleteItem` yang sedang berlangsung.
**catatan**
Saat permintaan `PutItem`, `UpdateItem`, atau `DeleteItem` ditolak, permintaan gagal dengan `TransactionConflictException`.
Jika ada permintaan tingkat item dalam `TransactWriteItems` atau `TransactGetItems` ditolak, permintaan gagal dengan `TransactionCanceledException`. Jika permintaan itu gagal, AWS SDKs jangan coba lagi permintaan tersebut.
Jika Anda menggunakan AWS SDK untuk Java, pengecualian berisi daftar [CancellationReasons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_CancellationReason.html), diurutkan sesuai dengan daftar item dalam parameter `TransactItems` permintaan. Untuk bahasa lain, representasi string daftar disertakan dalam pesan kesalahan pengecualian.
Jika operasi `TransactWriteItems` atau `TransactGetItems` yang sedang berlangsung bertentangan dengan permintaan `GetItem` bersamaan, kedua operasi dapat berhasil.
[TransactionConflict CloudWatch Metrik](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html) ditambahkan untuk setiap permintaan tingkat item yang gagal.
## Menggunakan transaksional di APIs DynamoDB Accelerator (DAX)
`TransactWriteItems` dan `TransactGetItems` keduanya didukung di DynamoDB Accelerator (DAX) dengan tingkat isolasi yang sama seperti di DynamoDB.
`TransactWriteItems` menulis melalui DAX. DAX menyampaikan panggilan `TransactWriteItems` ke DynamoDB dan mengembalikan respons. Untuk mempopulasi cache setelah menulis, DAX memanggil `TransactGetItems` di latar belakang untuk setiap item dalam operasi `TransactWriteItems`, yang mengonsumsi unit kapasitas baca tambahan. (Untuk informasi selengkapnya, lihat [Manajemen kapasitas untuk transaksi](#transaction-capacity-handling).) Fungsionalitas ini memungkinkan Anda untuk menjaga logika aplikasi Anda sederhana dan menggunakan DAX untuk kedua operasi transaksional dan nontransaksional.
Panggilan `TransactGetItems` disampaikan melalui DAX tanpa item di-cache secara lokal. Ini adalah perilaku yang sama dengan pembacaan yang sangat konsisten APIs di DAX.
## Manajemen kapasitas untuk transaksi
Tidak ada biaya tambahan untuk mengaktifkan transaksi untuk tabel DynamoDB Anda. Anda hanya membayar untuk baca atau tulis yang merupakan bagian dari transaksi Anda. DynamoDB melakukan dua baca atau tulis mendasar dari setiap item dalam transaksi: satu untuk mempersiapkan transaksi dan satu untuk melakukan transaksi. Dua read/write operasi yang mendasarinya terlihat di CloudWatch metrik Amazon Anda.
Rencanakan untuk membaca dan menulis tambahan yang diperlukan oleh transaksional APIs ketika Anda menyediakan kapasitas ke tabel Anda. Misalnya, anggaplah aplikasi Anda menjalankan satu transaksi per detik, dan setiap transaksi menulis tiga item 500-byte dalam tabel Anda. Setiap item membutuhkan dua unit kapasitas tulis (WCUs): satu untuk mempersiapkan transaksi dan satu untuk melakukan transaksi. Oleh karena itu, Anda perlu menyediakan enam WCUs ke meja.
Jika Anda menggunakan DynamoDB Accelerator (DAX) pada contoh sebelumnya, Anda juga akan menggunakan dua unit kapasitas baca RCUs () untuk setiap item dalam panggilan. `TransactWriteItems` Jadi, Anda perlu memberikan enam tambahan RCUs ke tabel.
Demikian pula, jika aplikasi Anda menjalankan satu transaksi baca per detik, dan setiap transaksi membaca tiga item 500 byte dalam tabel Anda, Anda perlu menyediakan enam unit kapasitas baca (RCUs) ke tabel. Membaca setiap item membutuhkan dua RCUs: satu untuk mempersiapkan transaksi dan satu untuk melakukan transaksi.
Selain itu, perilaku SDK default adalah untuk mencoba lagi transaksi dalam kasus pengecualian `TransactionInProgressException`. Rencanakan unit kapasitas baca tambahan (RCUs) yang dikonsumsi oleh percobaan ulang ini. Hal yang sama juga berlaku jika Anda mencoba ulang transaksi dalam kode Anda sendiri menggunakan `ClientRequestToken`.
## Praktik terbaik untuk transactions
Pertimbangkan praktik yang disarankan berikut saat menggunakan DynamoDB Transactions.
+ Aktifkan penskalaan otomatis pada tabel Anda, atau pastikan bahwa Anda telah menyediakan kapasitas throughput yang cukup untuk melakukan dua operasi baca atau tulis untuk setiap item dalam transaksi Anda.
+ Jika Anda tidak menggunakan SDK yang AWS disediakan, sertakan `ClientRequestToken` atribut saat Anda melakukan `TransactWriteItems` panggilan untuk memastikan bahwa permintaan tersebut idempoten.
+ Jangan mengelompokkan operasi bersama-sama dalam sebuah transaksi jika tidak diperlukan. Misalnya, jika satu transaksi dengan 10 operasi dapat dipecah menjadi beberapa transaksi tanpa mengurangi kebenaran aplikasi, sebaiknya pisahkan transaksi tersebut. Transaksi yang lebih sederhana meningkatkan throughput dan lebih mungkin untuk berhasil.
+ Beberapa transaksi memperbarui item yang sama secara bersamaan dapat menyebabkan konflik yang membatalkan transaksi. Kami merekomendasikan praktik terbaik DynamoDB berikut untuk pemodelan data untuk meminimalkan konflik tersebut.
+ Jika satu set atribut sering diperbarui di beberapa item sebagai bagian dari transaksi tunggal, pertimbangkan pengelompokan atribut menjadi satu item untuk mengurangi lingkup transaksi.
+ Hindari penggunaan transaksi untuk menyerap data secara massal. Untuk tulis massal, lebih baik menggunakan `BatchWriteItem`.
## Menggunakan transaksional APIs dengan tabel global
Operasi transaksional memberikan jaminan atomisitas, konsistensi, isolasi, dan daya tahan (ACID) hanya di AWS Wilayah tempat API tulis dipanggil. Transaksi tidak didukung di seluruh Wilayah dalam tabel global. Misalnya, Anda memiliki tabel global dengan replika di Wilayah AS Timur (Ohio) dan AS Barat (Oregon) dan Anda melakukan operasi `TransactWriteItems` di Wilayah AS Timur (Virginia Utara). Anda dapat mengamati transaksi yang diselesaikan sebagian di Wilayah Barat AS (Oregon) saat perubahan direplikasi. Perubahan direplikasi ke Wilayah lain hanya setelah dilakukan di Wilayah sumber.
## Transaksi DynamoDB AWSLabs vs. perpustakaan klien transaksi
Transaksi DynamoDB menyediakan penggantian yang lebih hemat biaya, kuat, dan berkinerja untuk pustaka klien transaksi. [AWSLabs](https://github.com/awslabs) Kami menyarankan agar Anda memperbarui aplikasi Anda untuk menggunakan transaksi asli, sisi server. APIs