Dynamo Makalesinden DynamoDB'ye

2007 tarihli "Dynamo: Amazon's Highly Available Key-value Store" makalesi ve bugün kullandığınız DynamoDB, bir ad ve bir hedefi paylaşır — her ölçekte öngörülebilir performans — ama aynı sistem değildirler. Makale, kendinizin çalıştırdığı dahili, nihai tutarlı bir depolamayı tanımladı. DynamoDB ise dersleri koruyan ve mekanizmanın ç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 kullanılabilirlik — 2007 Amazon Dynamo makalesinden alır ve partition-key hashing fikrini neredeyse kelimesi kelimesine korudu. Ancak farklı, yönetilen bir sistemdir: makalenin vektör saatleri, gossip üyeliği ve ayarlanabilir okuma/yazma quorum'ları gitti, yerlerine AWS'ye ait dahili yapılar geldi.

• Makale kullanılabilirliği çözdü, ergonomiyi değil. İşi, bayram trafiği zirvesinde bir yazmayı asla reddetmemekti, bayat bir okuma döndürme pahasına bile olsa.
• DynamoDB şekli korudu, dahili yapıları değiştirdi. Anahtarın hash'iyle bölümlenmiş, AZ'ler arasında replike edilmiş, yatay ölçeklenmiş — ancak çakışma çözümleme iç yapıları (vektör saatleri, gossip, read-repair) gitti.
• Artık düğmeleri ayarlamıyorsunuz. Makaledeki N, R ve W tek bir seçim haline geldi: ConsistentRead true veya false. Geri kalanı AWS'ye ait.
• Zihinsel model hâlâ işe yarıyor. Soy ağacını bilmek, bir Scan'in neden pahalı olduğunu ve bir GSI okumasının neden gecikebileceğini açıklar — ikisi de orijinal tasarımdan kaynaklanır.

Makale aslında neyi çözüyordu

Amazon'un alışveriş sepeti çökemezdi. Yük altında yazmaları reddeden — ya da başarısız bir replikada bloke olan — ilişkisel bir veritabanı kabul edilemezdi. 2007 Dynamo makalesi tutarlılık yerine kullanılabilirliği seçti: yazmayı her zaman kabul et, anlaşmazlıkları sonra uzlaştır. Bu ödünleşim, 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 anahtar nerede yaşar ve bir okuma ya da yazma sayılmadan önce kaç kopya hemfikir olmalıdır?

Tutarlı hashing: bir anahtar nerede yaşar

Makale her düğümü bir hash halkasına yerleştirdi. Bir anahtarın konumu, anahtarının hash'idir; saat yönünde bir sonraki düğüme aittir ve takip eden N-1 düğüme replike edilir. Bir düğüm eklemek veya çıkarmak yalnızca komşularının anahtarlarını yeniden karıştırır — tüm veri kümesini değil. Bu tutarlı hashing'dir ve DynamoDB'nin neredeyse kelimesi kelimesine koruduğu tek fikirdir.

DynamoDB, item'ı hangi fiziksel partition'ın depoladığına karar vermek için hâlâ partition key'inizi hash'ler. Düşük kardinaliteli bir partition key seçin — diyelim iki değerli STATUS — ve aynı değere sahip her item aynı partition'a iner. Bu hot partition ayak tuzağıdır ve halkanın doğrudan bir sonucudur: hash, aynı anahtarları aynı evlere gönderir.

Quorum: kaç kopya hemfikir olmalı

Makalenin ikinci düğmesi bir quorumdu. N replikayla, bir yazma, onlardan W'si ack verdiğinde başarılı olur ve bir okuma, onlardan R'sine danışır. R + W > N ayarlayın, herhangi bir okuma en yeni yazmayı tutan en az bir düğümle örtüşür — güçlü tutarlılık. Onları daha düşük ayarlayın, tazeliği hız ve çalışma süresi için takas edersiniz.

Dynamo "gevşek" quorum'lar çalıştırdı: bir hedef düğüm çökmüşse, yazma bir vekile gitti ve sonradan geri teslim edildi (hinted handoff). Çakışan sürümler vektör saatleriyle etiketlendi ve okuma sırasında uygulama tarafından uzlaştırıldı.

DynamoDB neyi koruyup neyi değiştirdi

DynamoDB hedefleri ve bölümlemeyi devraldı, sonra orijinali işletmeyi zorlaştıran parçaları sildi.

Makalenin API'si iki çağrıydı: get(key) ve put(key, value). DynamoDB aynı key-value çekirdeğinin üzerine bir sort key, indeksler ve sorgular ekledi — bir Query'nin neden ucuz (bir partition) ve bir Scan'in neden ucuz olmadığının (halkanın oluşturduğu her partition'ı gezer) nedeni budur.

Bir yazma nasıl seyahat eder, o zaman ve şimdi

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

Makalede quorum matematiğine ve birleştirmeye siz sahiptiniz; DynamoDB'de o alt yarının tamamı yönetiliyor ve yalnızca istek başına ConsistentRead'i seçiyorsunuz.

Soy ağacı kodunuza nerede sızar

Nihai tutarlılık varsayılanı, makalenin kendini gösterdiği yerdir. Bir global ikincil indeks asenkron olarak replike edilir, bu yüzden yeni yazılan bir item bir an için indeksten eksik olabilir — aynı "sonra uzlaştır" pazarlığı, sadece indeks katmanında. O gecikmenin ne zaman önemli olduğu için GSI ve LSI sayfasına bakın.

Güçlü tutarlılığı iki şekilde geri satın alırsınız. Bir base-table okumasında ConsistentRead: true kullanın (lider kopyaya yönlendirir) veya bir yazmayı bir ConditionExpression ile koruyun, böylece yalnızca item'ın mevcut durumu eşleşirse iner. DynamoDB expression builder'da bir tane taslak oluşturun — örneğin bir PutItem'ı yalnızca-ekleme işlemi yapmak için attribute_not_exists(PK), makalenin çakışma tespitinin modern yerine geçeni.

Hatırlanması gereken tek şey

Makale, bir yazmaya asla hayır dememek için optimize edildi. DynamoDB o eğilimi devraldı, bu yüzden varsayılanları kullanılabilirliği tercih eder ve güçlü okumalar neden daha pahalıdır. Anahtarlarınızı tek-partition'lı Query'ler için modelleyin, single-table design sayfasındaki gibi, ve bir Scan'e yalnızca gerçekten zorunda olduğunuzda başvurun — halka, tam bir tablo taramasını kulağa geldiği kadar pahalı yapar.

DynoTable'ı deneyin, tablolarınızı ve GSI'lerini görüntüleyin, sonra SQL Workbench'te kendi verinize karşı JOIN'ler ve GROUP BY çalıştırın.