DynoTable
고급5분 분량

DynamoDB 병렬 스캔

병렬 스캔은 하나의 Scan를 N개의 독립적인 Scan 요청으로 분할합니다. 테이블의 Segment를 요구하므로 여러 작업자가 동시에 읽을 수 있습니다. 그것은 Scan API가 하나의 파티션보다 더 빠르게 전체 테이블을 읽을 수 있는 유일한 방법입니다. 처리량이 허용됩니다.

DynamoDB 병렬 스캔이란 무엇입니까?

DynamoDB 병렬 스캔은 하나의 Scan를 N개의 독립적인 요청으로 분할하고, 각각은 Segment 및 TotalSegments를 통해 테이블의 Segment를 요구하므로 여러 작업자가 동시에 읽습니다. 이는 단일 파티션의 처리량이 허용하는 것보다 더 빠르게 전체 테이블을 읽을 수 있도록 Scan API가 제공하는 유일한 방법입니다. 하지만 여전히 전체 읽기이므로 스캔한 모든 항목에 대해 비용을 지불해야 합니다.

  • 순차 Scan는 한 번에 하나의 파티션을 읽습니다 — 속도는 테이블 크기에 관계없이 단일 파티션의 처리량.
  • Segment + TotalSegments 읽기를 TotalSegments 워커에 걸쳐 샤드합니다. 각 작업자는 자체 슬라이스를 병렬로 스캔합니다.
  • DynamoDB는 를 해시하여 세그먼트를 할당합니다. 편향된 — 더 많은 작업자가 항상 더 빠른 것을 의미하는 것은 아닙니다.
  • 아직 11%입니다. 모든 항목을 읽으려면 비용을 지불해야 하며, 병렬 스캔은 실시간 트래픽에서 테이블 처리량을 빼냅니다.

순차 Scan이 느린 이유

SQL에서 오면 전체 테이블 읽기는 하나의 스트리밍 작업처럼 느껴집니다. DynamoDB에서는 아닙니다. 테이블 데이터는 여러 물리 파티션에 있지만, 단일 Scan은 페이지당 1 MB로 한 번에 하나씩 걷습니다.

즉 일반 Scan은 테이블이 수십 파티션에 퍼져 idle 용량이 있어도, 순간적으로는 한 파티션의 처리량 예산만 끌어올 수 있습니다. 테이블이 클수록 더 오래 기어갑니다. (AWS: Parallel scan)

Segment와 TotalSegments로 읽기를 분할합니다.

병렬 스캔은 병목 현상을 해결합니다. 작업자 수를 선택하고 설정하세요. TotalSegments를 해당 숫자로 지정하고 각 작업자에게 고유한 0부터 시작하는 숫자를 제공합니다. Segment. 모든 근로자는 자체 Scan를 발행합니다. DynamoDB는 이를 동시에 제공합니다.

Worker 0 →  Scan  Segment=0  TotalSegments=4
Worker 1 →  Scan  Segment=1  TotalSegments=4
Worker 2 →  Scan  Segment=2  TotalSegments=4
Worker 3 →  Scan  Segment=3  TotalSegments=4

각 작업자는 여전히 독립적으로 LastEvaluatedKey를 페이징합니다. 첫 페이지부터 마지막 페이지까지 세그먼트를 만듭니다. 애플리케이션은 4개의 스트림을 다시 연결합니다. 함께. 대신 이제 4개의 파티션에 해당하는 처리량을 한 번에 읽고 있습니다. 하나의.

실제 사례: 야간 내보내기

원격 측정 테이블 sensor-readings을 실행한다고 가정해 보겠습니다. 각 항목은 현장 장치:

PK = "DEVICE#a83f"          (partition key — the device id)
SK = "TS#2026-06-22T03:14"  (sort key — ISO timestamp)
batteryMv  = 3120
tempC      = 41.8
firmwareTag = "fw-7.2.1"

매일 밤 cron 작업은 전체 테이블을 분석 웨어하우스용 S3에 덤프합니다. 80GB를 순차적으로 저장하려면 몇 시간이 걸리며 프로비저닝된 읽기에 거의 영향을 미치지 않습니다. 용량. 따라서 8명의 워커에 걸쳐 이를 팬아웃합니다.

Scan  sensor-readings  Segment=0  TotalSegments=8  ConsistentRead=false
…
Scan  sensor-readings  Segment=7  TotalSegments=8  ConsistentRead=false

8명의 작업자, 8개의 세그먼트, 1개의 테이블이 대략 8배 더 빠르게 읽힙니다. 당신이 최근 판독값만 필요합니다. 이전 타임스탬프를 삭제하려면 FilterExpression를 추가하세요. 행이 연결됩니다. - 해당 표현식을 작성하고 검사합니다. Expression Builder:

FilterExpression:  begins_with(SK, :today)

DynamoDB가 항목을 세그먼트에 할당하는 방식

DynamoDB는 행 수나 바이트 수가 아니라 파티션 키를 해시해 각 항목을 세그먼트에 넣습니다.

같은 PK를 공유하는 모든 항목은 같은 세그먼트에 갑니다. sensor-readings에서 DEVICE#a83f의 모든 측정값은 타임스탬프가 얼마나 많든, 이 얼마나 크든 한 워커로 갑니다. (AWS: Parallel scan)

sensor-readings 테이블파티션 키 해시Segment 0DEVICE#a83fDEVICE#1c20Segment 1DEVICE#9be4Segment 2 (비어 있음)

세그먼트는 불균등해집니다. 한 워커는 측정값이 수백만인 수다한 디바이스를 갖고, 다른 워커는 빈 조각을 받을 수 있습니다. 파티션 키가 뭉치면 TotalSegments를 올려도 핫한 워커를 기다리는 유휴 워커만 늘어납니다. 키 분포가 고를 때 팬아웃이 이득입니다.

실행하기 전에 읽기 비용을 확인하세요

병렬 스캔은 공짜 점심이 아닌 처리량 이벤트입니다. 솔직한 질문은 "내가 이 표 전체를 얼마나 읽을까?" — 그리고 DynoTable이 실행되기 전에 전체 테이블 읽기는 대략적인 테이블을 보여주는 확인 대화 상자를 통해 사용자를 안내합니다. 크기 및 항목 수와 읽기 용량 경고를 표시한 다음 라이브로 스트리밍합니다. 읽기가 실행됨에 따라 항목 검색이 진행되므로 야간 작업이 놀라지 않습니다.

함정과 귀찮게 하지 말아야 할 때

  • 처리량 절벽. 높은 TotalSegments 스캔은 테이블의 전체 읽기 용량을 초 단위로 줄여 라이브 트래픽을 부족하게 만듭니다. 서빙되는 테이블에 사용자는 Limit 매개변수를 사용하여 각 작업자를 조절하거나 사용량이 적은 시간을 스캔합니다. (AWS: Parallel scan)
  • 액세스 패턴에 대해서는 여전히 잘못된 도구입니다. 병렬 스캔은 의도적인 전체 테이블 작업(내보내기, 백필, 마이그레이션) 당신이 도달하는 경우 반복되는 쿼리에 응답하는 것은 모델링 신호입니다. GSI 대신 Query로 만드세요.
  • PartiQL의 SELECT *은 변장된 동일한 스캔입니다. 순차적 Scan. 실제로 교차 항목 분석이 필요한 경우 — GROUP BY, a JOIN, 집계 — DynoTable의 SQL Workbench는 해당 클라이언트 측을 통해 실행됩니다. 테이블을 망치는 대신 제한된 결과 집합을 사용합니다.
  • 강력한 일관성은 비용을 두 배로 늘립니다. Scan의 기본값은 읽기입니다. 내보내기의 경우 각 페이지가 최신 쓰기를 반영해야 하는 경우를 제외하고는 ConsistentRead=false를 그대로 둡니다. 심지어 매우 일관된 스캔도 몇 분에 걸쳐 수행되므로 특정 시점 스냅샷이 아닙니다(PITR/내보내기 사용).

다음 단계

일상적인 읽기에 스캔이 필요하지 않도록 키를 모델링하십시오. single-table design 및 Query vs Scan. 전체 테이블 작업이 진정으로 필요한 경우 올바른 호출, try DynoTable를 사용하여 전체 테이블 읽기를 실행 크기 및 비용에 대한 사전 경고 및 실시간 스캔 진행.

업데이트됨