DynamoDB fiziksel bölümleri

Fiziksel bölüm, DynamoDB'nin verinizi gerçekten sakladığı birimdir: Erişilebilirlik Bölgeleri arasında çoğaltılan, anahtar uzayınızın bir dilimini tutan bir SSD parçası. Tablonuz mantıksal bir kavramdır. Baytların — ve throughput sınırlarının — gerçekten yaşadığı yer bölümlerdir.

DynamoDB bölümleri nasıl çalışır?

DynamoDB tablonuzu fiziksel bölümlere yayarak saklar — Erişilebilirlik Bölgeleri arasında çoğaltılan SSD dilimleri. Her biri yaklaşık 10 GB, saniyede 3.000 okuma birimi ve saniyede 1.000 yazma birimiyle sınırlıdır. Bir öğenin hangi bölüme düşeceğine bölüm anahtarınızın hash'i karar verir ve bölümler büyüdükçe ya da ısındıkça DynamoDB onları otomatik olarak böler.

• Her bölüm yaklaşık 10 GB depolama, saniyede 3.000 okuma birimi ve saniyede 1.000 yazma birimiyle sınırlıdır. Bu tavanlar tablo başına değil, bölüm başınadır.
• Bölümü, bölüm anahtarınızın hash'i seçer. Aynı anahtara sahip öğeler birlikte düşer; tek bir sıcak sıcak öğe — ya da monoton artan bir sıralama anahtarı — tek bir bölümü sabitleyen şeydir.
• Bölümleri sizin yerinize DynamoDB böler — boyuta ve sürekli ısıya göre; bir LSI ya da hep artan bir sıralama anahtarı engellemedikçe, tek bir anahtarın öğe koleksiyonunu sıralama anahtarı sınırında bölmek de buna dahildir.
• Kapasite boldayken kısıtlanmak asıl işarettir. Tablonuz %5 kullanımdayken alınan bir ProvisionedThroughputExceeded hatası, tek bir bölümün tavana vurduğu anlamına gelir.

Bir öğe bölümünü nasıl bulur

DynamoDB, bölüm anahtarı değerinizi dahili bir hash fonksiyonundan geçirir. Hash çıktısı fiziksel bölümü seçer. Aynı anahtar girer, aynı bölüm çıkar — her seferinde.

SQL'den gelenler için bir karşılığı yok. Ayarladığınız bir dizin B-ağacı yok, elle atadığınız bir shard anahtarı yok. Yerleşim, denetlemediğiniz ve hiç görmediğiniz bir hash'tir.

Aynı bölüm anahtarını paylaşan öğeler bir öğe koleksiyonu oluşturur; birlikte saklanır ve sıralama anahtarına göre sıralanır. Tek bir anahtar üzerindeki Query'yi ucuz kılan da budur — tek bir bölümde bitişik tek bir diziyi okur. (Bkz. Query ile Scan.)

Bir oyun için maç olayı deposu düşünün. Tablo anahtarları arenaId (bölüm) ve eventKey (sıralama):

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

7f3a arenasına ait her olay aynı bölüme hash'lenir ve sıralama anahtarı düzeninde üst üste yığılır. "Bu maçın zaman çizelgesini oku" için harika. Tüm trafiği o tek arena alıyorsa bir yük.

Her bölümün dayattığı üç tavan

Tek bir bölüm en fazla şunu sunacak şekilde tasarlanmıştır:

Kaynak: AWS Best practices for designing partition keys rehberi.

Öğe boyutu hesabı ölçekler. 20 KB'lık bir öğe, güçlü tutarlı okuma başına 5 okuma birimi tutar; yani bir bölüm kısıtlanmadan önce saniyede 3.000 değil, yaklaşık 600 böyle okuma sunar. Yazma maliyetini 1 KB'lık, okuma maliyetini 4 KB'lık dilimlere yukarı yuvarlayın.

Bu tavanlar tablo başına değil, bölüm başınadır. Tablonuz 40.000 WCU için sağlanabilir ve yine de kısıtlanabilir, çünkü tüm yazmalar 1.000'de tavan yapan tek bir bölümü dövmektedir.

Bölümler nasıl bölünür

DynamoDB iki durumda otomatik olarak bölüm ekler. Hiçbir komut çalıştırmazsınız.

Boyuta göre bölme. Bir bölüm ~10 GB'a doğru dolduğunda DynamoDB anahtar aralığını ikiye böler ve öğelerin yarısını yeni bir bölüme taşır. Depolama şeffaf biçimde büyür; okumalarınız ve yazmalarınız bu süre boyunca çalışmaya devam eder.

Isıya göre bölme. Bir bölüm throughput tavanına yakın sürekli trafik aldığında, DynamoDB sıcak anahtar aralığını böler ve her yarı kendi bölümüne düşer. AWS buna split-for-heat mekanizması diyor. Kendiliğinden duran kısa kısıtlama patlamaları genellikle split-for-heat'in devreye girdiği anlamına gelir — gerçi kısa ani yükselmeler sadece burst kapasitesinin tükenmesi de olabilir.

Bölme, çok sayıda anahtar arasında yer açar ve split-for-heat tek bir anahtarın öğe koleksiyonunu bile bir sıralama anahtarı kesiminde ayırabilir. Yayamadığı şey tek bir sıcak öğe, hep artan bir sıralama anahtarı ya da bir LSI tarafından sabitlenmiş bir koleksiyondur.

Sıcak bir anahtar bölücüyü neden yener

Bölme, bölüm anahtarlarının aralıklarını yeniden dağıtır. Trafiğiniz tek bir anahtar değerinde yoğunlaşıyorsa her istek aynı bölüme hash'lenir ve bölünecek aralık kalmaz.

7f3a arenası, diğer bütün arenalar boştayken saniyede 4.000 yazma çeken bir turnuva finaliyse 1.000'de kısıtlanırsınız — ve split-for-heat burada kurtaramaz, çünkü zaman damgası önekli eventKey monotondur; her yeni yazma tek bir dar sıralama anahtarı aralığının ön ucuna düşer ve ayrılacak bir şey kalmaz. Daha yeni KeyRangeThroughputExceeded kısıtlama nedeni tam olarak bunu adlandırır: sınırını aşan şey tablo değil, tek bir bölümün anahtar aralığıdır.

Çözüm kapasite kaydıracında değil, veri modelindedir. Sıcak anahtarı yazma tarafında shard'layın: küçük bir sonek ekleyin ki tek bir mantıksal arena N fiziksel bölüme yayılsın.

arenaId = "ARENA#7f3a#3"   # shard 0..9, chosen per write

Okumalar bundan sonra shard'lara dağılır ve istemci tarafında birleştirilir. Anahtar biçimlerinin ve her shard için Query'nin prototipini, tek satır uygulama koduna dokunmadan DynamoDB Expression Builder içinde kurabilirsiniz.

Bir ayrıntı: LSI istisnası

Depolamanın bölüm anahtarı başına gerçekten sınırlandığı tek bir durum var. Local Secondary Index olmadan bir öğe koleksiyonu, hem saklanan baytlarını hem throughput'unu karşılamak için gereken kadar bölüme yayılır — milyarlarca sıralama anahtarı değeri sorun değildir.

Bir LSI ekleyin; artık tek bir bölüm anahtarına ait koleksiyonun tamamı tek bir 10 GB'lık bölüme sığmak zorundadır, çünkü LSI onu paylaşır. Bu, PK başına yaşanan ve GSI ile LSI sayfasında anlatılan uçurumdur — çoğu ekibin GSI'lara yönelmesinin bir başka nedeni.

Bölümler serin kalsın diye tasarlamak

Gerçekten denetlediğiniz kaldıraç bölüm anahtarıdır. Satır sayısına oranla çok sayıda farklı değeri olan bir anahtar seçin ki trafik eşit yayılsın. (Daha fazla desen için tek tablo tasarımı.)

• Yüksek kardinaliteli anahtar. Kullanıcı ya da kiracı başına bir anahtar, herkesin aynı anda dövdüğü gün ya da durum başına bir anahtardan iyidir.
• Bilinen sıcak anahtarlara dikkat edin. "Güncel turnuva" ya da "bugün" gibi bir değer, siz canlıya çıktıktan sonra değil, önce fark edilmesi gereken bir yoğunlaşma riskidir.
• Kaçınılmaz sıcak anahtarı shard'layın. Bir anahtarın orantısız trafik alması gerekiyorsa, sonek standart kaçış kapısıdır.

Kapasite boldayken kısıtlanmak, bir bölümün sıcak olduğunun işaretidir. Çarpık öğe koleksiyonunu inceleyin ve shard'lanmış bir anahtar düzenini DynoTable içinde prova edin — onu kendi tablonuza yöneltin, hangi anahtarların baskın olduğunu görmek için SQL Workbench'te bölüm anahtarına göre GROUP BY yapın ve düzeltmeyi size çağrı gelmeden modelleyin.