Neden DynamoDB Kullanmalıyız?
Merhabalar sizlere bu yazımda DynamoDb nedir? Neden tercih etmeliyiz? Kullanırken nerelere dikkat etmeliyiz? Single Table Design ve Local Secondary Index-Global Secondary Index yapılarından bahsedeceğim.
DynamoDB AWS(Amazon Web Service)’in geliştirmiş olduğu yüksek hız ve öngörülebilir performans sağlayan, uygulamalarınızı kolayca scale edebileceğiniz bir NoSQL (key-value ve document store) tabanlı bir veritabanıdır.
Neden Tercih Etmeliyiz?
- Eğer ki releational bir database kullanıyorsanız, yüksek trafik aldığınız da sisteminizi scale up yapmak durumunda kalırsınız. Ciddi yük aldığınız durumlarda makineyi kapatmak, yükseltmek ciddi problem ve gelir kaybı yaratır. Bu konuda DynamoDB serveless yapıda olduğundan makine maliyetinden kurtulmuş oluyorsunuz. İsterseniz AWS’nin auto-scaling özelliğini kullanarak sisteminizi kolayca ölçekleyebiliyorsunuz. Belirli bir değer tanımlayıp bunun üstüne yada altına düştüğünde sizin adınıza scale-up/down yapıyor. Bunları Amazon’ a bırakmayıp kendinizde istediğiniz zaman yapabiliyorsunuz tabiki. Maliyetlerinizi azaltmak adına güzel bir olanak sağlıyor.
- DynamoDB, database yapınızı güzel şekilde kurguladığınızda milyonlarca veri de milisaniyeler düzeyinde okuma - yazma performansı vaadediyor.
- DynamoDB verileri partitionlar halinde tutuyor. Bazı partition da tutulan veriler sık kullanıldığında Hot Partition olarak değerlendiriliyor. Genel kapasite, her partitiona aynı seviyede bölümleyip veriliyor. Bazıları sık çağrılırken bazıları da az çağrılıyor. Eskiden kullanmadığımız bir partitionın kapasite tüketmesi ciddi bir problem iken Adaptive Capacity ile bu sorunu aşmışlar ve her partition’lar arasında kapasite yönetimini sağlamışlar.
- TTL(Time To Live) özelliği sayesinde belirlenen bir süre sonra verinin expire edilmesi sağlanabiliyor. TTL bu noktada ciddi bir fayda sağlıyor, az kullanılan partitionları farklı bir tabloya taşıyabiliyorsunuz. Sık kullandığınız veriler için yüksek performanslı bir tablo, az kullandığınız veriler için düşük kapasiteli bir tablo oluşturabiliyorsunuz. Böylece sonsuz kapasite artışı maliyetinden kurtulmuş oluyorsunuz.
- DynamoDB de lambda functionları kullanabilirsiniz. Örnek olarak bir müşteri sitenizden alışveriş yaptı hemen ona otomatik mail yada sms gönderebilirsiniz.
- Kolaylıkla DynamoDB’nin dumpını alıp S3'e atabiliyorsunuz. Benzer şekilde S3' ten dump alıp yeni bir tablo oluşturabilirsiniz. Yine S3'e eklediğiniz excell ile de DynamoDB’ye bulk insert yapabiliyorsunuz.
- DynamoDB bir NoSQL olduğu için normal SQL sorguları yazmak isterseniz dataları AWS RedShift’e atıp SQL sorguları yazabilirsiniz.
- DynamoDB text search alanında zayıf kalıyor benzer şekilde datalarınızı AWS’nin CloudSearch servisine atıp bu service de rahatlıkla text search yapabilirsiniz.
Neden Tercih Etmemeliyiz?
- DynamoDB kompleks sorgular ve text search yetisi bakımından zayıf kalıyor. AWS’nin başka bir servisine aktararak çözüm bulmaya çalışmak gerekiyor.
- Real time analiz yapıyorsak ve geçmiş datalara sürekli ihtiyaç duyuyorsak bu anlamda da sıkıntılar yaşabiliriz. İkinci bir AWS servisine aktararak çözüm bulmaya çalışıyoruz.
- DynamoDB columnar bir db olduğunda ilk başta çok iyi tasarlanması gerekiyor. Yanlış bir tasarım yapıldığında performans anlamında ve ileriye dönük geliştirme konusunda problem yaşayabilirsiniz.
- Eğer ki tablo kurgusunda birbiri arasında join ihtiyacı yoksa ve db miz yüksek bir trafik almıyorsa sadece yeni teknoloji diye kullanıyor olmamamız uygun olmaz. İhtiyacımıza göre bir db seçimiz yapmamız gerekiyor bu anlamda DynamoDB kullanmamız bize daha fazla maliyet yaratabilir.
Kullanırken Nelere Dikkat Etmeliyiz?
- İlk olarak database tasarımınızı ele almalısınız. DynamoDB single table design modelini baz alıyor. Sizin yapınız bu modele uygun mu öncelikle olarak buna karar vermeniz gerekiyor.
- Single table design nedir buna bakalım. Örnek olarak Movie Advice App’niz olduğunu varsayalım. Database tasarımı olarak da aşağıdaki gibi bir tasarım olduğunu düşünelim. Sayfanızda Müşteri’nin bilgilerini, filmlerini ve sepet hakkında bilgileri görmek istiyorsunuz. Bu işlemleri yapmak için tablolarımızı join yapısını kullanarak getirebiliriz. Ama uygulamamız scale edildikçe bu modelimiz yavaşlamaya, performansı giderek azalmaya başlayacaktır.
- DynamoDB bu anlamda single table design modeli ile maliyetli bir join işlemi yapmak yerine tek bir sorgu ile istediğiniz datayı alabilmenizi sağlıyor.
Bu söz DynamoDB ile ilgili herşeyi anlatır diye düşünüyorum.
The main reason for using a single table in DynamoDB is to retrieve multiple, heterogenous item types using a single request.
Daha detaylı öğrenmek isterseniz burayı inceleyebilirsiniz.
https://www.alexdebrie.com/posts/dynamodb-single-table
Biraz da şema tasarımından ve index yapılarından bahsedelim.
DynamoDB hangi veriye nasıl erişeceğimizi belirlememiz için bize tasarımı zorunlu tutuyor.
- Sadece Hash yani partition key kullanarak sorgu atabiliriz. Yukarıda PK olarak yer alan kısım.
- Hash + Range(Sort) Key ile birlikte PK + SK.
- Hash + Local Secondary Index ile birlikte
- Sadece Global Seconday Index
- Global Secondary Index + Range(Sort) Key birlikte kullanarak sorgulama yapabilirsiniz.
- Partition key alanına verileri yazarken suffix yada prefix (ön ek, son ek) kullanmak da oldukça popülerdir.
DynamoDB bizlere Primary Key tanımlamamızı zorunlu tutuyor, isterseniz sadece hash yada hash + range key ile (primary key) oluşturabilirsiniz. Bu alanların uniqe olmasına dikkat edin.
- Tablo yapımızda ortak olan customerId olduğu için id yerine username kullandık hash key olarak önüne bir prefix ekleyip username ekledik. Range(Sort Key) olarak ilgili tabloların isimlerini prefix olarak ekledik daha sonra uniqe olan değerlerini de ekledik.
- Bu prefixleri neden ekliyoruz onu da kısaca açıklayayım, DynamoDB de sorgu yazmak istediğimizde begins-with özelliği ile de sorgulama yapabiliyoruz bu da şu anlama geliyor. Hash Key =CUSTOMER#rockybalboa, Range(Sort Key) = #ORDER# bu şekilde sorguladığımızda rocky isimli müşterinin bütün sipariş kayıtlarını görmemize yarıyor. DynamoDB yapısında bu tarz modeller çok kullanıyor.
- Local Secondary Index: Sadece tablomuzu create ederken oluşturabiliyoruz. SK2, SK3 anlamına geliyor hash key ile sorgularımızda kullanabiliyoruz alternatif search yapabilmenizi sağlıyor.
- Global Secondary Index: İkinci bir PK ve SK oluşturmamıza imkan veriyor. Tablomuzu create ettikten sonra da oluşturabiliyoruz. Ancak maliyetimiz iki katına çıkmış oluyor o yüzden iyice düşünmek gerekiyor. DynamoDB de veriler partitionlar halinde tutulduğundan ana tabloya bir yazma işlemi geldiğinde aynı veri GSI tablosuna da yazılır. Bu da her bir yazma işlemi için maliyetimizi iki katına çıkarıyor. Eğer 4 tane GSI’ınız varsa 1 satır orijinal tabloya, 4 satır da GSI tablolarına yazılacağı için 4+1 = 5 katı ödeme yapmanız anlamına geliyor. Maksimum 20 GSI’a izin veriliyor.
Nasıl Sorgu Tipi Kullanmalıyım:
DynamoDB de sorgulama yaparken iki tip yöntem kullanabilirsiniz.
- Scan: Bütün partitionlar arasında gezer, oldukça yavaştır ve performans anlamında önerilmez.
- Query: Partition(Hash) Key ve Range Key(Sort) kullanarak yapabildiğimiz sorgulamadır, oldukça performanslı bir şekilde verilerinizi getirebilirsiniz. Bu sayede hız ve capacity unit kazanmış oluruz, bu sorgu operatörünün kullanılması önerilir.
Database mimarimizi ve hangi şartlarda sorgular kullanacağımızı önceden belirlememiz çok önemli bunlara dikkat etmemiz gerekiyor.
Umarım sizlere DynamoDB hakkında bilgiler verebilmişimdir. Diğer yazılarımda localimizde DynamoDB kurulumu ve unit test yazımı hakkında bilgiler vermeyi planlıyorum, sağlıcakla kalın.
Referanslar:
