DynamoDB Sort Key Stratejileri

Bir DynamoDB birincil anahtarı bir veya iki attribute'tur: tek başına bir partition key ya da bir partition key artı bir sort key. Partition key, bir öğeyi hangi fiziksel partition'ın tuttuğuna karar verir.

Sort key, o partition içindeki öğelerin sırasına karar verir — ve Query'yi güçlü kılan o sıralamadır.

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

SQL'den gelince, sonradan bir ORDER BY veya bir secondary index'e uzanırdın. DynamoDB'de sırayı en baştan anahtara gömersin, yoksa onu elde edemezsin.

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

Bir DynamoDB sort key, partition içindeki öğeleri sıralar; böylece Query her seferinde tek bir öğe almak yerine aralık okumaları — >=, between, begins_with — yapabilir. Sıralama, kodlanmış anahtar üzerindeki byte-sırasıdır; bu nedenle anahtarı (bir ISO-8601 zaman damgası, sıfırla doldurulmuş bir sayı) byte-sırası okumak istediğin sırayla eşleşecek şekilde tasarla.

• Sort key, partition-içi index'indir. Item collection'ı disk üzerinde sıralar, böylece Query tek bir GetItem yerine aralık okumaları (>=, between, begins_with) yapabilir.
• Sıralama, kodlanmış anahtar üzerindeki byte-sırasıdır. Anahtarı, byte-sırası okumak istediğin sırayla eşit olacak şekilde tasarla — bir ISO-8601 zaman damgası, sıfırla doldurulmuş bir sayı, asla ham bir UUID veya 6/23/2026 değil.
• İyi şekillendirilmiş tek bir sort key birçok erişim desenine hizmet eder. Bir bileşik anahtar (EVT#<timestamp>) hem bir önek hem de bir aralıktır — GSI gerekmez.
• Yön bedavadır. ScanIndexForward = false aynı maliyetle en yeniden başlayarak 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 öğe yalnızca tam birincil anahtarıyla adreslenebilir — en iyi durumda bir GetItem. Bir sort key ekle ve DynamoDB öğeleri partition içinde ona göre sıralanmış saklar, bu da Query'yi açar.

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

AWS DynamoDB Developer Guide'a göre, bir partition key'i paylaşan tüm öğeler bir item collection oluşturur, disk üzerinde sort key'e göre sıralanır.

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

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

Aralık sorgularının bir anlam ifade etmesini istiyorsan, byte-sırası okumak istediğin sırayla eşleşmek zorundadır.

Strateji 1: sort key'i sıralanabilir yap

En yaygın hata, anlamlı şekilde sıralanmamış bir sort key'dir. Rastgele bir UUID sana benzersizlik verir ama hiçbir yararlı aralık sorgusu vermez — byte-sırası keyfi olduğu için "bana son 20'yi ver" imkansız hale gelir.

Bunun yerine, üzerinde sıraladığın ve filtrelediğin değeri, byte-sırası mantıksal sırasına eşit olan bir gösterimde sort key'in içine kodla. Zaman damgaları için bu, sözlüksel olarak sıralanabilir bir format demektir: bir ISO-8601 string'i veya sıfırla doldurulmuş bir epoch.

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

Sayılar üzerinde sıralıyorsan (bir versiyon 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ının bir bileşik string sort key'in içinde yaşaması gerekiyorsa, onu sabit bir genişliğe sıfırla doldur.

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

Bir sort key, segmentleri bir ayraçla, en yaygın olarak # ile birleştirerek bir hiyerarşi kodlayabilir. Tek bir begins_with koşulu sonra tüm bir alt ağacı seçer:

begins_with(SK, "EVENT#2026-06#") yalnızca haziran etkinliklerini döndürür; daha geniş begins_with(SK, "EVENT#") hepsini döndürür.

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

Strateji 3: yönü ScanIndexForward ile kontrol et

DynamoDB öğeleri artan sort-key sırasında saklar ve varsayılan olarak onları bu şekilde okur. En yeniden başlayarak okumak için — bir etkinlik akışı için doğal sıra — Query üzerinde ScanIndexForward = false ayarla.

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

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

Aynı öğeler, aynı partition, aynı maliyet — yalnızca okuma yönü farklı.

Tek istisna: azalan sıranın aynı zamanda bir sparse index'in veya bir pagination imlecinin ilerlediği sıra olması özellikle gerekiyorsa. Bunun dışında, ScanIndexForward daha basit kaldıraçtır.

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

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

1. Bir aktör için etkinlik akışı, en yeni etkinlik ilk.
2. Bir aktörün bir zaman penceresi içindeki etkinlikleri (örn. "iki dağıtım arasındaki her şey"), bir araştırma için.

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

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

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

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

O anahtar koşulunu elle oluştururken, between sınırlarını ya da attribute adları üzerindeki rezerve-kelime kaçışını yanlış yapmak kolaydır.

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

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

DynoTable'da yap

Bir sort key tasarlamak yinelemelidir: birkaç temsili öğe 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, kod üzerinden gidip gelmekten iyidir.

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

Tuzaklar ve sonraki adımlar

• Sort key'ler bir partition içinde benzersiz olmalı. İki etkinlik bir zaman damgasını paylaşabiliyorsa, bileşiğin benzersiz kalması için sort key'e bir ayrıştırıcı (bir sıra numarası veya kısa id) ekle.
• Sıcak bir partition sıralanarak aşılamaz. Bir aktör geri kalanından çok daha fazla etkinlik üretiyorsa, sort key seni kurtarmaz — yükü dağıtan bir partition-key tasarımına ihtiyacın var. Bkz. single-table tasarım.
• İkinci bir sıralama düzeni ikinci bir index gerektirir. Temel tablonun sort key'i bir sıralama verir. Aynı öğeleri farklı şekilde sıralamak için (diyelim ki etkinlik türüne göre), farklı bir sort key'e sahip bir GSI ekle — local ve global secondary index ödünleşimlerini tartarak.
• "Sonra sıralamak" için Scan'e uzanma. Bir Scan'den sonra istemci tarafında sıralamak tüm tabloyu okur ve sıralamayı çöpe atar; bu, Scan ayak tuzağıdır. Bunun yerine sırayı sort key'e it.

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