DynamoDB 스토리지 내부 작동 방식

DynamoDB는 값이 정렬된 트리로 여러 시스템에 분산되어 있는 해시 테이블입니다. 3개의 가용 영역에서. 두 가지 데이터 구조가 거의 모든 작업을 수행합니다: 해시 파티션 키에서는 기계를 선택하고, 정렬 키 주문 항목에서는 B-트리를 선택합니다. 그 안에.

DynamoDB는 데이터를 어떻게 저장합니까?

DynamoDB는 값이 B-트리로 정렬된 거대한 분산 해시 테이블로 데이터를 저장합니다. 파티션 키의 해시는 하나의 스토리지 노드를 선택합니다. B-트리는 내부의 정렬 키를 기준으로 항목을 정렬합니다. 모든 쓰기는 3개의 가용 영역에 걸쳐 2개의 피어에 복제되는 리더로 이동하여 쿼럼(3개 복제본 중 2개)에 쓰기가 있으면 이를 승인합니다.

• 파티션 키는 검색되지 않고 해시됩니다. DynamoDB는 해시 함수를 실행합니다. 저장 노드(또는 큰 컬렉션이 분할되면 노드)를 찾기 위해 PK 이상 해당 파티션을 유지하는 경우 — 테이블 크기에 관계없이 O(1) 점프입니다.
• 정렬 키는 B-트리에 있습니다. 파티션 내부의 항목은 정렬 키를 기준으로 정렬된 B-트리 — 문자열의 경우 UTF-8 바이트 순서, 문자열의 경우 숫자 순서 숫자 키 — 이것이 바로 범위 읽기(begins_with, between)가 저렴하고 Scan은 그렇지 않습니다.
• 모든 쓰기는 승인되기 전에 쿼럼에 커밋됩니다. 쓰기는 리더에게 전달됩니다. 다른 AZ에 있는 두 피어에 복제하고 쿼럼(두 개 중 두 개)을 한 번 승인합니다. 세 개의 복제본)이 있습니다. 내구성은 PutItem가 반환되기 전에 구입됩니다.
• 이것이 액세스 패턴 규칙이 존재하는 이유입니다. Hash-then-tree는 다음 경우에만 빠릅니다. 당신은 열쇠로 읽습니다. 키도 없고 빠른 경로도 없습니다. 다시 트리 스캔으로 돌아갑니다.

API가 아닌 데이터 구조부터 시작하세요

SQL에서 쿼리 플래너 선택을 통해 테이블을 디스크의 행으로 묘사합니다. 인덱스. DynamoDB에는 플래너가 없습니다. 스토리지 레이아웃은_계약입니다. 빠르고 풋건은 둘 다 두 구조물에서 곧바로 떨어집니다.

거대한 분산 지도를 그려보세요. 키는 파티션 키의 해시입니다. 는 값은 해당 값을 공유하는 항목의 전체 B-트리입니다. 정렬 키에 따라 정렬된 파티션 키입니다.

그 밖의 모든 것 — 쿼리 의미 체계, 10GB 경고, 누락된 키가 강제로 실행되는 이유 a Scan — 그 한 문장의 결과입니다.

파티션 키를 해시하여 노드를 찾습니다.

요청이 도착하면 DynamoDB는 내부 해시 함수를 파티션 키 값. 해시는 하나의 스토리지 노드에 결정적으로 매핑됩니다. 해당 항목을 소유하는 물리적 파티션입니다. AWS는 이를 다음과 같이 문서화합니다. 테이블 크기에 관계없이 일정한 시간 키 조회를 지원하는 메커니즘입니다.

이것이 O(1) 단계입니다. 10TB 테이블과 10KB 테이블의 찾기 비용은 동일합니다. 해시, 점프, 완료. 노드를 찾기 위한 인덱스 스캔도 없고, 통계도 없고, 계획도 없습니다.

캐치는 반대편입니다. 파티션 키를 제공하지 않으면 DynamoDB는 점프할 노드가 없습니다. 모든 파티션을 이동해야 합니다. 그건 Scan이고, O(1)과 전체 테이블을 읽는 것의 차이점.

요청은 정확히 하나의 파티션으로 해시된 다음 해당 파티션의 하위 파티션으로 내려갑니다. 항목에 대한 정렬 키 B-트리 — 테이블 워크 대신 저렴한 두 단계.

파티션별 B-트리에서 항목 주문

단일 파티션 내부의 항목은 힙이 아닙니다. B-트리 키에 보관되어 있습니다. 정렬 키를 기준으로 사전순으로 정렬됩니다. B-트리 탐색은 O(log n)이고, 결정적으로 n는 전체 테이블이 아니라 one 파티션에 있는 항목이라는 점입니다.

이것이 정렬 키 범위 읽기가 저렴한 이유입니다. 차량 원격 측정을 이용하세요 각 장치의 판독값이 하나의 파티션 키 아래에 있는 테이블:

B-트리가 정렬되어 있으므로 "08:00~09:00 사이의 모든 판독값"이 트리입니다. 시작 값까지 하강하고 순차적 걷기를 수행합니다. 모든 항목에 대한 필터는 아닙니다. 이제까지 전송된 장치를 읽는 중입니다. 일치하는 범위만 읽습니다.

이러한 순서는 begins_with(SK, "READING#2026-06-23") 쿼리가 빠른 이유이기도 합니다. 키가 아닌 속성에 대한 필터링은 그렇지 않습니다. 트리는 SK로 탐색할 수 있습니다. 그것 다른 어떤 것으로도 추구할 수 없습니다. 이러한 주요 조건을 안전하게 구성하려면 빌드하세요. 오히려 DynamoDB Expression Builder에서는 문자열을 직접 연결하는 것보다:

KeyConditionExpression  PK = :pk AND begins_with(SK, :day)

모든 쓰기를 3개의 AZ에 복제합니다.

파티션은 하나의 머신이 아닙니다. 각각은 3개의 노드에 걸쳐 복제됩니다. 3개의 가용 영역 — 2022년에 자세히 설명된 리더 기반 쿼럼 설계 USENIX ATC DynamoDB 문서(2007년 Amazon Dynamo 문서의 이름은 이 복제 모델이 아닌 철학 조상).

한 노드는 파티션의 리더입니다. 쓰기는 리더에게 전달됩니다. 로컬로 쓰고 두 피어에 복제합니다. 리더는 1회에 한 번씩 쓰기를 승인합니다. 내구성이 뛰어난 노드 쿼럼이 있으므로 AZ 전체의 내구성은 _이전_에 지불됩니다. 당신의 PutItem 수익.

읽기에는 선택권이 있습니다. strongly consistent 읽기는 리더에게 전달되고 최근에 커밋된 쓰기. 최종 일관성 읽기는 다음을 통해 제공될 수 있습니다. 세 개의 노드 중 하나가 몇 밀리초 뒤쳐질 수 있습니다. 더 저렴하고 더 많은 읽기를 위해 지연 시간을 교환합니다.

주문형 청구에서 2KB 항목 읽기에는 1RCU 비용이 많이 듭니다. 같은 최종적으로 일관된 비용 0.5 RCU를 읽어보세요. 핫 경로의 라인 등급을 지정하세요. pricing calculator.

동일한 비동기 전파 아이디어는 GSI 읽기가 오래될 수 있는 이유입니다. GSIs are eventually consistent.

구조의 규칙을 읽어보세요

거의 모든 DynamoDB "규칙"은 단지 스토리지 물리학일 뿐입니다.

• 항상 파티션 키를 제공하세요. 키도 없고 해시 대상도 없습니다. 스캔 중입니다. 지도 전체. 이것이 Query vs Scan의 핵심입니다.
• 함께 읽는 내용을 하나의 파티션 키 아래에 배치하므로 단일 hash + tree-walk는 전체 항목 컬렉션을 반환합니다. 그게 기초야 single-table design.
• 파티션을 경계로 유지합니다. 하나의 파티션은 유한 집합의 하나의 B-트리입니다. 노드; 런어웨이 핫키 또는 LSI의 10GB 제한은 둘 다 물리적인 한계입니다. 파티션.

해시 후 B 트리 모양이 보이면 액세스 패턴 규율이 중지됩니다. 자의적 느낌 — 모든 읽기를 빠른 경로로 유지하는 것뿐입니다.

다음 단계

sort key strategies의 구조와 일치하도록 키를 모델링하세요. 그리고 single-table design, 실제 조립 DynamoDB Expression Builder의 표현. Try DynoTable 이러한 읽기가 자신의 테이블에 대해 실행되는 것을 확인하고 주요 조건이 어떤 항목을 되돌리는지 정확히 확인하세요.