DynamoDB 물리적 파티션

물리적 파티션은 DynamoDB가 실제로 데이터를 저장하는 단위입니다. 가용 영역 전체에 복제되어 키 공간의 한 조각을 보유하는 SSD입니다. 귀하의 테이블은 논리적입니다. 파티션은 바이트와 처리량이 있는 곳입니다. 한계 - 실제로 살아있습니다.

DynamoDB 파티션은 어떻게 작동합니까?

DynamoDB는 물리적 파티션(가용 영역 전체에 복제된 SSD 슬라이스)에 테이블을 저장합니다. 각각 최대 10GB, 읽기 단위/초 3,000개, 쓰기 단위/초 1,000개로 제한됩니다. 의 해시는 항목이 어느 파티션에 놓일지 결정하고, DynamoDB는 파티션이 커지거나 뜨거워지면 자동으로 파티션을 분할합니다.

모든 파티션은 최대 10GB의 스토리지, 3,000 읽기 단위/초, 1,000으로 제한됩니다. 쓰기 단위/초. 이러한 한도는 테이블당이 아니라 파티션당 적용됩니다.
의 해시가 파티션을 선택합니다. 동일한 키를 가진 항목 함께 착륙하다; 단일 핫 또는 단조로운 정렬 키가 하나의 파티션을 고정하는 것입니다.
DynamoDB는 다음을 포함하여 크기 및 지속적인 열에 따라 파티션을 분할합니다 LSI 또는 계속 증가하는 정렬 키가 이를 차단하지 않는 한 정렬 키 경계에서 하나의 키 항목 컬렉션을 분할합니다.
여분의 용량을 조절하는 것이 중요합니다. A ProvisionedThroughputExceeded 테이블 사용량이 5%인 동안 오류가 발생하면 단일 파티션이 최대치에 도달했음을 의미합니다.

항목이 파티션을 찾는 방법

DynamoDB는 내부 해시 함수를 통해 파티션 키 값을 제공합니다. 해시 출력은 물리적 파티션을 선택합니다. 매번 동일한 키 입력, 동일한 파티션 출력.

SQL에서는 아날로그가 없습니다. 조정하는 인덱스 B-트리도 없고 샤드 키도 없습니다. 당신은 손으로 할당합니다. 배치는 제어할 수 없고 볼 수 없는 해시입니다.

파티션 키를 공유하는 항목은 를 형성하여 함께 저장되고 정렬 키로 정렬됩니다. 이것이 바로 하나의 키에 대한 Query을 저렴하게 만드는 이유입니다. — 하나를 읽습니다. 하나의 파티션에서 연속적으로 실행됩니다. (Query vs Scan 참조)

게임을 위한 매치 이벤트 상점을 이용해보세요. 테이블 키는 arenaId(파티션)이고 eventKey (정렬):

# Item
arenaId    = "ARENA#7f3a"
eventKey   = "EVT#1719100800#a91c"
playerTag  = "Nightjar"
dmgDealt   = 412

arena 7f3a의 모든 이벤트는 동일한 파티션으로 해시되고 정렬 키에 스택됩니다. 주문. "이 경기의 타임라인 읽기"에 적합합니다. 해당 경기장이 얻는 경우 책임 모든 교통.

모든 파티션이 적용하는 세 가지 천장

단일 파티션은 최대 다음을 제공하도록 설계되었습니다.

| 한도 | 파티션별 | |로 계산됨 | -------------- | -------- | --------------------------- | | 저장 | ~10GB | 원시 항목 바이트 | | 읽기 용량 | 3,000 읽기 단위/초 | 1RU = 4KB 강력한 일관성 읽기 1개 | | 쓰기 용량 | 1,000개 쓰기 단위/초 | 1WU = 1KB 쓰기 1개 |

출처: AWS 파티션 키 설계 모범 사례 가이드.

항목 크기는 수학을 확장합니다. 20KB 항목의 비용은 강력한 일관성당 읽기 단위 5개입니다. 따라서 하나의 파티션은 제한되기 전에 3,000개가 아닌 ~600개의 읽기/초를 제공합니다. 1KB당 라운드 쓰기 비용이 증가하고, 4KB당 읽기 비용이 증가합니다.

이러한 한도는 테이블당이 아닌 _파티션_당입니다. 귀하의 테이블은 다음에 대해 프로비저닝될 수 있습니다. 40,000 WCU이고 모든 쓰기가 하나의 파티션에 집중되기 때문에 여전히 제한적입니다. 그것은 1,000으로 최고입니다.

파티션 분할 방법

DynamoDB는 두 가지 경우에 파티션을 자동으로 추가합니다. 명령을 실행하지 마십시오.

크기에 따라 분할. 파티션이 최대 10GB까지 차면 DynamoDB는 키를 분할합니다. 범위를 두 개로 나누고 항목의 절반을 새 파티션으로 이동합니다. 스토리지 증가 투명하게; 읽기와 쓰기는 계속해서 작동합니다.

열을 위해 분할. 파티션이 처리량에 가까운 지속적인 트래픽을 받는 경우 DynamoDB는 핫 키 범위를 분할하여 각 절반이 자체 파티션에 위치하도록 합니다. AWS에서는 이를 열 분할 메커니즘이라고 부릅니다. 중지되는 짧은 제한 버스트 그 자체로 열 분할이 발생하는 경우가 많습니다. 짧은 스파이크가 발생할 수도 있습니다. 버스트 용량이 부족해집니다.

분할하면 여러 키에 걸쳐 공간을 확보할 수 있으며, 열 분할을 통해 키 하나를 분할할 수도 있습니다. 정렬 키 컷에서 항목 수집. 퍼질 수 없는 것은 하나의 핫 아이템, 계속 증가하는 정렬 키 또는 LSI에 의해 고정된 컬렉션입니다.

단축키가 스플리터보다 나은 이유

분할하면 파티션 키의 _범위_가 재분배됩니다. 교통량이 집중되는 경우 하나의 키 값에 대해 모든 요청은 동일한 파티션으로 해시되며 나눌 수 있는 범위가 남았습니다.

arena 7f3a가 토너먼트 결승전이고 다른 모든 경기장은 초당 4,000개의 쓰기를 수행하는 토너먼트 결승전인 경우 경기장이 유휴 상태이면 1,000에서 스로틀하게 됩니다. 열로 인해 분할되어 여기서는 구할 수 없습니다. 타임스탬프 앞에 붙은 eventKey는 단조롭기 때문에 모든 새로운 쓰기는 잘라낼 것이 없는 하나의 좁은 정렬 키 범위의 앞쪽 가장자리입니다. 최신 KeyRangeThroughputExceeded 스로틀 이유의 이름은 정확히 다음과 같습니다. 하나의 파티션의 키 테이블이 아닌 범위가 한도를 초과했습니다.

수정 사항은 용량 슬라이더가 아닌 데이터 모델에 있습니다. 쓰기-샤드 단축키: 하나의 논리적 영역이 N개의 물리적 파티션에 분산되도록 작은 접미사를 추가합니다.

arenaId = "ARENA#7f3a#3"   # shard 0..9, chosen per write

읽은 다음 샤드 전체에 팬아웃하고 클라이언트 측을 병합합니다. 프로토타입을 만들 수 있습니다. 키 모양과 각 샤드의 Query DynamoDB Expression Builder 만지기 전에 애플리케이션 코드 한 줄.

한 가지 뉘앙스: LSI 예외

파티션 키별로 스토리지가 _제한_되는 경우가 있습니다. 이 없으면 항목 컬렉션이 원하는 만큼의 파티션으로 분할됩니다. 저장된 바이트와 처리량을 모두 제공해야 합니다. 수십억 개의 정렬 키 값은 괜찮습니다.

LSI를 추가하면 하나의 파티션 키에 대한 전체 컬렉션이 단일 파티션 키에 맞아야 합니다. LSI가 공유하기 때문에 10GB 파티션입니다. 그게 PK당 절벽입니다. GSI vs LSI — 대부분의 팀이 GSI를 찾는 또 다른 이유입니다.

파티션이 시원하게 유지되도록 설계

실제로 제어하는 레버는 파티션 키입니다. 구별되는 것이 많은 것을 고르세요 행 수에 상대적인 값이므로 트래픽이 균등하게 분산됩니다. (더 많은 패턴 single-table design.)

높은 카디널리티 키. 사용자별 또는 테넌트별 키가 일일 또는 테넌트별 키보다 우수합니다. 모든 사람이 동시에 누르는 상태별 키입니다.
알려진 단축키를 살펴보세요. "현재 토너먼트" 또는 "오늘" 값은 집중 위험은 배송 후가 아니라 배송 전입니다.
피할 수 없는 단축키를 공유합니다. 하나의 키가 대규모 트래픽을 처리해야 하는 경우, 접미사는 표준 탈출구입니다.

여유 용량을 제한하는 것은 한 파티션이 핫하다는 신호입니다. 검사 왜곡된 항목 컬렉션을 수집하고 분할된 키 레이아웃을 연습합니다. DynoTable — 자신의 테이블을 가리키고, 파티션 키를 GROUP BY로 지정합니다. SQL Workbench를 사용하여 어떤 키가 지배적인지 확인하고 페이지를 보내기 전에 수정 사항을 모델링하세요.