DynamoDB 배치 작업

한 번에 많은 항목을 읽거나 써야 할 때 GetItem 또는 PutItem 중 하나를 실행합니다. 항목당은 항목당 하나의 네트워크 왕복을 의미합니다. 느리고 말이 많습니다. DynamoDB의 배치 API는 많은 항목 작업을 단일 요청으로 합칩니다. 읽기의 경우 BatchGetItem, BatchWriteItem는 쓰기용입니다.

이는 일관성 보장이 아닌 처리량 및 지연 시간 측면의 이점입니다. 구별은 사람들이 화상을 입는 곳입니다. 배치는 트랜잭션이 아닙니다.

DynamoDB 배치 작업이란 무엇입니까?

DynamoDB 배치 작업은 많은 항목 읽기 또는 쓰기를 단일 요청으로 합칩니다. BatchGetItem는 최대 100개 항목을 가져오고, BatchWriteItem는 최대 25개 항목을 넣거나 삭제하며 각각 16MB로 제한됩니다. 용량이 아닌 왕복 여행을 절약합니다. 중요한 점은 배치는 트랜잭션이 아닙니다. 항목은 롤백 없이 독립적으로 성공하거나 실패합니다.

• BatchGetItem — 하나 이상의 테이블에서 최대 100개 항목(또는 16MB)을 가져옵니다. 한 번의 통화로.
• BatchWriteItem — 한 번의 호출로 최대 25개의 넣기/삭제 작업(또는 16MB). 업데이트 없음 - 넣기 및 삭제만 가능합니다.
• 원자적이지 않습니다. 개별 항목은 성공할 수 있지만 다른 항목은 실패할 수 있습니다. 롤백이 없습니다.
• 부분적인 실패는 정상입니다. 조절된 항목은 UnprocessedItems / UnprocessedKeys — 백오프를 사용하여 직접 다시 시도해야 합니다.
• 개별 통화와 동일한 용량 비용 — 일괄 처리를 통해 왕복 시간이 절약됩니다. 용량 단위.

문제: 물건이 많고 왕복은 1회

지원 데스크를 운영한다고 가정해 보겠습니다. 대시보드는 ID별로 50개의 티켓을 로드해야 합니다. 대기열; 야간 작업은 해결된 티켓 1,000개를 보관합니다. 한 번에 한 가지 항목씩 수행 50(또는 1,000) 순차 왕복입니다. 대기 시간이 늘어나고 작업이 크롤링됩니다.

일괄 처리는 이를 소수의 호출로 축소합니다. 50장의 티켓 읽기는 단일이 됩니다. BatchGetItem; 아카이브 작업은 25개 호출의 BatchWriteItem 스트림이 됩니다. 각각 삭제합니다. 왕복 횟수가 훨씬 적고 동일한 데이터가 이동되었습니다.

배치 API 작동 방식

BatchGetItem 기본 키 세트(하나 이상의 테이블에서)를 가져와서 반환합니다. 일치하는 항목. 테이블별로 강력하게 일관된 읽기를 요청할 수 있습니다. 뭐든지 읽을 수 없습니다. 일반적으로 요청이 처리량 제한을 초과했기 때문에 다시 수신됩니다. UnprocessedKeys 통화 전체를 실패하는 것보다.

BatchWriteItem는 PutRequest / DeleteRequest 작업 목록을 가져옵니다. 참고 누락된 사항: 업데이트 없음이 없습니다. 일괄 쓰기는 전체 항목을 대체하거나 (넣기) 또는 제거하기 (삭제) — 여전히 필요한 특정 속성을 수정하려면 UpdateItem. 쓸 수 없는 항목은 UnprocessedItems에 다시 나타납니다.

핵심 정신 모델: 배치는 독립적인 작업 묶음입니다. 하나의 전부 아니면 전무 단위가 아니라 그 자체로 성공하거나 실패합니다.

배치는 트랜잭션이 아닙니다

이것이 함정입니다. 아카이브 작업의 배치가 처리량 한도의 절반에 도달하면 일부 티켓은 삭제되고 일부는 삭제되지 않습니다. DynamoDB는 티켓을 취소하지 않습니다 통과했다. 롤백도, 격리도, "25개 모두 또는 없음"도 없습니다.

전부 아니면 전무의 의미 체계가 필요한 경우 — "티켓을 보관된 및 감소로 이동합니다. 오픈 티켓 카운터에 가거나 둘 다 하지 않으면 됩니다." — 그건 0, 배치가 아닙니다. 거래 비용 더 많은 비용이 청구되며(각 작업은 두 배로 청구됨) 100개 항목으로 제한되지만 원자성 배치는 의도적으로 그렇지 않습니다.

처리되지 않은 항목 처리

올바른 일괄 호출자는 항상 처리되지 않은 세트를 확인하고 다시 시도합니다. DynamoDB 요청 전체가 다음과 같을 때마다 UnprocessedItems/UnprocessedKeys를 반환합니다. 허용되지만 일부 항목을 제공할 수 없습니다. 일반적으로 일시적인 제한이 발생합니다.

처리되지 않은 항목만 다시 제출하세요. exponential backoff and jitter. 배치를 실행 후 잊어버리는 방식으로 처리하면 자동으로 쓰기가 삭제됩니다. 몇 달 후에 누락된 데이터로 표시됩니다.

DynoTable에서 일괄 쓰기

먼저 대량 작업의 비용을 추정해 보세요. DynamoDB pricing calculator — 배치가 다음을 소비합니다. 더 적은 수의 요청으로 개인이 번들로 작성하는 것과 동일한 용량을 제공합니다.

DynoTable에서는 편집 내용을 로컬로 스테이징하고 커밋하기 전에 검토합니다. 여러 행에 대한 대량 변경 사항은 하나의 API 호출이 아닌 그룹화된 요청으로 전달됩니다. 각각. 대량 삭제는 일괄 쓰기로 진행되며 처리되지 않은 항목 재시도가 처리됩니다. 당신을 위해.

함정과 다음 단계

• UnprocessedItems/UnprocessedKeys는 항상 백오프와 함께 재시도하세요 — 예외가 아니라 예상된 동작입니다.

• 부분 실패 롤백은 없습니다. 원자성이 필요하면 트랜잭션을 쓰세요.

• 배치 쓰기에는 업데이트가 없습니다 — BatchWriteItem은 put/delete만 가능합니다. 속성을 바꾸려면 UpdateItem을 쓰세요.

• 호출당 한도를 지키세요 — 쓰기 25 / 읽기 100 / 16 MB. 초과하면 호출 전체가 ValidationException으로 실패합니다 (BatchGetItem에서 항목이 너무 많음, BatchWriteItem에서). 더 큰 작업은 페이지네이션하세요. 페이지네이션을 참고하세요.

재시도 루프를 스크립팅하지 않고 대량 읽기/쓰기를 실행하고 싶나요? DynoTable 다운로드하고 테이블을 직접 편집하세요.

왕복 수학

직렬 GetItem 호출은 홉마다 지연 시간을 냅니다. BatchGetItem은 요청당 최대 100 키 또는 16 MB — 먼저 닿는 한도까지 — 를 묶습니다.

용량 비용은 변하지 않습니다 — 배칭이 아끼는 것은 벽시계 시간과 클라이언트 CPU이지 RCU가 아닙니다. 쓰기라면 배치당 25개로 삭제 1,000건은 개별 삭제 1,000회 대신 BatchWriteItem 40회입니다.

강력하게 일관된 배치 읽기

BatchGetItem은 요청 맵의 테이블마다 ConsistentRead: true를 받습니다. 강한 읽기는 같은 항목의 최종적 일관 읽기 RCU의 2배입니다. 한 배치 호출에서 강한 일관/최종적 일관 테이블을 섞어도 됩니다 — 각 테이블 항목이 자기 플래그를 가집니다.

큰 작업 청킹

평균 3 KB 항목 1,000개를 아카이브할 때, 한 번 배치 읽기는 100개 한도 안이지만 16 MB를 넘을 수 있습니다(100 × 3 KB = 300 KB — 안전). 50 KB 항목이면 개수 한도는 100이어도 호출당 약 320개에서 메가바이트 한도에 걸립니다.

쓰기는 명시 루프로 페이지합니다.

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

DynoTable의 스테이징 커밋은 적격 쓰기를 배치하고 미처리 항목을 자동 재시도합니다 — 지터 sleep으로 직접 스크립트하던 그 패턴입니다.

배치 vs 트랜잭션 결정

픽스처에서 배치 로드를 시드할 때는 DynamoDB JSON 변환기로 일반 JSON에서 put/delete 페이로드를 만드세요.

소비 용량 점검

배치 응답은 요청 시 테이블별 ConsumedCapacity를 포함할 수 있습니다. 백필 중 로그하세요 — 스로틀 비율 상승은 작업이 완전히 멈추기 전에 미처리 집합이 커지는 것으로 보입니다. 배치가 스케줄로 돌면 요금 계산기로 지속 WCU를 교차 확인하세요.