DynamoDB Batch İşlemleri: BatchGetItem & BatchWriteItem

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

Bunlar bir throughput-ve-gecikme kazancıdır, bir tutarlılık garantisi değil — ve insanların canının yandığı yer bu ayrımdır. Bir batch, işlem (transaction) değildir.

DynamoDB batch işlemleri nedir?

DynamoDB batch işlemleri birçok öğe okumasını ya da yazmasını tek bir isteğe katlar: BatchGetItem 100 öğeye kadar getirir, BatchWriteItem 25 öğeye kadar put ya da delete yapar; her biri 16 MB ile sınırlanır. Kapasiteden değil, gidiş-dönüşlerden tasarruf ederler. Önemlisi, bir batch bir işlem (transaction) değildir — öğeler birbirinden bağımsız olarak başarılı olur ya da başarısız olur ve geri alma (rollback) yoktur.

BatchGetItem — bir ya da daha fazla tabloda tek bir çağrıda 100 öğeye kadar (ya da 16 MB) getir.
BatchWriteItem — tek bir çağrıda 25 put/delete işlemine kadar (ya da 16 MB). Güncelleme yok — yalnızca put ve delete.
Atomik değil. Bazı öğeler başarılı olurken diğerleri başarısız olabilir. Geri alma (rollback) yok.
Kısmi başarısızlık normaldir. Throttle olan öğeler UnprocessedItems / UnprocessedKeys içinde geri gelir — onları geri çekilmeyle (backoff) kendin yeniden denemen gerekir.
Bireysel çağrılarla aynı kapasite maliyeti — batch'leme gidiş-dönüşlerden tasarruf eder, kapasite birimlerinden değil.

Sorun: birçok öğe, bir gidiş-dönüş

Diyelim ki bir destek masası işletiyorsun. Bir gösterge paneli bir kuyruğu render etmek için ID'ye göre 50 ticket yüklemesi gerekir; gece çalışan bir iş 1.000 çözülmüş ticket'ı arşivler. Bunu öğe öğe yapmak 50 (ya da 1.000) sıralı gidiş-dönüş demektir — gecikme birikir ve iş emekler.

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

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

BatchGetItem bir birincil anahtar kümesi alır (bir ya da daha fazla tabloda) ve eşleşen öğeleri döndürür. Tablo başına güçlü tutarlı okumalar isteyebilirsin. Okuyamadığı herhangi bir şey — genellikle istek bir throughput sınırını sıyırdığı için — tüm çağrıyı başarısız etmek yerine UnprocessedKeys içinde geri gelir.

BatchWriteItem bir PutRequest / DeleteRequest işlemleri listesi alır. Neyin eksik olduğuna dikkat et: güncelleme yok. Bir batch yazma ya tüm bir öğeyi değiştirir (put) ya da onu kaldırır (delete) — belirli attribute'ları değiştirmek için yine de UpdateItem'a ihtiyacın var. Yazamadığı öğeler UnprocessedItems içinde geri gelir.

Anahtar zihinsel model: bir batch, her biri kendi başına başarılı ya da başarısız olan bağımsız işlemlerden oluşan bir demettir — hep-ya-hiç bir birim değil.

Batch'ler işlem (transaction) değildir

Tuzak budur. Arşiv işinin batch'i yarı yolda bir throughput sınırına çarparsa, bazı ticket'lar silinir bazıları silinmez — ve DynamoDB geçenleri geri almaz. Geri alma yok, izolasyon yok, "ya 25'i ya hiçbiri" yok.

Hep-ya-hiç semantiğine ihtiyacın varsa — "ticket'ı arşivlenmişe taşı ve açık-ticket sayacını azalt, ya da ikisini de yapma" — bu bir batch değil, TransactWriteItems'tir. İşlemler daha pahalıdır (her işlem iki kat faturalandırılır) ve 100 öğede sınırlanır, ama sana batch'lerin kasıtlı olarak vermediği atomikliği verir.

İşlenmemiş öğeleri ele alma

Doğru bir batch çağrıcısı her zaman işlenmemiş kümeyi kontrol eder ve onu yeniden dener. DynamoDB, istek bir bütün olarak kabul edildiği ama bazı öğeler sunulamadığı her durumda — tipik olarak geçici throttling — UnprocessedItems/UnprocessedKeys döndürür.

Yalnızca işlenmemiş öğeleri, üssel geri çekilme ve jitter ile yeniden gönder. Bir batch'i at-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 et — bir batch, demetlediği bireysel yazmalarla aynı kapasiteyi tüketir, sadece daha az istekte.

DynoTable'da düzenlemelerini yerel olarak stage'ler ve onları verimli batch'lenmiş yazmalar olarak commit etmeden önce gözden geçirirsin — birçok satırdaki toplu değişiklikler, değişiklik başına bir API çağrısı yerine gruplanmış isteklerle çıkar ve işlenmemiş-öğe yeniden denemesi senin için ele alınır.

DynoTable'da stage'lenmiş düzenlemeleri bir batch olarak commit etmeden önce gözden geçirme.

Tuzaklar ve sonraki adımlar

UnprocessedItems/UnprocessedKeys'i her zaman geri çekilmeyle yeniden dene — bunlar istisnai değil, beklenen şeylerdir.
Kısmi-başarısızlık geri alması yok. Atomiklik mi gerek? İşlemleri kullan.
Bir batch yazmada güncelleme yok — BatchWriteItem yalnızca put/delete'tir; attribute'ları değiştirmek için UpdateItem'a uzan.
Çağrı başına tavanlara dikkat et — 25 yazma / 100 okuma / 16 MB. Daha büyük işleri sayfala; bkz. sayfalama.

Yeniden deneme döngüsünü betiklemeden toplu okumalar ve yazmalar çalıştırmak mı istiyorsun? DynoTable'ı indir ve tablolarını doğrudan düzenle.