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
GetItemO(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.
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önetir | Sunabildiği tutarlılık |
|---|---|---|
| Primary | Tüm yazmalar; güçlü tutarlı okumalar | Güçlü (kendi en son yazmasını görür) |
| Secondary | Nihai tutarlı okumalar; failover | Nihai (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.