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

DynamoDB Nedir ve Neden Takımlar Kullanır

Amazon 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.

Temelde DynamoDB, verileri tablolardaki item'lar (satırlar) olarak saklar, ancak her item esnek attribute'lara sahip olabilir. Veri modeli şu şekilde anlaşılabilir:

• Anahtar-değer: bir item'ı birincil anahtarıyla hızlıca alın, bir kaydı ID ile aramaya benzer.
• 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ı.

Takı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.

Bu 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.

Temel Kavramlar: Tablolar, Item'lar ve Birincil Anahtarlar

DynamoDB 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.

Tablolar, item'lar ve attribute'lar

Bir 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.

İ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.

Birincil anahtarlar: basit vs bileşik

Her item benzersiz olarak bir birincil anahtar ile tanımlanır ve DynamoDB iki tipi destekler:

• Basit birincil anahtar (sadece partition key): tek bir attribute her item'ı benzersiz kılar.
• 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.

Uygulamada, bileşik anahtarlar “bir müşterinin tüm siparişleri, en yeniler ilk” gibi gruplanmış erişim desenlerini mümkün kılar.

Query vs. Scan (yüksek seviye)

Query, 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.

Scan 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.

Dikkat edilmesi gereken sınırlar

Erken hissedeceğiniz birkaç kısıtlama:

• Maks item boyutu: 400 KB.
• Attribute tipleri: skalerler (string/number/binary/boolean/null), setler, listeler ve map'ler.
• Anahtar attribute'lar skaler olmalı (partition veya sort key olarak list/map kullanılamaz).

Bu temel bilgiler gerisini kurar: erişim desenleri, indeks seçimleri ve performans özellikleri.

DynamoDB'nin Veri Modeli: Anahtar-Değer ve Doküman

DynamoDB 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.

Anahtar-değer erişimi vs doküman tarzı item'lar

Temelde 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.

Aynı 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.

Item'larda hiyerarşik JSON-benzeri yapılar modelleme

Item'lar JSON-benzeri verilere doğal olarak uyar:

• Map'ler nesneleri temsil eder (örn. profile.name, profile.address).
• List'ler dizileri temsil eder (örn. recent actions, tags).

Bu, 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.

Ne zaman denormalize edilmeli (ve neden yaygın olduğu)

DynamoDB 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.

İlişkisel normalizasyon ile takaslar

Denormalizasyon 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.

Partition Key ve Sort Key: Erişim Desenleri İçin Tasarım

En 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.

Partition key: dağılım ve öngörülebilir okumalar

Partition 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.

İyi partition key'ler:

• Yüksek kardinaliteye sahiptir (çok sayıda ayrı değer)
• Sık erişim desenine uyar (okumalar doğrudan, filtrelenmemiş)
• Popüler hale gelecek değerlerden kaçınır (örn. "GLOBAL" gibi sabit değerler)

Sort key: aralık sorguları ve gruplanmış varlıklar

Bir 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:

• Aralık sorguları (BETWEEN, begins_with)
• Zamana göre sıralı okumalar (ters taramalarla en yeniler ilk)
• Varlık gruplama (birden fazla item türü aynı partition altında)

Sı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.

Yaygın erişim desenlerini anahtarlara eşleme

• ID ile al: PK = USER#<id> (GetItem ile basit)
• Kullanıcıya göre listele: PK = USER#<id>, SK begins_with ORDER# (veya SK = CREATED_AT#...)
• Zaman serisi aralıkları: PK = DEVICE#<id>, SK = TS#<timestamp> ile BETWEEN kullanımı

Anahtar seçiminin performans ve ölçeklenmeye etkisi

Partition 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.

İkincil İndeksler: GSI ve LSI Açıklaması

İ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.

GSI vs. LSI: farkı nedir?

Global 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.

Local 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.

Projeksiyonlar: indekse ne kopyalanır

Projeksiyon, hangi attribute'ların indekste saklanacağını belirler:

• KEYS_ONLY: en ucuz depolama, ancak genelde temel tablodan ekstra okuma gerekir.
• INCLUDE: sık döndürdüğünüz sadece belirli attribute'ları kopyalayın.
• ALL: en basit, ancak depolama ve yazma maliyetini artırabilir.

Yazma amplifikasyonu (gizli fatura)

Her 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.

Kapasite Modları ve Ölçeklenme Davranışı

DynamoDB'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.

On-Demand vs. Provisioned: nasıl seçilir

On-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.

Provisioned 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.

Okuma/yazma kapasitesi pratikte

Provisioned throughput şu birimlerle ölçülür:

• RCU'lar (Read Capacity Units): yaklaşık olarak 4 KB'ye kadar güçlü tutarlı bir okuma/ saniye (veya iki zayıf tutarlı okuma).
• WCU'lar (Write Capacity Units): yaklaşık olarak 1 KB'ye kadar bir yazma/ saniye.

Gerç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.

Auto scaling temelleri (ve limitleri)

Auto 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.

DAX: okuma ağırlıklı iş yükleri için önbellek

DynamoDB 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.

Tutarlılık, İşlemler ve Doğruluk

DynamoDB, 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.

Eventually consistent vs strongly consistent okumalar

Varsayı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.

Strongly 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.

Güçlü tutarlılığın gerektiği durumlar

Aşağıdaki gibi geri döndürülemez işlemleri kısıtlayan okumalar için güçlü tutarlılık değerlidir:

• Bir siparişi onaylamadan önce stok kontrolü yapmak
• Erişim vermeden önce yetkilendirme bayrağını okumak
• Bir iş akışının mevcut durumunu alıp bir sonraki adımı yürütmek

Sayaç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.

İşlemsel okuma/yazmalar

DynamoDB 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.

Güvenli yeniden denemeler için idempotentlik

Dağıtık sistemlerde yeniden denemeler normaldir. Yeniden denemeler işlem tekrarı yaratmasın diye yazmaları idempotent yapın:

• Sonuçla birlikte saklanan bir istemci istek token'ı (idempotency key) kullanın
• ConditionExpression ile benzersizliği zorlayın (örn. attribute_not_exists ile yalnızca oluşturma)
• Okuma-değiştir-yaz döngüleri yerine atomik güncellemeleri tercih edin

DynamoDB'de doğruluk çoğunlukla doğru tutarlılık seviyesini seçmek ve yeniden denemelerin verinizi bozmayacağı şekilde işlemleri tasarlamaktır.

Partition'lar, Hot Key'ler ve Trafik Sıçramaları

DynamoDB, tablo verilerini birden çok fiziksel partition'a yayar. Her partition'ın okuma ve yazma için sınırlı throughput'u ve tutabileceği veri miktarı vardır. Partition key'iniz bir item'sin nerede tutulduğunu belirler; çok fazla istek aynı partition key değerine (veya küçük bir dizi değere) yönelirse o partition darboğaza dönüşür.

Hot partition'lar neden oluşur

Hot partition'lar genellikle trafik yoğunluğunu tek bir değere yoğunlaştıran anahtar seçimlerinden kaynaklanır: USER#1, TENANT#default veya STATUS#OPEN gibi “global” partition key'ler veya herkesin “şimdi” yazdığı zamana dayalı desenler.

Hot key belirtileri ve düzensiz trafik

Genelde şunları görürsünüz:

• Bazı anahtarlar için throttling (ProvisionedThroughputExceededException)
• Birkaç erişim deseni için artan ve düzensiz gecikme, diğerleri hızlı kalırken
• CloudWatch metriklerinde düzensiz tüketilmiş kapasite ve ani patlamalar

Azaltma teknikleri

Önce dağılım için, sonra sorgu kolaylığı için tasarlayın:

• Anahtar tasarımı: yüksek kardinaliteli partition key'ler seçin (örn. TENANT#<id> sabit bir değerin yerine).
• 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.
• Zaman kovaları (time buckets): saat/gün bazlı kovalar (METRIC#2025-12-22T10) kullanarak tüm yazıların tek bir öğeye gitmesini önleyin.

Patlamalı iş yüklerini yönetme

Ö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.

Ölçeklenebilir Sistemler İçin Veri Modelleme Desenleri

DynamoDB 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.

Tek tablo tasarımı (neden popüler)

“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.

Yaygın yaklaşım bileşik anahtar kullanımıdır:

• PK mantıksal bir bölümü gruplar (örn. USER#123)
• SK o grup içindeki öğeleri sıralar (örn. PROFILE, ORDER#2025-12-01, MSG#000123)

Bu sayede “bir kullanıcı için her şeyi al” veya “sadece kullanıcının siparişlerini al” gibi sorguları sort-key önekleriyle yapabilirsiniz.

İlişkiler: adjacency list ve çoktan-çoğa (many-to-many)

Graf benzeri ilişkiler için bir adjacency list iyi çalışır: kenarları item olarak saklayın.

• PK = USER#123, SK = FOLLOWS#USER#456

Ters 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.

Zaman serisi: bucket + sort key + TTL

Olaylar ve metrikler için sınırsız partition'lardan kaçının, bucket kullanın:

• PK = DEVICE#9#2025-12-22 (cihaz + gün)
• SK = TS#1734825600 (zaman damgası)

Eski 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.

Daha derin bir tazeleme isterseniz, /blog/partition-key-and-sort-key-design yazısını inceleyin.

Streams ve Event-Driven Mimariler

DynamoDB 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.

DynamoDB Streams temelleri

Bir 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.

Event-driven iş akışları kurmak

Yaygı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).

Tipik iş akışları şunları içerir:

• Materialized view'lar: kaynak tablo değiştiğinde denormalize edilmiş bir okuma modeli tablosu yazmak.
• Cache invalidation: yazmalardan sonra Redis/ElastiCache öğelerini süresizleştirmek veya yenilemek.
• Audit log'lar: değişim olaylarını immutable olarak bir audit tablosuna veya harici bir depoya eklemek.

Böylece birincil tablo düşük gecikmeli okuma/yazma için optimize edilirken türetilmiş işler asenkron tüketicilere itilir.

Sıralama, yeniden denemeler ve doğruluk

Streams 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.

Bunu güvenli şekilde ele almak için:

• Handler'ları idempotent yapın (örn. anahtara göre upsert, koşullu yazılar veya işlenmiş event ID'lerini saklama).
• Yeniden denemeler ve kısmi batch hataları bekleyin; mümkünse DLQ/on-failure hedefleri kullanın.
• E-posta veya ödeme gibi yan etkileri deduplama veya işlemsel güvenliklerin arkasına koyun.

Bu garantiler göz önüne alındığında, Streams DynamoDB'yi event-driven sistemler için sağlam bir omurga haline getirebilir.

Güvenilirlik, Yedekleme ve Gözlemlenebilirlik

DynamoDB, 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.

Yedeklemeler: on-demand vs point-in-time recovery

On-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.

Point-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.

Replikasyon ve çoklu bölge seçenekleri

Ç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.

İzleme için temel metrikler

En azından şu konularda uyarı oluşturun:

• Okuma ve yazma için gecikme (p95/p99)
• Throttled requests ve sistem hataları
• Tüketilen kapasite (ve provisioned'a kıyasla boşluk)

Bu sinyaller genelde hot-partition sorunlarını, yetersiz kapasiteyi veya beklenmedik erişim desenlerini ortaya çıkarır.

Olay kitapları (incident playbooks)

Throttling 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.

Kı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.

Güvenlik ve Erişim Kontrolü

DynamoDB 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.

IAM izinleri: en az ayrıcalık ilkesine göre

İ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.

Daha 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.

Şifreleme: doğrulanacaklar

DynamoDB, 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:

• Tablonun amaçlanan KMS anahtarıyla yapılandırıldığını
• Çağıran rolün yalnızca gerekli KMS izinlerine sahip olduğunu

Taşı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.

Ağ kontrolleri: veri sızdırma yollarını azaltın

Trafiğ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.

Çok kiracılı (multi-tenant) tasarım ve izolasyon desenleri

Paylaşı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.

Daha 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.

DynamoDB İçin Maliyet Optimizasyonu

DynamoDB 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.

Maliyet tetikleyicilerini bilin

Faturanızı şekillendiren ana kalemler:

• Okumalar ve yazmalar (provisioned modda RCU/WCU'lar, on-demand'da istek bazlı ücretlendirme)
• Depolama (tablo verisi ve item boyutu)
• İkincil indeksler (her GSI kendi yazma ve depolama maliyetlerine sahiptir)
• Streams (stream kayıtlarına yönelik okuma istekleri ve downstream tüketiciler)

Sı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.

İsrafı önlemek için anahtarları tasarlayın

İyi anahtar tasarımı gereksiz işlemlerden kaçınır. Sık sık Scan yapmak veri atma maliyeti demektir.

Tercih edin:

• Partition key ile Query (ve isteğe bağlı sort key koşulları)
• GSI'lerde dar projeksiyonlar (gerçekten ihtiyaç duyduğunuz attribute'ları kopyalayın)

Nadir 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.

Depolamayı TTL ve yaşam döngüsü ile kontrol et

Kı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.

Ek 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.

Kapasiteyi doğru boyutlandırın ve kazara zirvelerden kaçının

Provisioned 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.

Scan'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.

Ne Zaman DynamoDB Seçilmeli (Ne Zaman Seçilmemeli)

DynamoDB, 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.

İyi uyum sağlayan durumlar

DynamoDB şu durumlarda güçlü bir seçimdir:

• Öngörülebilir sorgular (kullanıcı profili çekme, bir kullanıcının siparişlerini zamanla listeleme, ID ile oturum yükleme)
• Yüksek yazma throughput'u veya sürekli bakım istemediğiniz ani trafik patlamaları
• Sunucuları yönetmeden yatay ölçeklenme ihtiyacı
• Streams kullanarak event-driven tasarımlar

Alternatiflere bakılmalıysa

Başka çözümler düşünün eğer temel gereksinimleriniz şunlarsa:

• Çok sayıda entity arasında sık kompleks join'ler veya ilişki gezintileri
• Haftalık değişen keşifsel analizler ve ad-hoc sorgular (group-by, keşifsel filtreler)
• Harici indeks olmadan ağır metin arama ve alaka sıralaması gereksinimi

İyi çalışan hibrit yaklaşımlar

Birçok ekip “sıcak” operasyonel okuma ve yazmalar için DynamoDB kullanır, sonra şunları ekler:

• Analitik ve tarihsel raporlama için S3 + Athena
• Tam metin arama ve faceting için OpenSearch (veya benzeri)
• Bazı anahtarların aşırı okunduğu durumlarda bir cache katmanı

Prototipleme notu: modelden uygulamaya giden yolu kısaltın

Eriş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.

Hızlı karar kontrol listesi

Doğ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.