AWS: DynamoDB Nedir?

Bu yazıda AWS’in saÄŸladığı baÅŸka bir veri saklama yönteminden, DynamoDB’den bahsedeceÄŸim. Genel olarak, terminolojisine ve ücretlendirmesine deÄŸineceÄŸim. Uzun bir yazı olmasını istemediÄŸimden Java ile nasıl uygulama geliÅŸtirilir gibi konulara deÄŸinmeyeceÄŸim.

DynamoDB Nedir?

DynamoDB, Amazon Web Servislerinin saÄŸladığı bir NoSQL veritabanı. BildiÄŸim kadarıyla, AWS ile son kullanıcıya saÄŸlanmadan önce, yıllarca Amazon içerisinde kullanılmış ve kendini ispat etmiÅŸ bir veritabanı. NoSQL veritabanı türlerinden Key-Value olduÄŸunu söyleyebiliriz. Yani büyük bir tabloda hash’lere karşılık deÄŸerler tutuluyor.

Şemasız

Åžemasız veritabanı olarak geçiyor. Aslında bakarsanız bu tüm Key-Value tipindeki NoSQL veritabanları için geçerli. Bu saye de aynı ÅŸekilde Hash’leye bileceÄŸiniz bilgileri aynı tabloda saklayabiliyorsunuz. ÖrneÄŸin ürün kataloÄŸu oluÅŸturduÄŸunuzu düşünün. Hangi kategoriden olursa olsun ürünlerinize ÅŸirket genelinde bir seri numarası atadığınızı düşünelim. Ãœrünleriniz tamamen farklı kategoride olabilir. Farklı kategorilerdeki ürünlerinizin de tabi ki farklı özellikleri olacaktır. ÖrneÄŸin, kitap ürünlerinizde yazar, sayfa sayısı yayın evi gibi bilgileri tutarken, ayakkabı ürünlerinizde, ayakkabı numarası, rengi, modeli gibi bilgiler bulunacaktır. Aynı ÅŸekilde (ürün seri numaranızla) hash’lediÄŸiniz için tüm bu bilgileri aynı tabloda tutabilirsiniz. Hatta isterseniz bu bilgileri kategorisine göre de sıralayabilirsiniz.

Tutarlılık (Consistency)

BildiÄŸiniz üzere NoSQL veritabanlarının çoÄŸu ACID (Atomicity, Consistency, Isolation, Durability)’i desteklemiyor. Bende zaten bir NoSQL veritabanından hepsini desteklemesini beklemiyorum. Fakat tutarlılık konusunda çekincelerim oluyor. Bu sebepten bir NoSQL veritabanını incelerken ilk baktığım ÅŸeylerden biri oluyor. DynamoDB ise, tutarlılık için iki farklı çözüm öneriyor. Neticede tutarlı ve Kesin Tutarlı (Eventually Consistent ve Strongly Consistent)…

Neticede tutarlı, verilerinizi okurken yeni yapılan güncellemeleri almama ihtimaliniz var. Burada “yeni” çok göreceli bir kavram. EÄŸer DynamoDB dokümantasyonuna bakacak olursanız, yeni den kastının 1 sn içerisinde yapılan güncellemeler olduÄŸunu göreceksiniz. Bir örnek üzerinden anlatmaya çalışayım. Bir tablonuzda kullanıcı adı ile kullanıcı bilgilerini tutuyorsunuz. EÄŸer kullanıcı bilgileri, siz okumadan 1 sn içerisinde güncellendiyse, siz hala eski veriyi alıyorsunuz. Kesin tutarlı ise tahmin edebileceÄŸiniz gibi her okumanızda verinizin son halini alıyorsunuz. Tabi bunun bir bedeli oluyor. Kesin tutarlı yaptığınız okumalar, neticede tutarlıya göre daha maliyetli oluyor.

Bu fark size API düzeyinde sunuluyor. Yani okuma taleplerinizi yaparken ne şekilde okuyacağınıza siz karar veriyorsunuz.

Ölçeklendirilebilirlik

DynamoDB’nin ölçeklendirilmesi, bana göre, alışılmışın biraz dışında. Bir AWS servisinden benim beklediÄŸim otomatik olarak kendini ölçeklendirmesi. DynamoDB’de bunu bu ÅŸekilde yapıyor ama bunu yapmadan önce sizden öngördüğünüz saniyelik okuma ve yazma sayılarınızı istiyor. Bu bilgilere dayanarak, ne kadar kaynak kullanması gerektiÄŸine, DynamoDB tablolarınızı sunuculara ne ÅŸekilde dağıtacağına falan karar veriyor. Tabi aynı zamanda da bu bilgiler üzerinden ücretlendiriliyorsunuz.

Burada insanın aklına hemen, “Peki ön gördüğümden daha fazla okuma/yazma yaparsam ne olacak?“, sorusu geliyor.  Bunu bir örnek üzerinden anlatmaya çalışayım. ÖrneÄŸin siz saniyede 10 okuma ve 10 yazma olacak ÅŸekilde ön görünü belirttiniz. Fakat sürekli olarak 11 okuma yapmaya çalışırsanız sistem yapmanızı engelleyecek ve ThrottlingException tadında bir exception ile karşılaÅŸacaksınız. Ama diyelimki, anlık olarak 11 okuma yaptınız. O zaman bir exception ile karşılaÅŸmazsınız. Sisteminizin yaşıyacağı anlık yoÄŸunluklarda (pike vs) DynamoDB sizin lehinizde çalışacaktır. Her iki durumdada size aylık öngördüğünüz okuma ve yazma üzerinden fatura kesilecektir. Tabi isterseniz, saniyede 10 okuma ve 10 yazma olan deÄŸerinizi istediÄŸiniz gibi deÄŸiÅŸtirebilirsiniz. Yani baktınız ki 11 okuma alıyorsunuz ve bu hep böyle devam ediyor deÄŸerlerinizi 11 okuma ve 10 yazma olarak deÄŸiÅŸtirmeniz mümkün. Bunu isterse AWS arayüzünden isterseniz size saÄŸladığı API üzerinden yapabilirsiniz. Bu deÄŸerlerin nasıl hesaplandığının detayına dynamodb dokümantasyonundan eriÅŸebilirsiniz. Bu konuya ücretlendirme bölümünde tekrar döneceÄŸiz.

Terminoloji

Ücretlendirmenin nasıl olduğuna geçmeden önce terminoloji kısmına değinelim.

PartitionKey (a.k.a HashKey)

Tablonuzun olmazsa olması. Her ne kadar DynamoDB için Key-Value store dediysekte, ÅŸemasız olmasından ileri gelen Document Store benzeri özellikleri de bünyesinde barındırmaktadır. Bu sebepten internette arama yaptığınızda sıkça MongoDB ile karşılaÅŸtırıldığını göreceksiniz. EÄŸer DynamoDB’yi bir Document Store olarak düşünecek olursanız, HashKey’iniz dokümanınızın Id’si olarak düşünebilirsiniz.

PartitionKey denilmesinin sebebi ise, bu bilginin aynı zamanda bilgilerinizin nasıl dağıtılacağını belirlemesidir. Ä°lk bölümde DynamoDB’nin ölçeklendirilebilirlik konusunda iyi olduÄŸundan ve ölçeklendirmeyi sizin belirlediÄŸiniz okuma ve yazma oranları üzerinden yaptığını belirtmiÅŸtik. DynamoDB ölçeklendirme kapsamında, sharding’de yapıyor. Sharding’yaparken hangi veriyi hangi sunucuya dağıtacağına yine bu key üzerinden karar veriyor.

Sort Key

Her ne kadar tablonuzun her alanı üzerinden arama iÅŸlemi yapabilsenizde, hızlı bir arama yapabilmek için HashKey’in yanında SortKey’e de ihtiyacınız olacak. SortKey yaratıp yaratmamak tamamen sizin tasarımınıza kalmış bir ÅŸey.

Primary Key

PrimaryKey (PK), RDB dünyasındaki gibi tekil bilgileri ifade etmektedir. Aslında, DynamoDB’de doÄŸrudan PK tanımlamanız mümkün deÄŸil. Aynı ÅŸekilde AWS konsolu üzerinden baktığınızda PK olarak tanımlayabileceÄŸiniz bir alan da bulamayacaksınız. Fakat Java API’sini kullandığınızda, aramalarınızı PK üzerinden yapabildiÄŸinizi göreceksiniz. Bir DynamoDB tablosunda PK iki türlü olabilir:

  1. PartitionKey
  2. PartitionKey + SortKey

PartitionKey tanımlamanızın zaten zorunlu olduÄŸundan bahsettim. EÄŸer SortKey’de tanımladıysanız PK’iniz otomatik olarak PartitionKey + SortKey halini alıyor. Yani herÅŸey PK doÄŸrultusunda tekil olmak durumunda.

Secondary Indexes

Adından da anlayabileceÄŸiniz üzere ikincil index’ler. Yani hızlı arama yapmanızı saÄŸlayan ek alanlar eklemeniz mümkün. Fakat bunu yaparken dikkatli olmalısınız, tanımladığınız index’in türüne göre, index’iniz için ek tablolar oluÅŸuyor. Bu durumda da ücretlendirmenizde deÄŸiÅŸimler olabiliyor. Detaylarına DynamoDB’nin dokümantasyonu üzerinden ulaÅŸabilirsiniz. Daha önce söyledim ama yeri gelmiÅŸken tekrar belirteyim, veritabanı üzerinde arama yapmak için ikincil index tanımlama gibi bir zorunluluÄŸunuz yok.

Provisioned Throughput ve Capacity Units

Bu benim gözümde DynamoDB’nin en alengirli bölümü. Tüm ücretlendirme ve ölçeklendirme bu bilgiler üzerinden hesaplandığından, insan birazcık bile şüpheye düşse kazıklanıyormuÅŸ hissine kapılıyor. Sıradan bir kullanıcı olarak AWS’in böyle bir amacı olmadığına eminim ama, Türk aklı iÅŸte hemen gardımı alıyorum.

Provisioned Throughput, yani ön gördüğünüz yük miktarı, hem ölçeklendirmede hem fiyatlandırmada hem de yazılımınızı geliÅŸtirirken sık sık karşınıza çıkacak bir konu. Bunu iyi ölçüp biçmelisiniz. EÄŸer hiç bir deÄŸerinizi ölçmüyorsanız ilk baÅŸta hesaplamanız zor olabilir. EÄŸer fazla düşük verirseniz, hem sık sık yük miktarını aÅŸtığınızla ilgili Exception’lar alabilirsiniz hem de DynamoDB’nin tüm hızından yararlanamamış olursunuz. GereÄŸinden yüksek ayarlarsanız da tahmin edebileceÄŸiniz gibi kullanmadığınız ÅŸeyler için ücretlendirilmiÅŸ olacaksınız. Peki ön gördüğümüz kapasiteyi nasıl hesaplayacağız? Ön gördüğünüz yük miktarını saniyede yaptığınız okuma ve yazma iÅŸlemlerini Capacity Units üzerinden hesaplamanız gerekiyor.

Åžimdi gelelim Capacity Units kısmına. Capacity Units tahmin edebileceÄŸiniz gibi bir ölçüm ÅŸekli. DynamoDB’de sakladığınız bilginin boyuna göre hesaplanıyor. Okuma ve yazma iÅŸlemine göre kullandığınız boyutlar deÄŸiÅŸiyor. En iyisi doÄŸrudan örnekler üzerinden anlatmaya çalışayım.

Okuma

  • EÄŸer okuyacağınız satır 4KB’tan küçükse: Saniyede yapacağınız her kararlı (Strongly Consistent) ya da her 2 neticede kararlı (Eventually Consistent) okumanız için 1 RCU (Read Capacity Unit).
  • EÄŸer okuyacağınız satır 4KB’tan büyükse: ÖrneÄŸin okuyacağınız satır ya da veri 8.1 KB ise 3 RCU harcamanız gerekiyor.

Okuma işlemlerini sadece satır okumaları olarak düşünmeyin. Her türlü veritabanından yapacağınız okuma için geçerli bu durum.

Yazma

  • EÄŸer yazacağınız bilgi 1KB’tan küçükse: Saniyede yapacağınız her 1KB’lık yazma iÅŸlemi 1 WCU (Write Capacity Unit) olarak hesaplanmaktadır.
  • EÄŸeryazacağınız bilgi 1KB’tan büyükse: ÖrneÄŸin yazacağınız satır ya da veri 8.1 KB ise 9 WCU harcamanız gerekiyor.

Daha önce de dediğim gibi eğer ölçüm yapmıyorsanız bu değerleri bulmakta zorlanabilirsiniz.

Ãœcretlendirme

En eğlenceli bölüme geldik, Ücretlendirme. Heralde en çok farkedecek kısım bu. Bu sebepten de sona sakladım. Ücretlendirmeyi hesaplarken her zaman alternatifini düşünmeniz de fayda var. Örneğin MongoDB mi düşünüyorsunuz alternatifi olarak. Oturun size gerekecek sunucuları, bu sunucların bakımları için harcanacak zamanları, kabataslakta olsa bir hesaplayın. Eminim takımınızda ki arkadaşlardan biri sunucular konusunda bilgi sahibidir hızlıca kuracaktır falan. Ama yine de oturup bir hesaplamaya çalışın.

Free Tier

FreeTier’da Amazon DynamoDB size 25 GB, 25 RCU ve 25 WCU sunuyor. Bu 1 yılın sonunda da kesilmiyor. Ondan istediÄŸiniz gibi kullanabilir, test edebilirsiniz. Bence uygulamanızın maliyetini hesaplamak, en azınan bir POC çıkarmak için yeter de artar bile.

Paralı Tier

Öncelikle S3’te olduÄŸu gibi rahat rahat ucuz demek isterdim. Ama ne yazık ki deÄŸil. Fakat, güzel tarafı, pahalı da deÄŸil. Yine online hesaplama aracını kullanarak istediÄŸiniz gibi fiyatlandırmasına bakabilirsiniz ama ben bir kaç deÄŸerle size ne kadar olduÄŸunu anlatmaya çalışayım.

Tablo sayısından bağımsız olarak:

  • 100 GB’lık veri için 100 RCU ve 50 WCU kullanacak olursanız aylık ~40$.
  • 100 GB’lık veri için 500 RCU ve 100 WCU kullanacak olursanız aylık ~100$.
  • 250 GB’lık veri için 500 RCU ve 100 WCU kullanacak olursanız aylık ~150$.
  • 100 GB’lık veri için 2500 RCU ve 500 WCU kullanacak olursanız aylık ~480$.
  • 250 GB’lık veri için 2500 RCU ve 500 WCU kullanacak olursanız aylık ~525$.

Gördüğünüz üzere çok ucuz değil. (Değerleri özellikle büyük seçtim. Küçük uygulamalar için hala ucuz bence). Fakat yine de sırf veritabanlarınızın bakımını yapması, yedeğini alması, sunucularla ilgilenmesi için birini çalıştırıyorsanız 525$ hiç birşey (kaldı ki kaç uygulama saniyede 2500 okuma yapıyor, 500 yazma yapıyor).

Son

DynamoDB tabiki de bu kadar deÄŸil. Daha DynamoDB Stream’lerinden, trigger mekanizmalarından vs. bahsetmedim. Daha bir kaç yazı daha o konulara deÄŸinmek istemiyorum. AWS ile ilgili bir sonraki yazıda planım Java API’lerini tanıtmak. Büyük ihtimalle ilk baÅŸta normal API’si sonrasında Mapper API’sine deÄŸineceÄŸim.

Ek olarak ilginizi çekerse, güzel bir karşılaştırma