DynamoDB 핫 파티션: 이를 찾고 수정하는 방법

DynamoDB는 데이터를 여러 물리적 파티션에 분산시키며, 각 파티션에는 자체 파티션이 있습니다. 처리량 조각. 핫 파티션은 하나의 키가 훨씬 더 많은 읽기를 수행하거나 슬라이스가 제공할 수 있는 것보다 쓰기 - 따라서 해당 키에 대한 요청은 제한되고 나머지는 요청됩니다. 테이블이 유휴 상태로 앉아 있습니다.

DynamoDB 핫 파티션이란 무엇입니까?

DynamoDB 핫 파티션은 하나의 66이 처리량 조각이 제공할 수 있는 것보다 훨씬 더 많은 읽기 또는 쓰기를 흡수하므로 해당 키에 대한 요청은 테이블의 나머지 부분이 유휴 상태인 동안 제한됩니다. 원인은 테이블 크기가 아닌 키 디자인(연예인 아이템, 낮은 카디널리티 키, 오늘 날짜)입니다. 치료법은 널리 쓰인다.

• 원인은 테이블 크기가 아니라 키 디자인입니다. 1개 파티션 키 집중 트래픽(유명인 사용자, status="OPEN" 플래그, 오늘 날짜)이 함정입니다.
• 적응형 용량이 도움이 되지만 해결될 수는 없습니다. DynamoDB는 열의 균형을 재조정합니다. 자동으로 발생하지만 단일 항목이나 단일 키는 여전히 하나의 항목을 초과할 수 있습니다. 파티션이 제공될 수 있습니다.
• 치료법은 쓰기 확산입니다. 키에 엔트로피를 추가하거나(샤딩 쓰기) 핫 읽기 경로를 더 잘 분산된 액세스 패턴으로 이동합니다.
• SQL에서 가져온 것으로 이에 상응하는 것이 없습니다. 관계형 테이블에는 "한 행의 인덱스 값이 너무 많이 사용됩니다." — DynamoDB의 키당 균일 처리량 모델 그렇습니다.

파티션이 존재하는 이유

DynamoDB는 2007년 Amazon Dynamo 논문의 후속 제품입니다. 분할된 수평 확장 모델을 위한 단일 노드 SQL 모델입니다. 데이터가 샤딩됨 물리적 스토리지 노드 전체의 파티션 키 해시로.

각 파티션은 제한된 양의 데이터를 보유하고 제한된 양의 데이터를 제공합니다. 처리량. AWS에서는 3,000RCU 및 1,000WCU라는 엄격한 한도를 기록합니다. 파티션, 초당 — 프로비저닝 및 온디맨드에서 동일한 소프트 캡 us-east-1 (AWS — partition behavior). 청구 모드는 물리적 한계를 높이지 않습니다. 테이블 수준 지출 방식만 변경됩니다. 측정됩니다. pricing calculator를 사용하여 테이블 수준 비용 및 Contributor Insights를 통해 조절이 가능한지 여부를 확인할 수 있습니다. 파티션 제한과 테이블 제한.

그 천장이 이야기의 전부입니다. 테이블의 provisioned 처리량은 다음과 같습니다. 모든 파티션에 걸쳐. 키의 항목 수집은 하나의 파티션에서 시작되고 Split-for-heat는 정렬 키 경계에서 여러 개에 걸쳐 이를 조각할 수 있습니다. LSI가 있거나 정렬 키가 계속 증가하여 LSI에 고정됩니다.

함정 이름 지정: 하나의 키에 쌓이는 트래픽

처리량은 액세스가 키 전체에 균등하게 분산된 경우에만 균등하게 공유됩니다. 하나의 키에 불균형적인 트래픽이 발생하는 순간, 해당 키는 단독으로 조절되고 테이블의 전체 용량은 사용되지 않습니다.

클래식 단축키 모양:

• 연예인 아이템 — 모두가 읽는 하나의 사용자, 제품 또는 테넌트입니다.
• 낮은 카디널리티 파티션 키 — status, country, type. 몇 가지 뚜렷한 값은 모든 작업을 수행하는 파티션이 거의 없음을 의미합니다.
• 시간 버켓 키 — PK = "2026-06-23". 오늘 글을 쓸 때마다 하나의 망치질이 발생합니다. 파티션; 어제는 영원히 춥습니다.

SQL에서는 이들 중 어느 것도 중요하지 않습니다. 대중적인 값에 대한 B-트리 인덱스는 다음과 같습니다. 괜찮아. DynamoDB에서 널리 사용되는 값은 물리적 배치 단위입니다. 인기가 처리량 절벽이 됩니다.

실제 사례: 유명인 리더보드

글로벌 게임 리더보드를 운영한다고 가정해 보겠습니다. 점수는 다음과 같이 입력된 테이블에 표시됩니다.

PK = "BOARD#global"
SK = "PLAYER#<playerId>"

읽기는 점수별로 상위 N개를 차지합니다. 각각의 뒤에 플레이어의 currentScore 범프를 씁니다. 일치합니다. 글로벌 보드의 모든 행은 하나 파티션 키를 공유합니다 — BOARD#global — 따라서 모든 읽기 및 쓰기는 단일 파티션에 저장됩니다.

2백만 명의 실시간 시청자가 새로 고침 버튼을 스팸으로 보내는 스트리머를 추가하세요. 하나의 파티션이 읽기 단위 3,000개를 넘어섰습니다. 당신은 얻는다 ProvisionedThroughputExceededException는 글로벌 보드에 있고 다른 모든 테이블의 보드가 유휴 상태입니다.

풋건은 BOARD#global 붕괴입니다. 단일 논리 보드를 다음과 같이 모델링했습니다. 단일 물리적 키.

쓰기 확산: 키 샤딩

해결 방법은 카디널리티를 제조하는 것입니다. 파티션에 샤드 접미사 추가 키를 사용하면 하나의 논리 보드가 N개의 물리적 파티션에 걸쳐 펼쳐집니다.

PK = "BOARD#global#<shard>"  -- shard = playerId mod 10
SK = "PLAYER#<playerId>"

쓰기는 이제 하나가 아닌 10개의 파티션에 분산됩니다(쓰기의 10배). 헤드룸. 비용: 전체 보드를 읽으려면 10개의 샤드를 모두 히트하고 병합해야 합니다. 단일 Query이 샤드 경계에 걸쳐 있지 않기 때문입니다. 읽기 단순성을 위해 교환합니다. 배포를 작성합니다.

차이점을 직접 확인해 보세요. 단일 반복 키를 시각화 도우미에 붙여넣기 아래에서는 모든 쓰기가 하나의 버킷, 즉 핫 파티션에 저장됩니다. 샤드 접미사 추가 (BOARD#global#0 … #9) 그리고 동일한 내용이 균등하게 팬아웃됩니다.

이는 직관 교육용 해시이지 DynamoDB의 실제 내부 해시는 아닙니다. 실제 기능과 파티션 경계는 AWS 내부입니다. "퍼져도"라고 읽어보세요 vs 왜곡"은 키가 어떤 물리적 파티션에 있는지 예측하는 것이 아닙니다.

AWS는 이것을 쓰기 샤딩이라고 부르며 고속을 위해 정확하게 권장합니다. 낮은 카디널리티 키 (AWS — using write sharding).

이것은 뒤에 있는 동일한 key-overloading 본능입니다. single-table design — 키 모양을 만듭니다. 데이터가 "자연스럽게" 위치하는 방식이 아닌 액세스 패턴입니다.

적응형 용량으로 쉬운 작업 수행

DynamoDB는 re:Invent 2018 세션에서 다룬 적응형 용량을 제공합니다. "Amazon DynamoDB Under the Hood"(DAT401). 지속적으로 테이블을 재분배합니다. 열을 흡수하는 파티션을 향한 처리량을 늘리고 지속적으로 격리합니다. 자체 파티션에 대한 핫키(키 수준 격리, AWS — bursting & adaptive capacity).

즉각적이고 무료이지만 물리학의 제약을 받습니다. (how adaptive capacity works). 적응력은 움직일 수 있다 키 간 열을 사용하고 열 분할을 통해 핫 항목 컬렉션을 한 번에 분할할 수도 있습니다. 정렬 키 경계. 파티션당 한도는 단일 핫에 대해서만 절대적으로 유지됩니다. item, 계속 증가하는 정렬 키 또는 LSI가 있는 테이블 — 유명인 키 여전히 스로틀합니다. 샤딩은 결정론적인 수정입니다. 열 분할은 느리고 기회주의적이므로 기다리지 마십시오.

사용 중인 키에 제한이 있는 경우 결정 경로는 다음과 같습니다.

대부분의 핫 파티션은 "키 분할" 또는 "적응 용량 허용"으로 해결됩니다. 흡수하세요" - 다이어그램은 당신이 어느 지점에 있는지를 보여줍니다.

재설계하기 전에 진단하세요

보이지 않는 것을 고칠 수는 없습니다. 스로틀링은 다음과 같이 나타납니다. ProvisionedThroughputExceededException(프로비저닝) 또는 다음과 같이 ThrottledRequests, ReadThrottleEvents/WriteThrottleEvents 및 ReadThrottleEventsForKeyRange/WriteThrottleEventsForKeyRange — 파티션 제한별 개수 - CloudWatch에서 (AWS — CloudWatch metrics).

이를 CloudWatch Contributor Insights for DynamoDB와 결합하여 순위를 매깁니다. 가장 많이 액세스된 키 직접 — 유명인 키를 이름으로 확인하는 가장 빠른 방법 (AWS — Contributor Insights). 단축키가 원인인지 아직 확실하지 않은 경우 — DynamoDB는 네 가지 뚜렷한 이유 — 시작부터 the throttling guide 그리고 측정항목의 이름을 지정합니다. 실제로 도달한 한도.

샤딩된 읽기 경로를 테스트할 때, 각 샤드당 KeyConditionExpression. 다음을 사용하여 오타 없이 생성합니다. DynamoDB Expression Builder — 다음을 방출합니다. 샤드당 정확한 PK = :pk AND begins_with(SK, :sk) 모양.

피해야 할 함정

• 계속 증가하는 정렬 키. 단조로운 정렬 키(타임스탬프, 시퀀스 번호) 모든 새로운 쓰기를 하나의 항목 컬렉션의 동일한 끝에 강제로 적용합니다. Split-for-heat는 도움이 되지 않습니다. 컬렉션의 쓰기 단위는 1,000개로 제한됩니다. 정렬 키에 엔트로피를 추가하거나 파티션 키를 분할합니다.
• 읽기가 많은 경로를 불필요하게 분할합니다. 읽기가 지배적이고 항목이 작은 캐시 또는 더 잘 분산된 키가 있는 GSI 샤딩의 분산-수집 읽기 비용을 능가합니다.
• 핫 파티션을 느린 Scan과 혼동합니다. A Scan은 느리기 때문에 느립니다. 모든 것을 읽습니다. 키 하나가 과부하되어 핫 파티션이 제한됩니다. 다양한 문제 — Query vs Scan를 참조하세요.

다음 단계

분할된 키를 스케치한 다음 실제 데이터에 대한 읽기 경로를 증명합니다. 빌드 샤드별 조건 DynamoDB Expression Builder, 그리고 download DynoTable 자신의 테이블에 놓고 어떤 결과가 나오는지 지켜보세요. 파티션은 실제로 열을 흡수합니다.