Orta6 dakikalık okuma

DynamoDB'de Type Özniteliği

SQL'deki bir satırın tablosu onun türüdür; documents'deki bir satır ise bir belgedir. bir DynamoDB tek tablo tüm varlıkları tek bir şema altında karıştırır, böylece bir öğe hiçbir şey taşımaz "Bu nedir?" sorusunun yerleşik yanıtı.

Type özelliği bu yanıtı geri getirir: her öğede düz bir dize Temsil ettiği varlığın adını verir.

DynamoDB'de Type özniteliği nedir?

Tür özelliği, her öğenin üzerine, öğenin temsil ettiği varlığı adlandıran EntityType: "Document" gibi damgaladığınız düz bir dizedir. single table birçok varlığı tek bir şema altında karıştırdığından öğeler yerleşik bir tür taşımaz. Tür onu geri koyar; böylece kodunuz satırları tanımlar, tek bir varlığa GSI filtreler ve taşıma işlemlerinde hayatta kalır.

  • Her yazmaya bir Tür damgası ekleyin. Bir özellik — EntityType: "Document" — her öğede istisna yok. Birkaç bayta mal olur ve sizi daha sonra kurtarır.
  • Karma bölümdeki varlıkları tanımlar. Query çalışma alanlarını döndürür, belgeler ve yorumlar birlikte; Tür kodunuza hangisinin olduğunu söyler anahtar öneklerini ayrıştırmadan.
  • üzerinde tek varlık filtrelemeyi destekler. Türü bir dizine yansıtın ve aşırı yüklenmiş bir dizini tam olarak tek bir varlık türüne daraltabilirsiniz.
  • Bu, geçişler için kaçış yolunuzdur. Yeniden modellemek veya taşımak için dışa aktardığınızda Bir varlığı kendi tablosuna bağladığınızda Tür, böldüğünüz sütundur.

Karışık bir tablo neden tipi kaybeder

Single-table design her varlığı tek bir yerde saklar PK ve SK gibi genel tuşların arkasındaki tablo. Bütün mesele bu – bir Query bir ebeveyni ve çocuklarını birlikte döndürür. Ama bu bir bölümün olduğu anlamına gelir heterojen.

Bir SaaS belge işbirliği uygulamasını kullanın. Bir çalışma alanı bölümü çalışma alanını tutar Kayıt, belgeler ve bu belgelere ilişkin yorumlar:

PKSKattributes
WS#acmeMETAname, plan, seats
WS#acmeDOC#a1#METAtitle, owner, wordCount
WS#acmeDOC#a1#CMT#0007author, body, createdAt
WS#acmeDOC#a1#CMT#0008author, body, createdAt

Query PK = "WS#acme" faturalı bir okumada dört öğenin tamamını geri verir. Şimdi senin kodda ham öğelerin bir listesi var ve hangisinin belge olduğunu söylemenin güvenilir bir yolu yok. bu bir yorumdur — SK ile eşleşen dizeden kısadır, bu da kırılgandır Anahtar formatınızın değiştiği an.

Her öğeye Type bas

Düzeltme, her yazma işleminde varlığı adlandıran bir özelliktir:

PKSKEntityTypetitle
WS#acmeMETAWorkspace
WS#acmeDOC#a1#METADocumentQ3 Roadmap
WS#acmeDOC#a1#CMT#0007Comment

item.EntityType === "Document" üzerinde dallanma istikrarlı bir eşitlik kontrolüdür. SK.startsWith("DOC#") && SK.includes("#CMT#")'ün ayrıştırılması başarısızlığa uğrayan bir tahmindir anahtarı çevirdiğinizde. Tür, okuma mantığınızı anahtar kodlamanızdan ayırır — gerçek kazanç budur.

Query PK = 'WS#acme'Karışık partitionEntityType: 'Workspace'EntityType: 'Document'EntityType: 'Comment'Type'a göre yönlendir

Bir okuma üç varlık türünü döndürür; Type özelliği her öğeyi şuraya yönlendirir: tuşlara dokunmadan sağ işleyici.

Bir GSI'yi tek bir varlığa filtrele

Type, endekslerdeki yerini koruyor. Diyelim ki GSI anahtarlı bir sayı eklediniz GSI1PK = WS#acme, GSI1SK = updatedAt "yakın zamanda değişen her şeyi listelemek için bu çalışma alanında en yenisi önce gelir". Aşırı yüklenmiş bir dizin, and belgelerini tarar yorumlar — ancak bir yayın kullanıcı arayüzü yalnızca belgeleri isteyebilir.

Onu daraltmanın iki yolu var ve aradaki fark paradır:

YaklaşımMaliyeti nedirNe zaman kullanılır
FilterExpression TipteEşleşen tüm öğeleri okur, hepsini faturalandırır, okunduktan sonra eşleşmeyen öğeleri bırakırSonuçta karma varlıklar nadirdir; hızlı gönderim
Seyrek dizin (GSI1PK yalnızca hedef varlığa yazılır)Yalnızca istediğiniz varlık dizine girerBir varlık hakimdir; sıfır atık istiyorsunuz

Talep üzerine us-east-1 içinde, GSI Query 2 KB boyutunda 100 karışık öğe döndürüyor her biri kabaca 100 RCU sonuçta tutarlı faturalandırıyor - ve FilterExpression EntityType yorumları bırakmadan önce hâlâ her satırı ölçer. Seyrek bir indeks hiçbir zaman yorumları indekslemez, yalnızca belge satırlarını faturalandırır. Her iki şekli de modelleyin pricing calculator.

Öğeler okunduktan sonra ve kapasite sonra doldurulduktan sonra FilterExpression çalışır tüketildi — AWS filtrelemenin okuma maliyetini azaltmadığı açıktır (DynamoDB Geliştirici Kılavuzu: FilterExpression). Türe göre filtreleme yapmak ücretsiz değil, dürüsttür: çöpe attığınız yorumların bedelini ödersiniz.

Beslemeyi belgelere daraltmak için sorgu, Tür üzerinde bir koşul taşır. özellik. FilterExpression'u, adları ve değerleri aşağıdakilerle birleştirin: DynamoDB expression builder — yayar #t = :doc yer tutucu, böylece ayrılmış bir kelimeye parmakla bakmazsınız.

KeyConditionExpression     GSI1PK = :ws
FilterExpression           #t = :doc
ExpressionAttributeNames   { "#t": "EntityType" }
ExpressionAttributeValues  { ":ws": "WS#acme", ":doc": "Document" }

Dizinin only belgeleri taşımasını ve filtreyi tamamen atlamasını mı istiyorsunuz? Yaz GSI1PK yalnızca belge öğelerinde — a . GSI tuşu olmayan öğeler hiçbir zaman dizine kopyalanmaz, bu nedenle okuma belgeler tek başına. Type özelliği, yazarınıza hangi öğelerin hak kazanmak.

Değeri kararlı ve tekil tut

Değeri bir kez seçin ve onu bir numaralandırma olarak değerlendirin. Document, bazen hiçbir zaman Doc ve bazen document — değişken bir değer hiç değer olmamasından daha kötüdür, çünkü senin eşitlik kontrolleri bir kasadan geçiyor ve diğerini sessizce kaçırıyor.

Öğe başına bir Tür. Bir öğe iki varlık gibi görünüyorsa bu genellikle bir modellemedir koku — her biri in its own collection or sort-key range olmak üzere iki öğe olmalıdır, bir sıra iki şapka takmıyor.

Migration getirisi

Tip'i ihtiyaç duymadan damgalamanın nedeni: yeniden modelleme. Önerilen yeniden modelleme yolu dışa aktarma, dönüştürme, yeniden içe aktarmadır ve AWS belgeleri toplu olarak dışa aktarır S3 tam da bu tür bir çevrimdışı yeniden şekillendirme için (Exporting DynamoDB to S3).

O gün geldiğinde Tip GROUP BY sütununuzdur. Yorumları kaldırmak istiyorum kendi tablolarına aktarabilir veya dışa aktarmayı varlık bazında dosyalar halinde yeniden normalleştirebilirler. analiz deposu? Çöpü EntityType'de bölüştünüz. O olmadan geri dönersin Milyonlarca satırdaki anahtarları tersine mühendislik yapmak için.

Sonraki adımlar

Type özelliği ucuz bir sigortadır: karma okuma, filtredeki varlıkları tanımlayın aşırı yüklenmiş bir GSI ve yeniden modelleme yaptığınızda temiz bir şekilde bölünür. Her yazıya damgala ilk günden itibaren — canlı bir masaya sonradan donatmak, tam bir dolgu anlamına gelir.

İlgili okuma: single-table design için bu, karma bölümlü desene hizmet eder, GSI vs LSI seyrek bir indeksin arkasındaki indeks şeklini seçme ve Query vs Scan çünkü FilterExpression asla kaydetmez Maliyeti okudun.

Tür üzerinde filtreyi şununla oluşturun: DynamoDB expression builder ve Gerçek bir karma varlık tablosuna göz atmak ve Türü görmek için try DynoTable sütun her öğede sıralanır.

Güncellendi