DynamoDB Ne Zaman Kullanılır (ve Ne Zaman Kullanılmaz)

DynamoDB, kurulduğu iş yükleri için harika bir veritabanı ve geri kalanı için sinir bozucu bir veritabanıdır. Belirleyici soru "web ölçeğinde mi?" değil — "erişim desenlerimi baştan biliyor muyum ve anahtar tabanlı mılar?" Bunu doğru yapın, DynamoDB size herhangi bir ölçekte tek haneli milisaniyelik okumalar verir; yanlış yapın, join'lerin ve geçici sorguların yokluğuyla sonsuza dek boğuşursunuz.

DynamoDB'yi ne zaman kullanmalıyım?

Erişim desenleriniz bilinir, anahtar tabanlı ve yüksek hacimli olduğunda ve sıfır sunucu yönetimiyle herhangi bir ölçekte öngörülebilir tek haneli milisaniyelik gecikme istediğinizde DynamoDB kullanın. Geçici sorgular, zengin join'ler veya tüm veri kümesi üzerinde analitikler için ve veri küçükken ile sorgu şekilleri sürekli değişirken bundan kaçının.

• DynamoDB'yi şu durumda kullanın: erişim desenleriniz bilinir, anahtar tabanlı ve yüksek hacimli olduğunda — ve yönetilecek sunucu olmadan herhangi bir ölçekte öngörülebilir gecikme istediğinizde.
• Şu durumda kaçının: geçici sorgulara, zengin join'lere veya tüm veri kümesi üzerinde analitiklere ihtiyacınız olduğunda ya da veri küçükken ve sorgu şekilleri sürekli değişirken.
• Temel ödünleşim: DynamoDB, sorgularınız için baştan tasarlamanızı zorunlu kılar; karşılığında büyüdükçe asla yavaşlamaz.
• O, farklı bir söz dizimine sahip bir ilişkisel veritabanı değildir — onu öyle modellemek 1 numaralı acı kaynağıdır.

DynamoDB'yi destekleyen sinyaller

DynamoDB, bunların çoğu geçerliyse parlar:

• Erişim desenlerinizi önceden biliyorsunuz. Uygulamanın yaptığı tam sorguları listeleyebilirsiniz ("id ile bir kullanıcı al", "bir kullanıcının siparişlerini en yeni önce listele") ve bunlar bir hevesle değişmez. DynamoDB, o sorguların etrafında modellenir.
• Erişim anahtar tabanlıdır. Item'lara, rastgele attribute kombinasyonları için tarayarak değil, bilinen bir partition key ile bakarsınız.
• Ölçek ve öngörülebilir gecikme önemlidir. DynamoDB, tablo ister bin item ister bir milyar tutsun tutarlı tek haneli milisaniyelik performans sunar.
• Sıfır operasyonel yük istiyorsunuz. Örnek yok, failover yok, vacuum yok — tamamen yönetilir ve on-demand sıfıra ölçeklenir.
• Yazma verimliliği yüksek ve dikenlidir. Olay günlükleri, IoT telemetrisi, oturum/sepet durumu, liderlik tabloları — net bir anahtarla ekleme ağırlıklı iş yükleri.

Ona karşı sinyaller

Şu durumlarda bunun yerine ilişkisel bir veritabanına (veya bir arama/analitik motoruna) başvurun:

• Sorgularınız geçici. Analistler veriyi rastgele sütunlara göre dilimliyor ya da gereksinimler haftalık değişiyor. SQL'in esnekliği kazanır; DynamoDB her desen için yeni bir index gerektirir.
• Tüm veri kümesi üzerinde gerçek join'lere ve toplamalara ihtiyacınız var. Raporlama, iş zekâsı, "bölgeye göre aya göre geliri topla" — bu bir OLAP/ilişkisel iştir.
• Veri kümesi küçük ve düşük trafikli. Sessiz bir yönetim uygulamasındaki birkaç bin satır, DynamoDB'nin ölçeğinden hiçbir fayda görmez ve SQL'in kolaylığını kaybeder.
• Erişim desenlerini henüz öngöremiyorsunuz. Hâlâ şeklini bulan erken aşama bir ürün mü? Özgürce yeniden sorgulayabileceğiniz bir ilişkisel şema, desenler oturana kadar daha bağışlayıcıdır.

Bağlanmadan önce maliyeti hesaplamak

DynamoDB fiyatlandırması okumaları, yazmaları ve depolamayı izler — örnek saatlerini değil — bu yüzden dikenli ve sunucusuz iş yükleri için ucuz, sürekli ağır taramalar için pahalı olabilir. Bağlanmadan önce gerçek okuma/yazma karışımınızı DynamoDB fiyatlandırma hesaplayıcısı ile modelleyin; teknik olarak uygun görünen bir iş yükü maliyet açısından da tutmalıdır.

Uygun olduğuna karar verdikten sonra

İş, modellemeye kayar. DynamoDB, tabloyu sorgularınızın etrafında tasarlamayı ödüllendirir — DynamoDB'de veri nasıl modellenir ve single-table tasarımı'na bakın — ve açıkça single-table'a ne zaman başvurulmaması gerektiği'ne.

Tuzaklar + sonraki adımlar

• DynamoDB'yi ilişkisel bir veritabanı gibi modellemeyin — okuma zamanında join yaptığınız normalize edilmiş tablolar, en sert cezalandırdığı anti-desendir.
• Onu analitik için seçmeyin — raporlama için tarama yapmak yerine onu bir analitik deposuyla eşleştirin (veya birine dışa aktarın).
• Erişim desenlerinden emin değil misiniz? Bekleyin. Sorgularınızı bilmeden DynamoDB benimsemek, sizden onları bilmenizi talep eden tek veritabanını seçmektir.
• İlgili: query vs scan, "anahtar tabanlı erişim"in size gerçekte ne kazandırdığını gösterir.

Uygulamanızı üzerine kurmadan önce bir DynamoDB tablosunu keşfetmek mi istiyorsunuz? DynoTable'ı indirin ve verilerinize doğrudan bağlanın.