Pembacaan Strongly Consistent vs Eventually Consistent DynamoDB

Anda memperbarui sebuah Item, langsung membacanya kembali, dan mendapat nilai lama. Penulisan berhasil — sesaat kemudian pembacaan yang sama mengembalikan nilai baru. Tidak ada yang rusak: Anda menabrak pembacaan eventually consistent default DynamoDB, dan Anda bisa menonaktifkannya per permintaan.

Ini adalah salah satu dari sedikit tombol kebenaran yang diserahkan DynamoDB langsung kepada Anda, dan ada harga nyata yang melekat padanya. Menggunakannya dengan benar berarti mengetahui apa yang dijamin setiap mode, berapa biayanya, dan di mana strong read sama sekali tidak tersedia.

Apa perbedaan antara pembacaan strongly consistent dan eventually consistent di DynamoDB?

Pembacaan eventually consistent (default) dilayani oleh replika mana pun, sehingga sesaat bisa mengembalikan data basi tepat setelah sebuah penulisan, tetapi biayanya separuh. Pembacaan strongly consistent, yang diaktifkan per permintaan dengan ConsistentRead=true, dialihkan ke leader partisi dan selalu mencerminkan setiap penulisan yang ter-commit — dengan 2× read capacity.

• Eventually consistent (default) — bisa sesaat mengembalikan data basi tepat setelah sebuah penulisan. Mode pembacaan termurah.
• Strongly consistent — selalu mencerminkan setiap penulisan yang ter-commit sebelum pembacaan. Aktifkan per permintaan dengan ConsistentRead=true.
• Strong read berbiaya 2× eventual. Sebuah pembacaan strongly consistent menghabiskan dua kali read capacity dari pembacaan eventually consistent untuk data yang sama.
• Tidak di mana-mana. Anda mendapat strong read pada tabel dasar dan pada Local Secondary Index. Sebuah Global Secondary Index hanya eventual — tanpa opsi aktivasi.
• Jadikan eventual sebagai default. Raih strong hanya saat membaca data yang baru saja Anda tulis sendiri dan basi-sesaat akan menjadi masalah.

Masalahnya: pembacaan yang tak melihat penulisan terbaru

Misalkan Anda mengelola akun user. Seorang user mengubah email notifikasinya, aplikasi Anda menulis pembaruan itu, dan layar konfirmasi langsung membaca ulang profil untuk menampilkan alamat baru. Dengan mode pembacaan default, pembacaan ulang itu bisa mendarat pada sebuah replika yang belum menerima perubahannya — sehingga user melihat email lama mereka dan mengira penyimpanannya gagal.

Jendelanya kecil (biasanya jauh di bawah satu detik) dan menutup dengan sendirinya. Tetapi "biasanya benar" tidak cukup baik untuk konfirmasi read-after-write. Itulah persis kasus mengapa strong consistency ada.

Mengapa eventual consistency terjadi

DynamoDB menyimpan setiap partisi pada tiga storage node — satu primary dan dua replika — di seluruh Availability Zone yang terpisah. Sebuah penulisan diakui begitu ia mendarat di primary dan satu replika; ia kemudian berpropagasi ke node ketiga secara asinkron.

Pembacaan, untuk menyebar beban, bisa dilayani oleh node mana pun dari ketiganya. Sebuah pembacaan eventually consistent bisa menabrak node yang belum menerima penulisan terbaru Anda — sehingga ia mengembalikan nilai yang sedikit basi. Sebuah pembacaan strongly consistent dialihkan ke leader untuk partisi itu, yang selalu memegang data ter-commit paling baru, sehingga tak pernah mengembalikan hasil basi.

Lag replikasi itulah seluruh perbedaannya. Ia juga menjelaskan biaya 2×: strong read tidak bisa di-load-balance ke seluruh replika seperti eventual read, jadi DynamoDB memberinya harga dua kali kapasitas.

Biayanya, secara konkret

Pembacaan dihitung dalam Read Capacity Unit (RCU), masing-masing mencakup hingga 4 KB. Satu RCU membeli satu pembacaan strongly consistent atau dua pembacaan eventually consistent atas sebuah Item 4 KB. Jadi menyalakan ConsistentRead=true pada jalur pembacaan panas menggandakan biaya bacanya — pada endpoint berlalu-lintas tinggi itu adalah pos biaya yang akan Anda perhatikan.

Modelkan perbedaannya untuk ukuran Item dan laju permintaan Anda sendiri dengan kalkulator harga DynamoDB sebelum Anda menjadikan strong read sebagai default — jarang sekali sepadan membayar dua kali untuk semuanya.

Di mana strong read tersedia (dan tidak)

Sebuah GSI memelihara salinan datanya sendiri, direplikasi dari tabel dasar secara asinkron, jadi ia tak pernah bisa menawarkan strong read. Jika sebuah pola akses benar-benar membutuhkan read-after-write dan Anda berencana melayaninya dari GSI, itu adalah sinyal untuk melayaninya dari tabel dasar atau sebuah LSI sebagai gantinya.

Jebakan + langkah berikutnya

• Jangan jadikan strong read sebagai default. Sebagian besar pembacaan mentoleransi jendela basi sub-detik; membayar 2× di mana-mana adalah pemborosan.
• Jangan harapkan read-after-write dari GSI. Ia eventual secara desain — lihat mengapa GSI bersifat eventually consistent.
• Transaksi membaca secara strong. TransactGetItems selalu strongly consistent — lihat transaksi DynamoDB.
• Konsistensi berinteraksi dengan kapasitas. Pengali 2× terkait langsung dengan perencanaan biaya on-demand vs provisioned.

Ingin menjelajahi tabel dan index DynamoDB Anda tanpa menulis panggilan API? Unduh DynoTable dan periksa data Anda secara langsung.