DynamoDB Sort Key Stratejileri: 3 Desen ve Hangisi Ne Zaman

Bir DynamoDB birincil anahtarı bir ya da iki nitelikten oluşur: yalnızca bir partition key, ya da bir partition key artı bir sort key. Partition key, hangi fiziksel partition'ın bir item'ı tuttuğuna karar verir.

Sort key ise o partition'ın içindeki item'ların sırasına karar verir — ve o sıralama, Query'yi güçlü kılan şeydir.

Yanlış sort key'i seç, yine de veri yazabilirsin, ama tek bir koleksiyondan aralık okumalarını, sıralamayı ve birkaç erişim modelini kaybedersin.

SQL'den geliyorsan, sonradan bir ORDER BY'a ya da ikincil bir index'e başvururdun. DynamoDB'de sırayı baştan anahtara pişirirsin, yoksa onu elde edemezsin.

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

Bir DynamoDB sort key, item'ları bir partition içinde sıralar; böylece Query, tek seferde bir item getirmek yerine aralık okumaları yapabilir — >=, between, begins_with. String sort key'ler UTF-8 baytlarına göre sıralanır (Number'lar sayısal olarak sıralanır); bu yüzden bir string anahtarı (bir ISO-8601 zaman damgası, sıfır-dolgulu bir sayı) bayt sırası okumak istediğin sıraya eşit olacak şekilde tasarla.

• Sort key, partition-içi index'indir. item koleksiyonunu diskte sıralar, böylece Query, tek bir GetItem yerine aralık okumaları (>=, between, begins_with) yapabilir.
• String sort key'ler UTF-8 baytlarına göre sıralanır (Number'lar sayısal olarak). Bir string anahtarı, bayt sırası okumak istediğin sıraya eşit olacak şekilde tasarla — bir ISO-8601 zaman damgası, sıfır-dolgulu bir sayı, asla ham bir UUID ya da 6/23/2026.
• İyi şekillenmiş tek bir sort key birçok erişim modeline hizmet eder. Bir bileşik anahtar (EVT#<timestamp>) aynı anda hem bir önek hem bir aralıktır — GSI gerekmez.
• Yön bedavadır. ScanIndexForward = false, aynı maliyette en yeniyi-önce okur; bunu taklit etmek için ters çevrilmiş zaman damgaları saklama.

Neden sort key kaldıraçtır

Bir sort key olmadan, bir partition'daki her item yalnızca tam birincil anahtarıyla adreslenebilir — en iyi durumda bir GetItem. Bir sort key ekle, DynamoDB item'ları partition içinde ona göre sıralı saklar, bu da Query'nin kilidini açar.

Bu, aralık koşulları (>=, between), önek eşleştirme (begins_with) ve artan ya da azalan okumak için bir ScanIndexForward bayrağı demektir.

AWS DynamoDB Developer Guide'a göre, bir partition key'i paylaşan tüm item'lar bir item koleksiyonu oluşturur ve diskte sort key'e göre sıralanır.

Yani sort key sadece ikinci bir tanımlayıcı değildir. Bir partition içinde ona karşı sorguladığın index'tir.

O sıralama, kodlanmış sort key üzerindeki bayt sırasıdır: string'ler UTF-8 baytlarına göre karşılaştırılır, sayılar sayısal olarak karşılaştırılır. Aşağıdaki neredeyse her stratejiyi bu tek gerçek yönlendirir.

Aralık sorgularının bir anlam ifade etmesini istiyorsan, bayt sırası okumak istediğin sıraya uymak zorundadır.

Strateji 1: sort key'i sıralanabilir yap

En yaygın hata, anlamlı biçimde sıralanmamış bir sort key'dir. Rastgele bir UUID sana benzersizlik verir ama kullanışlı bir aralık sorgusu vermez — "bana son 20'yi ver" imkansız hale gelir çünkü bayt sırası keyfidir.

Bunun yerine, üzerinde sıraladığın ve filtrelediğin değeri, bayt sırası mantıksal sırasına eşit olan bir gösterimle sort key'in içine kodla. Zaman damgaları için bu, sözlükbilimsel olarak sıralanabilir bir format demektir: bir ISO-8601 string'i ya da sıfır-dolgulu bir epoch.

ISO-8601, string karşılaştırması kronolojik karşılaştırmaya eşit olacak şekilde tasarlanmıştır — tam olarak bir aralık sorgusunun ihtiyaç duyduğu şey. 6/23/2026 gibi formatlardan kaçın; ay değiştiği anda yanlış sıralanırlar.

Sayılar üzerinde sıralıyorsan (bir sürüm sayacı, bir puan), 42'nin 9'dan önce değil sonra sıralanması için bir string yerine DynamoDB'nin yerel Number türünü kullan.

Bir sayı bir bileşik string sort key'in içinde yaşamak zorundaysa, onu sabit bir genişliğe sıfır-dolgula.

Strateji 2: hiyerarşi için bileşik sort key'ler

Bir sort key, en yaygın olarak # olmak üzere bir ayırıcıyla segmentleri birleştirerek bir hiyerarşiyi kodlayabilir. Tek bir begins_with koşulu, o zaman tüm bir alt-ağacı seçer:

begins_with(SK, "EVENT#2026-06#") yalnızca Haziran'ın olaylarını döndürür; daha geniş begins_with(SK, "EVENT#") ise hepsini döndürür.

Segment sıralaması bir tasarım kararıdır. Kabadan-inceye (yıl → ay → gün), ilgili item'ları bitişik tutar; böylece bir aralık okuması, partition boyunca dağılmak yerine tek bir ucuz sorgu olarak kalır.

Strateji 3: yönü ScanIndexForward ile kontrol et

DynamoDB, item'ları artan sort-key sırasında saklar ve varsayılan olarak bu şekilde okur. En yeniyi-önce okumak için — bir etkinlik akışının doğal sırası — Query üzerinde ScanIndexForward = false ayarla.

Bu, bir şema kararı değil, okuma-zamanı bir bayraktır: aynı koleksiyon her iki yöne de aynı maliyette hizmet eder. Azalan okumalar elde etmek için zaman damgalarını ters çevirme (bir "ters epoch" saklama).

Tek bir item koleksiyonu, artan sırada bir kez saklanır, her iki şekilde de okunur:

Aynı item'lar, aynı partition, aynı maliyet — yalnızca okuma yönü farklıdır.

İşlenmiş örnek: aktör kapsamlı bir denetim günlüğü

Diyelim ki bir SaaS üründe aktörler — kullanıcılar, hizmetler, API anahtarları — tarafından üretilen zaman damgalı olayları kaydediyorsun ve iki okuman var:

1. Tek bir aktör için etkinlik akışı, en yeni olay önce.
2. Bir soruşturma için bir aktörün belirli bir zaman penceresindeki olayları (örn. "iki dağıtım arasındaki her şey").

Her iki okuma da tek bir aktöre kapsamlıdır, bu yüzden aktör partition key ve olay zamanı sort key'dir. Aynı tablonun daha sonra başka varlıkları da tutabilmesi için genel anahtar adları kullan:

EVT# öneki artı bir ISO-8601 zaman damgası, sıralanabilir bir sort key verir. Okuma 1, en yeniyi-önce için ScanIndexForward = false ile Query PK = "ACTOR#u_8814"'tür. Okuma 2, sort key üzerinde bir between koşuluyla aynı partition'ı daraltır:

Query
PK = "ACTOR#u_8814"
AND SK BETWEEN "EVT#2026-06-23T00:00:00Z"
AND "EVT#2026-06-23T23:59:59Z"

Tek bir koleksiyon, iki erişim modeli, GSI yok — çünkü sort key hem bir önek (EVT#) hem bir aralıktır (zaman damgası). Azalan okuma ve pencere okuması, aynı sırada aynı item'lardır; yalnızca parametreler farklıdır.

O anahtar koşulunu elle kurarken, between sınırlarını ya da nitelik adlarındaki ayrılmış-kelime kaçışını yanlış yapmak kolaydır.

DynamoDB Expression Builder, bir begins_with ya da between sort-key koşulu için KeyConditionExpression'ı, ExpressionAttributeNames'i ve ExpressionAttributeValues'i üretir.

Çalışma zamanında kaçış hatalarını ayıklamak yerine, onu doğrudan SDK çağrına kopyala.

Bunu DynoTable'da yapın

Bir sort key tasarlamak yinelemelidir: birkaç temsili item yaz, aralık sorgusunu çalıştır ve satırların beklediğin sırada geri geldiğini kontrol et. Bunu bir GUI'de canlı bir tabloya karşı yapmak, koddan gidip gelmekten iyidir.

Sıralama yönünü çevir, between sınırlarını sıkılaştır ve dönen koleksiyonun tek bir satır kod yazmadan değiştiğini izle — bir sort-key tasarımını commit etmeden önce onaylamanın en hızlı yolu.

Tuzaklar ve sonraki adımlar

• Sort key'ler bir partition içinde benzersiz olmalıdır. İki olay bir zaman damgasını paylaşabiliyorsa, bileşiğin benzersiz kalması için sort key'e bir ayırt edici (bir sıra numarası ya da kısa bir id) ekle.
• Bir sıcak partition sıralamayla çözülemez. Bir aktör gerisinden çok daha fazla olay üretiyorsa, sort key seni kurtarmaz — yükü yayan bir partition-key tasarımına ihtiyacın var. Bkz. tek tablo tasarımı.
• İkinci bir sıralama düzeni ikinci bir index gerektirir. Temel tablonun sort key'i tek bir sıralama verir. Aynı item'ları farklı sıralamak için (örneğin olay türüne göre), farklı bir sort key'e sahip bir GSI ekle — yerel ve global ikincil index takaslarını tartarak.
• "Sonra sıralamak" için Scan'e başvurma. Bir Scan'den sonra istemci tarafında sıralamak, tüm tabloyu okur ve sıralamayı çöpe atar; bu, Scan ayak kapanıdır. Bunun yerine sırayı sort key'in içine it.

Anahtar koşulu doğru olduğunda, koleksiyonu modellemek, artan ve azalan sorguları yan yana çalıştırmak ve gönderilmeden önce sort-key stratejini gerçek verilere karşı doğrulamak için DynoTable'ı dene.