Amazon DynamoDB Açıklaması: Ölçeklenebilir Sistemler Kurmak

DynamoDB Nedir ve Neden Takımlar Kullanır\n\nAmazon DynamoDB, AWS'in tamamen yönetilen NoSQL veritabanı hizmetidir ve neredeyse sınırsız ölçekte tutarlı şekilde düşük gecikmeli okuma ve yazma gerektiren uygulamalar için tasarlanmıştır. “Tamamen yönetilen” olması, AWS'in donanım sağlama, replikasyon, yamalama ve birçok operasyonel görevi üstlendiği anlamına gelir; böylece ekipler veritabanı sunucuları işletmek yerine özellik geliştirmeye odaklanabilir.\n\nTemelde DynamoDB, verileri tablolardaki item'lar (satırlar) olarak saklar, ancak her item esnek attribute'lara sahip olabilir. Veri modeli şu şekilde anlaşılabilir:\n\n- Anahtar-değer: bir item'ı birincil anahtarıyla hızlıca alın, bir kaydı ID ile aramaya benzer.\n- Doküman: iç içe attribute'lar (map ve list) saklayın, JSON'a benzer; katı bir şema olmadan ilişkili alanlar için kullanışlı.\n\nTakımlar, ilişkisel join'lere güzel uymayan iş yükleri için öngörülebilir performans ve daha basit operasyonlar istediklerinde DynamoDB'yi seçer. Mikroservisler (her servis kendi verisine sahip), ani trafik patlamaları olan serverless uygulamalar ve veri değişikliklerine tepki veren event-driven sistemlerde sık kullanılır.\n\nBu yazı temel yapı taşlarını (tablolar, anahtarlar, indeksler), erişim desenlerine göre modelleme (tek tablo tasarımı dahil), ölçeklenme ve kapasite modlarının nasıl çalıştığını ve değişiklikleri event-driven mimariye akıtmak için pratik desenleri anlatıyor.\n\n## Temel Kavramlar: Tablolar, Item'lar ve Birincil Anahtarlar\n\nDynamoDB birkaç basit yapı taşı etrafında organize olur; ancak ayrıntılar önemlidir çünkü veri modellemesini ve isteklerin ne kadar hızlı (ve maliyet etkin) olacağını belirler.\n\n### Tablolar, item'lar ve attribute'lar\n\nBir tablo en üst seviye konteynerdir. Tablo içindeki her kayıt bir item'dır (satıra benzer) ve her item bir dizi attribute (sütun benzeri) içerir.\n\nİlişkisel veritabanlarının aksine, aynı tabloda yer alan item'ların aynı attribute'ları paylaşması gerekmez. Bir item {status, total, customerId} içerirken başka bir item {status, shipmentTracking} içerebilir—DynamoDB sabit bir şema gerektirmez.\n\n### Birincil anahtarlar: basit vs bileşik\n\nHer item benzersiz olarak bir birincil anahtar ile tanımlanır ve DynamoDB iki tipi destekler:\n\n- Basit birincil anahtar (sadece partition key): tek bir attribute her item'ı benzersiz kılar.\n- Bileşik birincil anahtar (partition key + sort key): birden fazla item aynı partition key'i paylaşabilir; sort key onları ayırt eder ve partition içindeki sıralamayı belirler.\n\nUygulamada, bileşik anahtarlar “bir müşterinin tüm siparişleri, en yeniler ilk” gibi gruplanmış erişim desenlerini mümkün kılar.\n\n### Query vs. Scan (yüksek seviye)\n\nQuery, birincil anahtar (veya bir indeks anahtarı) ile item'ları okur. Belirli bir partition key'i hedefler ve sort key aralıklarıyla filtrelenebilir—bu en verimli, tercih edilen yoldur.\n\nScan tüm tabloyu (veya indeksi) dolaşır ve sonra filtre uygular. Başlaması kolaydır, fakat ölçeklendiğinde genelde daha yavaş ve daha maliyetlidir.\n\n### Dikkat edilmesi gereken sınırlar\n\nErken hissedeceğiniz birkaç kısıtlama:\n\n- Maks item boyutu: 400 KB.\n- Attribute tipleri: skalerler (string/number/binary/boolean/null), setler, listeler ve map'ler.\n- Anahtar attribute'lar skaler olmalı (partition veya sort key olarak list/map kullanılamaz).\n\nBu temel bilgiler gerisini kurar: erişim desenleri, indeks seçimleri ve performans özellikleri.\n\n## DynamoDB'nin Veri Modeli: Anahtar-Değer ve Doküman\n\nDynamoDB sıklıkla hem bir anahtar-değer deposu hem de bir doküman veritabanı olarak tanımlanır. Bu doğru, ancak her birinin günlük tasarımda ne anlama geldiğini anlamak faydalıdır.\n\n### Anahtar-değer erişimi vs doküman tarzı item'lar\n\nTemelde veriyi anahtarla alırsınız. Birincil anahtar değerlerini verin ve DynamoDB tek bir item döndürür. Bu anahtarlı arama birçok iş yükü için öngörülebilir, düşük gecikmeli depolama sağlar.\n\nAynı zamanda bir item iç içe attribute'lar (map ve list) içerebilir; bu da doküman veritabanı hissi verir: katı bir şema tanımlamadan yapılandırılmış yükler saklayabilirsiniz.\n\n### Item'larda hiyerarşik JSON-benzeri yapılar modelleme\n\nItem'lar JSON-benzeri verilere doğal olarak uyar:\n\n- Map'ler nesneleri temsil eder (örn. profile.name, profile.address).\n- List'ler dizileri temsil eder (örn. recent actions, tags).\n\nBu, genellikle bir varlık bütün halinde okunduğunda—örneğin kullanıcı profili, alışveriş sepeti veya konfigürasyon paketi—iyi bir eşleşmedir.\n\n### Ne zaman denormalize edilmeli (ve neden yaygın olduğu)\n\nDynamoDB sunucu tarafı join'leri desteklemez. Uygulamanız “bir sipariş artı onun satır öğeleri artı kargo durumu” gibi birden çok kaynağı tek bir okuma yolunda almayı gerektiriyorsa, genellikle denormalize edersiniz: bazı attribute'ları birden çok item'a kopyalayın veya küçük alt yapıları doğrudan bir item içine gömün.\n\n### İlişkisel normalizasyon ile takaslar\n\nDenormalizasyon yazma karmaşıklığını artırır ve güncelleme fan-out'u yaratabilir. Karşılığı ise daha az round trip ve daha hızlı okumalar—çoğu zaman ölçeklenebilir sistemlerde kritik olan yol budur.\n\n## Partition Key ve Sort Key: Erişim Desenleri İçin Tasarım\n\nEn hızlı DynamoDB sorguları “bana bu partition'ı ver” (ve isteğe bağlı olarak “bu partition içinde bu aralığı ver”) şeklinde ifade edilebilenlerdir. Bu yüzden anahtar seçimi esas olarak veriyi nasıl okuyacağınızla ilgilidir, sadece nasıl sakladığınızla değil.\n\n### Partition key: dağılım ve öngörülebilir okumalar\n\nPartition key, bir item'ın hangi fiziksel partition'da saklanacağını belirler. DynamoDB bu değeri hash'leyip veriyi ve trafiği yayıyor. Çok fazla istek küçük bir partition key kümesine yoğunlaşırsa “hot” partition'lar oluşur ve tablo çoğunlukla boş olsa bile throughput limitlerine takılabilirsiniz.\n\nİyi partition key'ler:\n\n- Yüksek kardinaliteye sahiptir (çok sayıda ayrı değer)\n- Sık erişim desenine uyar (okumalar doğrudan, filtrelenmemiş)\n- Popüler hale gelecek değerlerden kaçınır (örn. "GLOBAL" gibi sabit değerler)\n\n### Sort key: aralık sorguları ve gruplanmış varlıklar\n\nBir sort key ile aynı partition key'i paylaşan item'lar birlikte saklanır ve sort key'e göre sıralanır. Bu şunları sağlar:\n\n- Aralık sorguları (BETWEEN, begins_with)\n- Zamana göre sıralı okumalar (ters taramalarla en yeniler ilk)\n- Varlık gruplama (birden fazla item türü aynı partition altında)\n\nSık kullanılan bir desen sort key'in bileşenler halinde oluşturulmasıdır; örneğin TYPE#id veya TS#2025-12-22T10:00:00Z, böylece ek tabloya ihtiyaç duymadan birden fazla sorgu şekli desteklenir.\n\n### Yaygın erişim desenlerini anahtarlara eşleme\n\n- ID ile al: PK = USER#<id> (GetItem ile basit)\n- Kullanıcıya göre listele: PK = USER#<id>, SK begins_with ORDER# (veya SK = CREATED_AT#...)\n- Zaman serisi aralıkları: PK = DEVICE#<id>, SK = TS#<timestamp> ile BETWEEN kullanımı\n\n### Anahtar seçiminin performans ve ölçeklenmeye etkisi\n\nPartition key'iniz en yüksek hacimli sorgularınızla hizalanır ve eşit dağılırsa tutarlı düşük gecikmeli okuma ve yazma elde edersiniz. Aksi takdirde scan'lar, filtreler veya ek indekslerle telafi edersiniz—bunların her biri maliyeti artırır ve hot key riskini yükseltir.\n\n## İkincil İndeksler: GSI ve LSI Açıklaması\n\nİkincil indeksler, DynamoDB'ye tablo birincil anahtarının ötesinde alternatif sorgu yolları sağlar. Yeni bir erişim deseni çıktığında temeldeki tabloyu yeniden şekillendirmek yerine, aynı item'ları farklı bir anahtarla yeniden sunan bir indeks ekleyebilirsiniz.\n\n### GSI vs. LSI: farkı nedir?\n\nGlobal Secondary Index (GSI) kendi partition key'ine (ve isteğe bağlı sort key'ine) sahiptir ve tablonun tüm partition'larını kapsar; herhangi bir zamanda eklenip kaldırılabilir. Orijinal anahtar tasarımına uymayan yeni bir erişim deseni gerektiğinde GSI kullanın; örneğin tablo orderId ile anahtelenmişken customerId ile sorgulama yapmak istediğinizde.\n\nLocal Secondary Index (LSI) temel tablo ile aynı partition key'i paylaşır ancak farklı bir sort key kullanır. LSI'ler tablo oluşturulurken tanımlanmalıdır. Aynı entity grubunda (aynı partition key) birden fazla sıralama istiyorsanız faydalıdırlar; örneğin bir müşterinin siparişlerini createdAt vs status sırasına göre çekmek gibi.\n\n### Projeksiyonlar: indekse ne kopyalanır\n\nProjeksiyon, hangi attribute'ların indekste saklanacağını belirler:\n\n- KEYS_ONLY: en ucuz depolama, ancak genelde temel tablodan ekstra okuma gerekir.\n- INCLUDE: sık döndürdüğünüz sadece belirli attribute'ları kopyalayın.\n- ALL: en basit, ancak depolama ve yazma maliyetini artırabilir.\n\n### Yazma amplifikasyonu (gizli fatura)\n\nHer temel tablo yazması bir veya daha fazla indekse yazmayı tetikleyebilir. Daha fazla GSI ve geniş projeksiyonlar yazma maliyetlerini ve kapasite tüketimini artırır. İndeksleri kararlı erişim desenlerine göre planlayın ve mümkünse projekte edilen attribute'ları minimumda tutun.\n\n## Kapasite Modları ve Ölçeklenme Davranışı\n\nDynamoDB'de ölçekleme bir seçimle başlar: On-Demand veya Provisioned kapasite. Her ikisi de çok yüksek throughput'a ulaşabilir, fakat değişen trafik karşısında farklı davranırlar.\n\n### On-Demand vs. Provisioned: nasıl seçilir\n\nOn-Demand en basiti: isteğe göre ücretlendirilirsiniz ve DynamoDB değişken yükü otomatik karşılar. Tahmin edilemeyen trafik, erken aşama ürünler ve ani dalgalanmalar için uygundur; kapasite hedefleriyle uğraşmak istemeyenler için idealdir.\n\nProvisioned kapasite planlamasıdır: okuma ve yazma throughput'unu belirlersiniz (veya auto-scale yapılandırırsınız) ve sabit kullanımda daha öngörülebilir fiyat alırsınız. Bilinen, tutarlı iş yükleri ve talebi öngörebilen ekipler için genelde daha ucuzdur.\n\n### Okuma/yazma kapasitesi pratikte\n\nProvisioned throughput şu birimlerle ölçülür:\n\n- RCU'lar (Read Capacity Units): yaklaşık olarak 4 KB'ye kadar güçlü tutarlı bir okuma/ saniye (veya iki zayıf tutarlı okuma).\n- WCU'lar (Write Capacity Units): yaklaşık olarak 1 KB'ye kadar bir yazma/ saniye.\n\nGerçek maliyeti item boyutu ve erişim deseni belirler: büyük item'lar, güçlü tutarlılık ve scan'lar kapasiteyi hızla tüketebilir.\n\n### Auto scaling temelleri (ve limitleri)\n\nAuto scaling, provisioned RCU/WCU'ları kullanım hedeflerine göre ayarlar. Kademeli büyüme ve döngülerde yardımcı olur, ancak anlık değildir. Ani zirveler kapasite yeterince hızlı artmazsa hala throttle'lanabilir ve bir partition key'in hot olması auto scaling ile çözülemez.\n\n### DAX: okuma ağırlıklı iş yükleri için önbellek\n\nDynamoDB Accelerator (DAX), tekrarlanan okumalarda gecikmeyi azaltan bellek içi bir cache'tir (örn. popüler ürün sayfaları, session aramaları, lider tablolar). Birçok istemci aynı item'ları tekrar tekrar istiyorsa faydalıdır; yazma ağırlıklı desenlerde yardımcı olmaz ve dikkatli anahtar tasarımının yerini almaz.\n\n## Tutarlılık, İşlemler ve Doğruluk\n\nDynamoDB, okuma garantilerini gecikme ve maliyetle takas etmenize izin verir; bu yüzden her işlem için “doğru”nun ne anlama geldiğini açıkça belirlemek önemlidir.\n\n### Eventually consistent vs strongly consistent okumalar\n\nVarsayılan olarak GetItem ve Query eventually consistent okur: bir yazmadan hemen sonra kısa süreli olarak eski bir değeri görebilirsiniz. Bu, feed'ler, ürün katalogları ve diğer çoğunlukla okuma yapılan görünümler için genelde uygundur.\n\nStrongly consistent okumalar (tek bölgeden tablodan okurken opsiyon) DynamoDB'nin en son onaylanmış yazmayı görmenizi garanti eder. Güçlü tutarlılık daha fazla okuma kapasitesi ve kuyruk uç gecikmesi getirebilir; bu yüzden gerçekten kritik okumalar için saklayın.\n\n### Güçlü tutarlılığın gerektiği durumlar\n\nAşağıdaki gibi geri döndürülemez işlemleri kısıtlayan okumalar için güçlü tutarlılık değerlidir:\n\n- Bir siparişi onaylamadan önce stok kontrolü yapmak\n- Erişim vermeden önce yetkilendirme bayrağını okumak\n- Bir iş akışının mevcut durumunu alıp bir sonraki adımı yürütmek\n\nSayaçlar için en güvenli yaklaşım genelde “güçlü okuma sonra yazma” değil, atomik güncelleme (ör. UpdateItem ile ADD) kullanmaktır, böylece artışlar kaybolmaz.\n\n### İşlemsel okuma/yazmalar\n\nDynamoDB işlemleri (TransactWriteItems, TransactGetItems) ACID semantiği sağlar ve 25 item'a kadar kapsar. Bir siparişi yazmak ve stoğu rezerve etmek gibi birden çok item'ın birlikte güncellenmesi gerektiğinde kullanışlıdır.\n\n### Güvenli yeniden denemeler için idempotentlik\n\nDağıtık sistemlerde yeniden denemeler normaldir. Yeniden denemeler işlem tekrarı yaratmasın diye yazmaları idempotent yapın:\n\n- Sonuçla birlikte saklanan bir istemci istek token'ı (idempotency key) kullanın\n- ConditionExpression ile benzersizliği zorlayın (örn. attribute_not_exists ile yalnızca oluşturma)