Dari Paper Dynamo ke DynamoDB

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

Apakah DynamoDB berbasis paper Dynamo?

Sebagian. DynamoDB mengambil nama dan tujuan intinya — performa yang dapat-diprediksi dan ketersediaan tinggi pada skala apa pun — dari paper Amazon Dynamo 2007, dan ia mempertahankan gagasan hashing partition key nyaris kata demi kata. Tapi ia adalah sistem lain yang terkelola: vector clock, keanggotaan gossip, dan quorum baca/tulis yang dapat-disetel dari paper telah hilang, digantikan oleh internal yang dimiliki AWS.

• Paper memecahkan ketersediaan, bukan ergonomi. Tugasnya adalah tidak pernah menolak sebuah tulisan selama lonjakan lalu lintas liburan, bahkan dengan biaya mengembalikan pembacaan yang basi.
• DynamoDB mempertahankan bentuknya, mengganti internalnya. Di-partition oleh hash key, direplikasi di seluruh AZ, diskalakan secara horizontal — tapi isi resolusi-konflik (vector clock, gossip, read-repair) telah hilang.
• Anda tidak lagi menyetel knob. N, R, dan W dari paper menjadi satu pilihan: ConsistentRead true atau false. AWS memiliki sisanya.
• Model mentalnya tetap berbuah. Mengetahui garis keturunannya menjelaskan mengapa sebuah Scan mahal dan mengapa sebuah pembacaan GSI bisa tertinggal — keduanya jatuh dari desain aslinya.

Apa yang sebenarnya dipecahkan paper

Keranjang belanja Amazon tidak boleh down. Sebuah database relasional yang menolak tulisan di bawah beban — atau memblokir pada replica yang gagal — tak bisa diterima. Paper Dynamo 2007 memilih ketersediaan di atas konsistensi: selalu terima tulisan, rekonsiliasi ketidaksepakatan nanti. Pertukaran itu adalah akar dari segala hal di bawah.

Untuk melakukannya tanpa master tunggal, Dynamo harus menjawab dua pertanyaan sendiri: di mana sebuah key tinggal, dan berapa banyak salinan yang harus setuju sebelum sebuah pembacaan atau tulisan dihitung?

Consistent hashing: di mana sebuah key tinggal

Paper 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 sebuah node hanya mengocok ulang key tetangganya — bukan seluruh dataset. Itulah consistent hashing, dan ia adalah satu gagasan yang dipertahankan DynamoDB nyaris kata demi kata.

DynamoDB masih meng-hash partition key Anda untuk menentukan partition fisik mana yang menyimpan Item. Pilih partition key ber-cardinality-rendah — katakanlah STATUS dengan dua nilai — dan setiap Item dengan nilai yang sama mendarat di partition yang sama. Itulah footgun hot partition, dan ia adalah konsekuensi langsung dari ring: hash mengirim key identik ke rumah identik.

Quorum: berapa banyak salinan yang harus setuju

Knob kedua paper adalah sebuah quorum. Dengan N replica, sebuah tulisan berhasil begitu W darinya meng-ack, dan sebuah pembacaan berkonsultasi dengan R darinya. Atur R + W > N dan setiap pembacaan tumpang tindih dengan setidaknya satu node yang menampung tulisan terbaru — strong consistency. Atur lebih rendah dan Anda menukar kesegaran untuk kecepatan dan uptime.

Dynamo menjalankan quorum "sloppy": jika sebuah node target down, tulisan masuk ke pengganti dan diserahkan kembali nanti (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 partitioning-nya, lalu menghapus bagian yang membuat yang asli sulit dioperasikan.

API paper adalah dua panggilan: get(key) dan put(key, value). DynamoDB menambah sebuah sort key, index, dan query di atas inti key-value yang sama — itulah mengapa sebuah Query murah (satu partition) dan sebuah Scan tidak (ia menjelajahi setiap partition yang pernah diciptakan ring).

Bagaimana sebuah tulisan berjalan, dulu dan kini

Alur di bawah membandingkan tulisan quorum paper dengan tulisan terkelola DynamoDB. Bentuknya berima; tanggung jawab pindah dari kode Anda ke AWS.

Di paper Anda memiliki matematika quorum dan merge-nya; di DynamoDB seluruh separuh bawah itu terkelola, dan Anda hanya memilih ConsistentRead per request.

Di mana garis keturunannya bocor ke kode Anda

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

Anda membeli kembali strong consistency dengan dua cara. Gunakan ConsistentRead: true pada sebuah pembacaan tabel-basis (ia dirutekan ke salinan leader), atau jaga sebuah tulisan dengan sebuah ConditionExpression sehingga ia hanya mendarat jika state Item saat ini cocok. Sketsakan satu di DynamoDB expression builder — misalnya attribute_not_exists(PK) untuk membuat sebuah PutItem operasi insert-saja, pengganti modern untuk deteksi konflik paper.

Satu hal untuk diingat

Paper mengoptimalkan untuk tidak pernah berkata tidak pada sebuah tulisan. DynamoDB mewarisi bias itu, itulah mengapa default-nya mengutamakan ketersediaan dan mengapa pembacaan strong berbiaya lebih. Modelkan key Anda untuk Query satu-partition, seperti di single-table design, dan raih sebuah Scan hanya saat Anda benar-benar harus — ring membuat penjelajahan tabel-penuh semahal kedengarannya.

Coba DynoTable untuk memeriksa partition Anda, menjalankan pembacaan konsisten sesuai permintaan, dan menyaksikan sebuah GSI menyusul terhadap tabel Anda sendiri.