DynamoDB 요청 라우팅 작동 방식

전송하는 모든 읽기 또는 쓰기는 먼저 무상태 요청 라우터 집합에 도달합니다. 라우터는 귀하의 파티션 키를 해시하고 해당 해시를 소유한 스토리지 노드에 매핑합니다. 해당 키의 데이터를 저장하고 거기로 요청을 전달합니다. 그 한 번의 홉으로 인해 키 조회가 수행됩니다. 테이블에 항목이 천 개가 있든 십억 개가 있든 비용은 동일합니다.

DynamoDB 요청 라우팅은 어떻게 작동합니까?

DynamoDB는 파티션 키를 해시하는 상태 비저장 요청 라우터 플릿을 통해 모든 요청을 라우팅하고 해당 파티션을 소유한 단일 스토리지 노드에 해시를 매핑한 다음 그곳에서 읽기 또는 쓰기를 전달합니다. 라우팅은 키 해시의 순수한 기능이므로 테이블에 항목이 1,000개가 있든 10억 개가 있든 상관없이 한 번의 조회 비용은 동일합니다.

• 요청 라우터는 정문입니다. 요청하고 파티션 키를 해시한 후 해당 키를 보유한 스토리지 노드로 라우팅합니다. 파티션 — 스캐닝이 필요 없고 전체 테이블 지식이 필요하지 않습니다.
• 파티션 키가 모든 것을 결정합니다. 라우팅은 파티션 키의 순수한 기능입니다. 파티션 키의 해시 — 동일한 키는 항상 이를 소유한 파티션으로 라우팅됩니다. GetItem은 O(테이블 크기)가 아닌 O(1)입니다.
• 기본 1개, 보조 2개. 쓰기는 파티션의 기본 노드에 도달합니다. 이는 쿼럼(3개의 복제본 중 2개)이 이를 유지하면 이를 승인합니다.
• 잘못된 키는 디자인을 무효화합니다. 낮은 카디널리티 또는 "hot" partition 키 퍼널 한 노드로의 트래픽 — 라우팅은 양호하지만 키가 문제입니다.

라우팅 문제 해결부터 시작하세요.

SQL에서 보면 쿼리 플래너를 떠올릴 수 있습니다. 쿼리 플래너는 통계를 읽고, 인덱스를 선택하고, 어쩌면 스캔. 비용은 다루는 데이터의 양에 따라 달라집니다. 그 모델은 맞지 않아요 어떤 크기에서도 한 자릿수 밀리초 내에 응답해야 하는 키-값 저장소입니다.

DynamoDB의 대답은 단일 항목 조회를 직접 주소로 만드는 것입니다. 검색. 파티션 키는 where를 계산하는 해시 함수에 대한 입력입니다. 데이터가 물리적으로 존재합니다 - 필터링하는 열이 아닙니다. 통계도 없고 계획도 없습니다.

그것은 관계적 사고에서 벗어날 때 받아들이는 거래입니다. 포기하는 것입니다. 임시 쿼리 유연성과 그 대가로 상수 시간 주소 지정을 얻습니다.

요청 라우터를 만나보세요

요청이 도착하면 바로 스토리지로 이동되지 않습니다. 요청에 도달했습니다. 라우터 — 전체 서비스를 담당하는 무국적, 수평 확장형 플릿입니다. (The USENIX ATC '22 DynamoDB paper describes this request-router fleet.)

라우터는 세 가지 작업을 수행하며 자체 데이터를 보유하지 않습니다.

• IAM에 대한 요청을 인증하고 승인합니다.
• 파티션 키를 해시하여 이를 소유한 파티션을 찾습니다.
• 해당 파티션의 스토리지 노드로 요청을 전달합니다.

라우터는 상태 비저장이므로 서비스는 로드 시 더 많은 라우터를 추가합니다. 없음 병목 현상이 발생하며 단일 실패 지점이 없습니다. 2007 Amazon Dynamo paper 주변에 원래 시스템을 구축했습니다.

라우터를 통해 하나의 읽기를 따르십시오.

드론 함대에 대한 원격 측정 테이블을 사용하세요. 항목의 키는 DroneId(파티션 키) 및 ReadingTs(정렬 키)이며 BatteryPct 및 AltitudeM와 같은 속성을 갖습니다.

6월 23일부터 드론 한 대의 판독값을 요청합니다.

PK = "DRONE#A19F"
SK begins_with "2026-06-23"

아래 다이어그램은 요청을 위에서 아래로 추적합니다. 하나의 하향 흐름으로 읽습니다.

라우터는 DRONE#A19F를 해시하고 이를 해당 키를 소유한 파티션에 매핑한 다음 해당 파티션의 기본 스토리지 노드로 읽기 내용을 전달하고 항목을 반환합니다.

해시는 테이블 중 _하나_의 파티션을 가리킵니다. 있다. 라우터는 다른 파티션을 절대 보지 않으므로 드론과 파티션을 추가합니다. — 이 조회 속도가 느려지지 않습니다.

파티션이 실제로 무엇인지 알아보세요

파티션은 스토리지 및 처리량의 단위입니다. 각각은 제한되어 있습니다(대략적으로 10GB 및 고정된 읽기/쓰기 용량), DynamoDB는 파티션을 분할합니다. 어느 한도를 초과할 때. 지정된 파티션 키가 있는 모든 항목은 하나로 시작됩니다. 파티션; Split-for-heat는 나중에 정렬 키 범위별로 해당 컬렉션을 분할할 수 있습니다. LSI 또는 단조로운 정렬 키가 이를 고정합니다), 이는 여전히 Query 이상을 만드는 것입니다. 하나의 파티션 키가 저렴합니다.

각 파티션은 가용성 전체에 분산된 3개의 스토리지 노드에 복제됩니다. 영역: 기본 1개 및 보조 2개.

쓰기는 쿼럼(2개 중 2개)에 한 번 쓰기를 승인하는 기본 데이터베이스로 이동합니다. 세 개의 복제본)이 이를 유지했습니다. strongly consistent 읽기는 기본으로 라우팅됩니다. 그래서 최신 쓰기를 반영합니다. 최종 일관성 읽기가 제공될 수 있습니다. 아직 따라잡지 못한 보조 장치에 의해 — 비용의 절반, 아마도 오래되었을 수 있습니다.

풋건 이름 지정: 핫 파티션 키

라우팅은 파티션 키만큼만 우수합니다. 해시는 키를 균등하게 분산하므로 귀하의 키는 높은 카디널리티를 가지며 심지어 트래픽도 있고 부하가 모든 키에 분산됩니다. 노드. 두 속성 중 하나를 중단하면 핫 파티션이 발생합니다.

DroneId 대신 Region로 해당 원격 측정 키를 입력한다고 가정해 보겠습니다. 이제 모든 드론이 us-east-1는 하나의 파티션 키를 공유하므로 읽기 및 쓰기가 동일한 파티션 키로 해시됩니다. 키스페이스 슬롯을 사용하여 하나의 항목 컬렉션에 쌓습니다. 라우터가 작업을 수행 중입니다. 완벽하게; 단일 파티션의 용량으로 전체 집합을 퍼널링했습니다.

라우터가 노드를 선택하는 것을 볼 수는 없지만 잘 라우팅되는 키를 설계할 수는 있습니다. 핵심 조건을 구축할 때 Expression Builder, 당신이 넣은 파티션 키 PK = … 왼쪽에는 라우터가 해시할 정확한 값이 있습니다. 이를 유지하세요. 높은 카디널리티 값은 별도의 노드에서 읽기를 유지하는 것입니다.

이것이 귀하의 액세스 패턴과 어떻게 연관되는지

요청 라우팅은 single-table design을 수행하는 메커니즘입니다. 협상할 수 없는 규칙: 파티션 키는 파티션 키를 중심으로 모델링됩니다. is 주소입니다. 이것이 Query가 Scan을 이기는 이유이기도 합니다 — Query는 라우터를 통해 하나의 파티션에 도달하고, Scan는 모든 파티션을 통과합니다. 순차적으로 분할합니다.

보조 인덱스는 자체 파티션과 라우팅을 갖습니다. GSI is routed by its own partition key, 기본 테이블은 테이블이 뜨거워지지 않은 경우에도 GSI가 뜨거워질 수 있는 이유입니다.

다음 단계

하나가 아닌 여러 노드로 라우팅되는 키를 설계합니다. PK = … 조건을 그림으로 그려보세요. Expression Builder를 사용하여 정확히 어떤 값인지 확인하세요. 해시된 다음 download DynoTable에 대해 해당 쿼리를 실행합니다. 테이블을 소유하고 각 주요 조건이 반환하는 내용을 정확히 확인하세요.