DynamoDB Güçlü Tutarlı ve Nihai Tutarlı Okumalar

Bir öğeyi güncellersin, hemen geri okursun ve eski değeri alırsın. Yazma başarılı olmuştur — bir an sonra aynı okuma yeni değeri döndürür. Bozuk bir şey yok: DynamoDB'nin varsayılan nihai tutarlı (eventually consistent) okumasına çarptın ve bundan istek bazında vazgeçebilirsin.

Bu, DynamoDB'nin sana doğrudan verdiği nadir doğruluk ayarlarından biridir ve gerçek bir bedeli vardır. Doğru yapmak, her modun neyi garanti ettiğini, neye mal olduğunu ve güçlü okumaların basitçe mevcut olmadığı yerleri bilmek demektir.

DynamoDB'de güçlü tutarlı ve nihai tutarlı okumalar arasındaki fark nedir?

Nihai tutarlı okuma (varsayılan), herhangi bir replika tarafından sunulur; bu yüzden bir yazmadan hemen sonra kısa süreliğine eski veri döndürebilir, ancak maliyeti yarı yarıyadır. Güçlü tutarlı okuma ise istek bazında ConsistentRead=true ile etkinleştirilir, partition'ın liderine yönlendirilir ve işlenmiş her yazmayı her zaman yansıtır — okuma kapasitesinin 2× maliyetinde.

• Nihai tutarlı (varsayılan) — bir yazmadan hemen sonra kısa süreliğine eski veri döndürebilir. En ucuz okuma modu.
• Güçlü tutarlı — okumadan önce işlenmiş her yazmayı her zaman yansıtır. İstek bazında ConsistentRead=true ile etkinleştir.
• Güçlü okumalar nihai okumanın 2× maliyetindedir. Güçlü tutarlı bir okuma, aynı veri için nihai tutarlı bir okumanın iki katı okuma kapasitesi tüketir.
• Her yerde değil. Temel tabloda ve bir Local Secondary Index üzerinde güçlü okuma elde edersin. Bir Global Secondary Index yalnızca nihai tutarlıdır — etkinleştirme yok.
• Varsayılan olarak nihai kullan. Güçlü okumaya yalnızca kendi az önce yazdığın veriyi okurken ve bir anlık eskilik yanlış olacağında başvur.

Sorun: en son yazmayı görmeyen bir okuma

Diyelim ki kullanıcı hesapları işletiyorsun. Bir kullanıcı bildirim e-postasını değiştiriyor, uygulaman güncellemeyi yazıyor ve onay ekranı yeni adresi göstermek için profili hemen yeniden okuyor. Varsayılan okuma modunda, o yeniden okuma henüz değişikliği almamış bir replikaya düşebilir — böylece kullanıcı eski e-postasını görür ve kaydın başarısız olduğunu sanır.

Pencere küçüktür (tipik olarak bir saniyenin epey altında) ve kendiliğinden kapanır. Ama "genellikle doğru", yazma-sonrası bir okuma onayı için yeterince iyi değildir. Güçlü tutarlılığın var olma nedeni tam da bu durumdur.

Nihai tutarlılık neden olur

DynamoDB her partition'ı ayrı Availability Zone'larda üç depolama düğümünde saklar — bir birincil ve iki replika. Bir yazma, birincile ve bir replikaya ulaştığında onaylanır; sonra üçüncü düğüme asenkron olarak yayılır.

Okumalar, yükü dağıtmak için, üç düğümün herhangi biri tarafından sunulabilir. Nihai tutarlı bir okuma, en son yazmanı henüz almamış bir düğüme isabet edebilir — böylece hafifçe eski bir değer döndürür. Güçlü tutarlı bir okuma ise partition'ın liderine yönlendirilir; lider her zaman en son işlenmiş veriyi tutar, bu yüzden asla eski sonuç döndürmez.

Tüm fark o çoğaltma gecikmesidir. Bu aynı zamanda 2× maliyeti de açıklar: güçlü okumalar, nihai okumaların yapabildiği gibi replikalar arasında yük dengelenemez, bu yüzden DynamoDB onları kapasitenin iki katı fiyatlandırır.

Maliyet, somut olarak

Okumalar her biri 4 KB'ye kadarını kapsayan Read Capacity Units (RCU) ile ölçülür. Bir RCU, 4 KB'lik bir öğenin bir güçlü tutarlı okumasını veya iki nihai tutarlı okumasını satın alır. Yani sık kullanılan bir okuma yolunda ConsistentRead=true yapmak okuma maliyetini ikiye katlar — yüksek trafikli bir endpoint'te bu, fark edeceğin bir kalemdir.

Güçlü okumaları varsayılanın yapmadan önce farkı kendi öğe boyutların ve istek oranların için DynamoDB fiyatlandırma hesaplayıcısı ile modelle — genelde her şeyde iki kat ödemeye değmez.

Güçlü okumaların nerede mevcut olduğu (ve olmadığı)

Bir GSI, temel tablodan asenkron olarak çoğaltılan kendi veri kopyasını tutar, bu yüzden asla güçlü bir okuma sunamaz. Bir erişim deseni gerçekten yazma-sonrası-okumaya ihtiyaç duyuyorsa ve onu bir GSI'den sunmayı planlıyorduysan, bu onu bunun yerine temel tablodan veya bir LSI'den sunman gerektiğinin işaretidir.

Tuzaklar ve sonraki adımlar

• Güçlü okumaları varsayılan yapma. Çoğu okuma saniye-altı bir eskilik penceresini tolere eder; her yerde 2× ödemek boşa harcamadır.
• Bir GSI'den yazma-sonrası-okuma bekleme. Tasarımı gereği nihaidir — bkz. bir GSI neden nihai tutarlıdır.
• İşlemler güçlü okur. TransactGetItems her zaman güçlü tutarlıdır — bkz. DynamoDB işlemleri (transactions).
• Tutarlılık kapasiteyle etkileşir. 2× çarpanı doğrudan on-demand ve provisioned maliyet planlamasına bağlanır.

DynamoDB tablolarını ve index'lerini API çağrıları yazmadan keşfetmek mi istiyorsun? DynoTable'ı indir ve verilerini doğrudan incele.