DynamoDB İstek Yönlendirmesi Nasıl Çalışır

Gönderdiğiniz her okuma ya da yazma önce durumsuz istek yönlendiricilerinden oluşan bir filoya çarpar. Bir yönlendirici bölüm anahtarınızı hash'ler, hash'i o anahtarın verisine sahip depolama düğümüne eşler ve isteği oraya iletir. Bir anahtar aramasının, tablo bin öğe de tutsa bir milyar öğe de tutsa aynı maliyette olmasının nedeni bu tek sıçramadır.

DynamoDB istek yönlendirmesi nasıl çalışır?

DynamoDB her isteği, bölüm anahtarınızı hash'leyen, hash'i o bölüme sahip tek depolama düğümüne eşleyen ve okumayı ya da yazmayı oraya ileten durumsuz bir istek yönlendirici filosundan geçirir. Yönlendirme, anahtarın hash'inin saf bir fonksiyonudur; bu yüzden bir arama, tablo bin öğe de tutsa bir milyar öğe de tutsa aynı maliyettedir.

• İstek yönlendirici ön kapıdır. İsteğinizi alan, bölüm anahtarını hash'leyen ve onu o bölümü tutan depolama düğümüne yönlendiren durumsuz bir filodur — tarama yok, tüm tabloyu bilme gereği yok.
• Her şeye bölüm anahtarı karar verir. Yönlendirme, bölüm anahtarının hash'inin saf bir fonksiyonudur — aynı anahtar her zaman ona sahip olan bölüme yönlenir, dolayısıyla GetItem O(tablo boyutu) değil O(1)'dir.
• Bir birincil, iki ikincil. Bir yazma, bölümün birincil düğümüne düşer; düğüm de üç kopyadan ikisinden oluşan çoğunluk yazıyı kalıcılaştırdığında onaylar.
• Kötü anahtarlar tasarımı boşa çıkarır. Düşük kardinaliteli ya da "sıcak" bölüm anahtarı trafiği tek bir düğüme hunileştirir — yönlendirme gayet iyi, sorun anahtarınız.

Yönlendirmenin çözdüğü sorunla başlayın

SQL'den gelirken gözünüzde bir sorgu planlayıcı canlanır: istatistikleri okur, bir dizin seçer, belki tarar. Maliyet, dokunduğu veri miktarıyla ölçeklenir. Bu model, her ölçekte tek haneli milisaniyede cevap vermek zorunda olan bir anahtar-değer deposuna uymaz.

DynamoDB'nin cevabı, tek öğelik bir aramayı arama değil doğrudan adres yapmaktır. Bölüm anahtarı, filtrelediğiniz bir sütun değil, verinin fiziksel olarak nerede yaşadığını hesaplayan bir hash fonksiyonunun girdisidir. İstatistik yok, planlayıcı yok.

İlişkisel düşünceden çıkarken kabul ettiğiniz takas budur: anlık sorgu esnekliğinden vazgeçer, karşılığında sabit zamanlı adresleme alırsınız.

İstek yönlendiriciyle tanışın

Bir istek geldiğinde doğruca depolamaya gitmez. Önce bir istek yönlendiriciye çarpar — tüm servisin önünde duran, durumsuz ve yatay ölçeklenen bir filo. (USENIX ATC '22 DynamoDB makalesi bu istek yönlendirici filosunu anlatıyor.)

Yönlendirici üç iş yapar ve kendine ait hiç veri tutmaz:

• İsteği IAM'e karşı kimlik doğrular ve yetkilendirir.
• Ona sahip olan bölümü bulmak için bölüm anahtarını hash'ler.
• İsteği o bölümün depolama düğümüne iletir.

Yönlendiriciler durumsuz olduğu için servis yük altında daha fazlasını ekler. Hiçbiri darboğaz ve hiçbiri tek hata noktası değildir — orijinal sistemi de 2007 Amazon Dynamo makalesinin üzerine kurduğu özellik budur.

Tek bir okumayı yönlendiriciden geçirin

Bir drone filosu için telemetri tablosu düşünün. Öğeler DroneId (bölüm anahtarı) ve ReadingTs (sıralama anahtarı) ile anahtarlanır; BatteryPct ve AltitudeM gibi attribute'lar taşır.

23 Haziran'a ait tek bir drone'un ölçümlerini istiyorsunuz:

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

Aşağıdaki diyagram isteği yukarıdan aşağı izler — tek bir aşağı akış olarak okuyun.

Yönlendirici DRONE#A19F değerini hash'ler, onu o anahtara sahip bölüme eşler ve okumayı o bölümün birincil depolama düğümüne iletir; düğüm de öğeyi döndürür.

Hash, tablonun kaç bölümü varsa onlardan tek birini gösterir. Yönlendirici diğer bölümlere hiç bakmaz, bu yüzden drone — ve bölüm — eklemek bu aramayı yavaşlatmaz.

Bir bölümün gerçekte ne olduğunu bilin

Bölüm, bir depolama ve throughput birimidir. Her birinin bir tavanı vardır (kabaca 10 GB ve okuma/yazma kapasitesinin sabit bir dilimi) ve bir bölüm bu sınırlardan birini aştığında DynamoDB onu böler. Belirli bir bölüm anahtarına sahip her öğe tek bir bölümde başlar; bir LSI ya da monoton bir sıralama anahtarı sabitlemedikçe, split-for-heat o koleksiyonu daha sonra sıralama anahtarı aralığına göre ayırabilir — tek bir bölüm anahtarı üzerindeki Query'yi hâlâ ucuz kılan da budur.

Her bölüm, Erişilebilirlik Bölgelerine yayılmış üç depolama düğümüne çoğaltılır: bir birincil ve iki ikincil.

Bir yazma birincile gider; birincil de üç kopyadan ikisinden oluşan çoğunluk yazıyı kalıcılaştırdığında onaylar. Güçlü tutarlı bir okuma, son yazmayı yansıtsın diye birincile yönlendirilir. Nihai tutarlı bir okuma ise henüz yetişememiş bir ikincil tarafından karşılanabilir — yarı maliyet, muhtemelen bayat.

Tuzağı adıyla anın: sıcak bölüm anahtarı

Yönlendirme ancak bölüm anahtarınız kadar iyidir. Hash anahtarları eşit dağıtır; yani anahtarlarınızın kardinalitesi yüksek ve trafiği dengeliyse yük tüm düğümlere yayılır. Bu iki özellikten birini bozun, elinizde bir sıcak bölüm kalır.

Diyelim ki o telemetriyi DroneId yerine Region ile anahtarladınız. Artık us-east-1'deki her drone aynı bölüm anahtarını paylaşıyor — okumaları ve yazmaları aynı anahtar uzayı yuvasına hash'leniyor ve tek bir öğe koleksiyonu üzerinde yığılıyor. Yönlendirici işini kusursuz yapıyor; siz tüm filoyu tek bir bölümün kapasitesine hunilediniz.

Yönlendiricinin düğüm seçişini izleyemezsiniz, ama iyi yönlenen anahtarlar tasarlayabilirsiniz. Expression Builder içinde bir anahtar koşulu kurduğunuzda, PK = … ifadesinin soluna koyduğunuz bölüm anahtarı, yönlendiricinin hash'leyeceği tam değerdir — o değerin kardinalitesini yüksek tutmak, okumaları ayrı düğümlerde tutan şeydir.

Bunun erişim desenlerinizle bağı

İstek yönlendirmesi, tek tablo tasarımı kurallarını tartışmaya kapatan mekanizmadır: bölüm anahtarı etrafında modellersiniz, çünkü bölüm anahtarı adresin kendisidir. Bir Query'nin Scan'i yenmesinin nedeni de budur — Query yönlendirici üzerinden tek bir bölüme çarparken Scan her bölümü sırayla gezer.

İkincil dizinlerin kendi bölümleri ve kendi yönlendirmesi vardır: bir GSI, temel tablonunkinden bağımsız olarak kendi bölüm anahtarıyla yönlendirilir; tablo sıcak değilken bir GSI'ın sıcak olabilmesinin nedeni budur.

Sonraki adımlar

Tek düğüme değil, çok düğüme yönlenen anahtarlar tasarlayın. Hangi değerin hash'lendiğini tam olarak görmek için PK = … koşulunu Expression Builder içinde taslak olarak kurun, sonra bu sorguları kendi tablolarınıza karşı çalıştırıp her anahtar koşulunun tam olarak ne döndürdüğünü görmek için DynoTable'ı indirin.