Amazon DynamoDB'nin ne olduğunu, NoSQL modelinin nasıl çalıştığını ve ölçeklenebilir, düşük gecikmeli sistemler için pratik tasarım desenlerini öğrenin.

{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)DynamoDB, AWS üzerinde tamamen yönetilen bir NoSQL veritabanıdır ve tutarlı şekilde düşük gecikmeli okuma/yazma gerektiren çok yüksek ölçekli uygulamalar için tasarlanmıştır. Erişim desenlerini (ID ile çekme, sahip tarafından listeleme, zaman aralığı sorguları) tanımlayabiliyorsanız ve veritabanı altyapısı çalıştırmak istemiyorsanız tercih edilir.
Mikroservisler, serverless uygulamalar ve event-driven sistemlerde sıkça kullanılır.
Bir tablo item'lar (satırlara benzer) içerir. Her item, esnek bir attribute kümesidir (sütun benzeri) ve iç içe veri barındırabilir.
DynamoDB, bir isteğin genellikle “tüm varlığı” alacağı senaryolarda iyi çalışır; çünkü item'lar maps ve lists (JSON-benzeri yapılar) içerebilir.
Tek başına bir partition key bir item'ı benzersiz tanımlar (basit birincil anahtar). Bir partition key + sort key (bileşik anahtar) aynı partition key'i paylaşan birden çok item olmasına izin verir ve sort key ile öğeler sıralanır ve benzersiz hale gelir.
Bileşik anahtarlar şu desenleri mümkün kılar:
Query kullanabileceğiniz zaman (partition key belirtilebiliyorsa ve isteğe bağlı olarak sort key koşulu varsa) Query kullanın. Bu hızlı ve ölçeklenebilir yoldur.
Scan yalnızca gerçekten tüm tabloyu okumanız gerektiğinde kullanılmalı; tüm tablo veya indeks üzerinde dolaşır ve sonra filtre uygular, bu da genelde daha yavaş ve maliyetlidir.
Sık sık Scan yapıyorsanız, anahtar veya indeks tasarımınızı gözden geçirmeniz gerektiğinin bir işaretidir.
İkincil indeksler alternatif sorgu yolları sağlar.
İndeksler yazma maliyetini artırır çünkü yazmalar indekse de çoğaltılır.
On-Demand (isteğe bağlı) trafik tahmininin zor olduğu, ani zirvelerin olduğu veya kapasiteyi yönetmek istemediğiniz durumlar için uygundur; isteğe göre ücretlendirilirsiniz.
Provisioned (ayrılmış) kapasite, sabit/öngörülebilir kullanımda daha kontrollü maliyet sağlar; kapasiteyi belirtir (veya auto scaling ile ayarlarsınız). Ani zirveler için anında tepki vermeyebilir.
Varsayılan olarak okuma işlemleri eventually consistent (zamanla tutarlı) olur; yazmadan hemen sonra eski bir değeri görebilirsiniz.
Kritik ve güncel olması gereken okumalar için (yetkilendirme kontrolleri, iş akışı durum kontrolleri gibi) strongly consistent okumaları kullanın. Güçlü tutarlılık daha fazla okuma kapasitesi gerektirir ve kuyruğun kuyruk gecikmesini artırabilir.
Eşzamanlılık altında doğruluk için, genelde okuma-sonra-yaz yerine atomik güncellemeler (örn. ile ) tercih edilmelidir.
Transactions (TransactWriteItems, TransactGetItems) ACID özellikleri sağlar ve aynı anda en fazla 25 item üzerinde işlem yapar.
Bir siparişi oluşturup stoğu rezerve etmek gibi birden çok item'ın birlikte güncellenmesi gerektiğinde kullanın. Maliyet ve gecikmeyi artırır; yalnızca gerçekten gerekli akışlar için ayrılmalıdır.
Hot partition'lar, çok fazla isteğin aynı partition key değerine (veya küçük bir değer kümesine) yönelmesiyle oluşur; bu, tablo genelinde düşük kullanım olsa bile tıkanmaya neden olabilir.
Yaygın çözümler:
DynamoDB Streams tabloya yapılan insert, update ve delete işlemlerinin değişim akışını verir. Yaygın bir desen: Streams → Lambda ve her kayıt kümesi bir fonksiyon tetikler.
Tasarımda dikkat edilmesi gereken garantiler:
Tüketicileri yapın (anahtarla upsert, koşullu yazılar veya işlenmiş event ID'lerini saklama).
USER#1, TENANT#default veya STATUS#OPEN gibi “global” partition key'ler veya herkesin “şimdi” yazdığı zamana dayalı desenler.\n\n### Hot key belirtileri ve düzensiz trafik\n\nGenelde şunları görürsünüz:\n\n- Bazı anahtarlar için throttling (ProvisionedThroughputExceededException)\n- Birkaç erişim deseni için artan ve düzensiz gecikme, diğerleri hızlı kalırken\n- CloudWatch metriklerinde düzensiz tüketilmiş kapasite ve ani patlamalar\n\n### Azaltma teknikleri\n\nÖnce dağılım için, sonra sorgu kolaylığı için tasarlayın:\n\n- Anahtar tasarımı: yüksek kardinaliteli partition key'ler seçin (örn. TENANT#<id> sabit bir değerin yerine).\n- Write sharding: ORDER#<id>#<shard> gibi küçük rastgele veya hash ekleriyle yazıları N shard'a yaymak; gerektiğinde shard'lar arasında sorgulama yapmak.\n- Zaman kovaları (time buckets): saat/gün bazlı kovalar (METRIC#2025-12-22T10) kullanarak tüm yazıların tek bir öğeye gitmesini önleyin.\n\n### Patlamalı iş yüklerini yönetme\n\nÖngörülemeyen zirveler için on-demand kapasite patlamaları emebilir (servis limitleri dahilinde). Provisioned moddaysanız auto scaling kullanın ve throttle durumlarında istemci tarafında exponential backoff with jitter uygulayın, çünkü senkronize yeniden denemeler spike'ı güçlendirebilir.\n\n## Ölçeklenebilir Sistemler İçin Veri Modelleme Desenleri\n\nDynamoDB veri modellemesi ER diyagramlarından değil erişim desenlerinden başlar. Anahtarları, ihtiyaç duyduğunuz sorguları hızlı Query işlemlerine dönüştürecek şekilde tasarlarsınız; geri kalan işler ya kaçınılır ya da asenkron olarak ele alınır.\n\n### Tek tablo tasarımı (neden popüler)\n\n“Tek tablo tasarımı” birden çok varlık türünü (kullanıcılar, siparişler, mesajlar) tek bir tabloda saklamak ve ilgili verileri tek bir Query ile almak için tutarlı anahtar konvansiyonları kullanmak anlamına gelir. Bu, varlıklar arası round trip'leri azaltır ve gecikmeyi öngörülebilir tutar.\n\nYaygın yaklaşım bileşik anahtar kullanımıdır:\n\n- PK mantıksal bir bölümü gruplar (örn. USER#123)\n- SK o grup içindeki öğeleri sıralar (örn. PROFILE, ORDER#2025-12-01, MSG#000123)\n\nBu sayede “bir kullanıcı için her şeyi al” veya “sadece kullanıcının siparişlerini al” gibi sorguları sort-key önekleriyle yapabilirsiniz.\n\n### İlişkiler: adjacency list ve çoktan-çoğa (many-to-many)\n\nGraf benzeri ilişkiler için bir adjacency list iyi çalışır: kenarları item olarak saklayın.\n\n- PK = USER#123, SK = FOLLOWS#USER#456\n\nTers yönde sorgulamayı desteklemek veya gerçek many-to-many için bir inverted edge item ekleyin veya okuma yollarına bağlı olarak bir GSI'ye projekte edin.\n\n### Zaman serisi: bucket + sort key + TTL\n\nOlaylar ve metrikler için sınırsız partition'lardan kaçının, bucket kullanın:\n\n- PK = DEVICE#9#2025-12-22 (cihaz + gün)\n- SK = TS#1734825600 (zaman damgası)\n\nEski noktaları otomatik silmek için TTL kullanın ve panolar için hızlı erişim sağlamak üzere saatlik/günlük rollup'ları ayrı item'larda saklayın.\n\nDaha derin bir tazeleme isterseniz, /blog/partition-key-and-sort-key-design yazısını inceleyin.\n\n## Streams ve Event-Driven Mimariler\n\nDynamoDB Streams, DynamoDB'nin yerleşik change data capture (CDC) akışıdır. Tablo üzerinde etkinleştirildiğinde her insert, update veya delete bir stream kaydı üretir ve downstream tüketiciler bu kayıtlara tepki verebilir—tabloyu poll etmek yerine.\n\n### DynamoDB Streams temelleri\n\nBir stream kaydı, anahtarları ve isteğe bağlı olarak item'ın eski ve/veya yeni görüntüsünü içerir; bu, seçtiğiniz stream view type'a bağlıdır (keys only, new image, old image, both). Kayıtlar shard'lara gruplanır ve sırasıyla okunur.\n\n### Event-driven iş akışları kurmak\n\nYaygın bir kurulum DynamoDB Streams → AWS Lambda'dır; her kayıt partisi bir fonksiyonu tetikler. Diğer tüketiciler de mümkündür (özelleştirilmiş tüketiciler veya analitik/loglama sistemlerine yönlendirme).\n\nTipik iş akışları şunları içerir:\n\n- Materialized view'lar: kaynak tablo değiştiğinde denormalize edilmiş bir okuma modeli tablosu yazmak.\n- Cache invalidation: yazmalardan sonra Redis/ElastiCache öğelerini süresizleştirmek veya yenilemek.\n- Audit log'lar: değişim olaylarını immutable olarak bir audit tablosuna veya harici bir depoya eklemek.\n\nBöylece birincil tablo düşük gecikmeli okuma/yazma için optimize edilirken türetilmiş işler asenkron tüketicilere itilir.\n\n### Sıralama, yeniden denemeler ve doğruluk\n\nStreams her shard için sıralı işleme sağlar (genelde partition key ile korelasyon gösterir), ancak tüm anahtarlar arasında global bir sıralama yoktur. Teslimat en az bir defa gerçekleşir; yani çoğaltmalar olabilir.\n\nBunu güvenli şekilde ele almak için:\n\n- Handler'ları idempotent yapın (örn. anahtara göre upsert, koşullu yazılar veya işlenmiş event ID'lerini saklama).\n- Yeniden denemeler ve kısmi batch hataları bekleyin; mümkünse DLQ/on-failure hedefleri kullanın.\n- E-posta veya ödeme gibi yan etkileri deduplama veya işlemsel güvenliklerin arkasına koyun.\n\nBu garantiler göz önüne alındığında, Streams DynamoDB'yi event-driven sistemler için sağlam bir omurga haline getirebilir.\n\n## Güvenilirlik, Yedekleme ve Gözlemlenebilirlik\n\nDynamoDB, veriyi bir bölge içinde birden fazla Availability Zone'a yayarak yüksek erişilebilirlik için tasarlanmıştır. Çoğu takım için pratik güvenilirlik kazanımları net bir yedekleme stratejisine sahip olmaktan, replikasyon seçeneklerini anlamaktan ve doğru metrikleri izlemekten gelir.\n\n### Yedeklemeler: on-demand vs point-in-time recovery\n\nOn-demand backups manuel (veya otomatik) anlık görüntülerdir; bir migration öncesi, bir sürüm sonrası veya büyük bir backfill öncesi alınır. “Yer imi” anları için uygundur.\n\nPoint-in-time recovery (PITR) sürekli değişiklikleri yakalar, böylece tabloları retention penceresi içinde herhangi bir saniyeye geri döndürebilirsiniz. PITR yanlışlıkla silinmeler, hatalı deploy'lar veya doğrulamadan geçen bozuk yazılar için güvence sağlar.\n\n### Replikasyon ve çoklu bölge seçenekleri\n\nÇok bölge dayanıklılığı veya kullanıcılara yakın düşük gecikmeli okumalar gerekiyorsa Global Tables veriyi seçilen bölgeler arasında çoğaltır. Failover planlamasını basitleştirir, ancak bölgeler arası replikasyon gecikmesi ve çakışma çözümlemeyi beraberinde getirir—bu yüzden yazma desenleri ve öğe sahipliğini net tutun.\n\n### İzleme için temel metrikler\n\nEn azından şu konularda uyarı oluşturun:\n\n- Okuma ve yazma için gecikme (p95/p99)\n- Throttled requests ve sistem hataları\n- Tüketilen kapasite (ve provisioned'a kıyasla boşluk)\n\nBu sinyaller genelde hot-partition sorunlarını, yetersiz kapasiteyi veya beklenmedik erişim desenlerini ortaya çıkarır.\n\n### Olay kitapları (incident playbooks)\n\nThrottling durumunda önce buna neden olan erişim desenini belirleyin, sonra geçici olarak on-demand'a geçmeyi veya provisioned kapasiteyi artırmayı düşünün ve hot key'leri sharding ile azaltmayı planlayın.\n\nKısmi kesintiler veya artan hatalar durumunda blast radius'u küçültün: kritik olmayan trafiği devre dışı bırakın, jitter'lı backoff ile yeniden deneyin ve tablo stabilize olana dek önbellekten servis etme gibi nazik düşüşler sağlayın.\n\n## Güvenlik ve Erişim Kontrolü\n\nDynamoDB güvenliği büyük ölçüde kim hangi API eylemlerini çağırabilir, nereden ve hangi anahtarlar üzerinde yapabileceğiyle ilgilidir. Tablolar birçok varlık türünü (ve bazen birçok tenant'ı) içerebildiğinden, erişim kontrolünü veri modeli ile birlikte tasarlamak gerekir.\n\n### IAM izinleri: en az ayrıcalık ilkesine göre\n\nİlk olarak identity-based IAM politikalarıyla eylemleri sınırlayın (örn. dynamodb:GetItem, Query, PutItem) ve bunları belirli tablo ARN'leriyle sınırlayın.\n\nDaha ince kontrol için dynamodb:LeadingKeys kullanarak erişimi partition key değerleriyle kısıtlayın—bir servis veya tenant yalnızca kendi keyspace'ine erişmeli ise faydalıdır.\n\n### Şifreleme: doğrulanacaklar\n\nDynamoDB, varsayılan olarak AWS tarafından sahip olunan anahtarlarla veya müşteri yönetimli KMS anahtarlarıyla veriyi disk üzerinde şifreler. Uyumluluk gereksinimleriniz varsa doğrulayın:\n\n- Tablonun amaçlanan KMS anahtarıyla yapılandırıldığını\n- Çağıran rolün yalnızca gerekli KMS izinlerine sahip olduğunu\n\nTaşınma sırasında şifreleme için, istemcilerin HTTPS kullandığından emin olun (AWS SDK'ları bunu varsayılan yapar). TLS'yi bir proxy'de sonlandırıyorsanız, proxy ile DynamoDB arasındaki hop'un hâlâ şifreli olduğundan emin olun.\n\n### Ağ kontrolleri: veri sızdırma yollarını azaltın\n\nTrafiğin AWS ağı içinde kalması için DynamoDB için bir VPC Gateway Endpoint kullanın ve endpoint politikalarıyla erişimi kısıtlayın. Bunu egress kontrolleri (NACL'ler, security group'lar ve routing) ile eşleştirerek “her şey internete ulaşabilir” yollarından kaçının.\n\n### Çok kiracılı (multi-tenant) tasarım ve izolasyon desenleri\n\nPaylaşılan tablolar için partition key'e tenant tanımlayıcısı ekleyin (örn. TENANT#<id>) ve tenant izolasyonunu dynamodb:LeadingKeys ile IAM koşullarıyla zorlayın.\n\nDaha güçlü izolasyon gerekiyorsa, her tenant için ayrı tablolar veya ortama göre tablolar düşünün; paylaşılan tablo tasarımlarını operasyonel sadelik ve maliyet verimliliği daha önemli olduğunda kullanın.\n\n## DynamoDB İçin Maliyet Optimizasyonu\n\nDynamoDB genelde “kesin olduğunuzda ucuz, belirsiz olduğunuzda pahalı” olur. Maliyetler büyük ölçüde erişim desenlerinize bağlıdır; bu yüzden en iyi optimizasyon çalışması bu desenleri netleştirmekle başlar.\n\n### Maliyet tetikleyicilerini bilin\n\nFaturanızı şekillendiren ana kalemler:\n\n- Okumalar ve yazmalar (provisioned modda RCU/WCU'lar, on-demand'da istek bazlı ücretlendirme)\n- Depolama (tablo verisi ve item boyutu)\n- İkincil indeksler (her GSI kendi yazma ve depolama maliyetlerine sahiptir)\n- Streams (stream kayıtlarına yönelik okuma istekleri ve downstream tüketiciler)\n\nSık yapılan sürpriz: bir tablodaki her yazma, etkilenen her GSI'ya da yazmadır; bu yüzden “sadece bir indeks daha” demek yazma maliyetini çarpabilir.\n\n### İsrafı önlemek için anahtarları tasarlayın\n\nİyi anahtar tasarımı gereksiz işlemlerden kaçınır. Sık sık Scan yapmak veri atma maliyeti demektir.\n\nTercih edin:\n\n- Partition key ile Query (ve isteğe bağlı sort key koşulları)\n- GSI'lerde dar projeksiyonlar (gerçekten ihtiyaç duyduğunuz attribute'ları kopyalayın)\n\nNadir bir erişim deseni için, ayrı bir tablo, bir ETL işi veya bir önbelleğe alınmış okuma modeli tercih edin; kalıcı bir GSI yerine daha ucuz yollar seçin.\n\n### Depolamayı TTL ve yaşam döngüsü ile kontrol et\n\nKısa ömürlü öğeleri (session'lar, geçici token'lar, ara iş akışı durumu) otomatik silmek için TTL kullanın. Bu depolamayı azaltır ve indeksleri zaman içinde daha küçük tutar.\n\nEk olarak, eklemeli veriler için (olaylar, loglar) TTL ile birlikte yalnızca “son” veriyi sorgulamayı kolaylaştıran sort-key tasarımları kullanın, böylece soğuk geçmişe sık erişim yapmazsınız.\n\n### Kapasiteyi doğru boyutlandırın ve kazara zirvelerden kaçının\n\nProvisioned moddaysa muhafazakar taban değerleri ayarlayın ve gerçek metriklere göre auto scaling ile büyütün. On-demand moddaysa verimsiz desenleri (büyük item'lar, chatty istemciler) izleyin; bunlar istek hacmini artırır.\n\nScan'i son çare olarak düşünün—tam tablo işlemi gerekliyse, bunu yoğun olmayan saatlere planlayın veya sayfalandırma ve backoff ile kontrollü bir batch halinde çalıştırın.\n\n## Ne Zaman DynamoDB Seçilmeli (Ne Zaman Seçilmemeli)\n\nDynamoDB, uygulamanızı iyi tanımlanmış erişim desenleri kümesiyle ifade edebildiğinizde ve yüksek ölçekte tutarlı düşük gecikme gerektiğinde parlıyor. En üst sorgularınızı (partition key, sort key ve az sayıda indeksle) önden tanımlayabiliyorsanız, genellikle yüksek kullanılabilirlikli bir veri deposunu yönetmenin en basit yollarından biridir.\n\n### İyi uyum sağlayan durumlar\n\nDynamoDB şu durumlarda güçlü bir seçimdir:\n\n- Öngörülebilir sorgular (kullanıcı profili çekme, bir kullanıcının siparişlerini zamanla listeleme, ID ile oturum yükleme)\n- Yüksek yazma throughput'u veya sürekli bakım istemediğiniz ani trafik patlamaları\n- Sunucuları yönetmeden yatay ölçeklenme ihtiyacı\n- Streams kullanarak event-driven tasarımlar\n\n### Alternatiflere bakılmalıysa\n\nBaşka çözümler düşünün eğer temel gereksinimleriniz şunlarsa:\n\n- Çok sayıda entity arasında sık kompleks join'ler veya ilişki gezintileri\n- Haftalık değişen keşifsel analizler ve ad-hoc sorgular (group-by, keşifsel filtreler)\n- Harici indeks olmadan ağır metin arama ve alaka sıralaması gereksinimi\n\n### İyi çalışan hibrit yaklaşımlar\n\nBirçok ekip “sıcak” operasyonel okuma ve yazmalar için DynamoDB kullanır, sonra şunları ekler:\n\n- Analitik ve tarihsel raporlama için S3 + Athena\n- Tam metin arama ve faceting için OpenSearch (veya benzeri)\n- Bazı anahtarların aşırı okunduğu durumlarda bir cache katmanı\n\n### Prototipleme notu: modelden uygulamaya giden yolu kısaltın\n\nErişim desenlerini ve tek tablo konvansiyonlarını doğrularken hız önemlidir. Ekipler bazen çevresel servis ve UI'yi hızlıca prototiplemek için Koder.ai üzerinde çalışır ve gerçek sorgu yolları ortaya çıktıkça DynamoDB anahtar tasarımını iteratif olarak düzenler. Üretim backend'iniz farklı olsa bile, hızlı uçtan uca prototipler hangi sorguların Query olması gerektiğini ve hangilerinin kazara pahalı Scan'e dönüşeceğini ortaya çıkarmaya yardımcı olur.\n\n### Hızlı karar kontrol listesi\n\nDoğrulayın: (1) en önemli sorgularınız biliniyor ve anahtar tabanlı, (2) doğruluk gereksinimleri tutarlılık modeliyle uyumlu, (3) beklenen item boyutları ve büyüme anlaşılmış, ve (4) maliyet modeli (on-demand vs provisioned + autoscaling) bütçenize uyuyor.UpdateItemADD