İleri6 dakikalık okuma

DynamoDB Request Routing Nasıl Çalışır

Gönderdiğin her okuma ya da yazma önce bir request router filosuna çarpar. Bir router partition key'ini hash'ler, hash'i o key'in verisine sahip depolama node'una eşler ve isteği oraya iletir. O tek sıçrama, bir key aramasının tablonun bin item mı yoksa bir milyar item mı tuttuğundan bağımsız aynı maliyette olmasının nedenidir.

DynamoDB request routing nasıl çalışır?

DynamoDB her isteği, partition key'ini hash'leyen, hash'i o partition'a sahip tek depolama node'una eşleyen ve okuma ya da yazmayı oraya ileten stateless bir request router filosuna yönlendirir. Routing, key'in hash'inin saf bir fonksiyonudur; dolayısıyla bir arama, tablonun bin item mı yoksa bir milyar item mı tuttuğundan bağımsız aynı maliyettedir.

  • Request router ön kapıdır. İsteğini alan, partition key'ini hash'leyen ve onu o partition'ı tutan depolama node'una yönlendiren stateless bir filodur — tarama yok, tüm tablo bilgisi gerekmez.
  • Partition key her şeye karar verir. Routing, partition key'in hash'inin saf bir fonksiyonudur. Aynı key, aynı node, her seferinde — dolayısıyla GetItem O(1)'dir, O(tablo boyutu) değil.
  • Bir primary, iki secondary. Bir yazma, partition'ın primary node'una iner, ki o dayanıklı olmadan önce Availability Zone'lar arasında iki secondary'ye replike eder.
  • Kötü key'ler tasarımı bozar. Düşük-kardinaliteli ya da "sıcak" bir partition key trafiği tek bir node'a yönlendirir — routing iyi, key'in sorun.

Routing'in çözdüğü sorunla başla

SQL'den geliyorsan, bir sorgu planlayıcısı resmedersin: istatistikleri okur, bir index seçer, belki tarar. Maliyet, dokunduğu veri miktarıyla ölçeklenir. O model, herhangi bir boyutta tek haneli milisaniyelerde cevap vermek zorunda olan bir key-value deposuna uymaz.

DynamoDB'nin cevabı, tek bir item aramasını bir arama değil, bir doğrudan adres yapmaktır. Partition key, üzerinde filtrelediğin bir sütun değildir — verinin fiziksel olarak nerede yaşadığını hesaplayan bir hash fonksiyonuna verilen girdidir. İstatistik yok, planlayıcı yok.

İlişkisel düşünceden uzaklaştığında kabul ettiğin takas budur: ad-hoc sorgu esnekliğinden vazgeçersin ve karşılığında sabit-zamanlı adresleme alırsın.

Request router'la tanış

Bir istek geldiğinde, doğrudan depolamaya gitmez. Bir request router'a çarpar — tüm servisin önünde duran, stateless, yatay ölçeklenen bir filo. (AWS re:Invent "DynamoDB Deep Dive" oturumları bu ön-uç filosunu açıklar.)

Router üç şey yapar ve kendi verisini tutmaz:

  • İsteği IAM'e karşı kimlik doğrular ve yetkilendirir.
  • Ona sahip partition'ı bulmak için partition key'i hash'ler.
  • İsteği o partition için depolama node'una iletir.

Router'lar stateless olduğundan, servis yük altında daha fazlasını ekler. Hiçbiri bir darboğaz değildir ve hiçbiri tek bir hata noktası değildir — orijinal sistemi etrafında inşa ettiği aynı özellik, 2007 Amazon Dynamo makalesi.

Bir okumayı router boyunca izle

Bir drone filosu için bir telemetri tablosu ele al. Item'lar DroneId (partition key) ve ReadingTs (sort key) ile key'lenmiş, BatteryPct ve AltitudeM gibi attribute'larla.

Bir drone için en son okumayı istersin:

PK = "DRONE#A19F"
SK begins_with "2026-06-23"

İşte router'ın onunla ne yaptığı. Aşağıdaki giriş, isteği yukarıdan aşağıya izler — onu tek bir aşağı doğru akış olarak oku.

İstemci: GetItemPK = DRONE#A19FRequest router(stateless filo)Hash(DRONE#A19F) anahtar uzayı yuvasıYuvayı, key'e sahippartition'a eşleO partition içinprimary nodeItem'ı okuDRONE#A19F

Router DRONE#A19F'yi hash'ler, onu o key'e sahip partition'a eşler ve okumayı o partition'ın primary depolama node'una iletir, ki o item'ı döndürür.

Anahtar içgörü: hash, tablonun sahip olduğu ne kadar partition varsa, bir partition'a işaret eder. Router asla diğer partition'lara bakmaz, dolayısıyla drone'lar — ve partition'lar — eklemek bu aramayı yavaşlatmaz.

Bir partition'ın gerçekte ne olduğunu bil

Bir partition bir depolama ve throughput birimidir. Her biri sınırlıdır (kabaca 10 GB ve okuma/yazma kapasitesinin sabit bir dilimi) ve DynamoDB bir partition'ı her iki limitini de aştığında böler. Belirli bir partition key'e sahip her item aynı partition'da yaşar, ki bu tek bir partition key üzerindeki bir Query'yi ucuz yapan şeydir.

Her partition, Availability Zone'lara yayılmış üç depolama node'una replike edilir: bir primary ve iki secondary.

Node rolüNe yönetirSunabildiği tutarlılık
PrimaryTüm yazmalar; güçlü tutarlı okumalarGüçlü (kendi en son yazmasını görür)
SecondaryNihai tutarlı okumalar; failoverNihai (primary'nin gerisinde kalabilir)

Bir yazma primary'ye gider, ki o dayanıklılığı onaylamadan önce secondary'lere replike eder. Bir güçlü tutarlı okuma, en son yazmayı yansıtması için primary'ye yönlendirilir. Bir nihai tutarlı okuma, henüz yetişmemiş bir secondary tarafından sunulabilir — maliyetin yarısı, muhtemelen bayat.

Ayak kapanını adlandır: bir hot partition key

Routing yalnızca partition key'in kadar iyidir. Hash key'leri eşit yayar, dolayısıyla key'lerin yüksek kardinaliteye ve eşit trafiğe sahipse, yük tüm node'lara yayılır. Her iki özelliği de boz, bir hot partition alırsın.

Diyelim ki o telemetriyi DroneId yerine Region'a göre key'liyorsun. Artık us-east-1'deki her drone tek bir partition key'i paylaşır — dolayısıyla her okuma ve yazması aynı node'a hash'lenir. Router işini mükemmel yapıyor; sen yalnızca tüm filoyu tek bir partition'ın kapasitesine yönlendirdin.

Router'ın bir node seçmesini izleyemezsin, ama iyi yönlenen key'ler tasarlayabilirsin. Expression Builder içinde bir key koşulu oluşturduğunda, PK = …'in soluna koyduğun partition key, router'ın hash'leyeceği tam değerdir — o değeri yüksek-kardinaliteli tutmak, okumaları ayrı node'larda tutan şeydir.

Bunun erişim desenlerine nasıl bağlandığı

Request routing, single-table design kurallarını tartışılmaz yapan mekanizmadır: partition key etrafında modellersin, çünkü partition key _adres_dir. Ayrıca bir Query'nin bir Scan'i yenmesinin nedenidir — bir Query router aracılığıyla tek bir partition'a çarpar, bir Scan ise her partition'ı sırayla gezer.

Secondary index'ler kendi partition'larını ve kendi routing'lerini alır: bir GSI kendi partition key'iyle yönlendirilir, base tablonunkinden bağımsız olarak, ki bu yüzden bir GSI, tablo sıcak olmasa bile sıcak olabilir.

Sonraki adımlar

Tek bir node'a değil, birçok node'a yönlenen key'ler tasarla. Tam olarak hangi değerin hash'lendiğini görmek için Expression Builder içinde PK = … koşulunu çiz, sonra o sorguları kendi tablolarına karşı çalıştırmak ve hangi partition key'lerin gerçekte trafiğini taşıdığını izlemek için DynoTable'ı indir.

Güncellendi