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

Tek tablo tasarımı, DynamoDB için varsayılan tavsiyedir ve bunu hak eder: tek bir Query, bir üst öğeyi ve alt öğelerini geri verir, join yok, N+1 yok.

Ama bu bir takastır — okuma hızını katı, opak bir şemayla satın alırsınız. Bazı iş yükleri bu bedeli karşılayamaz ve onlara tek bir tablo dayatmak kendi tuzağıdır.

DynamoDB'de tek tablo tasarımı ne zaman kullanılmamalı?

İş yükünüz ağır OLAP analitiği, birkaç ilgisiz varlık üzerinde düz CRUD veya bağımsız ölçeklenen ya da başarısız olan varlıklardan oluştuğunda tek tablo tasarımından kaçının. Bu durumlarda birden fazla tablo daha okunabilir, aynı maliyette ve esnek kalır. Tek tablo tasarımı yalnızca erişim desenleri bilinen, ilişkili ve yüksek hacimli olduğunda kazanır.

• Ağır analitik mi? Tek tablo yapmayın. Aşırı yüklenmiş anahtarlar OLAP'a düşmandır — bir sütunlu (columnar) depoya dışa aktarın ve orada sorgulayın.
• Bir avuç erişim deseniyle düz CRUD mu? Varlık başına bir tablo iyidir, okunabilirdir ve performansta size hiçbir şeye mal olmaz.
• Bağımsız ölçeklenen ya da başarısız olan varlıklar mı? Ayrı tablolar, onları kendi başlarına ayarlamanıza, faturalandırmanıza ve patlama yarıçaplarını sınırlamanıza izin verir.
• Tek tablo yine de kazanır desenleriniz bilinen, ilişkili ve yüksek hacimli olduğunda — bu, onun için inşa edildiği durumdur.

Tek tablonun gerçekte neye mal olduğunu bilin

Tek tablo tasarımı bedava değildir; yalnızca maliyeti okuma yolundan alıp diğer her şeye taşır. Okunabilirlik ve esneklikle ödersiniz.

PK/SK ardında beş varlık türü tutan bir tablo, okunması zor, üzerine adaptasyonu zor ve değiştirilmesi zordur. Yeni bir erişim deseni, bölümdeki her öğe türü boyunca bir geri doldurma demek olabilir.

Yani soru "tek tablo iyi mi?" değildir. "Erişim desenlerim katılığı haklı çıkarıyor mu?"dur. Çıkarmadıklarında, birden fazla tabloya uzanın.

Bir analitik iş yükünü tek tablo yapmayın

DynamoDB OLTP için inşa edilmiştir — küçük, bilinen, nokta-ve-aralık okumaları. Analitik OLAP'tır: GROUP BY, büyük toplamalar, tüm veri kümesi boyunca anlık (ad-hoc) dilimleme. İkisi zıt yönlere çeker.

Tek tablo tasarımı OLAP'ı daha iyi değil, daha kötü yapar. Aşırı yüklenmiş anahtarlar ve karışık varlık türleri, bir analitik işinin herhangi bir şeyi toplayabilmesi için önce hangi öğenin hangisi olduğunu çözmesi gerektiği anlamına gelir — temiz bir sütunlu taramanın tam tersi.

SQL'den geliyorsanız, refleks toplamayı canlı tabloya karşı yazmaktır. DynamoDB'de bu tam bir Scan'dir — her öğeyi okur ve ödersiniz ki bu, tam hacimde Scan tuzağıdır.

Çözüm daha akıllı bir anahtar değildir. Farklı bir depodur. AWS'nin kendi rehberi, DynamoDB'yi S3'e dışa aktarmak ve analitiği Athena gibi bir sorgu motoruyla çalıştırmaktır.

OLTP ve OLAP'ı ayrı motorlarda tutun (AWS DynamoDB Developer Guide, S3DataExport.html).

Basit CRUD'u tek tablo yapmayın

Uygulamanız birkaç ilgisiz varlığı kendi kimlikleriyle okuyup yazıyorsa ve belki üç erişim deseniniz varsa, tek tablo size hiçbir şey kazandırmaz.

Küçük bir B2B aracı için bir Tenants tablosu ve bir ApiKeys tablosu alın:

Her sorgu kimliğe göre bir GetItem'dır ya da TenantId ile anahtarlanmış bir GSI üzerinde bir Query. Optimize edilecek bir üst-ve-alt-öğe getirmesi yoktur, bu yüzden aşırı yüklenmiş bir bölümün kazanacağı bir şey yoktur. İki net tablo, bir bulanık tablodan daha iyi okunur.

Tuzak, "en iyi uygulama" olduğu için tek tabloyu kült olarak taklit etmektir. En iyi uygulama erişim-deseni-öncelidir. Desenler önemsizse, basit şekil doğru şekildir.

Bağımsız ölçeklenen ya da başarısız olan tabloları ayırın

Tek bir tablo, tek bir verim yüzeyini, tek bir yedeği, tek bir patlama yarıçapını paylaşır. İki varlığın çılgınca farklı yazma hızları ya da dayanıklılık ihtiyaçları olduğunda, o paylaşılan kader bir yükümlülük olur.

Bir filo-takip sistemi düşünün. Araçlar nadiren değişir; telemetrileri her saniye dökülür:

İki tablo, telemetriyi bir hortum için sağlamanıza, araçları küçük ve ucuz tutmanıza, TTL'i yalnızca telemetriye ayarlamanıza ve bir telemetri yazma fırtınasının araç kataloğunun okumalarını kısıtlamasını durdurmanıza izin verir. Tek bir tablo bunların hepsini birbirine bağlar.

2007 Amazon Dynamo makalesine göre, bölümleme ve kullanılabilirlik birinci sınıf endişelerdir — bağımsız tablolar, her ikisi üzerinde de bağımsız kontrol verir.

Taahhüt etmeden önce kararı haritalayın

İş yükünü tek bir kapıdan geçirin: varlıklar ilişkili mi ve desenler bilinen ve yüksek hacimli mi? Değilse, birden fazla tablo.

İşte karar bir akış olarak — en üstten başlayın ve eşleşen ilk dalı izleyin:

Yalnızca sağ-alt yaprak tek tabloyu hak eder; diğer her yola birden fazla tabloyla daha iyi hizmet edilir.

Tek ile çoklu, kafa kafaya

Tuzaklar + sonraki adımlar

Ayna görüntüsü hata aşırı düzeltmedir — gerçekten ilişkili, yüksek hacimli varlıkları varlık-başına-tabloya bölmek ve uygulamanızda SQL tarzı join'leri yeniden kurmaktır. Bu, tek tablonun öldürdüğü N+1 tuzağıdır.

Dogmayı değil, erişim desenlerinin istediği şekli seçin.

İlişkileri modellediğinizde, doğru indeks türüne yaslanın — bir tane eklemeden önce bkz. GSI vs LSI.

Çok tablolu bir şemaya karşı bir sorgu yazdığınızda, KeyConditionExpression'ı önce DynamoDB Expression Builder içinde çizin.

Böylece üretime çarpmadan önce bir tam-Scan şeklini yakalarsınız.

Sonra her iki şekli kendi tablolarınıza karşı göz atmak ve erişim desenlerinizin gerçekte hangisini istediğini görmek için DynoTable'ı deneyin.