DynamoDB ne kadar hızlı?
Hızlı. DynamoDB her ölçekte tutarlı, tek haneli milisaniyelik okuma ve yazma gecikmesi sunar. Bellek içi bir önbellek olan DynamoDB Accelerator'ı (DAX) eklemek, nihai tutarlı okumaları mikrosaniyelere indirir. Tablolar büyüdükçe performans düz kalır, çünkü okumalar tarama yerine doğrudan bir bölüm anahtarını hedefler; dolayısıyla gecikme veri hacmiyle bozulmaz.
Ölçekte neden hızlı kalır
Bir GetItem ya da Query, bölüm anahtarını hash'ler ve doğrudan doğru fiziksel bölüme gider. Tablonun tamamını asla taramaz, dolayısıyla yanıt süresi tabloda binlerce de milyarlarca da öğe olsa kabaca sabittir.
DAX ile mikrosaniyelik okumalar
DAX, tablonuzun önünde duran, tamamen yönetilen ve DynamoDB uyumlu bir bellek içi önbellektir. Nihai tutarlı okumaları mikrosaniyelerde döndürür — milisaniyelere göre 10 kata kadar iyileşme — ve yönetilecek bir önbellek geçersizleştirme yoktur. Güçlü tutarlı okuma gerektiren iş yükleri için uygun değildir.
Kullanıcılarınızın gerçekte gördüğü sayı
Tek haneli milisaniye, DynamoDB uç noktasında ölçülür. Uygulamanızın yaşadığı şey bunun üstüne ağdır ve ağ genellikle açık ara daha büyük yarıdır.
2026-07-28 tarihinde İspanya'daki tek bir makineden, Bölge başına dokuz örnekle, her bölgesel DynamoDB uç noktasına medyan TCP el sıkışması ölçüldü. Bu tek bir gidiş dönüştür, isteğin tek baytı bile gönderilmeden önce:
| Bölge | Medyan TCP el sıkışması |
|---|---|
| eu-central-1 (Frankfurt) | 46,6 ms |
| eu-south-2 (İspanya) | 49,1 ms |
| eu-west-1 (İrlanda) | 53,8 ms |
| us-east-1 (K. Virginia) | 113,6 ms |
| ap-northeast-1 (Tokyo) | 259,5 ms |
Tek makine, tek ISS, tek öğleden sonra; dolayısıyla bunları bir kıyaslama değil, büyüklük mertebeleri olarak okuyun. İçlerindeki iki şey genel olarak geçerlidir. Atlantik ötesi bir gidiş dönüş, taşıdığı okumanın on katından fazladır; dolayısıyla o mesafede DynamoDB'nin gecikmesi sizinkinde bir yuvarlama hatasıdır. Ve makineye coğrafi olarak en yakın Bölge ondan en hızlı olan değildi: eu-south-2 İspanya'da bulunuyor ve Frankfurt'tan daha iyi ölçülmedi, çünkü kararı mesafe değil yönlendirme veriyor.
Bunun pratik hâli şudur: hesaplamayı tabloyla aynı yere koymak, yapabileceğiniz her DynamoDB ayarından daha çok kazandırır. Tablonun Bölgesindeki bir Lambda fonksiyonu yukarıdaki sayıların bir kesrini öder; başka bir kıtadaki bir dizüstü ya da bir CI işi ise her bağlantıda hepsini öder — SDK bağlantı yeniden kullanımının göründüğünden daha önemli olmasının nedeni de budur.
Sizi ne yavaşlatabilir
- Taramalar ve filtreler — tablonun tamamını okumak yavaş ve pahalıdır; bunun yerine anahtar tabanlı erişim tasarlayın.
- Sıcak bölümler — tek bir bölüm anahtarı payından çok daha fazla trafik çektiğinde, genel tablo kapasitesi yeterli olsa bile ona karşı yapılan istekler kısıtlanır.
DynamoDB'yi hızlı tutan şey daha fazla donanım değil, iyi anahtar tasarımıdır.
Daha derine inin
Query ile Scan sayfasını okuyun ve bir sıcak bölümden kaçının. Hangi okumaların Query, hangilerinin Scan olarak çalıştığını görmek için DynoTable'ı indirin.
Kaynaklar
- Fast NoSQL Key-Value Database — Amazon DynamoDB — AWS
- In-memory acceleration with DynamoDB Accelerator (DAX) — Amazon DynamoDB Developer Guide
- What is Amazon DynamoDB? — Amazon DynamoDB Developer Guide
- Core components of Amazon DynamoDB — Amazon DynamoDB Developer Guide
En son 2026-07-13 tarihinde yukarıda bağlantısı verilen resmi AWS belgelerine karşı doğrulandı.
Gecikme rakamları 2026-07-28 tarihinde İspanya'daki tek bir makineden curl ile, Bölge başına dokuz istekle, https://dynamodb.<region>.amazonaws.com adresine karşı time_connect eksi time_namelookup medyanı bildirilerek ölçüldü. İki bağımsız çalıştırma 3 ms içinde uyuştu.