DynamoDB'de adaptive capacity

DynamoDB tablonu partition'lara yayar, ama trafiğin nadiren eşit yayılır. Burst capacity ve adaptive capacity, çarpık bir iş yükünün kısıtlanmasını (throttle) durduran iki otomatik mekanizmadır — ta ki katı bir limite çarpana kadar.

DynamoDB adaptive capacity nedir?

DynamoDB adaptive capacity, kullanılmayan throughput'u bir hot partition'a kaydıran otomatik bir mekanizmadır; böylece çarpık bir key, tablonun geri kalanı boş dururken kısıtlanmaz (throttle). Burst capacity ile birlikte ani yükleri ve sürekli çarpıklığı ücretsiz emer — ama tek bir key'i partition tavanının ötesine itemez.

• Burst capacity kısa ani yükleri atlatman için sana 5 dakikaya (300 saniye) kadar kullanılmamış throughput ödünç verir. O bir tampondur, ayarlayacağın bir özellik değil.
• Adaptive capacity bir "sıcak" partition için throughput'u otomatik olarak yükseltir — tablonun geri kalanının kullanılmayan kapasitesinden çekerek — böylece çarpık bir key kısıtlanmaz (throttle).
• Hatta sıcak bir item'ı kendi partition'ına izole eder, tek bir key'e partition tavanı olan 3.000 RCU / 1.000 WCU'ya kadar verir.
• Key tasarımını görmezden gelme ruhsatı değildir. Partition başına tavanın ötesinde ödünç alınacak yer kalmaz — gerçekten sıcak bir key yine kısıtlanır (throttle).

Önce partition tavanını bil

Her partition bağımsız olarak sınırlıdır: saniyede 3.000 okuma birimi ve 1.000 yazma birimi. O limit sağlanan değil, fizikseldir — hem sağlanan hem on-demand tablolarda geçerlidir. (AWS, Burst and adaptive capacity.)

SQL'den geliyorsan, toplam sunucu yükü üzerine akıl yürütürsün. DynamoDB'de kısıtlayan (throttle) birim tek bir partition'dır ve çarpık tek bir key, tablo %90 boşken eriyebilir. Her iki mekanizmanın da kapatmak için var olduğu boşluk budur.

Burst capacity kısa ani yükü emer

Bir partition'ın throughput'unu tam olarak kullanmadığın her zaman, DynamoDB artanı bankaya koyar. O kullanılmayan kapasitenin 300 saniyeye kadarı yedekte tutulur ve ani bir patlama onu, saniye başına oranının normalde izin vereceğinden daha hızlı boşaltabilir.

Görünmez ve otomatiktir. Onu boyutlandıramazsın ve DynamoDB bir kısmını sessizce kendi arka plan işine harcayabilir. Onu patlamalı trafik için bir yastık olarak ele al — asla karşı plan yapabileceğin bir boşluk olarak değil.

Adaptive capacity hot partition'ı yükseltir

Burst capacity kısa ani yükleri ele alır. Adaptive capacity sürekli çarpıklığı ele alır. Bir partition sıcakken komşuları boş durduğunda, DynamoDB throughput'u sıcak olana kaydırır — tablo toplamına ve partition tavanına kadar.

Diyelim ki VEHICLE#<id> (partition) ve TS#<epoch> (sort) ile key'lenmiş bir filo-telemetri tablosu çalıştırıyorsun. Bir flaş-indirim bölgesindeki bir teslimat minibüsü, diğerlerinden 10× ping yayıyor. Onun partition'ı sıcak; diğer 200 minibüsün partition'ları neredeyse boş duruyor.

Adaptive capacity bunu fark eder ve o tek partition'ın throughput'unu, soğuk partition'ların kullanılmayan kapasitesinden çekerek yükseltir. Config yok, maliyet yok, ısınma yok — Mayıs 2019'dan beri artış esasen anlıktır. (AWS Database Blog, "How DynamoDB adaptive capacity accommodates uneven access patterns".)

Sıcak minibüsün partition'ı 150 WCU'ya ihtiyaç duyar ama 100-WCU'luk eşit payı kısıtlanır (throttle); adaptive capacity onu karşılamak için soğuk partition'lardan boş WCU'yu ödünç alır.

İzolasyon: tek bir item sorun olduğunda

Çarpıklık her zaman key başına değildir — bazen tek bir item kor gibi sıcaktır. Amansız trafik tek bir VEHICLE#HOT item'ını sürerse, DynamoDB'nin split-for-heat'i partition'ları yeniden dengeler, böylece sık erişilen item yalnız iner.

İzole edildiğinde, o tek item'ın key'i tam partition tavanını: 3.000 RCU ve 1.000 WCU'yu çekebilir. Bu, tek bir key için mutlak çatıdır — onun üzerinde bir mekanizma yoktur. (AWS, Key range throughput exceeded.)

Sabitlenmeye değer bir uyarı: adaptive capacity, tablonun bir Local Secondary Index'i olduğunda bir item koleksiyonunu partition'lar arasında bölmez. Bir LSI koleksiyonu tek bir partition'a bağlar — nedeni için GSI vs LSI'ye bak.

Adaptive capacity seni kurtaramadığında

İşte tuzak. Her iki mekanizma da throughput'u etrafta taşır; ikisi de bir partition'ın fiziksel olarak izin verdiğinden fazlasını yaratmaz.

Tek bir key meşru olarak saniyede 1.000'den fazla yazmaya ihtiyaç duyuyorsa, hiçbir otomatik mekanizma seni kurtarmaz — yükü daha fazla key'e yaymalısın.

Write sharding her zamanki çözümdür: bir son ek ekle (VEHICLE#HOT#0 … #9) böylece yazmalar partition'lara yelpazelenir, sonra okumaları geri içeri yelpazele.

O içeri-yelpazeleme kendi başına kasıtlı modellenecek bir erişim desenidir, tıpkı single-table design'de bir sorgu yolunu planlayacağın gibi — adaptive capacity zaman alır, key tasarımına bir bedava geçiş değil.

Kendi tablonda gör

Adaptive capacity tasarım gereği görünmezdir, dolayısıyla onun üzerine tek bir belirti aracılığıyla akıl yürütürsün: hangi key'ler sıcak. Parçalanmış (sharded) yazma yolunu kurarken, Expression Builder sonekli bir key için PutItem ve Query sözdizimini üretir.

Bir key'in verin boyunca gerçekte nasıl dağıldığını izlemek için, DynoTable'ı indir ve adaptive capacity'nin halletmiş olduğunu varsaymadan önce gerçek tablolarında partition yayılımını incele. Çarpıklığın okuma tarafı için Query vs Scan'e bak.