DynamoDB Partition Key'ler Nasıl Çalışır

Partition key'in bir sütun değildir — bir adrestir. DynamoDB o key'i hash'ler ve hash, item'ı hangi fiziksel makinenin sakladığına karar verir. Key'i iyi seç, yük yayılsın; kötü seç, bir sunucu tüm ateşi yesin.

DynamoDB partition key'leri nasıl çalışır?

DynamoDB, partition key'ini dahili bir hash fonksiyonundan geçirir ve bu hash, item'ı hangi fiziksel partition'ın sakladığına karar verir. Key, SQL sütunu gibi sıralanmaz veya indekslenmez — o bir adrestir. Yüksek-kardinaliteli bir key seç ve yük birçok partition'a yayılsın; düşük-kardinaliteli bir key seç ve tek bir partition tüm ısıyı üstlensin.

• Key hash'lenir, sıralanmaz. DynamoDB partition key'ini bir partition seçmek için dahili bir hash'ten geçirir. İki bitişik değer diskte birbirinden çok uzakta durur.
• Bir partition gerçek bir depolama birimidir. Her biri yaklaşık 10 GB, saniyede 3.000 okuma birimi ve saniyede 1.000 yazma biriminde tepe yapar. Trafiğin, key'lerinin yayıldığı partition sayısına bölünür.
• Hot key'ler ayak kapanıdır. İsteklerin çoğunu tek bir partition-key değerine yönlendir, o partition'da kısıtlanırsın (throttle) ve tablonun geri kalanı boş durur.
• Yüksek-kardinaliteli key'ler kazanır. Ne kadar çok ayrı, eşit-vurulan key değerin varsa, o kadar çok partition yükü emer.

Key'in gerçekte ne yaptığıyla başla

SQL'den geliyorsan, bir birincil key, üzerinde JOIN ve ORDER BY yaptığın sıralı, indekslenmiş bir sütundur. DynamoDB'de partition key (bazen hash key denir) farklı bir şey yapar: yerleşime karar verir.

DynamoDB partition key'ini dahili bir hash fonksiyonuna besler. Çıktı bir anahtar uzayına eşlenir ve anahtar uzayı aralıklara dilimlenir — her aralık bir fiziksel partition tarafından sahiplenilir. O partition, gerçek bir node üzerindeki gerçek depolamadır.

Yani partition key tek bir soruyu cevaplar: bu item'ı hangi makine tutuyor? Varsa sort key, yalnızca item'ları o makinenin içinde sıralar. Yerleşimde hiçbir rolü yoktur.

Bir yazmayı hash boyunca izle

Diyelim ki cihaz okumalarını alan bir SaaS çalıştırıyorsun. Tablon SensorReadings, bir partition key deviceId ve bir sort key readingTs kullanıyor. deviceId = "vac-7741" için bir okuma yazıyorsun.

İşte o yazmanın izlediği yol — key'inden indiği diske kadar:

vac-7741 için yazma anahtar uzayında bir noktaya hash'lenir, o nokta P2'nin aralığına düşer ve item P2'ye iner — orada readingTs'e göre sıralanır.

İçselleştirilecek şey: "vac-7741" ve "vac-7742" bir karakter farklıdır, ama hash'leri ilişkisizdir. Neredeyse kesinlikle farklı partition'larda yaşarlar. Partition anahtar uzayında "yakın" diye bir şey yoktur.

Bu, DynamoDB'nin orijinal tasarımdan miras aldığı tutarlı-hash'leme fikridir — 2007 Amazon Dynamo makalesi ("Dynamo: Amazon's Highly Available Key-value Store") key'leri node'lara tam da bu şekilde hash'leyerek yaydı, böylece tek bir node darboğaz olmasın.

Partition'ın katı limitlerine saygı göster

Bir fiziksel partition sonludur. AWS DynamoDB Developer Guide'a göre, her biri yaklaşık şu kadarını tutar:

Bir partition 10 GB'ı geçecek şekilde dolduğunda ya da sağlanan throughput'un daha fazla yere ihtiyaç duyduğunda, DynamoDB onu böler — anahtar uzayı aralığı bölünür ve item'lar daha fazla partition'a yeniden dağıtılır. Bu otomatiktir; onu sen tetiklemezsin.

Püf nokta: bir bölme item'ları hash'lerine göre yayar. Her sıcak istek tek bir partition-key değerini hedefliyorsa, bölme yardımcı olmaz — tüm o trafik yine aynı noktaya hash'lenir. Tek bir key'in yükünü partition'lara bölemezsin.

Tuzağı adlandır: hot partition

Bir hot partition klasik ayak kapanıdır. Tek bir partition-key değeri (ya da küçük bir kümesi) trafiğin orantısız bir payını emdiğinde olur.

Somut başarısızlık: SensorReadings'i "us-east", "eu-west" gibi değerlere sahip bir partition key region'a geçiriyorsun. Üç bölge, üç key değeri demek — en fazla — üç partition'ın gerçek iş yapması demek. "us-east"'i okumalarla döv, o 3.000 RCU'da kısıtlanır (throttle) iken tablonun toplam sağlanan kapasitesi kullanılmadan durur.

DynamoDB'nin adaptive capacity'si bunu yumuşatır — kullanılmayan throughput'u meşgul bir partition'a kaydırabilir ve tek bir çok-sıcak key'i kendi partition'ına izole edebilir. AWS bunu re:Invent "Advanced Design Patterns for DynamoDB" derin-inceleme oturumlarında detaylandırdı. Ama adaptive capacity zaman alır, dokunulmazlık değil: tek bir bireysel key'in yükünü alt bölemez. Yayılma için tasarla; güvenlik ağına yaslanma.

Yüksek-kardinaliteli bir key seç

Çözüm kardinalitedir — ayrı key değerlerinin sayısı ve trafiğin onlara ne kadar eşit vurduğu.

• Düşük kardinalite (region, status, true/false): az partition, trafik yoğunlaşır, erken kısıtlanırsın (throttle).
• Yüksek kardinalite (deviceId, userId, bir sipariş ID'si): birçok değer birçok partition'a hash'lenir, yük yayılır, boşluk büyür.

SQL'den geliyorsan bir status sütununu memnuniyetle indeksler ve üzerinde filtrelerdin. Bir DynamoDB partition key'i olarak bu bir tuzaktır — yayılamaz. Düşük-kardinaliteli attribute'ları filtre olarak ya da bir secondary index'in sort key'i olarak tut, asla yerleşime karar veren şey olarak değil.

Doğal olarak iyi bir key yine de çarpıkken — geri kalanı geçen bir avuç balina kiracı — bir mantıksal değeri N partition'a yelpazelemek için bir son ek ekle, örn. parçalanmış (sharded) bir yazma yolu için tenantId#3. Okumada yeniden toplarsın.

Key'in yayıldıktan sonra bir partition içindeki item'ları hedeflemek için, sort key üzerinde bir KeyConditionExpression yazarsın. Onu koda bağlamadan önce kendi şemana karşı DynamoDB expression builder içinde birleştirebilirsin:

deviceId = "vac-7741" AND readingTs BETWEEN "2026-06-01" AND "2026-06-30"

Bu, bir cihazın Haziran penceresini tek bir partition'dan okur — bir Query, bir Scan değil. Partition key makineyi sabitler; sort-key koşulu satırları daraltır.

Tuzaklar ve sonraki adımlar

• Bir key'i SQL'de iyi okunduğu için seçme. Onu neyin yayıldığına göre seç. Önce kardinalite, sonra sorgu kolaylığı.
• Tablonun toplam kapasitesinin key başına senin olduğunu varsayma. Throughput partition başınadır; tek bir sıcak değer, tablo boş görünürken kısıtlayabilir.
• Bir bölmeyle savaşma. Otomatiktir ve hash güdümlüdür — senin işin ona yayılması için yeterince ayrı key vermektir.

Key'in temiz yayıldıktan sonra, bir sonraki kararlar bir partition'ın içine item'ların nasıl yerleştirileceğidir — single-table design'a bak — ve bir secondary index ikinci bir erişim deseni için ne zaman doğru araçtır.

Gerçek partition'larına ve key dağılımına göz atmak ve bir hot key'i seni sayfalamadan önce yakalamak için DynoTable'ı indir.