DynamoDB Adaptive Capacity: Ne Yapar, Ne Yapmaz
DynamoDB tablonuzu partition'lara yayar, ancak trafiğiniz nadiren eşit yayılır. Burst capacity ve adaptive capacity, çarpık bir iş yükünün throttle olmasını durduran iki otomatik mekanizmadır — ta ki sert bir sınıra çarpana kadar.
DynamoDB adaptive capacity nedir?
DynamoDB adaptive capacity, kullanılmayan verimi bir 'a kaydıran otomatik bir mekanizmadır, böylece çarpık bir anahtar, tablonun geri kalanı boş dururken throttle olmaz. Burst capacity ile eşleştirildiğinde, zirveleri ve sürekli çarpıklığı ücretsiz emer — ancak tek bir anahtarı partition tavanının ötesine itemez.
- Burst capacity, kısa zirveleri atlatmak için size 5 dakikaya (300 saniye) kadar kullanılmayan verim ödünç verir. Ayarladığınız bir özellik değil, bir tampondur.
- Adaptive capacity, bir için verimi otomatik olarak yükseltir — tablonuzun geri kalanının kullanılmayan kapasitesinden çekerek — böylece çarpık bir anahtar throttle olmaz.
- Hatta bir hot item'ı kendi partition'ına izole eder, tek bir anahtara 3.000 RCU / 1.000 WCU'luk partition tavanına kadar verir.
- Anahtar tasarımını görmezden gelmenin ruhsatı değildir. Partition başına tavanın ötesinde ödünç alacak yer kalmaz — gerçekten hot bir anahtar yine de throttle olur.
Önce partition tavanını bilin
Her partition bağımsız olarak sınırlıdır: saniyede 3.000 okuma birimi ve 1.000 yazma birimi. Bu sınır fizikseldir, sağlanan değil — hem provisioned hem de on-demand tablolarda geçerlidir. (AWS, Burst and adaptive capacity.)
SQL'den gelirken, toplam sunucu yükü üzerinden akıl yürütürsünüz. DynamoDB'de throttle olan birim tek partition'dır ve çarpık bir anahtar, tablo %90 boş dururken erimeye geçebilir. İki mekanizmanın da kapatmak için var olduğu boşluk budur.
Burst capacity kısa zirveyi emer
Bir partition'ın verimini tam kullanmadığınız her seferinde, DynamoDB artakalanı biriktirir. Bu kullanılmayan kapasitenin 300 saniyeye kadarı rezervde tutulur ve ani bir burst, saniye başına oranınızın normalde izin vereceğinden daha hızlı onu boşaltabilir.
Görünmez ve otomatiktir. Onu boyutlandıramazsınız ve DynamoDB bunun bir kısmını kendi arka plan işine sessizce harcayabilir. Onu bursty trafik için bir yastık olarak ele alın — asla karşı planlayabileceğiniz bir başlık boşluğu olarak değil.
Adaptive capacity hot partition'ı güçlendirir
Burst capacity kısa zirveleri halleder. Adaptive capacity sürekli çarpıklığı halleder. Bir partition hot çalışırken komşuları boş dururken, DynamoDB verimi hot olana kaydırır — tablo toplamına ve partition tavanına kadar.
Diyelim ki VEHICLE#<id> (partition) ve TS#<epoch> (sort) ile anahtarlanmış bir
filo telemetri tablosu çalıştırıyorsunuz. Flash-satış bölgesindeki bir teslimat
minibüsü, diğerlerinin 10 katı ping yayıyor. Onun partition'ı hot; diğer 200
minibüsün partition'ları neredeyse boş duruyor.
Adaptive capacity bunu fark eder ve o tek partition'ın verimini yükseltir, soğuk partition'ların kullanılmayan kapasitesinden çekerek. Yapılandırma yok, maliyet yok, ısınma yok — Mayıs 2019'dan bu yana artış etkin biçimde anında. (AWS Database Blog, "How DynamoDB adaptive capacity accommodates uneven access patterns".)
Hot minibüsün partition'ı 150 WCU'ya ihtiyaç duyar ancak 100 WCU'luk eşit payı throttle olur; adaptive capacity, bunu karşılamak için soğuk partition'lardan boş WCU'yu ödünç alır.
İzolasyon: bir item sorun olduğunda
Çarpıklık her zaman anahtar-başına değildir — bazen tek bir item kızgın-hot olur.
Amansız trafik bir VEHICLE#HOT item'ını sürerse, DynamoDB'nin split-for-heat'i,
sık erişilen item tek başına inecek şekilde partition'ları yeniden dengeler.
Bir kez izole edildiğinde, o tek item'ın anahtarı tam partition tavanını: 3.000 RCU ve 1.000 WCU'yu çekebilir. Bu, bir anahtar için mutlak tavandır — üstünde bir mekanizma yoktur. (AWS, Key range throughput exceeded.)
Sabitlemeye değer bir uyarı: adaptive capacity, tablonun bir 'i olduğunda bir partition'lar arasında bölmez. Bir LSI, koleksiyonu tek bir partition'a bağlar — nedenini GSI ve LSI sayfasında görün.
Adaptive capacity sizi kurtaramadığında
İşte tuzak burada. İki mekanizma da verimi etrafta taşır; hiçbiri bir partition'ın fiziksel olarak izin verdiğinden fazlasını yaratmaz.
| Senaryo | Burst | Adaptive | Sonuç |
|---|---|---|---|
| Kısa zirve, tabloda boşluk var | Karşılar | — | Throttle yok |
| Sürekli çarpıklık, soğuk komşular | — | Hot'u güçlendirir | Throttle yok |
| Bir item, < 3K RCU / 1K WCU | — | İzole eder | Throttle yok |
| Bir item, > partition tavanı | Hızla boşalır | Tavanda | Throttle — yeniden tasarım gerekli |
| Aynı anda çok hot anahtar, tablo dolu | Hızla boşalır | Boşta hiçbir şey yok | Throttle — yeniden tasarım gerekli |
Tek bir anahtar meşru şekilde saniyede 1.000 yazmadan fazlasına ihtiyaç duyuyorsa, hiçbir otomatik mekanizma sizi kurtarmaz — yükü daha fazla anahtara yaymanız gerekir.
Write sharding her zamanki çözümdür: bir sonek ekleyin (VEHICLE#HOT#0 … #9),
böylece yazmalar partition'lar arasında dağılır, sonra okumaları geri toplayın.
O geri toplama, tıpkı single-table design içinde bir sorgu yolunu planlayacağınız gibi kasıtlı olarak modellenmesi gereken bir erişim modelidir — adaptive capacity zaman kazandırır, anahtar tasarımında bedava bir geçiş değil.
Kendi tablonuzda görün
Adaptive capacity tasarım gereği görünmezdir, bu yüzden onun üzerine tek bir belirti
aracılığıyla akıl yürütürsünüz: hangi anahtarlar hot. Sharded yazma yolunu
oluştururken, Expression Builder sonekli bir
anahtar için PutItem ve Query söz dizimini üretir.
Bir anahtarın verinizde gerçekte nasıl dağıldığını izlemek için, DynoTable'ı indirin ve adaptive capacity'nin işi hallettiğini varsaymadan önce item'ların anahtar başına nasıl biriktiğini görmek için SQL Workbench'te partition key'iniz üzerinde bir GROUP BY çalıştırın. Çarpıklığın okuma tarafı için Query ve Scan sayfasına bakın.