DynamoDB Batch İşlemleri

Aynı anda çok sayıda item okumanız veya yazmanız gerektiğinde, item başına bir GetItem veya PutItem ateşlemek, item başına bir ağ gidiş-dönüşü demektir — yavaş ve gevezedir. DynamoDB'nin batch API'leri, çok sayıda item işlemini tek bir istekte katlar: okumalar için BatchGetItem, yazmalar için BatchWriteItem.

Bunlar bir verim-ve-gecikme kazancıdır, bir tutarlılık garantisi değil — ve insanların canını yakan yer bu ayrımdır. Bir batch, bir transaction değildir.

DynamoDB batch işlemleri nedir?

DynamoDB batch işlemleri, çok sayıda item okuma veya yazmasını tek bir istekte katlar: BatchGetItem 100 item'a kadar getirir, BatchWriteItem 25'e kadar put veya delete yapar, her biri 16 MB ile sınırlıdır. Gidiş-dönüşleri kurtarır, kapasiteyi değil. Kritik olarak, bir batch bir transaction değildir — item'lar bağımsız olarak başarılı olur veya başarısız olur, geri alma yoktur.

• BatchGetItem — bir veya daha fazla tablodan tek çağrıda 100 item'a (veya 16 MB) kadar getirir.
• BatchWriteItem — tek çağrıda 25 put/delete işlemine (veya 16 MB) kadar. Update yok — yalnızca put ve delete.
• Atomik değildir. Bireysel item'lar başarılı olurken diğerleri başarısız olabilir. Geri alma yoktur.
• Kısmi başarısızlık normaldir. Throttle edilen item'lar UnprocessedItems / UnprocessedKeys içinde geri gelir — bunları geri çekilmeyle kendiniz yeniden denemelisiniz.
• Bireysel çağrılarla aynı kapasite maliyeti — batch'leme gidiş-dönüşleri kurtarır, kapasite birimlerini değil.

Sorun: çok item, tek gidiş-dönüş

Diyelim ki bir destek masası çalıştırıyorsunuz. Bir gösterge tablosunun bir kuyruğu işlemek için 50 talebi ID'ye göre yüklemesi gerekiyor; gece boyunca çalışan bir iş 1.000 çözülmüş talebi arşivliyor. Bunu her seferinde bir item ile yapmak, 50 (veya 1.000) sıralı gidiş-dönüştür — gecikme birikir ve iş sürünerek ilerler.

Batch'leme bunları bir avuç çağrıya toplar. 50 talepli okuma tek bir BatchGetItem haline gelir; arşiv işi her biri 25 silme olan bir BatchWriteItem çağrıları akışı haline gelir. Çok daha az gidiş-dönüş, taşınan aynı veri.

Batch API'leri nasıl çalışır

BatchGetItem, bir dizi birincil anahtar alır (bir veya daha fazla tablo boyunca) ve eşleşen item'ları döndürür. Tablo başına güçlü tutarlı okumalar isteyebilirsiniz. Okuyamadığı her şey — genellikle istek bir verim sınırına dokunduğu için — tüm çağrıyı başarısız kılmak yerine UnprocessedKeys içinde geri gelir.

BatchWriteItem, bir PutRequest / DeleteRequest işlemleri listesi alır. Eksik olana dikkat edin: update yoktur. Bir batch yazma, ya tüm bir item'ı değiştirir (put) ya da onu kaldırır (delete) — belirli attribute'ları değiştirmek için hâlâ UpdateItem'a ihtiyacınız var. Yazamadığı item'lar UnprocessedItems içinde geri gelir.

Ana zihinsel model: bir batch, her biri kendi başına başarılı olan veya başarısız olan bağımsız işlemler demetidir — hep-ya-hiç bir birim değil.

Batch'ler transaction değildir

İşte tuzak. Arşiv işinizin batch'i yarı yolda bir verim sınırına çarparsa, bazı talepler silinir ve bazıları silinmez — ve DynamoDB geçenleri geri almaz. Geri alma yok, izolasyon yok, "25'i de yoksa hiçbiri" yok.

Hep-ya-hiç semantiğine ihtiyacınız varsa — "talebi arşivlenmişe taşı ve açık-talepler counter'ını azalt, ya da hiçbirini yapma" — bu bir batch değil, TransactWriteItems'dır. Transaction'lar daha pahalıdır (her işlem iki katı faturalandırılır) ve 100 item ile sınırlıdır, ancak sana batch'lerin kasıtlı olarak vermediği atomikliği verir.

İşlenmemiş item'ları ele alma

Doğru bir batch çağıranı, işlenmemiş kümeyi her zaman kontrol eder ve onu yeniden dener. DynamoDB, istek bir bütün olarak kabul edildiğinde ancak bazı item'lar sunulamadığında — genellikle geçici throttling — UnprocessedItems/UnprocessedKeys döndürür.

Yalnızca işlenmemiş item'ları üstel geri çekilme ve jitter ile yeniden gönderin. Bir batch'i ateşle-ve-unut olarak ele almak yazmaları sessizce düşürür — aylar sonra eksik veri olarak yüzeye çıkan türden bir hata.

DynoTable'da batch yazmalar

Bir toplu işin ne kadara mal olacağını önce DynamoDB fiyatlandırma hesaplayıcısı ile tahmin edin — bir batch, demetlediği bireysel yazmalarla aynı kapasiteyi tüketir, yalnızca daha az istekte.

DynoTable'da, düzenlemelerinizi local olarak hazırlar ve commit etmeden önce gözden geçirirsiniz — birçok satır boyunca toplu değişiklikler, her biri bir API çağrısı yerine gruplanmış istekler olarak gider. Toplu silmeler, işlenmemiş-item yeniden denemesi senin için ele alınmış olarak batch'lenmiş yazmalar olarak gider.

Tuzaklar ve sonraki adımlar

• UnprocessedItems/UnprocessedKeys'i her zaman geri çekilmeyle yeniden deneyin — bunlar beklenendir, istisnai değil.
• Kısmi-başarısızlık geri alması yok. Atomiklik gerekli mi? Transaction'ları kullanın.
• Bir batch yazmada update yok — BatchWriteItem yalnızca put/delete'tir; attribute'ları değiştirmek için UpdateItem'a başvurun.
• Çağrı başına sınırlara dikkat edin — 25 yazma / 100 okuma / 16 MB. Bunları aşmak tüm çağrıyı bir ValidationException ile başarısız kılar (BatchGetItem'da çok fazla item, BatchWriteItem'da). Daha büyük işler için sayfalayın; bkz. sayfalama.

Yeniden deneme döngüsünü betiklemeden toplu okuma ve yazmalar çalıştırmak mı istiyorsunuz? DynoTable'ı indirin ve tablolarınızı doğrudan düzenleyin.

Gidiş-dönüş matematiği

Sıralı GetItem çağrıları her sıçrama için gecikme öder. BatchGetItem, istek başına 100 anahtara veya 16 MB'a kadar demetler — hangi sınır önce gelirse.

Kapasite maliyeti değişmez — batch'leme duvar saati süresini ve istemci CPU'sunu kurtarır, RCU'yu değil. Yazmalarda, batch başına 25 ile 1.000 silme, 1.000 bireysel silme yerine 40 BatchWriteItem çağrısıdır.

Güçlü tutarlı batch okumalar

BatchGetItem, istek haritasında tablo başına ConsistentRead: true kabul eder. Güçlü okumalar, aynı item'lar için nihai tutarlı okumaların RCU'sunun yine 2 katına mal olur. Tek bir batch çağrısında tutarlı ve nihai tutarlı tabloları karıştırmak sorun değildir — her tablo girdisi kendi bayrağını taşır.

Büyük işleri parçalara ayırma

Her biri ortalama 3 KB olan 1.000 item'ı arşivlerken, tek bir batch okuma 100-item sınırının altında kalır ancak 16 MB'ı aşabilir (100 × 3 KB = 300 KB — güvenli). 50 KB'lık item'ları arşivleyin ve sayı sınırı 100 olsa bile çağrı başına yaklaşık 320 item'da megabayt sınırına çarparsınız.

Yazmaları açık döngülerle sayfalayın:

for each chunk of 25 keys:
  BatchWriteItem
  retry UnprocessedItems with backoff until empty

DynoTable'ın hazırlanmış commit'i uygun yazmaları batch'ler ve işlenmemiş item'ları otomatik olarak yeniden dener — aksi takdirde jitter'lı uyku ile betikleyeceğiniz desen.

Batch ve transaction kararı

Fixture'lardan batch yüklemeleri tohumlarken put/delete yüklerini düz JSON'dan DynamoDB JSON dönüştürücü ile oluşturun.

Tüketilen kapasiteyi inceleme

Batch yanıtları, istendiğinde tablo başına ConsumedCapacity içerebilir. Geri doldurmalar sırasında bunu loglayın — yükselen bir throttle oranı, işler tamamen durmadan önce büyüyen işlenmemiş kümeler olarak ortaya çıkar. Batch'ler bir zamanlamayla çalışıyorsa, sürekli WCU'yu fiyatlandırma hesaplayıcısı ile çapraz kontrol edin.