DynamoDB Item Collection'ları

Bir item collection, bir tablodaki (veya index'teki) aynı partition key değerini paylaşan tüm öğelerin kümesidir. Açtığın bir özellik değildir — anahtar şemanın ortaya çıkan bir özelliğidir.

İki öğe aynı partition key'i taşıdığı anda bir collection oluştururlar ve o collection, DynamoDB'nin tek bir Query ile birlikte okumana izin verdiği birim haline gelir.

Bunu doğru yap, okumaların tek bir turda geri gelsin. Yanlış yap, bir Scan'e takılı kal.

DynamoDB item collection'ı nedir?

Bir DynamoDB item collection'ı, aynı partition key değerini paylaşan tüm öğelerin kümesidir; birlikte saklanır ve sort key'e göre sıralanır. Açtığın bir özellik değildir — anahtar şemandan ortaya çıkar. Collection, tek bir Query'nin verimli biçimde okuduğu birimdir; bir Scan ise her partition'da dolaşır.

Bir collection sadece "aynı partition key"dir. Aynı partition key değerine sahip iki veya daha fazla öğe birlikte saklanır, sort key'e göre sıralanır.
Verimli bir Query'nin birimidir. Query bir collection okur; Scan her partition'da dolaşır. Tüm performans hikayesi budur.
Sort key yok, collection yok. Yalnızca partition-key olan bir tablo, anahtar başına tek bir öğe tutar — toplanacak bir şey yok.
İki sınır ısırır: bir LSI mevcut olduğunda collection başına 10 GB tavanı ve düşük kardinaliteli anahtarlardan kaynaklanan sıcak partition'lar.

Sorun: ilgili öğeleri birlikte okumak

Diyelim ki her biri birkaç saniyede bir telemetri yayan — hız, soğutucu sıcaklığı, yakıt seviyesi — bir araç filosu işletiyorsun. Baskın okuma "bana V-7741 aracının son okumalarını ver"dir.

SQL'den gelince, bir vehicle_id sütununu indeksler ve planlayıcının işi yapmasına güvenirdin. Düz bir key-value deposunun böyle bir lüksü yoktur.

Her okumayı izole bir kayıt olarak ele alır, bu yüzden o soru tüm tabloyu taramak ve filtrelemek anlamına gelir. Yavaş, pahalı ve filo büyüdükçe daha da kötü.

DynamoDB'nin yanıtı, "bir araç için tüm okumaları" fiziksel olarak gruplanmış, doğrudan adreslenebilir bir şey yapmaktır. O gruplama item collection'dır.

Bir collection gerçekte nedir

DynamoDB öğeleri partition'larda saklar ve her öğeyi partition key'ini hash'leyerek bir partition'a yönlendirir. Bu nedenle aynı partition key değerine sahip her öğe, aynı partition'a, sort key'e göre sıralanmış olarak iner.

AWS Developer Guide bunu tam olarak adlandırır: bir partition key değerini paylaşan öğeler bir item collection'dır, birlikte saklanır ve sort key'e göre sıralanır.

Bu, 2007 Amazon Dynamo makalesinin tanıttığı aynı fikirdir — anahtarları düğümlere atamak için tutarlı hashing — ilgili öğelerin disk üzerinde bitişik oturması için bir sıralama boyutuyla genişletilmiştir.

Bitişik ve sıralı oldukları için, DynamoDB bunların bitişik bir dizisini tek bir arama (seek) ile döndürür. Bu yüzden Query ucuzdur ve Scan değildir: Query tek bir collection okur; Scan her partition'da dolaşır.

Bir collection oluşturmak için bir bileşik birincil anahtara ihtiyacın var — bir partition key ve bir sort key. Yalnızca partition key üzerinde anahtarlanmış bir tabloda anahtar değeri başına tam olarak bir öğe vardır, bu yüzden toplanacak bir şey yoktur.

İşlenmiş örneğimiz: araç → telemetri okumaları

Telemetri akışını bir bileşik anahtarla modelle. Partition key aracı tanımlar; sort key, okumayı collection içinde en yeniden en eskiye sıralı tutan okumanın zaman damgasıdır.

PK (vehicleId)   SK (recordedAt)        attributes
VEH#V-7741       META                    plate, model, depotCode
VEH#V-7741       TS#2026-06-23T09:00:01Z speedKph, coolantC, fuelPct
VEH#V-7741       TS#2026-06-23T09:00:06Z speedKph, coolantC, fuelPct
VEH#V-7741       TS#2026-06-23T09:00:11Z speedKph, coolantC, fuelPct
VEH#V-7742       META                    plate, model, depotCode
VEH#V-7742       TS#2026-06-23T09:00:02Z speedKph, coolantC, fuelPct

Burada iki collection yaşar — araç başına bir tane. META öğesi (araç meta verisi) ve V-7741'in tüm okumaları bir collection oluşturur; V-7742'nin öğeleri başka birini oluşturur.

Püf noktasına dikkat et: meta veriye, herhangi bir TS#... değerinden önce sıralanan bir sort key (META) ver ve PK = "VEH#V-7741" üzerinde tek bir Query, aracın profilini ve okumalarını birlikte döndürür.

Bu, single-table tasarımın kalbindeki üst-ve-alt-öğe desenidir.

Her kesik çizgili kutu bir item collection'dır: aynı partition key, sort key'e göre sıralanmış öğeler. Bir Query tam olarak bir kutu okur.

Bir collection'ı sorgulama

Collection sort key'e göre sıralandığı için, aralık okumalarını bedava elde edersin. Bir araç için on dakikalık bir pencerede kaydedilen okumaları çekmek için sort key'i sınırlarsın:

Query
  KeyConditionExpression: vehicleId = :v AND recordedAt BETWEEN :from AND :to
  ScanIndexForward: false        # newest first

Anahtar koşulu seni bir collection'a (vehicleId = :v) ve ardından onun bitişik bir dilimine (recordedAt BETWEEN ...) kısıtlar. DynamoDB yalnızca o öğeleri okur ve sana yalnızca onlar için fatura keser. Yalnızca meta veri mi istiyorsun? recordedAt = "META" tek META öğesini getirir.

Bu anahtar koşullarını ve projection ifadelerini elle oluşturmak zahmetlidir. DynamoDB Expression Builder senin için KeyConditionExpression'ı, ExpressionAttributeNames'i ve ExpressionAttributeValues'ı üretir, böylece rezerve kelime ve placeholder ayrıntıları can yakmaz.

Index'lerde collection'lar

Bir secondary index'in kendi anahtar şeması vardır, bu yüzden kendi item collection'larını oluşturur.

depotCode (partition) ve recordedAt (sort) üzerinde anahtarlanmış bir global secondary index ekle ve "DEP-LON-3 deposundan tüm okumalar, en yeni ilk" o index'in collection'ına karşı tek bir Query haline gelir — temel tablonun sunamayacağı bir okuma.

Bu yüzden index türü önemlidir: hangi collection'ları oluşturabileceğini ve nasıl davranacaklarını yönetir. Ödünleşim için bkz. GSI ve LSI.

Keskin bir ayrım: bir local secondary index (LSI) temel tablonun partition key'ini paylaşır, bu yüzden collection'ı fiziksel olarak temel item collection'a bağlıdır — ve bu bağ, aşağıdaki katı bir sınır yaratır.

Isıran sınırlar

Item collection'ları güçlüdür, ancak iki kısıt anahtarları nasıl şekillendireceğine karar verir:

10 GB LSI sınırı. Bir tablonun bir veya daha fazla local secondary index'i olduğunda, tek bir item collection — temel öğeler artı bir partition key için LSI yansıtmaları — 10 GB'ı aşamaz. Aş ve collection'ı büyüten yazmalar ItemCollectionSizeLimitExceeded ile başarısız olmaya başlar. LSI'si olmayan bir tablonun böyle bir collection başına tavanı yoktur. Bu tam olarak, sınırsız, sürekli büyüyen bir akışın (hiç durmayan telemetri) bir LSI için neden kötü bir uyum olduğudur: collection yalnızca büyür. Bir GSI kendi partition'larını alır, bu yüzden sınırı atlatır.
Sıcak partition'lar. Bir collection bir partition'da yaşar ve tek bir partition'ın sonlu bir verimi (throughput) vardır. Bir araç (veya bir depotCode) trafiğin orantısız derecede büyük bir payını çekerse, tablo bir bütün olarak yetersiz sağlanmış olsa bile o partition'ı sıcak nokta haline getirebilirsin. Adaptive capacity — AWS'nin "Advanced Design Patterns for DynamoDB" re:Invent derinlemesine incelemelerinde işlenir — sıcak anahtarları otomatik olarak izole eder ve güçlendirir, ancak hiç yayılımı olmayan bir anahtarı kurtaramaz. Trafiğin birçok collection'a dağılması için yüksek kardinaliteli partition key'leri seç.

DynoTable'da gör

Collection'lar için sezgi geliştirmenin en hızlı yolu birine bakmaktır. DynoTable'da, bir partition key'i sorgulamak tüm collection'ı bitişik, sort-key sıralı bir liste olarak render eder — META öğesi, zaman damgalı okumalarının hemen önünde oturur, ekranda, hiçbir zihinsel yeniden inşa gerekmeden.

Tek bir partition key üzerinde bir Query, collection'daki her öğeyi sort key'e göre sıralı gösteriyor.

Tuzaklar ve sonraki adımlar

Sort key yok, collection yok. Yalnızca partition-key olan bir tablo ilgili öğeleri gruplayamaz. Öğeleri birlikte okuman gerekiyorsa, bir bileşik anahtara ihtiyacın var.
Bir LSI collection'ının sınırsız büyümesine izin verme. Yalnızca ekleme yapan (append-only) akışlar, 10 GB tavanı nedeniyle bir LSI'ye değil, bir GSI'ye (veya zaman-kovalı bir partition key'e) aittir.
Partition key'lerini yay. Bir collection yalnızca yaşadığı partition kadar ölçeklenebilirdir. Düşük kardinaliteli partition key'leri sıcak noktalar yaratır.
Scan'e değil, Query'ye uzan. Collection'lar, ilgili öğeleri tek bir hedefli Query ile okuyabilmen için vardır; bir Scan'e geri dönmek o avantajı çöpe atar — bkz. Query ve Scan.

Kendi anahtar şemanı çiz, gerçek bir partition key'e karşı bir Query çalıştır ve collection'ın sıralı geri geldiğini izle. DynoTable'ı indir ve tablolarının collection'larını doğrudan keşfet.