Amazon DynamoDB Transactions: Cara kerjanya - Amazon DynamoDB
TransactWriteItemsTransactGetItemsTingkat isolasiPenanganan konflik transaksiTransaksi di DAXManajemen kapasitasPraktik terbaikMenggunakan transaksional APIs dengan tabel globalTransaksi vs. pustaka klien

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 API operasi, manajemen kapasitas, praktik terbaik, dan detail lainnya tentang penggunaan operasi transaksional di DynamoDB.

TransactWriteItems API

TransactWriteItemsadalah 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.

Setelah transaksi selesai, perubahan yang dibuat dalam transaksi tersebut disebarkan ke indeks sekunder global (GSIs), aliran, dan cadangan. Karena propagasi tidak langsung atau instan, jika tabel dipulihkan dari backup (RestoreTableFromBackup) atau diekspor ke titik waktu (ExportTableToPointInTime) pertengahan propagasi, mungkin berisi beberapa tetapi tidak semua 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.

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.

Tingkat isolasi untuk DynamoDB transactions

Tingkat isolasi operasi transaksional (TransactWriteItems atau TransactGetItems) dan operasi lainnya adalah sebagai berikut.

SERIALIZABLE

Isolasi serialisasi 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 penulisan transaksi hanya ketika respons berhasil diterima untuk penulisan transaksional.

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

NOTSerializ*

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 for Java, pengecualian berisi daftar CancellationReasons, 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 ditambahkan untuk setiap permintaan tingkat item yang gagal.

Menggunakan transaksional di APIs DynamoDB Accelerator () DAX

TransactWriteItemsdan TransactGetItems keduanya didukung di DynamoDB Accelerator DAX () dengan tingkat isolasi yang sama seperti di DynamoDB.

TransactWriteItemsmenulis melaluiDAX. DAXmeneruskan TransactWriteItems panggilan ke DynamoDB dan mengembalikan respons. Untuk mengisi cache setelah menulis, DAX panggilan TransactGetItems di latar belakang untuk setiap item dalam TransactWriteItems operasi, yang mengkonsumsi unit kapasitas baca tambahan. (Untuk informasi selengkapnya, lihat Manajemen kapasitas untuk transaksi.) Fungsi ini memungkinkan Anda untuk menjaga logika aplikasi Anda sederhana dan digunakan DAX untuk operasi transaksional dan non-transaksional.

TransactGetItemspanggilan dilewatkan DAX tanpa item di-cache secara lokal. Ini adalah perilaku yang sama seperti untuk membaca APIs yang sangat konsistenDAX.

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 operasi baca/tulis yang mendasarinya terlihat di metrik Amazon CloudWatch 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 duaRCUs: satu untuk mempersiapkan transaksi dan satu untuk melakukan transaksi.

Selain itu, SDK perilaku default adalah mencoba kembali transaksi jika terjadi TransactionInProgressException pengecualian. 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 yang AWS disediakanSDK, 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 yang terkandung dalam transaksi DynamoDB hanya dijamin transaksional di wilayah tempat transaksi awalnya dijalankan. Transaksionalitas tidak dipertahankan ketika perubahan yang diterapkan dalam transaksi direplikasi di seluruh Wilayah ke replika tabel global.

Transaksi DynamoDB AWSLabs vs. perpustakaan klien transaksi

Transaksi DynamoDB menyediakan penggantian yang lebih hemat biaya, kuat, dan berkinerja untuk pustaka klien transaksi. AWSLabs Kami menyarankan agar Anda memperbarui aplikasi Anda untuk menggunakan transaksi asli, sisi server. APIs