DynamoDB On-Demand Verimi: Ölçüldü
Yeni bir DynamoDB on-demand tablosu ne kadar throughput alır?
Yepyeni bir tablo saniyede yaklaşık 4.130 yazma sunar — AWS 4.000 belgeliyor — ve saniyede en az 12.700 nihai tutarlı okuma. İkisini de 2026-08-27'de, dakikalar önce oluşturulmuş bir tabloya karşı ölçtük: yazmalar, sunduğumuz her taban-üstü yükte 4.130 ±2/s'de sabitlendi ve okumalar, kendi yük üretecimiz nefesi tükenmeden önce hiç kısıtlanmadı.
Bu iki sayı, ve bu sayfadaki her şey, canlı servise karşı gerçek isteklerin sayılmasından geliyor — belgeleri yeniden anlatmaktan değil. Yöntem, ham veri ve üç başarısız deneme benchmark hikâyesinde yazılı; bu sayfa, sayıların üzerinde yaşadığı başvuru kaynağıdır.
Taze bir tablodaki yazma tavanı
Sunulan yük, hiç trafik görmemiş bir tabloya karşı 30 saniyelik pencerelerde artırıldı. Her istek ~1 KB'lık bir item'ı tekdüze rastgele bir anahtarla taşıdı — ortada yok:
| Sunulan (yazma/sn) | Ulaşılan | Kısıtlanan istekler |
|---|---|---|
| 1.000 | 1.000 | 0 |
| 2.000 | 2.000 | 0 |
| 3.000 | 3.000 | 0 |
| 4.000 | 4.000 | 0 |
| 5.000 | 4.132 | 25.992 |
| 6.000 | 4.131 | 55.966 |
| 8.000 | 4.134 | 115.922 |
Belgelenen 4.000 yazma/sn taban değeri geçerli, üzerinde yaklaşık %3'lük bir pay var. Tavan dikkat çekici derecede düz: 5.000, 6.000 ve 8.000 sunulanda sırasıyla 4.132, 4.131, 4.134 ulaşılan yazma/sn. Onu geçtiğinde gecikme kötüleşmiyor — p50 yazma gecikmesi her pencerede bölge içinde 4–5 ms'de kaldı. Servis yavaşlamıyor; reddediyor.
Kısıtlama gerçekte ne döndürüyor
İlk ret, her taban-üstü pencerenin başlangıcından 0.9–3.8 saniye sonra geldi (sunulan hız ne kadar yüksekse o kadar erken). Birebir:
ThrottlingException: Throughput exceeds the current capacity of your table or index. DynamoDB is automatically scaling your table or index so please try again shortly. If exceptions persist, check if you have a hot key: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.htmlEtrafında plan yapılacak iki şey. Bu bir HTTP 400'dür, 5xx değil — yalnızca 5xx'i izleyen bir yeniden deneme politikası ya da alarm, on-demand kısıtlamayı tamamen kaçırır (SDK'lar bunu varsayılan olarak yeniden dener; bkz. ). Ve hot key ipucu bir teşhis değil, varsayılan bir öneridir — anahtarlarımız tekdüze rastgeleydi, bu yüzden küçük ölçekte bu mesajın ilk şüphelisi anahtar şeman değil, tablo düzeyindeki tavandır. Dört farklı kısıtlama nedeninin kendi kılavuzu var.
Okuma tavanı
Okumalar, 1.000 item ile tohumlanmış ikinci bir taze tabloya karşı
GetItem'lar olarak çalıştı (~1 KB,
her biri 0.5 okuma birimi):
| Sunulan (okuma/sn) | Ulaşılan | Kısıtlanan istekler |
|---|---|---|
| 4.000 | 4.000 | 0 |
| 8.000 | 7.941 | 0 |
| 12.000 | 11.119 | 0 |
| 16.000 | 12.762 | 0 |
Her hızda sıfır kısıtlama. Belgelenen 12.000 okuma/sn taban değeri geçerli ve gerçek sınırını bulamadık: 16.000/sn sunulanda, sekiz koşucumuzdan beşi istemci tarafında doydu, yani 12.762/sn bizim filomuzun tavan yaptığı yer — DynamoDB'nin değil. Okumalar bölge içinde p50 2–4 ms'de yanıtladı.
Tavan sürekli yük altında nasıl büyüyor
AWS, on-demand kapasitenin önceki zirvenin iki katına kadarını karşılayacak şekilde büyüdüğünü ve 30 dakika içinde önceki zirvenin iki katının aşılmasının kısıtlamaya yol açabileceğini belgeliyor. Bir tabloya karşı 34 kesintisiz dakika boyunca saniyede 8.000 yazmalık sunulan yükü tuttuk (aralarında bir dakikadan az duraklama olan dört 8 dakikalık dalga) ve tavanın dakika dakika nasıl hareket ettiğini izledik:
| Dalga | Başladı | Ulaşılan yazma/sn, dakika dakika |
|---|---|---|
| 1 | 06:06 UTC | 4.019 → 4.001 → 4.001 → 3.999 → 3.998 → 4.000 → 4.000 → 4.000 |
| 2 | 06:15 UTC | 5.046 → 5.000 → 4.996 → 4.990 → 4.991 → 4.998 → 4.992 → 4.993 |
| 3 | 06:24 UTC | 5.046 → 4.973 → 4.991 → 4.981 → 4.983 → 4.989 → 4.993 → 5.978 |
| 4 | 06:32 UTC | 7.006 → 6.991 → 6.979 → 6.996 → 6.991 → 6.988 → 7.002 → 6.990 |
Zaman çizelgesini okumak:
- İlk tavan yapışkandır. İlk 8 dakika boyunca tablo ~4.000/sn'lik taban değerinde kaldı — sürekli aşırı talep bu pencere içinde onu kımıldatmadı.
- Büyüme bir rampa halinde değil, ~1.000/sn'lik basamaklarla gelir. Tavan 9. dakika civarında ~5.000/sn'ye, 26. dakika civarında ~6.000/sn'ye ve bir dakika sonra ~7.000/sn'ye sıçradı, sonra sona kadar 7.000/sn'de düz kaldı. Her basamak, bir dakikayla sonraki arasında ansızın iniyor. Üç basamaktan ikisi dalga sınırlarımıza yakın indi, yani dakikanın altındaki duraklamalar büyüme mekanizmasıyla etkileşime giriyor olabilir — zamanlamayı gözlemlendiği gibi bildiriyoruz.
- Yarım saatlik sürekli talep, tavanı ikiye katlamadı. 8.000/sn sunulan yükte 34 dakika sonra tablo 7.000/sn sundu — başlangıç tavanının 1.75 katı, yine de hem sunulan hızın hem de temiz bir ikiye katlanmanın gerisinde. Kısıtlanan istekler dalgadan dalgaya düştü (1.9 milyon → 0.5 milyon), tavan büyürken.
Lansman gününün trafiği yeni bir tabloda ~4.000 yazma/sn'yi aşacaksa, onu önceden ısıt: olayın öncesinde sentetik yük sür ya da tablonun maksimum on-demand throughput'unu açıkça ayarlayıp AWS'in onun için sağlamasına izin ver. On-demand'e karşı provisioned kılavuzu hangi modun ne zaman kazandığını kapsıyor, otomatik ölçekleme ise burada otomatik olarak gerçekleştiğini izlediğin şeyin provisioned moddaki karşılığı.
Bizi şaşırtan iki sayı
- Create-to-ACTIVE süresi 3× değişiyor. Taze bir on-demand tablo, bir
koşuda 7.4 saniyede, diğer ikisinde 22 saniyede
ACTIVE'e ulaştı — aynı bölge, aynı şema. Tablo-başına-kiracı ya da tablo-başına-test tasarımlarında yavaş durum için bütçe ayır. - Benchmark'ın tamamı $0.97'ye mal oldu. 672.116 faturalanan yazma ve 1.08 milyon okuma. 34 dakikalık sürekli-büyüme koşusu $12.67 daha tuttu. Servisi kendin ölçmek, yanlış bir kapasite kararından daha ucuzdur — ve bunun gibi bir iş yükünü önceden DynamoDB fiyatlandırma hesaplayıcısıyla fiyatlandırabilirsin.
Kapsam ve yöntem, dürüstçe
Yukarıdakilerin hepsi tek bir aşama başına bir tablo, bir gün, bir bölge (us-east-1), ~1 KB'lık öğeler, tekdüze rastgele anahtarlar. Bölüm başına sınırlar (saniyede 3.000 okuma birimi / 1.000 yazma birimi), burada ölçülen tablo düzeyi davranışın altında kalır ve kendi başarısızlık biçimlerine sahiptir. Hesap düzeyi kotalar ve sert servis sınırları DynamoDB sınırları başvurusunda, aynı yöntemle ölçülmüş hâlde. Ve DynamoDB'ye karşı her gün çalışıyorsan, DynoTable bunun için masaüstü istemcimizdir — aynı ekip tarafından, iddiaları tekrarlamadan önce canlı servise karşı denetleme alışkanlığıyla birlikte yapıldı.