AWS(Amazon Web Services) DynamoDB - Roadmap

watch_later 6/27/2020
DynamoDB, Amazon Web Servisleri’nin sağladığı bir NoSQL veritabanıdır. Yıllarca Amazon içerisinde kullanılmış bir veritabanıdır. NoSQL veritabanı türlerinden key-value türünde olduğu söylenebilir. Büyük bir tabloda hashe karşılık değerler şeklinde tutuluyor.


Şemasız(Schemaless)
Tüm key-value tipindeki NoSQL veritabanları şemasız tasarlanmıştır. Şemasız olmasıyla hash  bilgileri aynı tabloda tutuluyor.

Tutarlılık(Consistency)
NoSQL veritabanlarının çoğu ACID (Atomicity, Consistency, Isolation, Durability) desteklemiyor. DynamoDB de tutarlılık için iki farklı çözüm var. (Eventually Consistent ve Strongly Consistent)
Eventually Consistent, verileri okurken yeni yapılan güncellemeleri okumama ihtimali var. DynamoDB dokümantasyonunda yeni yapılan güncelleme = 1 sn içerisinde yapılan güncellemeler olarak ifade ediliyor. Strongly Consistent ise her okumada verinin son halini okumak şeklinde tanımlanıyor. Strongly Consistent yaptığınız okumalar, Eventually Consistent göre daha maliyetli oluyor.
Relational Database(RDS)’i bir noktadan sonra genişlemek mümkün değilken, DynamoDB’i Provisioned Capacity hesabı yaparak down-time yaşatmadan sınırsız scale up/down yapabiliyor.
DynamoDB üç farklı A - Z üzerinde replica tutuyor. Bunlardan bir tanesi primary replica oluyor. Eğer primary replica olandan veri okumak istenirse bu Strong Consistency oluyor. Eğer primary dışındaki replica’lardan veri okunmak istenirse bu Eventual Consistency oluyor. Çünkü primary üzerinde yazma işlemleri olması sebebi ile verinin doğruluğu kesindir. Diğerleri henüz güncellemeyi almamış olabileceği için verinin kesinliği söz konusu değildir. Strong Consistency olan Eventual Consistency göre iki katı kapasite ihtiyaç duyuyor. Dolayısı ile yapılacak sorgularda consistency ihtiyacı yoksa ms gecikmeler problem değilse Eventual Consistency tercih etmek cost-saving sağlayacaktır. Default: Eventual Consistency

Ölçeklenebilirlik(Scalibity)
DynamoDB’de scalibity yapmadan önce öngörülen saniyelik okuma ve yazma sayıları isteniyor. Bu bilgilere dayanarak hem ne kadar kaynak kullanması gerektiğine, DynamoDB tablolarını sunuculara ne şekilde dağıtacağına karar veriyor hem de ücretlendiriliyor.
Öngörülen saniyelik okuma ve yazma sayılarında fazla saniyelik okuma ve yazma yapılırsa ThrottlingException hatası alınır.

Partition Key (a.k.a HashKey)
Her ne kadar DynamoDB için key-value store denirse de schemaless olmasından kaynaklanan document store benzeri özellikleri de bünyesinde barındırmaktadır.
Partition Key denilmesinin sebebi ise, bu bilginin aynı zamanda bilgilerin nasıl dağıtılacağını belirlemesidir. DynamoDB scailibity kapsamında, sharding yapıyor. Sharding yaparken hangi veriyi hangi sunucuya dağıtacağına yine bu key üzerinden karar veriyor.

DynamoDB verileri partition şeklinde tutuyor. Bazı partition tutulan veriler sıklıkla kullanılmasından dolayı Hot Partition olarak değerlendiriliyor. Genel kapasite her partitiona aynı seviyede bölümlenip veriliyor. Ancak bazıları çok sık çağırılırken bazıları daha az çağırılıyor. Bu bazılarının kapasitesini tüketmesine, diğerlerinin ise kullanmadığı bir kapasitenin oluşmasına sebep oluyor. Bu problemi çözmek için Adaptive Capacity ile partition arasında kapasite yönetimini yapma sağlanıyor.
TTL özelliği ile belirlenen bir süre sonra verinin expire etmesi sağlanabiliyor. DynamoDB tüm kapasiteyi partition şeklinde tutuyor. Eğer çok partition varsa partition başına düşecek kapasite azalacaktır. TTL bu noktada ciddi fayda sağlayıp az kullanılan partitionları farklı tabloya taşımaya imkan veriyor. Sık kullanılanlar için yüksek kapasiteli bir tablo sunabilir, az kullanılanlar için düşük kapasiteli bir tablo sunulabilir. Böylece sonsuz kapasite artışı maliyetinden ortadan kalkar.

Sort Key
Her ne kadar tabloların her alanı üzerinden arama işlemi yapılabilse de, hızlı bir arama yapabilmek için Hash Key’in yanında Sort Key’e de ihtiyaç var.

Primary Key
PrimaryKey (PK), RDB(Relational Database)de ki gibi tekil bilgileri ifade etmektedir. Aslında, DynamoDB’de doğrudan PK tanımlamak mümkün değildir. Bir DynamoDB tablosunda PK iki türlü olabilir:
Partition Key
Partition Key + Sort Key

Secondary Indexes
Hızlı arama yapabilmek için ek alanlar eklemek mümkündür. Ama bunu yaparken dikkatli olunmalıdır, tanımladığınız index türüne göre, index için ek tablolar oluşuyor. Bu durum maliyet olarak yansıtılıyor.
DynamoDB tabloları tanımlarken index yapısı iyice düşünülmelidir. Local Secondary Index tablo yaratılırken yaratılması gereken bir index olduğu için özellikle düşünülmelidir. Global Secondary Index tablonun temel kapasitesi yerine yeni bir kapasiteye ihtiyaç duyuyor. Bu sebeple maliyeti artırdığı için eğer gerek duyulmuyorsa tanımlanmaması gerekir.

Provisioned Throughput/Capacity Units
Provisioned Throughput, yani öngörülen yük miktarı, hem ölçeklendirmede hem de fiyatlandırmada sık karşılaşılabilecek bir konudur. Eğer düşük ayarlanırsa, hem sık sık yük miktarını aşılır hata alınır hem de DynamoDB tüm hızından yararlanılamaz. Gereğinden yüksek ayarlanırsa da maliyet artacaktır.
Capacity Units ile 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.
Kapasite belirleme hatalı ya da düzenli yapılmazsa maliyeti artırıcı yönde etki yapar. Bu problemden kaçınmak için AWS DynamoDB auto-scaling özelliği belirli bir süre tanımlanmış değerin üstünde kapasite kullanımı olursa otomatik scale-up/down yapmaya imkan veriyor.

Scan operatörü yerine Query operatörü kullanılmalıdır. Scan partition arasında işlem yaparken, Query sadece bir partition içinde işlem yapıyor Query operatörü kullanmakla hem hız kazanımı hem Capacity Unit kazanımı elde edilmiş oluyor.
DynamoDB NoSQL yapısından dolayı kompleks sorgu yazılamamasının önüne Redshift kullanılarak geçilebiliyor. Özellikle raporlama tarafımızda kullanmak için belirli bir andaki DynamoDB verisini DynamoDB’den çekilip Redshift’e alınabiliyor. Alınan veri üzerinde SQL sorgular yazılıp, rapor çıkarılabilir.
Redshift ile sadece kopyalanan veri üzerinde SQL işlemi yapılırken, AWS EMR ile real-time DynamoDB verisi üzerinde SQL işlemi yapılabiliyor. AWS EMR Apache Hadoop Cluster yönetiyor. Hadoop üzerinde çalışan Apache Hive Datawarehouse kullanıyor. Bu şekilde gerçek zamanlı veri üzerinde SQL ile sorgu yapılabiliyor.

Okuma(Read)
Okunan satır < 4 KB: Saniyede yapılacak her strongly consistent ya da her 2 her eventually consistent okuma için 1 RCU
Okunan satır  > 4KB: Okunacak satır ya da veri 8.1 KB ise 3 RCU harcanması gerekiyor.

Yazma(Write)
Yazılacak veri < 1KB: Saniyede yapılacak her 1KB’lık yazma işlemi 1 WCU
Yazılacak veri > 1KB: Yazılacak satır ya da veri 8.1 KB ise 9 WCU harcanması gerekiyor.

DynamoDB kısıtlarından birisi de attribute olarak tutulacak bir verinin boyutunun maksimum 400KB olmasıdır. 400KB üstü attribute saklama ihtiyacı için üç şekilde yapılabilir:
1.     GZIP ile küçültme
2.     S3 Bucket’a koyup linkini DynamoDB tutma
3.   Attribute farklı partition ve sort key ile bölümleme
DAX(DynamoDB Accelerator)(Eventual Consistency ile çalışıyor) kullanılarak DynamoDB kendi önüne kendi cache sistemini koyarak Hot Partition problemini çözüyor. Yani partition kendi kapasitesini tüketmeden DAX üzerinden verinin alımı sağlanıyor.



DAX üzerinde işlem yapan ile DAX aynı VPC üzerinde olacak şekilde tasarlanmak zorunludur. DAX oluşturulduğunda default cache tutma süresi 5dk değiştirilmezse 5dk içinde expire oluyor ve siliniyor.

DynamoDB Streams ile herhangi bir değişiklikte otomatik Lambda tetiklenebiliyor.
Manuel ya da Lamba da ile düzenli alınabilecek yedeklerin dışında Point in Time Recovery adlı özellik ile 35 güne kadar DynamoDB’yi istenen zamana döndürebiliyor. Sadece aktif olması gerekiyor ve otomatik bunun yönetimini yapıyor.
Global Table özelliğini kullanarak birden çok region üzerinde aynı anda çalışma imkanı sunulabiliyor. Europe(Frankfurt) region’da çöktüğünde Asia Pacific (Tokyo) bulunan bir diğer replica üzerinden hizmet vermeye devam ediliyor.
AWS Data Pipeline kullanılarak Amazon S3 Bucket’a DynamoDB dump verisi export edilebiliyor. Benzer şekilde import edip Amazon S3'den dump verisi alınıp kolaylıkla yeni tablo oluşturabiliyor.

Ücretlendirme(Pricing)
Free Tier
Free Tier Amazon DynamoDB 25 GB, 25 RCU ve 25 WCU sunuyor. Bu hizmet bir yılın sonunda da kesilmiyor.

Paid Tier
Data(GB)
RCU
WCU
Price($)
100
100
50
~40
100
500
100
~100
250
500
100
~150
100
2500
500
~480
250
2500
500
~525




Bir sonraki yazımda görüşmek üzere...



sentiment_satisfied Emoticon