DynamoDB Sınırları ve Kotaları, Canlı Servise Karşı Doğrulandı

DynamoDB sınırları nelerdir?

Bir item 400 KB'ta sınırlanır, bir partition anahtarı 2.048 bayt'ta ve bir sort anahtarı 1.024 bayt'ta. Bir batch write 25 item alır, bir batch get 100 anahtar, bir transaction 100 eylem. Bir tablo 20 global ve 5 local secondary index alır. Bu sayfadaki sayıların her biri, isteği Amazon DynamoDB'ye göndererek ve geri geleni okuyarak belirlendi.

Bu sayılar nasıl belirlendi

AWS kotalarını kanıt olmadan yayımlar ve bu normalde sorun değildir — ta ki bir sayı bir tasarım kararı için yük taşıyıcı hale gelene ve onun 400.000 bayt mı yoksa 409.600 mü anlamına geldiğini, öznitelik adlarınızı sayıp saymadığını ve onu aştığınızda servisin tam olarak ne söylediğini bilmek isteyene kadar.

Bu yüzden onları yokladık. Aşağıdaki ilk tablodaki her sınır için, belgelenen değerin tam üzerine oturacak bir istek kuruldu ve us-east-1'deki canlı servise gönderildi; ardından onun bir birim ötesinde ikinci bir istek. İlki kabul edilmeli, ikincisi reddedilmelidir — kenarı bulan şey belgelere güvenmek değil bu çifttir. Son sütundaki ret mesajı servisin kendi cümlesidir, birebir yakalanmış ve hiç yeniden yazılmamıştır.

Dört satır yalnızca ret tarafından belirlenebildi. Bunlar, kabul tarafı yirmi index'li bir tablo kurup her birinin etkin olmasını beklemek anlamına gelecek CreateTable sınırları — sayıyı ret zaten doğrudan söylüyor. Nasıl belirlendi sütunu hangisinin hangisi olduğunu söylüyor; süs değil.

Doğrulanmış sınırlar

Ortam: Amazon DynamoDB, canlı servis, us-east-1, 2026-08-27'de AWS SDK for JavaScript v3 ile yoklandı.

Yoklamaların ortaya çıkardıkları

400 KB, 409.600 bayt demektir ve öznitelik adlarınızı da sayar. Tam olarak 409.600 baytta ölçülen bir item kabul edildi; 409.601 reddedildi. Ölçüm, her öznitelik adının artı her değerin UTF-8 uzunluğunu sayıyor — bu, item boyutu hesaplayıcımızın uyguladığı aynı hesaplama; yoklama, payload'unu tam olarak o kütüphaneyle kuruyor, bu yüzden ikisi bir iddiayla değil kurgu gereği uyuşuyor. Bu sınırın ardındaki daha derin modelleme sorununun kendi kılavuzu var: DynamoDB item boyutu sınırı.

Herkesin alıntıladığı projected-attributes sınırı yanlış olanı. AWS Quotas sayfası tek bir rakam belgeliyor — "up to 100 attributes combined for all of a table's local and global secondary indexes" — ve index başına bir üst sınırdan hiç söz etmiyor. Bir tane var ve o 20. 21 non-key öznitelik tek bir index'e projeksiyonlayan bir CreateTable, tablo başına toplam 100'e daha yakından bile geçmeden reddediliyor. 20 belgeleniyor, ama yalnızca API Referansının Projection sayfasında, bir dizi-üyesi kısıtı olarak: "Maximum number of 20 items". Bir index'i yalnızca Quotas sayfasına göre planlarsanız, API, Quotas sayfasının sorunsuz dediği bir şemayı reddeder. Her iki sayı da yukarıdaki tabloda, her biri kendini kanıtlayan retle birlikte.

Mesajlardan ikisi AWS'nin kendi yazım hatalarını içeriyor, burada sessizce düzeltilmek yerine olduğu gibi yeniden üretildi — maximum size limit of2048 bytes bir boşluk eksik, ve number of projected attributes:120 bir boşluk daha eksik. Bu string'ler için logları grep'liyorsanız, doğru okunana değil servisin gönderdiğine göre grep'leyin.

Sort anahtarları toplu ölçülür. Sort anahtarı reddi "the sort key" değil "Aggregated size of all range keys" diyor, çünkü aynı 1.024 baytlık bütçe hem tablonun sort anahtarını hem de item'ın düştüğü her local secondary index'in sort anahtarını kapsıyor.

Hiçbir şey fırlatmayan 1 MB'lık sayfa

Yukarıdaki her sınır, sizi reddederek kendini duyurur. Query ve Scan sayfa sınırı öyle değil. Onu aştığınızda DynamoDB kısa bir sayfa ve bir LastEvaluatedKey döndürür, hiç hata ve hiç uyarı olmadan — bu yüzden "Scan'im tablonun yalnızca bir kısmını döndürdü" bu kadar yaygın bir sürpriz, ve bu yüzden sayfalama isteğe bağlı değil.

Bu aynı zamanda alıntılanacak bir hata mesajı olmadığı anlamına da geliyor, bu yüzden kışkırtmak yerine ölçüldü:

Item başına 1.000 baytta, bir sayfa 1.029 item tuttu ve bir LastEvaluatedKey döndürdü — 1.029.000 bayt item verisi, 1.030. item bir sonraki istek için bırakıldı. Item başına 5.000 baytta, bir sayfa 208 item tuttu ve bir LastEvaluatedKey döndürdü — 1.040.000 bayt item verisi, 209. item bir sonraki istek için bırakıldı.

Sayfaların hiçbiri 1 MiB item verisi tutmadı — ilki yaklaşık 19.576 bayt eksik kaldı. Yani sayfa bütçesi, item başına item'ın kendi baytlarından daha fazlasını hesaba katıyor.

Farklı item boyutlarındaki iki yoklama bunu netleştirmeye yetiyor. Bir sayfayı item × (item baytı + item başına overhead) ≤ bütçe olarak ele alırsak, yalnızca 7 tam-bayt overhead her iki ölçümle de tutarlı ve bunlardan tam olarak biri bütçeyi yuvarlak bir ikili megabayta oturtuyor: item başına 19 baytlık bir overhead, bütçe 1.048.551 ile 1.048.971 bayt arasında — 1.048.576'yı içeren bir aralık. DynamoDB'nin "1 MB"ı, kendi kotalar sayfasının belirttiği gibi ikilidir ve item baytları artı item başına overhead için harcanır. Bunun item başına kabaca 19 baytı için bütçe ayırın.

Yoklamadığımız kotalar

Aşağıdaki sınırlar AWS'ye atıfla verilmiştir, ölçülmemiştir. Bunlar hesap düzeyi kotalardır: çoğu istek üzerine ayarlanabilir ve onlara ulaşmak, saatlik faturalanan throughput sağlamak, binlerce tablo oluşturmak ya da bir yıllık rezerve kapasiteye taahhüt vermek anlamına gelir. Bunların hiçbiri bir yoklama değil, bu yüzden hiçbiri öyle sunulmuyor. Her satırın kaynağı AWS'nin Quotas in Amazon DynamoDB sayfasıdır.

Etrafında tasarım yapmanız gereken sınırlar

Bunların çoğuna asla ulaşmayacaksınız. Gerçek tasarımları şekillendiren birkaçı:

• Item başına 400 KB, bir kota değil bir modelleme kısıtıdır. Ona yaklaşan bir item genellikle gömülü bir liste olarak depolanmış sınırsız bir bire-çok ilişkidir. Bkz. item boyutu sınırı.
• 1 MB'lık sayfa, yazdığınız her Query ve Scan'i yönetir. LastEvaluatedKey'i yok sayan kod, verileriniz bir sayfayı aştığı gün sessizce yanlıştır.
• Batch write başına 25 item ve batch get başına 100, toplu yükleme döngülerinizi şekillendirir. Bkz. batch işlemleri.
• Transaction başına 100 eylem, insanların DynamoDB'yi ilişkisel gibi davranmaya zorlarken çarptığı sınırdır. Bkz. transaction'lar.
• 20 GSI, 5 LSI, 100 projeksiyonlanan öznitelik, erişim deseni tasarımını throughput kotalarından çok daha sık kısıtlar ve LSI sayısı tablo oluşturulduğu anda sabitlenir. Bkz. index projeksiyonları ve GSI ve LSI.

Yukarıda alıntılanan retlerin çoğunun, her birini üreten istekle birlikte DynamoDB hataları altında kendi sayfası da var. Dört CreateTable reddinin yok — onlar bu sayfa için yakalandı.

Tek bir item'ı yazmadan 400 KB sınırına karşı kontrol etmek için item boyutu hesaplayıcısı tarayıcınızda çalışır. Kendi tablolarınızdaki item'lara bakmak için DynoTable bir masaüstü DynamoDB istemcisidir.