DynamoDB blob depolayabilir mi?
Evet, sınırlar dahilinde. DynamoDB, ikili büyük nesneleri (BLOB) Binary (B) özniteliklerinde, kabloda base64 kodlanmış olarak, öğenin tamamı 400 KB'ın altında kaldığı sürece depolar. Daha büyük her şey için — video, ses, yüksek çözünürlüklü görseller — AWS, blobun Amazon S3'te depolanmasını ve DynamoDB'de yalnızca bir başvuru ile üst verinin tutulmasını önerir.
Bir blobu doğrudan depolamak
Baytları bir Binary özniteliğine koyun. Uygulamalar ikili değerleri göndermeden önce base64 kodlar; DynamoDB, 400 KB'lık öğe boyutuna ham bayt uzunluğunu sayar. Küçük bloblar (imzalar, derli toplu payload'lar) rahatça sığar.
Gerçekte kaç bayt sığıyor
400 KB öğe içindir, blob için değil. Sınırı ikili arama ile bulmak tam bir tavan verir: tek karakterlik bir bölüm anahtarı ve bir Binary özniteliğinden başka bir şey içermeyen bir öğe 409.594 bayt blob alır. Bir bayt fazlası ve yazma başarısız olur:
ValidationException: Item size has exceeded the maximum allowed sizeYanına konan altı gerçekçi üst veri özniteliği (içerik türü, boyutlar, yükleyen, zaman damgası) 94 bayt tutar ve tavanı 409.500'e düşürür.
base64 kodlaması bir kablo ayrıntısıdır, fazlası değil. O 409.594 baytlık put, istek gövdesinde 546.128 bayt base64 gönderir ve DynamoDB bunu kabul eder; dolayısıyla base64'ün bütçenizin üçte birini yediği yolundaki yaygın fikir yanlıştır. Asıl maliyeti verim tarafındadır: tam boyutlu bir blob, put başına 400 yazma birimi ve güçlü tutarlı okuma başına 100 okuma birimidir; küçük bir öğe için bunlar 1 ve 0,5'tir.
Büyük nesne deseni
Bir blob 400 KB'ı aştığında:
- Nesneyi Amazon S3'te depolayın.
- S3 anahtarını artı üst veriyi (ad, boyut, sahip, zaman damgaları) DynamoDB'de tutun.
Bu, DynamoDB'nin hızlı indeksli aramalarını S3'ün ucuz ve sınırsız nesne depolamasıyla eşler. Sınırın yalnızca biraz üzerindeki veriler için AWS ayrıca büyük öznitelikleri sıkıştırmayı (bir Binary özniteliğinde depolanan GZIP ya da LZO çıktısı) ya da onları birden çok öğeye bölmeyi önerir.
Sıkıştırma metni kurtarır, medyayı değil
O sıkıştırma tavsiyesi tam olarak tek bir blob türünde işe yarar. 614.499 baytlık
bir YAML kilit dosyası üzerinde gzip -9, 164.302 bayt döndürür — onu imkânsızdan
rahata taşıyan %73'lük bir kesinti. Aynı komut 794.311 baytlık bir PNG üzerinde
785.175 bayt döndürür, yani %1,2'lik bir tasarruf; çünkü biçim kendini zaten
sıkıştırmıştı. Yani sıkıştırma size günlükler, JSON payload'ları ve metin için yer
kazandırır, sınıra çarpmanın her zamanki nedeni olan medya dosyaları içinse hiçbir
şey kazandırmaz.
Bir uyarı
DynamoDB ile S3 arasında hizmetler arası işlem yoktur, dolayısıyla uygulamanız kısmi başarısızlıkları ve öksüz kalmış nesneleri kendisi ele almalıdır.
Daha derine inin
Boyutları öğe boyutu hesaplayıcısıyla denetleyin ve öğe boyutu sınırı kılavuzunu okuyun. İkili verileri görüntülemek için DynoTable'ı indirin.
Kaynaklar
- Best practices for storing large items and attributes in DynamoDB — Amazon DynamoDB Developer Guide
- Supported data types and naming rules in Amazon DynamoDB — Amazon DynamoDB Developer Guide
- Constraints in Amazon DynamoDB — Amazon DynamoDB Developer Guide
En son 2026-07-13 tarihinde yukarıda bağlantısı verilen resmi AWS belgelerine karşı doğrulandı.
2026-07-28 tarihinde @aws-sdk/client-dynamodb 3.1095.0 üzerinden DynamoDB Local 3.3.0'a karşı ölçüldü — iki bayt tavanı da türetilmedi, ikili aramayla bulundu ve gzip rakamları, anlatılan iki dosya üzerinde gzip -9 çalıştırmaktan gelir. AWS'nin üretim motoru reddetmelerini farklı ifade edebilir.