Dynamo Makalesinden DynamoDB'ye

2007 "Dynamo: Amazon's Highly Available Key-value Store" makalesi ve bugün çağırdığın DynamoDB bir adı ve bir hedefi paylaşır — herhangi bir ölçekte öngörülebilir performans — ama aynı sistem değildir. Makale, kendin çalıştırdığın dahili, nihai tutarlı bir deposu tarif etti. DynamoDB, dersleri koruyan ve makinenin çoğunu atan yönetilen bir servistir.

DynamoDB, Dynamo makalesine mi dayanıyor?

Kısmen. DynamoDB, adını ve temel hedeflerini — ölçekte öngörülebilir performans ve yüksek erişilebilirlik — 2007 Amazon Dynamo makalesinden alır ve partition key hash'leme fikrini neredeyse harfiyen korudu. Ama bu, farklı, yönetilen bir sistemdir: makalenin vector clock'ları, gossip üyeliği ve ayarlanabilir okuma/yazma quorum'ları gitti, yerini AWS'nin sahip olduğu dahili yapı aldı.

• Makale erişilebilirliği çözdü, ergonomiyi değil. İşi, tatil-trafiği ani yükü sırasında, bayat bir okuma döndürme pahasına bile, asla bir yazmayı reddetmemekti.
• DynamoDB şekli korudu, dahili yapıyı değiştirdi. Key'in bir hash'iyle partition'lanmış, AZ'ler arası replike edilmiş, yatay ölçeklenmiş — ama çatışma-çözümü iç organları (vector clock'lar, gossip, read-repair) gitti.
• Artık düğmeleri ayarlamıyorsun. Makaledeki N, R ve W, tek bir seçim oldu: ConsistentRead true ya da false. Gerisine AWS sahip.
• Zihinsel model hâlâ işe yarar. Soyu bilmek, bir Scan'in neden pahalı olduğunu ve bir GSI okumasının neden gecikebileceğini açıklar — ikisi de orijinal tasarımdan çıkar.

Makale gerçekte neyi çözüyordu

Amazon'un alışveriş sepeti devre dışı kalamazdı. Yük altında yazmaları reddeden — ya da başarısız bir replica'da bloke olan — ilişkisel bir veritabanı kabul edilemezdi. 2007 Dynamo makalesi erişilebilirliği tutarlılığa tercih etti: yazmayı her zaman kabul et, anlaşmazlıkları sonra mutabakatla çöz. O takas, aşağıdaki her şeyin köküdür.

Bunu tek bir master olmadan yapmak için, Dynamo iki soruyu kendi başına yanıtlamak zorundaydı: bir key nerede yaşar ve bir okuma ya da yazma sayılmadan önce kaç kopya hemfikir olmalı?

Tutarlı hash'leme: bir key nerede yaşar

Makale her node'u bir hash halkasına yerleştirdi. Bir key'in konumu, key'inin hash'idir; saat yönünde bir sonraki node tarafından sahiplenilir ve sonraki N-1 node'a replike edilir. Bir node eklemek ya da kaldırmak yalnızca komşularının key'lerini yeniden karar — tüm veri kümesini değil. Bu tutarlı hash'lemedir ve DynamoDB'nin neredeyse harfiyen koruduğu tek fikirdir.

DynamoDB hâlâ item'ı hangi fiziksel partition'ın sakladığına karar vermek için partition key'ini hash'ler. Düşük-kardinaliteli bir partition key seç — diyelim iki değerli STATUS — ve aynı değere sahip her item aynı partition'a iner. İşte hot partition ayak kapanı budur ve halkanın doğrudan bir sonucudur: hash, özdeş key'leri özdeş evlere gönderir.

Quorum: kaç kopya hemfikir olmalı

Makalenin ikinci düğmesi bir quorumdu. N replica ile, bir yazma W tanesi ack'lediğinde başarılı olur ve bir okuma R tanesine danışır. R + W > N ayarla, herhangi bir okuma en yeni yazmayı tutan en az bir node'la örtüşür — güçlü tutarlılık. Onları daha düşük ayarla, tazeliği hız ve çalışma süresi için takas et.

Dynamo "özensiz" quorum'lar çalıştırdı: bir hedef node devre dışıysa, yazma bir vekile gitti ve sonra geri verildi (hinted handoff). Çatışan sürümler vector clock'larla etiketlendi ve okumada uygulama tarafından mutabakatla çözüldü.

DynamoDB neyi korudu neyi değiştirdi

DynamoDB hedefleri ve partition'lamayı miras aldı, sonra orijinali işletmesi zor yapan parçaları sildi.

Makalenin API'si iki çağrıydı: get(key) ve put(key, value). DynamoDB aynı key-value çekirdeğinin üstüne bir sort key, index'ler ve sorgular ekledi — ki bu yüzden bir Query ucuzdur (tek partition) ve bir Scan değildir (halkanın oluşturduğu her partition'ı gezer).

Bir yazma nasıl yol alır, o zaman ve şimdi

Aşağıdaki akış, makalenin quorum yazmasını DynamoDB'nin yönetilen yazmasıyla karşılaştırır. Şekil benzer; sorumluluk kodundan AWS'ye taşındı.

Makalede quorum matematiğine ve merge'e sen sahiptin; DynamoDB'de o tüm alt yarı yönetilir ve sen istek başına yalnızca ConsistentRead'i seçersin.

Soyun koduna nerede sızdığı

Nihai tutarlılık varsayılanı, makalenin görünmesidir. Bir global secondary index asenkron replike edilir, dolayısıyla yeni yazılmış bir item bir an için index'ten eksik olabilir — aynı "sonra mutabakatla çöz" pazarlığı, yalnızca index katmanında. O gecikmenin ne zaman önemli olduğu için GSI vs LSI'ye bak.

Güçlü tutarlılığı iki yolla geri satın alırsın. Bir base-tablo okumasında ConsistentRead: true kullan (leader kopyaya yönlenir) ya da bir yazmayı bir ConditionExpression ile koru, böylece yalnızca item'ın mevcut durumu eşleşirse iner. Birini DynamoDB expression builder içinde çiz — örneğin bir PutItem'i yalnızca-ekleme operasyonu yapmak için attribute_not_exists(PK), makalenin çatışma tespitinin modern karşılığı.

Hatırlanacak tek şey

Makale, bir yazmaya asla hayır dememe için optimize etti. DynamoDB o önyargıyı miras aldı, ki bu yüzden varsayılanları erişilebilirliği kayırır ve güçlü okumalar neden daha pahalıdır. Key'lerini single-table design'deki gibi tek-partition Query'leri için modelle ve bir Scan'e yalnızca gerçekten mecbur olduğunda uzan — halka, bir tam tablo gezmesini kulağa geldiği kadar pahalı yapar.

Partition'larını incelemek, talep üzerine tutarlı okumalar çalıştırmak ve bir GSI'nin kendi tablolarına karşı yetişmesini izlemek için DynoTable'ı dene.