Model konsistensi DAX dan DynamoDB

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Amazon DynamoDB Accelerator (DAX) adalah layanan caching write-through yang dirancang untuk memudahkan proses menambahkan cache ke tabel DynamoDB. Karena DAX beroperasi secara terpisah dari DynamoDB, Anda harus memahami model konsistensi DAX dan DynamoDB untuk memastikan bahwa aplikasi Anda berfungsi seperti yang diharapkan.

Dalam banyak kasus penggunaan, cara aplikasi Anda menggunakan DAX memengaruhi konsistensi data dalam klaster DAX serta konsistensi data antara DAX dan DynamoDB.

Konsistensi di antara simpul klaster DAX

Guna mencapai ketersediaan tinggi untuk aplikasi Anda, sebaiknya sediakan setidaknya tiga simpul untuk klaster DAX Anda. Kemudian tempatkan simpul tersebut di beberapa Zona Ketersediaan dalam Wilayah.

Ketika klaster DAX Anda berjalan, klaster mereplikasi data di antara semua simpul dalam klaster (dengan asumsi bahwa Anda menyediakan lebih dari satu simpul). Pertimbangkan aplikasi yang berhasil melakukan UpdateItem menggunakan DAX. Tindakan ini menyebabkan cache item di simpul primer dimodifikasi dengan nilai baru. Nilai tersebut kemudian direplikasi ke semua simpul lain dalam klaster. Replikasi ini akhirnya konsisten dan biasanya membutuhkan waktu kurang dari satu detik untuk diselesaikan.

Dalam skenario ini, dua klien dapat membaca kunci yang sama dari klaster DAX yang sama tetapi menerima nilai yang berbeda, tergantung simpul yang diakses setiap klien. Semua simpul akan konsisten ketika pembaruan telah sepenuhnya direplikasi di seluruh simpul dalam klaster. (Perilaku ini mirip dengan sifat akhir konsisten DynamoDB.)

Jika Anda sedang membuat aplikasi yang menggunakan DAX, aplikasi tersebut harus dirancang agar dapat menoleransi data akhir konsisten.

Perilaku cache item DAX

Setiap klaster DAX memiliki dua cache yang berbeda, yaitu cache item dan cache kueri. Untuk informasi selengkapnya, lihat DAX: Cara kerjanya.

Bagian ini membahas implikasi konsistensi dari pembacaan dari dan penulisan ke cache item DAX.

Konsistensi pembacaan

Dengan DynamoDB, operasi GetItem melakukan bacaan akhir konsisten secara default. Anggaplah Anda menggunakan UpdateItem dengan klien DynamoDB. Jika kemudian Anda mencoba membaca item yang sama segera setelahnya, Anda mungkin melihat data yang muncul sebelum pembaruan. Hal ini disebabkan penundaan penyebaran di semua lokasi penyimpanan DynamoDB. Konsistensi biasanya tercapai dalam hitungan detik. Jadi jika mencoba kembali pembacaan, Anda mungkin akan melihat item yang diperbarui.

Saat Anda menggunakan GetItem dengan klien DAX, operasi (dalam kasus ini, bacaan akhir konsisten) berlanjut seperti yang ditunjukkan berikut ini.

Item tetap dalam cache item DAX, tunduk pada pengaturan Time to Live (TTL) dan algoritma paling lama tidak digunakan (LRU) untuk cache. Untuk informasi selengkapnya, lihat DAX: Cara kerjanya.

Namun, selama periode ini, DAX tidak membaca ulang item dari DynamoDB. Jika orang lain memperbarui item menggunakan klien DynamoDB dan sepenuhnya melewati DAX, permintaan GetItem menggunakan klien DAX memberikan hasil yang berbeda dari permintaan GetItem menggunakan klien DynamoDB. Dalam skenario ini, DAX dan DynamoDB memegang nilai yang tidak konsisten untuk kunci yang sama hingga TTL untuk item DAX kedaluwarsa.

Jika aplikasi memodifikasi data dalam tabel DynamoDB dasar dan melewati DAX, aplikasi perlu mengantisipasi dan menoleransi inkonsistensi data yang mungkin terjadi.

Konsistensi penulisan

DAX adalah cache write-through, yang memudahkan proses mempertahankan konsistensi cache item DAX dengan tabel DynamoDB dasar.

Klien DAX mendukung operasi API penulisan yang sama seperti DynamoDB (PutItem, UpdateItem, DeleteItem, BatchWriteItem, dan TransactWriteItems). Ketika Anda menggunakan operasi ini dengan klien DAX, item yang ada di DAX dan DynamoDB diubah. DAX memperbarui item dalam cache item, terlepas dari nilai TTL untuk item ini.

Misalnya, anggaplah Anda membuat permintaan GetItem dari klien DAX untuk membaca item dari tabel ProductCatalog. (Kunci partisinya adalah Id dan tidak ada kunci urutan.) Anda mengambil item dengan Id 101. Nilai QuantityOnHand untuk item itu adalah 42. DAX menyimpan item dalam cache item dengan TTL tertentu. Untuk contoh ini, TTL diasumsikan 10 menit. Lalu, 3 menit kemudian, aplikasi lain menggunakan klien DAX untuk memperbarui item yang sama sehingga nilai QuantityOnHand sekarang adalah 41. Dengan asumsi bahwa item tidak diperbarui lagi, pembacaan berikutnya untuk item yang sama dalam 10 menit ke depan akan menampilkan nilai cache untuk QuantityOnHand (41).

Cara DAX memproses penulisan

DAX ditujukan untuk aplikasi yang memerlukan pembacaan performa tinggi. Sebagai cache write-through, DAX meneruskan penulisan Anda ke DynamoDB secara bersamaan, kemudian mereplikasi pembaruan yang dihasilkan untuk cache item Anda di semua simpul dalam klaster secara otomatis dan asinkron. Anda tidak perlu mengelola logika pembatalan cache karena DAX menanganinya untuk Anda.

DAX mendukung operasi penulisan berikut: PutItem, UpdateItem, DeleteItem, BatchWriteItem, dan TransactWriteItems.

Ketika Anda mengirim permintaan PutItem, UpdateItem, DeleteItem, atau BatchWriteItem ke DAX, hal berikut akan terjadi:

Ketika Anda mengirim permintaan TransactWriteItems ke DAX, hal berikut akan terjadi:

Jika penulisan ke DynamoDB gagal dengan alasan apa pun, termasuk throttling, item tidak di-cache di DAX. Pengecualian untuk kegagalan ditampilkan ke pemohon. Hal ini memastikan bahwa data tidak ditulis ke cache DAX kecuali sudah berhasil ditulis ke DynamoDB.

Perilaku cache kueri DAX

DAX melakukan cache untuk hasil dari permintaan Query dan Scan dalam cache kueri. Namun, hasil tersebut tidak memengaruhi cache item sama sekali. Saat aplikasi Anda mengajukan permintaan Query atau Scan dengan DAX, set hasil disimpan di cache kueri, bukan di cache item. Anda tidak dapat melakukan "pemanasan" cache item dengan melakukan operasi Scan karena cache item dan cache kueri adalah entitas terpisah.

Konsistensi query-update-query

Pembaruan untuk cache item atau tabel DynamoDB dasar tidak membatalkan atau mengubah hasil yang disimpan dalam cache kueri.

Sebagai gambaran, pertimbangkan skenario berikut. Aplikasi bekerja dengan tabel DocumentRevisions, yang memiliki DocId sebagai kunci partisi dan RevisionNumber sebagai kunci urutan.

Dalam skenario ini, set hasil yang di-cache untuk Query yang dikeluarkan di langkah 3 identik dengan set hasil yang di-cache di langkah 1. Alasannya adalah karena DAX tidak membatalkan set hasil Query atau Scan berdasarkan pembaruan untuk masing-masing item. Operasi PutItem dari langkah 2 hanya tercermin dalam cache kueri DAX ketika TTL untuk Query kedaluwarsa.

Aplikasi Anda harus mempertimbangkan nilai TTL untuk cache kueri dan berapa lama aplikasi Anda dapat menoleransi hasil yang tidak konsisten antara cache kueri dan cache item.

Bacaan sangat konsisten dan transaksional

Untuk melakukan permintaan GetItem, BatchGetItem, Query, atau Scan yang sangat konsisten, Anda perlu mengatur parameter ConsistentRead ke benar. DAX meneruskan permintaan bacaan sangat konsisten ke DynamoDB. Ketika menerima respons dari DynamoDB, DAX mengembalikan hasil ke klien, tetapi tidak melakukan cache hasil. DAX tidak dapat menyediakan bacaan sangat konsisten sendiri karena tidak digabungkan dengan erat ke DynamoDB. Untuk alasan ini, setiap pembacaan berikutnya dari DAX harus merupakan bacaan akhir konsisten. Setiap bacaan sangat konsisten berikutnya juga harus diteruskan ke DynamoDB.

DAX menangani permintaan TransactGetItems dengan cara yang sama seperti bacaan sangat konsisten. DAX meneruskan semua permintaan TransactGetItems ke DynamoDB. Ketika menerima respons dari DynamoDB, DAX mengembalikan hasil ke klien, tetapi tidak melakukan cache hasil.

Caching negatif

DAX mendukung entri cache negatif baik di cache item dan di cache kueri. Entri cache negatif terjadi ketika DAX tidak dapat menemukan item yang diminta dalam tabel DynamoDB dasar. DAX melakukan cache hasil kosong dan mengembalikan hasil ke pengguna, bukan menghasilkan pesan kesalahan.

Misalnya, anggaplah aplikasi mengirimkan permintaan GetItem ke klaster DAX dan tidak ada item yang cocok dalam cache item DAX. Hal ini menyebabkan DAX membaca item yang sesuai dari tabel DynamoDB dasar. Jika item tidak ada di DynamoDB, DAX menyimpan item kosong dalam cache item dan mengembalikan item kosong ke aplikasi. Sekarang, anggaplah bahwa aplikasi mengirimkan permintaan GetItem lain untuk item yang sama. DAX menemukan item kosong dalam cache item dan langsung mengembalikannya ke aplikasi. DAX tidak melihat DynamoDB sama sekali.

Entri cache negatif tetap ada di cache item DAX hingga TTL item kedaluwarsa, LRU diinvokasi, atau item diubah menggunakan PutItem, UpdateItem, atau DeleteItem.

Cache kueri DAX menangani hasil cache negatif dengan cara yang sama. Jika aplikasi melakukan Query atau Scan dan cache kueri DAX tidak berisi hasil cache, DAX mengirimkan permintaan ke DynamoDB. Jika tidak ada item yang cocok dalam set hasil, DAX menyimpan set hasil kosong di cache kueri dan mengembalikan set hasil kosong ke aplikasi. Permintaan Query atau Scan berikutnya menghasilkan set hasil (kosong) yang sama, hingga TTL untuk hasil tersebut kedaluwarsa.

Strategi untuk penulisan

Perilaku write-through DAX sesuai untuk banyak pola aplikasi. Namun, ada beberapa pola aplikasi yang mungkin tidak cocok dengan model write-through.

Untuk aplikasi yang sensitif terhadap latensi, menulis melalui DAX menimbulkan lompatan jaringan tambahan. Jadi menulis ke DAX akan sedikit lebih lambat dibandingkan menulis langsung ke DynamoDB. Jika aplikasi Anda sensitif terhadap latensi tulis, Anda dapat mengurangi latensi dengan menulis langsung ke DynamoDB. Untuk informasi selengkapnya, lihat Write-around.

Untuk aplikasi dengan operasi tulis intensif (seperti yang melakukan pemuatan data massal), Anda mungkin tidak ingin menulis semua data melalui DAX karena hanya sebagian kecil dari data yang akan dibaca oleh aplikasi. Ketika Anda menulis sejumlah besar data melalui DAX, DAX harus menginvokasi algoritma LRU agar menyediakan ruang di cache untuk item baru yang akan dibaca. Hal ini mengurangi efektivitas DAX sebagai cache baca.

Ketika Anda menulis item ke DAX, status cache item diubah untuk mengakomodasi item baru. (Misalnya, DAX mungkin perlu menghapus data lama dari cache item untuk menyediakan ruang bagi item baru.) Item baru tetap dalam cache item, tunduk pada algoritma LRU cache dan pengaturan TTL untuk cache. Selama item tetap ada dalam cache item, DAX tidak membaca ulang item dari DynamoDB.

Write-through

Cache item DAX menerapkan kebijakan write-through. Untuk informasi selengkapnya, lihat Cara DAX memproses penulisan.

Ketika Anda menulis item, DAX memastikan bahwa item cache disinkronkan dengan item yang ada di DynamoDB. Hal ini sangat membantu untuk aplikasi yang perlu membaca ulang item segera setelah menulisnya. Namun, jika aplikasi lain menulis langsung ke tabel DynamoDB, item dalam cache item DAX tidak lagi sinkron dengan DynamoDB.

Sebagai gambaran, pertimbangkan dua pengguna (Alice dan Bob), yang bekerja dengan tabel ProductCatalog. Alice mengakses tabel menggunakan DAX, tetapi Bob melewati DAX dan mengakses tabel secara langsung di DynamoDB.

Dalam skenario ini, Alice dan Bob melihat representasi yang berbeda dari item ProductCatalog yang sama. Hal ini terjadi hingga DAX mengeluarkan item dari cache item, atau hingga pengguna lain memperbarui item yang sama lagi menggunakan DAX.

Write-around

Jika aplikasi Anda perlu menulis data dalam jumlah besar (seperti beban data massal), mungkin wajar untuk melewati DAX dan menulis data langsung ke DynamoDB. Strategi seperti write-around mengurangi latensi penulisan. Namun, cache item tidak akan sinkron dengan data di DynamoDB.

Jika Anda memutuskan untuk menggunakan strategi write-around, ingat bahwa DAX mengisi cache item setiap kali aplikasi menggunakan klien DAX untuk membaca data. Hal ini dapat menguntungkan dalam beberapa kasus karena memastikan bahwa hanya data yang paling sering dibaca yang di-cache (kebalikan dari data yang paling sering ditulis).

Sebagai contoh, pertimbangkan pengguna (Charlie) yang ingin bekerja dengan tabel yang berbeda, tabel GameScores, menggunakan DAX. Kunci partisi untuk GameScores adalah UserId, sehingga semua skor Charlie akan memiliki UserId yang sama.

DAX tidak memperbarui set hasil dalam cache kueri dengan data terbaru dari DynamoDB. Setiap set hasil dalam cache kueri adalah hasil terbaru saat operasi Query atau Scan dilakukan. Jadi, hasil Query Charlie tidak mencerminkan operasi PutItem. Hal ini terjadi hingga DAX menghapus set hasil dari cache kueri.