Veri Modelleme

DynamoDB'nin SQL'den en sert ayrıldığı yer burasıdır. Varlık başına bir tabloya normalize etmezsiniz — erişim desenlerinizden başlar ve onlara hizmet eden anahtarlar tasarlarsınız, çoğu zaman her varlığı tek bir tabloya paketleyerek. Doğru yapıldığında, bir ebeveyni ve çocuklarını tek bir Query'de, join'siz getirirsiniz.

Yanlış yapıldığında, sorgulayamayacağınız bir tablo ve çalıştıramayacağınız bir geçiş elde edersiniz. Yani takaslar önemlidir ve bu bölüm, tek-tablo tasarımının yanlış seçim olduğu durumlar hakkında dürüsttür.

7 içinden 0 okunduSınav

DynamoDB'de Single-Table Tasarımı

DynamoDB'de single-table tasarımı — aşırı yüklenmiş anahtarlara sahip tek bir tablonun neden entity-başına-tablodan daha iyi olduğu, somut bir sipariş/müşteri örneğiyle ve GSI aşırı yükleme modeliyle.

Orta4 dakikalık okuma

DynamoDB'de Veri Nasıl Modellenir

DynamoDB'de veriyi erişim-deseni öncelikli şekilde nasıl modelleyeceğiniz — bir çok oyunculu liderlik tablosunun sorgularını partition ve sort key'lere dönüştüren adım adım bir anlatım.

Orta8 dakikalık okuma

DynamoDB'de Tek Tablo Tasarımı NE ZAMAN Kullanılmamalı

DynamoDB'de tek tablo tasarımı NE ZAMAN KULLANILMAMALI — birden fazla tablonun kazandığı iş yükleri (ağır analitik, basit CRUD, bağımsız ölçekleme); somut örneklerle.

Orta6 dakikalık okuma

DynamoDB'de Type Attribute

DynamoDB Type attribute'ı — satırları tanımlamak, bir GSI'yi tek bir entity'ye daraltmak ve gelecekteki taşımalardan sağ çıkmak için neden her item'a bir entity tipi damgalarsınız.