DynamoDB Item Koleksiyonları

Bir item koleksiyonu, bir tablodaki (ya da dizindeki) aynı bölüm anahtarı değerini paylaşan tüm item'ların kümesidir. Açtığınız bir özellik değildir — anahtar şemanızın ortaya çıkardığı bir niteliktir.

İki item aynı bölüm anahtarını taşıdığı an bir koleksiyon oluştururlar ve o koleksiyon, DynamoDB'nin tek bir Query içinde birlikte okumanıza izin verdiği birim olur.

Bunu doğru yapın, okumalarınız tek bir gidiş-dönüşte geri gelir. Yanlış yapın, bir Scan ile takılıp kalırsınız.

DynamoDB item koleksiyonu nedir?

Bir DynamoDB item koleksiyonu, aynı bölüm anahtarı değerini paylaşan, birlikte depolanan ve sıralama anahtarına göre sıralanan tüm item'ların kümesidir. Etkinleştirdiğiniz bir özellik değildir — anahtar şemanızdan ortaya çıkar. Koleksiyon, tek bir Query'nin verimli biçimde okuduğu birimdir, oysa bir Scan her bölümü dolaşır.

• Bir koleksiyon sadece "aynı bölüm anahtarıdır." Aynı bölüm anahtarı değerine sahip iki ya da daha fazla item birlikte depolanır ve sıralama anahtarına göre sıralanır.
• Verimli bir Query'nin birimidir. Query bir koleksiyonu okur; Scan her bölümü dolaşır. Tüm performans hikâyesi budur.
• Sıralama anahtarı yoksa koleksiyon yoktur. Yalnızca bölüm anahtarlı bir tablo, anahtar başına bir item tutar — toplanacak bir şey yok.
• İki sınır ısırır: bir LSI varken 10 GB'lık koleksiyon başına tavan ve düşük kardinaliteli anahtarlardan kaynaklanan sıcak bölümler.

Sorun: ilgili item'ları birlikte okumak

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

SQL'den geliyorsanız, bir vehicle_id sütununu dizinler ve işi planlayıcıya bırakırdınız. Düz bir anahtar-değer deposunun böyle bir lüksü yoktur.

Her okumayı yalıtılmış bir kayıt olarak ele alır, bu yüzden o soru tüm tabloyu tarayıp filtrelemek demektir. 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 koleksiyonudur.

Bir koleksiyon gerçekte nedir

DynamoDB item'ları bölümlerde depolar ve her item'ı bölüm anahtarını hash'leyerek bir bölüme yönlendirir. Aynı bölüm anahtarı değerine sahip her item birlikte depolanır ve sıralama anahtarına göre sıralanır. Tek bir bölümde başlarlar ama bir LSI olmadan DynamoDB, büyük ya da sıcak bir koleksiyonu bölümler arasında bir sıralama anahtarı sınırında bölebilir; yalnızca bir LSI tüm koleksiyonu tek bir bölüme sabitler (bu yüzden aşağıdaki 10 GB'lık üst sınır yalnızca LSI'ye özgüdür).

AWS Developer Guide bunu tam olarak adlandırır: bir bölüm anahtarı değerini paylaşan item'lar bir item koleksiyonudur, birlikte depolanır ve sıralama anahtarına göre düzenlenir.

Bu, 2007 Amazon Dynamo makalesinin tanıttığı aynı fikirdir — anahtarları düğümlere atamak için tutarlı hash'leme — ilgili item'lar diskte yan yana otursun diye bir sıralama boyutuyla genişletilmiştir.

Yan yana ve sıralı oldukları için, DynamoDB onların bitişik bir dizisini tek bir aramayla döndürür. Query'nin ucuz, Scan'in olmamasının nedeni budur: Query tek bir koleksiyonu okur; Scan her bölümü dolaşır.

Bir koleksiyon oluşturmak için bir bileşik birincil anahtara ihtiyacınız var — bir bölüm anahtarı ve bir sıralama anahtarı. Yalnızca bölüm anahtarına dayanan bir tablo, anahtar değeri başına tam olarak bir item'a sahiptir, bu yüzden toplanacak bir şey yoktur.

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

Telemetri akışını bileşik bir anahtarla modelleyin. Bölüm anahtarı aracı tanımlar; sıralama anahtarı okumanın zaman damgasıdır, ki bu okumaları zaman damgası sırasında tutar (varsayılan olarak artan; en yeni önce için ScanIndexForward=false geçin).

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

Şu numaraya dikkat edin: meta veriye, herhangi bir TS#... değerinden önce sıralanan bir sıralama anahtarı (META) verin 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ın kalbindeki ebeveyn-ve-çocuklar desenidir.

Her kesikli kutu bir item koleksiyonudur: aynı bölüm anahtarı, sıralama anahtarına göre sıralanmış item'lar. Bir Query tam olarak bir kutuyu okur.

Bir koleksiyonu sorgulama

Koleksiyon sıralama anahtarına göre sıralı olduğu için, aralık okumalarını bedavaya alırsınız. Bir araç için on dakikalık bir pencerede kaydedilen okumaları çekmek için sıralama anahtarını sınırlarsınız:

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

Anahtar koşulu sizi bir koleksiyonla (vehicleId = :v) ve sonra onun bitişik bir dilimiyle (recordedAt BETWEEN ...) sınırlar. DynamoDB yalnızca o item'ları okur ve sana yalnızca onlar için fatura keser. Yalnızca meta veriyi mi istiyorsunuz? recordedAt = "META" tek META item'ını getirir.

Bu anahtar koşullarını ve projeksiyon ifadelerini elle kurmak zahmetlidir. DynamoDB Expression Builder senin için KeyConditionExpression'ı, ExpressionAttributeNames'i ve ExpressionAttributeValues'i üretir, böylece ayrılmış sözcük ve yer tutucu ayrıntıları ısırmaz.

Dizinlerdeki koleksiyonlar

Bir ikincil dizinin kendi anahtar şeması vardır, bu yüzden kendi item koleksiyonlarını oluşturur.

depotCode (bölüm) ve recordedAt (sıralama) üzerinde anahtarlanmış bir global secondary index ekleyin ve "DEP-LON-3 deposundan tüm okumalar, en yeni önce" o dizinin koleksiyonuna karşı tek bir Query olur — temel tablonun sunamayacağı bir okuma.

Dizin türünün önemli olmasının nedeni budur: hangi koleksiyonları oluşturabileceğinizi ve nasıl davranacaklarını yönetir. Takas için bkz. GSI ile LSI.

Keskin bir ayrım: bir local secondary index (LSI) temel tablonun bölüm anahtarını paylaşır, bu yüzden koleksiyonu temel item koleksiyonuna fiziksel olarak bağlıdır — ve bu bağ, aşağıdaki sert bir sınırı yaratır.

Isıran sınırlar

Item koleksiyonları güçlüdür ama iki kısıt anahtarları nasıl şekillendireceğinize karar verir:

• 10 GB LSI sınırı. Bir tablonun bir ya da daha fazla local secondary index'i varken, tek bir item koleksiyonu — bir bölüm anahtarı için temel item'lar artı onların LSI projeksiyonları — 10 GB'ı aşamaz. Onu aşın ve koleksiyonu büyüten yazmalar ItemCollectionSizeLimitExceededException ile başarısız olmaya başlar. Hiç LSI'si olmayan bir tablonun böyle bir koleksiyon başına tavanı yoktur. Sınırsız, sürekli büyüyen bir akışın (asla durmayan telemetri) bir LSI için neden kötü bir uyum olduğunun tam nedeni budur: koleksiyon yalnızca büyür. Bir GSI kendi bölümlerini alır, bu yüzden sınırı yan geçer.
• Sıcak bölümler. Bir koleksiyon bir bölümde yaşar ve tek bir bölümün sınırlı verimliliği vardır. Bir araç (ya da bir depotCode) trafiğin çılgın bir orantısız payını çekerse, tablo bütünüyle provisioned verimliliğinin çok altındayken bile o bölümü sıcak noktaya çevirebilirsiniz. Uyarlanabilir kapasite — AWS'nin "Advanced Design Patterns for DynamoDB" re:Invent derinlemesine oturumlarında ele alınır — sıcak anahtarları otomatik olarak izole edip güçlendirir, ama hiç dağılımı olmayan bir anahtarı kurtaramaz. Trafik birçok koleksiyona yayılsın diye yüksek kardinaliteli bölüm anahtarları seçin.

DynoTable'da görüntüleyin

Koleksiyonlar için sezgi geliştirmenin en hızlı yolu birine bakmaktır. DynoTable'da, bir bölüm anahtarını sorgulamak tüm koleksiyonu bitişik, sıralama anahtarına göre sıralı bir liste olarak render eder — META item'ı, zaman damgalı okumalarının tam önünde, ekranda, zihinsel bir yeniden kurma gerektirmeden oturur.

Tuzaklar ve sonraki adımlar

• Sıralama anahtarı yoksa koleksiyon yoktur. Yalnızca bölüm anahtarlı bir tablo ilgili item'ları gruplayamaz. Item'ları birlikte okumanız gerekiyorsa, bileşik bir anahtara ihtiyacınız var.
• Bir LSI koleksiyonunun sınırsız büyümesine izin vermeyin. Yalnızca-ekleme akışları, 10 GB'lık üst sınır nedeniyle bir LSI'ye değil, bir GSI'ye (ya da zaman kovalı bir bölüm anahtarına) aittir.
• Bölüm anahtarlarınızı dağıtın. Bir koleksiyon, içinde yaşadığı bölüm kadar ölçeklenebilirdir. Düşük kardinaliteli bölüm anahtarları sıcak noktalar yaratır.
• Scan'e değil, Query'ye uzanın. Koleksiyonlar, ilgili item'ları tek bir hedefli Query ile okuyabilesiniz diye vardır; bir Scan'e geri düşmek bu avantajı çöpe atar — bkz. Query ile Scan.

Kendi anahtar şemanızı eskizleyin, gerçek bir bölüm anahtarına karşı bir Query çalıştırın ve koleksiyonun sıralı geri gelmesini izleyin. DynoTable'ı indirin ve tablolarınızın koleksiyonlarını doğrudan keşfedin.