DynamoDB'de Single-Table Tasarımı

SQL'den gelince, içgüdü varlık başına bir tablodur: customers, orders, order_items. DynamoDB'de bu içgüdü genellikle yanlıştır. Aşırı yüklenmiş anahtar öneklerine göre ayırt edilen, her varlığı depolayan tek bir tablo, bir üst öğeyi ve çocuklarını tek bir Query ile getirmenize izin verir — join yok, N+1 yok.

DynamoDB'de single-table tasarımı nedir?

Single-table tasarımı, her varlığı — müşterileri, siparişleri, sipariş kalemlerini — aşırı yüklenmiş partition key ve sort key önekleriyle ayırt edilen tek bir DynamoDB tablosunda depolar. Anahtarlar, varlıklarınıza değil, erişim desenlerinize göre tasarlandığı için, bir üst öğe ve tüm çocukları tek bir item collection içinde bulunur ve tek bir Query'de geri gelir — join yok, N+1 okuma yok.

Fikir

Genel anahtar adları (PK, SK) seçin ve varlık türünü değerde kodlayın:

Şimdi tek bir Query PK = "CUSTOMER#42", tek bir faturalandırılan okumada profili ve her siparişi döndürür. SK begins_with "ORDER#", onu yalnızca siparişlere daraltır.

Görsel olarak, aşırı yüklenmiş item'lar tek bir partition key altında tek bir item collection olarak yığılır:

Partition'ın tek bir okuması, müşteriyi ve her siparişi birlikte geri verir.

Aşırı yüklenmiş GSI'ler

Aynı numara index'lerde de işe yarar. Item'lara genel bir GSI1PK/GSI1SK koyun ve tek bir GSI, her item'ın bu attribute'lara ne yazdığına bağlı olarak birden çok erişim desenine hizmet eder:

Şimdi Query GSI1 WHERE GSI1PK = "STATUS#OPEN", açık siparişleri tarihe göre listeler — temel tablonun cevaplayamadığı bir desen. Farklı bir varlık, GSI1'i kendi anlamıyla yeniden kullanabilir (ör. CATEGORY#books). Bir index, birçok sorgu.

Çoktan-çoğa: komşuluk listesi

İlişkiler için (birçok takımda bir kullanıcı, birçok kullanıcıya sahip bir takım), kenarı id'ler değiştirilmiş halde iki kez yazın: PK=USER#1, SK=TEAM#9 ve PK=TEAM#9, SK=USER#1. Her iki tarafı sorgulamak diğerini listeler — bir join tablosunun DynamoDB'deki karşılığı.

Ne zaman single-table yapmamalı

Bedava değil. Aşırı yüklenmiş tek bir tablonun akıl yürütmesi daha zor, geliştirmesi daha zor ve analitiğe düşmandır. Erişim desenleriniz gerçekten bilinmiyorsa ya da sürekli değişiyorsa veya veri çoğunlukla analitikse, ayrı tablolar (veya farklı bir depo) daha aklı başında bir seçim olabilir. Single-table, desenler bilinen ve yüksek hacimli olduğunda kazanır.

Yanlış şeklin maliyeti

Ayrı tablolar olarak modellemek, bir müşteriyi yeniden bir araya getirmek için bir Scan veya istemci tarafı join'i zorunlu kılar ki bu da Scan tuzağıdır. Önce erişim desenlerini modelleyin, sonra her birini bir Query yapmak için anahtarları tasarlayın. (Hiç modellemediğiniz anlık varlıklar-arası soru için, DynoTable'ın SQL Workbench'i JOIN'i istemci tarafında çalıştırır — keşif, yeniden modellemeyi beklemek zorunda değildir.)

Tasarımın kendisini ücretsiz Single-Table Design aracıyla taslaklayın — erişim deseni listenizi örnek öğeler ve maliyet ipuçlarıyla birlikte bir PK/SK/GSI planına dönüştürür. Bu item'ların okuma başına ne kadara mal olduğunu item boyutu ve kapasite hesaplayıcısıyla tahmin edin ve bir single-table şemasına göz atıp aşırı yüklenmiş collection'ları yan yana görmek için DynoTable'ı deneyin.