DynamoDB Global Tables
Bir global tablo, birden çok AWS bölgesine çoğaltılmış tek bir DynamoDB tablosudur ve her replika yazılabilirdir. DynamoDB bunları otomatik olarak senkronize tutar — kendi çoğaltmanızı çalıştırmadan, her bölgede düşük gecikmeli yerel okuma ve yazma ile bölgeler arası felaket kurtarma elde edersiniz.
Denetim günlüğü senaryosunda, bir AB müşterisi verilerinin eu-west-1'de
yaşamasını gerektirirken, geri kalanı us-east-1'de çalışır. Ve uyumluluk açısından
kritik bir günlük olarak, tam bir bölgesel kesintiden sağ çıkması gerekir. Bir global
tablo her ikisine de tek bir özellikle yanıt verir.
DynamoDB Global Tables nedir?
DynamoDB Global Tables, birden çok AWS bölgesine çoğaltılmış tek bir tablodur ve her replika okunabilir ve yazılabilirdir. DynamoDB bunları nihai olarak tutarlı asenkron çoğaltma üzerinden otomatik olarak senkronize eder ve çakışmaları son-yazan-kazanır ilkesiyle çözer. Her bölgede düşük gecikmeli yerel okuma ve yazma ile birlikte bölgeler arası felaket kurtarma elde edersiniz; bu, DynamoDB'nin %99,999 kullanılabilirlik SLA'sının temelini oluşturur.
- Çok bölgeli, active-active. Her replika tamamen okunabilir ve yazılabilir; herhangi bir bölgedeki yazmalar diğerlerine yayılır.
- Çoğaltma asenkron ve bölgeler arasında nihai olarak tutarlıdır — tipik olarak bir saniye içinde, ama anlık değil.
- Çakışmalar last-writer-wins ile çözülür. İki bölgede aynı öğeye eşzamanlı yazmalar, en yenisine indirgenir.
- %99,999 kullanılabilirlik SLA'sını destekler — çok bölgeli bir global tablo, DynamoDB'nin en yüksek kullanılabilirlik yapılandırmasıdır.
Sorun: tek bir bölge yeterli değil
Tek bölgeli bir tablonun, denetim günlüğünün kabul edemeyeceği iki sınırı vardır.
İlki, veri ikametgâhı: bir AB müşterisinin olayları AB'de saklanmalıdır, ama
uygulamanız ABD'de çalışır. İkincisi, felaket kurtarma: us-east-1 bir kesinti
yaşarsa, tek bölgeli bir denetim günlüğü kesinti boyunca okunamaz ve yazılamaz —
tam da kayda en çok ihtiyaç duyduğunuz anda.
İkisinden birini kendiniz inşa etmek — bölgeler arası çoğaltma, devre dışı kalma, çakışma yönetimi — büyük, hataya açık bir projedir. Global tablolar bunu bir yapılandırma seçimi haline getirir.
Global tablolar nasıl çalışır
Tabloya bir replika bölge eklersiniz; DynamoDB orada bir kopya oluşturur ve tüm replikaları senkronize tutar. AWS DynamoDB SSS'lerine göre global tablolar %99,999 kullanılabilirliğe kadar çok bölgeli çoğaltma sağlar ve her bölgenin replikası yerel okuma ve yazmalara hizmet eder.
İki tutarlılık kuralı davranışı tanımlar:
- Bölgeler arası çoğaltma asenkrondur.
us-east-1'deki bir yazma yerel olarak onaylanır, sonraeu-west-1'e yayılır — genellikle bir saniye içinde, ama bir yazmadan hemen sonra diğer bölgedeki bir okuma henüz görmeyebilir. (Güçlü tutarlı okumalar hâlâ çalışır, ama yalnızca tek bir bölge içinde.) - Çakışmalar last-writer-wins'tir. Aynı öğe iki bölgede neredeyse aynı anda yazılırsa, DynamoDB en son zaman damgalı yazmayı tutar ve diğerini atar.
Çalışılmış bir örnek: aynı zamanda DR olan bir AB replikası
Denetim günlüğü tablosunun replikası olarak eu-west-1 eklersiniz. Şimdi:
| yazma bölgesi | öğe | görünür yer | |
|---|---|---|---|
| us-east-1 | TENANT#acme | EVENT#…#a1 | her iki bölge (~1s AB gecikmesi) |
| eu-west-1 | TENANT#bmw | EVENT#…#e7 | her iki bölge (~1s ABD gecikmesi) |
AB müşterisinin uygulaması yerel eu-west-1 replikasına yazar ve ondan okur — düşük
gecikme ve bölge içinde ikamet eden veri. İkametgâhı karşılayan aynı çoğaltma,
felaket kurtarma olarak da iki katı işe yarar: us-east-1 çökerse, eu-west-1
replikası hâlâ tam günlüğü tutar ve trafiğe hizmet eder; ona devredersiniz.
Denetim günlüğü yalnızca-ekleme ve kiracı bazında bölümlendiği için, last-writer- wins burada esasen bir sorun değildir — belirli bir kiracının olayları tek bir bölgeden yazılır ve olay anahtarları benzersizdir, bu yüzden iki bölge aynı öğede nadiren yarışır. Bu şans değildir; yalnızca-ekleme bir günlüğün global tablolara en temiz uyumlardan biri olmasının nedeni tam da budur. Buna karşılık değiştirilebilir bir sayaç, eşzamanlı bölgeler arası yazmalar altında özen gerektirir.
DynoTable'da yapın
Bir replika ekledikten sonra, verinin yeni bölgeye gerçekten ulaştığını ve kaynakla
eşleştiğini doğrulamak istersiniz — AB replikasının gerçekten acme'nin olaylarını,
doğru özniteliklerle tuttuğunu ve geri kalmadığını.
DynoTable kendi kimlik bilgileriyle herhangi bir bölgeye bağlanır, böylece bir
pencereyi us-east-1'e, başka bir pencereyi eu-west-1'e yöneltip aynı kiracının
öğelerini yan yana karşılaştırarak çoğaltmayı doğrulayabilirsiniz.

Her replikaya çalıştıracağınız bölge bazındaki sorguları DynamoDB Expression Builder'da prototipleyebilirsiniz.
Tuzaklar ve sonraki adımlar
- Bölgeler arasında kendi yazmanızı okumayın. Çoğaltma gecikmesi, bir bölgedeki bir yazmanın bir saniye kadar başka bir bölgede görünmeyebileceği anlamına gelir. ABD'ye yazıp hemen AB'den okumayı, görmeyi bekleyerek yapmayın; güçlü tutarlılık yalnızca tek bölgelidir.
- Last-writer-wins sessizce veri düşürür. İki bölgede eşzamanlı yazılan değiştirilebilir öğeler için, kaybeden hiçbir hata olmadan atılır. Yalnızca-ekleme ya da öğe başına tek-yazar tasarımları (bu denetim günlüğü gibi) sorunu önler; paylaşılan değiştirilebilir durum çakışma-farkında bir tasarım gerektirir.
- Her replikanın bir maliyeti vardır. Her bölge tam bir kopya saklar ve kendi kapasitesini ve depolamasını faturalandırır — bir replika maliyeti kabaca iki katına çıkarır. Bölgeleri gerçek bir ikametgâh ya da DR ihtiyacı için ekleyin, varsayılan olarak değil.
- Yedekler replika bazındadır. Geri yüklenmiş bir global tablo bağımsız bir tablo olur — kurtarmayı bölge bazında planlayın. Bkz. yedekleme ve point-in-time recovery.
Global tablolar bir bölgeyi kaybetmeye karşı korur. Son operasyonel endişe, verilerinizi kaybetmeye — kötü bir dağıtım ya da kazara silme — karşı korumaktır: yedekleme ve point-in-time recovery.
Birden çok bölgeye bağlanıp global tablo replikalarınızın aynı veriyi tuttuğunu doğrulamak için DynoTable'ı indirin.


