DynamoDB fiziksel partition'lar

Bir fiziksel partition, DynamoDB'nin verini gerçekte üzerinde sakladığı birimdir: bir dilim SSD, Availability Zone'lar arasında replike edilmiş, key uzayının bir dilimini tutar. Tablon mantıksal bir şeydir. Partition'lar bayt'ların — ve throughput limitlerinin — gerçekte yaşadığı yerdir.

DynamoDB partition'lar nasıl çalışır?

DynamoDB tablonu fiziksel partition'lara yayarak saklar — Availability Zone'lar arasında replike edilmiş SSD dilimleri. Her biri ~10 GB, saniyede 3.000 okuma birimi ve saniyede 1.000 yazma birimiyle sınırlıdır. Partition key'inin hash'i bir item'ın hangi partition'a düşeceğini belirler ve DynamoDB, partition'lar büyüdükçe veya ısındıkça onları otomatik olarak böler.

• Her partition ~10 GB depolama, saniyede 3.000 okuma birimi ve saniyede 1.000 yazma biriminde tepe yapar. O tavanlar partition başınadır, tablo başına değil.
• Partition key'inin hash'i partition'ı seçer. Aynı key'e sahip item'lar birlikte iner; bir hot key bir hot partition demektir.
• DynamoDB partition'ları senin için böler — boyuta göre ve sürekli ısıya göre — ama tüm trafiği tek bir yere yönlendiren bir key'i düzeltemez.
• Kapasite varken kısıtlama (throttle) belirtidir. Tablon %5 kullanımdayken bir ProvisionedThroughputExceeded hatası, tek bir partition'ın maksimuma ulaştığı anlamına gelir.

Bir item partition'ını nasıl bulur

DynamoDB partition-key değerini dahili bir hash fonksiyonundan geçirir. Hash çıktısı fiziksel partition'ı seçer. Aynı key girer, aynı partition çıkar — her seferinde.

SQL'den geliyorsan, bir analog yok. Ayarladığın bir index B-tree'si yok, elle atadığın bir shard key yok. Yerleşim, kontrol etmediğin ve asla görmediğin bir hash'tir.

Bir partition key'ini paylaşan item'lar bir item koleksiyonu oluşturur, birlikte saklanır ve sort key'e göre sıralanır. Tek bir key üzerindeki bir Query'yi ucuz yapan şey budur — tek bir partition'da tek bir bitişik dizi okur. (Bkz. Query vs Scan.)

Bir oyun için bir maç-olayı deposu ele al. Tablo key'leri arenaId (partition) ve eventKey (sort):

# Item
arenaId    = "ARENA#7f3a"
eventKey   = "EVT#1719100800#a91c"
playerTag  = "Nightjar"
dmgDealt   = 412

7f3a arenası için her olay aynı partition'a hash'lenir ve sort-key sırasında yığılır. "Bu maçın zaman çizelgesini oku" için harika. O tek arena tüm trafiği alırsa bir yükümlülük.

Her partition'ın zorladığı üç tavan

Tek bir partition en fazla şunu sunacak şekilde tasarlanmıştır:

Kaynak: AWS Best practices for designing partition keys kılavuzu.

Item boyutu matematiği ölçekler. 20 KB'lık bir item, güçlü tutarlı okuma başına 5 okuma birimine mal olur, dolayısıyla tek bir partition kısıtlanmadan (throttle) önce saniyede ~600 böyle okuma sunar — 3.000 değil. Yazma maliyetini 1 KB başına, okuma maliyetini 4 KB başına yukarı yuvarla.

Tuzak: bunlar partition limitleridir, tablo limitleri değil. Tablon 40.000 WCU için sağlanmış olabilir ve yine de kısıtlar (throttle), çünkü tüm yazmalar 1.000'de tepe yapan tek bir partition'ı dövüyor.

Partition'lar nasıl bölünür

DynamoDB iki durumda partition'ları otomatik olarak ekler. Asla bir komut çalıştırmazsın.

Boyuta göre bölme. Bir partition ~10 GB'a doğru dolduğunda, DynamoDB key aralığını ikiye böler ve item'ların yarısını yeni bir partition'a taşır. Depolama şeffaf olarak büyür; okumaların ve yazmaların boyunca çalışmaya devam eder.

Isıya göre bölme. Bir partition throughput tavanına yakın sürekli trafik aldığında, DynamoDB sıcak key aralığını böler, böylece her yarı kendi partition'ına iner. AWS buna split-for-heat mekanizması der. Kendiliğinden duran kısa kısıtlama (throttle) patlamaları genellikle bir bölmenin yeni olduğu anlamına gelir.

Bölme birçok key arasında yer açar, ama alttaki node püf noktadır: bir bölme bir key aralığını böler, asla tek bir key'i değil.

Bir hot key bölücüyü neden yener

İşte ayak kapanı. Bölme, partition key'lerin aralıklarını yeniden dağıtır. Trafiğin tek bir key değerinde yoğunlaşırsa, her istek aynı partition'a hash'lenir ve bölünecek aralık kalmaz.

7f3a arenası, diğer her arena boştayken saniyede 4.000 yazma çeken bir turnuva finali ise, 1.000'de kısıtlanırsın (throttle) — ve bir bölme yardımcı olamaz, çünkü 4.000'in tümü tek bir key'i paylaşır. Daha yeni KeyRangeThroughputExceeded kısıtlama (throttle) nedeni tam da bunu adlandırır: tablonun değil, tek bir partition'ın key aralığı limitini aşmıştır.

Çözüm veri modelinde, kapasite kaydırıcısında değil. Hot key'i write-shard yap: tek bir mantıksal arenanın N fiziksel partition'a yayılması için küçük bir son ek ekle.

arenaId = "ARENA#7f3a#3"   # shard 0..9, yazma başına seçilir

Okumalar sonra shard'lar boyunca yelpazelenir ve istemci tarafında birleşir. Key şekillerini ve her shard için Query'yi, bir satır uygulama koduna dokunmadan önce DynamoDB Expression Builder ile prototipleyebilirsin.

Bir nüans: LSI istisnası

Depolamanın partition key başına gerçekten sınırlandığı bir durum var. Bir Local Secondary Index olmadan, bir item koleksiyonu ihtiyaç duyduğu kadar partition'a otomatik bölünür — milyarlarca sort-key değeri sorun değil.

Bir LSI ekle, ve bir partition key için tüm koleksiyon tek bir 10 GB partition'a sığmalıdır, çünkü LSI onu paylaşır. Bu, GSI vs LSI'de kapsanan PK başına uçurumdur — çoğu ekibin GSI'lere uzanmasının bir başka nedeni.

Partition'ların serin kalması için tasarlamak

Gerçekte kontrol ettiğin kaldıraç partition key'dir. Satır sayısına göre çok sayıda ayrı değere sahip birini seç, böylece trafik eşit yayılsın. (Daha fazla desen single-table design'de.)

• Yüksek-kardinaliteli key. Kullanıcı başına ya da kiracı başına bir key, herkesin aynı anda dövdüğü gün başına ya da durum başına bir key'i yener.
• Bilinen hot key'lere dikkat et. Bir "mevcut turnuva" ya da "bugün" değeri, yola çıkmadan önce bir yoğunlaşma riskidir, sonra değil.
• Kaçınılmaz hot key'i parçala (shard). Tek bir key aşırı trafik almak zorunda olduğunda, bir son ek standart kaçış kapısıdır.

Kapasite varken kısıtlama (throttle), tek bir partition'ın sıcak olduğu sinyalin. Sorunlu item'ları incele ve DynoTable içinde parçalanmış (sharded) bir key düzenini prova et — onu kendi tablona yönelt, aşırı yüklenmiş key'i bul ve seni sayfalamadan önce çözümü modelle.