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

DynamoDB, tasarlandığı iş yükleri için harika, geri kalanı içinse sinir bozucu bir veritabanıdır. Belirleyici soru şudur: "Erişim desenlerimi baştan biliyor muyum ve bunlar anahtar tabanlı mı?" Bunu doğru bilirseniz DynamoDB size her ölçekte tek haneli milisaniyelik okumalar verir; yanlış bilirseniz join ve anlık sorgu yokluğuyla sonsuza kadar boğuşursunuz.

DynamoDB'yi ne zaman kullanmalıyım?

Erişim desenleriniz bilinen, anahtar tabanlı ve yüksek hacimliyse ve her ölçekte öngörülebilir tek haneli milisaniyelik gecikmeyi sıfır sunucu yönetimiyle istiyorsanız DynamoDB kullanın. Anlık sorgular, zengin join'ler ya da tüm veri kümesi üzerinde analitik gerekiyorsa ve veri küçükken sorgu biçimleri sürekli değişiyorsa ondan kaçının.

• DynamoDB'yi şu durumda kullanın: erişim desenleriniz bilinen, anahtar tabanlı ve yüksek hacimli — ve her ölçekte öngörülebilir gecikmeyi sunucu yönetmeden istiyorsunuz.
• Şu durumda kaçının: anlık sorgulara, zengin join'lere ya da tüm veri kümesi üzerinde analitiğe ihtiyacınız var; ya da veri küçük ve sorgu biçimleri sürekli değişiyor.
• Temel takas: DynamoDB sizi sorgularınıza göre baştan tasarlamaya zorlar; karşılığında siz büyüdükçe hiç yavaşlamaz.
• Şu değildir: farklı sözdizimine sahip ilişkisel bir veritabanı — onu öyle modellemek acının bir numaralı kaynağıdır.

DynamoDB'den yana olan sinyaller

Şunların çoğu geçerliyse DynamoDB parlar:

• Erişim desenlerinizi önceden biliyorsunuz. Uygulamanın yaptığı tam sorguları sayabiliyorsunuz ("kullanıcıyı kimliğine göre getir", "kullanıcının siparişlerini en yeniden başlayarak listele") ve bunlar keyfî olarak değişmiyor. DynamoDB tam da bu sorguların etrafında modellenir.
• Erişim anahtar tabanlı. Öğeleri keyfî attribute kombinasyonları için tarayarak değil, bilinen bir bölüm anahtarıyla ararsınız.
• Ölçek ve öngörülebilir gecikme önemli. DynamoDB, tablo bin öğe de tutsa bir milyar öğe de tutsa tutarlı tek haneli milisaniyelik performans verir.
• Sıfır operasyonel yük istiyorsunuz. Örnek yok, devralma yok, vacuum yok — tümüyle yönetilen ve on-demand modda sıfıra kadar ölçeklenen bir servis.
• Yazma throughput'u yüksek ve ani. Olay günlükleri, IoT telemetrisi, oturum/sepet durumu, lider tabloları — net bir anahtarı olan, ekleme ağırlıklı iş yükleri.

Ona karşı olan sinyaller

Şu durumlarda bunun yerine ilişkisel bir veritabanına (ya da bir arama/analitik motoruna) uzanın:

• Sorgularınız anlık. Analistler veriyi keyfî sütunlara göre dilimliyor ya da gereksinimler haftalık değişiyor. SQL'in esnekliği kazanır; DynamoDB desen başına yeni bir dizin isterdi.
• Tüm veri kümesi üzerinde gerçek join ve toplamalara ihtiyacınız var. Raporlama, iş zekâsı, "bölgeye ve aya göre geliri topla" — bu bir OLAP/ilişkisel iştir. (Canlı bir tabloya sorulan tek seferlik soru farklı bir durumdur — DynoTable'ın SQL Workbench'i DynamoDB üzerinde JOIN, GROUP BY ve toplama işlevlerini istemci tarafında çalıştırır; başka yere ait olan, sürekli çalışan BI iş yüküdür.)
• 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 rahatlığını kaybeder.
• Erişim desenlerini henüz öngöremiyorsunuz. Şeklini hâlâ arayan erken aşama bir ürün mü? Desenler oturana kadar, serbestçe yeniden sorgulayabileceğiniz ilişkisel bir şema daha bağışlayıcıdır.

DynamoDB diğer veritabanlarıyla nasıl karşılaştırılır

"DynamoDB mi kullansam yoksa X mi?" genellikle aynı sorunun farklı kılıklarıdır: X, erişim deseni kararını ertelememe izin veriyor mu ve bunun bedeli ne? DynamoDB, bunu ertelemenize izin vermeyi reddeden seçenektir. Aşağıdaki her karşılaştırma, özellik listelerine değil, bu tek takasa dayanır.

İlişkisel: PostgreSQL, RDS ve Aurora

Asıl yol ayrımı budur ve çoğu ekibin yanlış yaptığı yer de burasıdır. İlişkisel bir veritabanı sorguyu, veriye sahip olduktan sonra yazmanıza izin verir. DynamoDB vermez — tablo, tek bir öğe yazılmadan önce sorgular tarafından şekillendirilir.

Sorgu biçimleri hâlâ hareket hâlindeyken, tüm veri kümesi boyunca join ya da toplama gerektiğinde ya da veri, ölçeğin sizin sorununuz olmayacağı kadar küçükken ilişkiseli seçin. Desenler oturmuşsa, anahtar tabanlıysa ve bir milyar öğede bin öğedekiyle aynı maliyette olmasını istiyorsanız DynamoDB'yi seçin.

RDS ve Aurora bu hesabı değiştirmez — bunlar yönetilen ilişkisel motorlardır, dolayısıyla SQL'in esnekliğini de ölçeklenme modelini de devralırlar. Değiştirdikleri şey operasyonel karşılaştırmadır: Aurora Serverless ile DynamoDB lehine "yönetilecek sunucu yok" argümanı çok zayıflar ve karar temiz biçimde erişim desenlerine döner. Aurora hesaplamayı ölçekler; DynamoDB kavramı ortadan kaldırır.

Doküman: MongoDB ve DocumentDB

İkisi de JSON'ımsı dokümanlar saklar, bu yüzden uzaktan DynamoDB'yle birbirinin yerine geçebilir görünürler. Değiller. MongoDB herhangi bir alanı dizinler ve ona karşı anlık sorgular çalıştırır; DynamoDB size bölüm anahtarını, sıralama anahtarını ve önceden tanımladığınız dizinleri verir.

Bu da MongoDB'yi evrilen sorgu biçimleri için, DynamoDB'yi ise yüksek hacimdeki bilinen biçimler için daha uygun kılar. DocumentDB aynı çizginin AWS tarafında durur — MongoDB API'sini konuşur, dolayısıyla onu "MongoDB'nin esnekliği, AWS'nin operasyonel modeli" olarak görün ve DynamoDB ile tam olarak yukarıdaki esneklik-öngörülebilirlik ekseninde karşılaştırın.

Geniş sütunlu: Cassandra

Cassandra, DynamoDB'nin mimari olarak en yakın akrabasıdır: bölüm anahtarı, kümeleme anahtarı ve kötü bir bölüm anahtarının dizinleyerek kurtulamayacağınız bir tasarım hatası olduğu gerçeği. Aralarında seçim yapıyorsanız belirleyici etkenler nadiren veri modelidir — genelde onu kimin işlettiği ve nasıl ödediğinizdir. Cassandra'yı siz işletirsiniz (ya da yönetilenini satın alırsınız); DynamoDB'yi tüketirsiniz. Amazon Keyspaces, yönetilen Cassandra orta yoludur.

Modeller birbirine bu kadar yakın olduğu için bu sitedeki modelleme rehberliğinin çoğu aktarılabilir: bölüm anahtarları ve erişim desenleri hakkındaki tek tablo tasarımı muhakemesi Cassandra'ya neredeyse satır satır uyar.

Bellek içi: Redis

Redis ve DynamoDB farklı sorunları çözer. Redis bellek önceliklidir ve kaybetmeyi ya da yeniden üretmeyi göze alabileceğiniz veriye milisaniyenin altında erişim için optimize edilmiştir; DynamoDB ise varsayılan olarak dayanıklıdır. Üretimdeki yaygın cevap ikisi birdendir — kayıt sistemi olarak DynamoDB, sıcak anahtarların önünde Redis (ya da DynamoDB'nin kendi okuma önbelleği DAX).

Tek başına Redis'e yalnızca veri gerçekten geçiciyse uzanın: hız sınırı sayaçları, kısa ömürlü oturumlar, yeniden hesaplayabileceğiniz lider tabloları.

Arama: Elasticsearch ve OpenSearch

Arama ile DynamoDB de farklı sorunları çözer — üstelik Redis'ten daha keskin bir nedenle: DynamoDB'de tam metin arama hiç yoktur. Query, anahtar eşitliğiyle ve dar bir sıralama anahtarı koşulu kümesiyle eşleşir. FilterExpression içeren bir Scan her öğeyi okur ve çoğunu sonra atar — bu, üzerine filtre cıvatalanmış bir tablo gezintisidir, arama değil; ve döndürülen öğelerin değil, okunan öğelerin parasını ödersiniz. Alaka sıralaması, analizör, bulanık eşleme ya da faset yoktur.

Yani soru asla "DynamoDB mi arama motoru mu" değildir. Soru şudur: "bu iş yükünün aramaya ihtiyacı var mı ve varsa dizini ne besliyor?" Standart biçim ikisi birdendir: kayıt sistemi olarak DynamoDB, yanında bir arama kümesi ve her değişikliği dizine taşıyan DynamoDB Streams. Bu size gerçek arama kazandırır; karşılığında işletilecek ikinci bir sistem ve tabloyla nihai tutarlı bir dizin ödersiniz.

OpenSearch ile Elasticsearch aynı karardır. OpenSearch, AWS'nin Elasticsearch çatallamasıdır; 2021'de Elastic'in lisans değişikliği üzerine 7.10 sürümünde ayrıldılar ve o günden beri birbirlerinden uzaklaştılar. Bu uzaklaşmanın hiçbiri buradaki soruya dokunmuyor — "arama DynamoDB'nin dışında mı yaşamalı" sorusunda ikisi aynı davranır. Aralarında DynamoDB'yle ilgili hiçbir şeye göre değil, lisanslamaya, barındırmaya ve hangi yönetilen servisi işletmek istediğinize göre seçim yapın.

Bir arama motorunu birincil depo olarak yalnızca arama gerçekten ürünün kendisiyse tercih edin — log analitiği, ana erişim deseni serbest metin olan bir katalog. O zaman bile çoğu ekip arkasında dayanıklı bir depo tutar, çünkü arama dizini yeniden kurabilmeniz gereken türetilmiş bir görünümdür.

Model karşılaştırmasının gizlediği maliyet ekseni

Yukarıdaki her karşılaştırma veri modelleriyle ilgili, ama faturadaki sürpriz genellikle yapısaldır: ilişkisel motorlar sağladığınız kapasite üzerinden, DynamoDB ise yaptığınız işlemler üzerinden faturalandırır. Bu da DynamoDB'yi ani ve boş duran iş yükleri için ucuz, sürekli tarama için pahalı kılar — aynı iş yükü, aralarında tek satır kod değişmeden bir motorda kazanıp diğerinde ağır kaybedebilir.

İnsanların gözden kaçırdığı çarpan dizinlerdir. İlişkisel bir motorda fazladan bir dizin depolamaya ve biraz yazma gecikmesine mal olur; DynamoDB'de her ikincil dizin, projekte edilen attribute'ların tam bir fazladan yazması demektir. Aritmetiği üç farklı yazma hacminde dizinler rehberinde işledik — bir GSI yazma faturasını ikiye, iki GSI üçe katlıyor. Taraflardan birine karar vermeden önce gerçek okuma/yazma karışımınızı fiyat hesaplayıcıda modelleyin.

Karar vermeden önce maliyeti hesaplayın

DynamoDB fiyatlandırması örnek saatlerini değil okumaları, yazmaları ve depolamayı izler — dolayısıyla ani ve sunucusuz iş yükleri için ucuzdur, sürekli ağır taramalar içinse pahalı olabilir. Karar vermeden önce gerçek okuma/yazma karışımınızı DynamoDB fiyat hesaplayıcısıyla 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

İş artık modellemeye kayar. DynamoDB, tabloyu sorgularınızın etrafında tasarlamayı ödüllendirir — bkz. DynamoDB'de veri nasıl modellenir ve tek tablo tasarımı — ayrıca açıkça tek tabloya ne zaman uzanılmayacağı.

Tuzaklar ve sonraki adımlar

• DynamoDB'yi ilişkisel bir veritabanı gibi modellemeyin — okuma anında birleştirdiğiniz normalleştirilmiş tablolar, en ağır cezalandırdığı anti-desendir.
• Onu analitik için seçmeyin — raporlama için taramak yerine onu bir analitik depoyla eşleştirin (ya da oraya dışa aktarın).
• Erişim desenlerinden emin değil misiniz? Bekleyin. Sorgularınızı bilmeden DynamoDB'yi benimsemek, tam da onları bilmenizi şart koşan veritabanını seçmektir.
• İlgili: query ile scan, "anahtar tabanlı erişimin" size gerçekte ne kazandırdığını gösterir.

Uygulamanızı ona emanet etmeden önce bir DynamoDB tablosunu keşfetmek ister misiniz? DynoTable'ı indirin ve verinize doğrudan bağlanın — onun SQL Workbench'i, DynamoDB'nin kendisinin çalıştırmadığı anlık JOIN'leri ve toplama işlevlerini çalıştırır.