Dari Paper Dynamo ke DynamoDB

Paper 2007 "Dynamo: Amazon's Highly Available Key-value Store" dan DynamoDB yang Anda panggil hari ini berbagi nama dan tujuan — performa yang dapat diprediksi pada skala apa pun — tetapi keduanya bukan sistem yang sama. Paper itu menggambarkan penyimpanan internal eventually-consistent yang Anda jalankan sendiri. DynamoDB adalah layanan terkelola yang mempertahankan pelajarannya dan membuang sebagian besar mesinnya.

Apakah DynamoDB didasarkan pada paper Dynamo?

Sebagian. DynamoDB mengambil nama dan tujuan intinya — performa yang dapat diprediksi dan ketersediaan tinggi pada skala — dari paper Amazon Dynamo 2007, dan ia mempertahankan ide hashing partition key hampir kata demi kata. Tetapi ia adalah sistem terkelola yang berbeda: vector clock, keanggotaan gossip, dan quorum baca/tulis yang dapat disetel dari paper itu sudah tiada, digantikan oleh internal milik AWS.

• Paper itu memecahkan ketersediaan, bukan ergonomi. Tugasnya adalah tak pernah menolak penulisan selama lonjakan trafik liburan, bahkan dengan biaya mengembalikan pembacaan basi.
• DynamoDB mempertahankan bentuknya, mengganti internalnya. Dipartisi oleh hash dari key, direplikasi lintas AZ, diskalakan secara horizontal — tetapi isi resolusi konflik (vector clock, gossip, read-repair) sudah tiada.
• Anda tak lagi menyetel tombolnya. N, R, dan W dari paper itu menjadi satu pilihan: ConsistentRead true atau false. AWS memiliki sisanya.
• Model mentalnya tetap membuahkan hasil. Mengetahui garis keturunannya menjelaskan mengapa Scan mahal dan mengapa pembacaan GSI bisa tertinggal — keduanya jatuh dari desain aslinya.

Apa yang sebenarnya dipecahkan paper itu

Keranjang belanja Amazon tak boleh mati. Basis data relasional yang menolak penulisan di bawah beban — atau memblokir pada replika gagal — tak dapat diterima. Paper Dynamo 2007 memilih ketersediaan di atas konsistensi: selalu terima penulisan, rekonsiliasi ketidaksepakatan belakangan. Trade itu adalah akar dari semua yang di bawah ini.

Untuk melakukan itu tanpa master tunggal, Dynamo harus menjawab dua pertanyaan sendiri: di mana sebuah key tinggal, dan berapa banyak salinan harus sepakat sebelum pembacaan atau penulisan dihitung?

Consistent hashing: di mana sebuah key tinggal

Paper itu menempatkan setiap node pada sebuah hash ring. Posisi sebuah key adalah hash dari key-nya; ia dimiliki oleh node berikutnya searah jarum jam, dan direplikasi ke N-1 node berikutnya. Menambah atau menghapus node hanya mengocok ulang key tetangganya — bukan seluruh dataset. Itulah consistent hashing, dan itu satu ide yang dipertahankan DynamoDB hampir kata demi kata.

DynamoDB masih meng-hash partition key Anda untuk memutuskan partisi fisik mana yang menyimpan Item. Pilih partition key berkardinalitas rendah — katakan STATUS dengan dua nilai — dan setiap Item dengan nilai yang sama mendarat di partisi yang sama. Itulah footgun hot partition, dan itu konsekuensi langsung dari ring: hash mengirim key identik ke rumah identik.

Quorum: berapa banyak salinan harus sepakat

Tombol kedua paper itu adalah quorum. Dengan N replika, penulisan berhasil begitu W di antaranya meng-ack, dan pembacaan berkonsultasi dengan R di antaranya. Setel R + W > N dan pembacaan apa pun tumpang tindih setidaknya satu node yang memegang penulisan terbaru — konsistensi kuat. Setel lebih rendah dan Anda menukar kesegaran demi kecepatan dan uptime.

Dynamo menjalankan quorum "sloppy": jika node target mati, penulisan pergi ke pengganti dan diserahkan kembali belakangan (hinted handoff). Versi yang berkonflik ditandai dengan vector clock dan direkonsiliasi oleh aplikasi saat pembacaan.

Apa yang dipertahankan versus diubah DynamoDB

DynamoDB mewarisi tujuan dan pemartisiannya, lalu menghapus bagian-bagian yang membuat aslinya sulit dioperasikan.

API paper itu adalah dua panggilan: get(key) dan put(key, value). DynamoDB menambahkan sort key, index, dan query di atas inti key-value yang sama — itulah sebabnya Query murah (satu partisi) dan Scan tidak (ia menyusuri setiap partisi yang pernah diciptakan ring).

Bagaimana penulisan berjalan, dulu dan kini

Alur di bawah membandingkan penulisan quorum paper dengan penulisan terkelola DynamoDB. Bentuknya berima; tanggung jawabnya berpindah dari kode Anda ke AWS.

Dalam paper Anda memiliki matematika quorum dan merge-nya; dalam DynamoDB seluruh paruh bawah itu terkelola, dan Anda hanya memilih ConsistentRead per permintaan.

Di mana garis keturunan bocor ke kode Anda

Default eventual-consistency adalah paper yang menampak. Sebuah global secondary index direplikasi secara asinkron, jadi Item yang baru ditulis bisa hilang dari index untuk sesaat — tawar-menawar "rekonsiliasi belakangan" yang sama, hanya di lapisan index. Lihat GSI vs LSI untuk kapan lag itu penting.

Anda menebus konsistensi kuat dengan dua cara. Gunakan ConsistentRead: true pada pembacaan base-table (ia dirutekan ke salinan leader), atau jaga penulisan dengan ConditionExpression agar ia hanya mendarat jika keadaan Item saat ini cocok. Sketsakan satu di DynamoDB expression builder — misalnya attribute_not_exists(PK) untuk menjadikan PutItem operasi insert-saja, pengganti modern dari deteksi konflik paper itu.

Satu hal untuk diingat

Paper itu dioptimalkan untuk tak pernah menolak penulisan. DynamoDB mewarisi bias itu, itulah sebabnya default-nya mengunggulkan ketersediaan dan mengapa pembacaan kuat berbiaya lebih. Modelkan key Anda untuk Query single-partition, seperti di desain tabel tunggal, dan andalkan Scan hanya saat Anda benar-benar harus — ring membuat penyusuran tabel penuh semahal kedengarannya.

Coba DynoTable untuk menelusuri tabel Anda dan GSI-nya, lalu jalankan JOIN dan GROUP BY atas data Anda sendiri di SQL Workbench.