imjae.DEV NOTES
글 모아보기/학습 메모

NOTES / 기술 노트

DynamoDB의 Partition Key·Sort Key와 조회 패턴 설계

가상의 퀘스트 데이터에서 키와 접두어 조회를 설계한다. Query와 Filter, 정렬·페이지네이션의 차이를 로컬 모델과 실습·풀이로 설명한다.

imjae5분 읽기
#DynamoDB#Database#Query

먼저 어떤 요청이 필요한지 적는다

DynamoDB 설계 예시는 접근 패턴 중심의 모델링을, C# 테스트는 QueryRequest와 begins_with를 다룬다. 원래 계정·사용자·서비스 데이터를 사용하지 않고 자체 퀘스트 샘플로 다시 구성했다.

원문의 ‘NoSQL은 어떤 규모에서나 일정 성능’ 같은 일반화는 사용하지 않는다. 키 분포, 항목 크기, 처리량, 인덱스와 접근 패턴에 따라 비용·지연·제한이 달라진다. RDB보다 언제나 빠르다는 비교도 이 글의 근거에 없다.

복합 기본 키 예제

PKSK상태
USER#study-aQUEST#001completed
USER#study-aQUEST#002active
USER#study-aPROFILE—
USER#study-bQUEST#001active

PK는 파티션 키, SK는 정렬 키인 문자열 속성으로 정한다. 기본 키 조합이 항목을 식별한다. ‘사용자 a의 퀘스트 목록’은 PK 동등 조건과 SK 접두어 조건으로 표현할 수 있다. 다른 사용자의 항목을 같은 Query로 읽는 것은 이 키 조건과 다르다.

KeyConditionExpression: #pk = :user AND begins_with(#sk, :prefix)
ExpressionAttributeNames: #pk → PK, #sk → SK
ExpressionAttributeValues: :user → USER#study-a, :prefix → QUEST#

문자열을 표현식에 이어 붙이지 않고 값 파라미터를 사용한다. 숫자처럼 정렬할 문자열 ID는 001·002처럼 고정 폭을 쓰거나 별도 숫자 키 설계를 선택한다. 문자열 1,10,2는 숫자 순서가 아니다.

로컬에서 키 조건 확인하기

Node.js 모델이며 DynamoDB의 실제 엔진·용량·일관성·페이지 제한을 구현한 것은 아니다.

const rows = [
  {PK:'USER#study-a',SK:'QUEST#002'},
  {PK:'USER#study-a',SK:'PROFILE'},
  {PK:'USER#study-b',SK:'QUEST#001'},
  {PK:'USER#study-a',SK:'QUEST#001'}
];
const selected = rows.filter(x => x.PK==='USER#study-a' && x.SK.startsWith('QUEST#'));
selected.sort((a,b) => a.SK < b.SK ? -1 : a.SK > b.SK ? 1 : 0);
console.log(selected.map(x=>x.SK).join(', '));
QUEST#001, QUEST#002

Query 뒤의 Filter와 페이지 끝

Query는 파티션 키 동등 조건을 사용하고 선택적으로 정렬 키 조건을 더한다. FilterExpression은 읽은 뒤 결과에서 걸러낸다. 따라서 Filter로 적게 반환됐다고 읽기 작업도 그만큼 줄었다고 해석하지 않는다. DynamoDB Query API

한 요청은 제한된 페이지를 반환한다. LastEvaluatedKey가 있으면 다음 요청의 ExclusiveStartKey에 넘긴다. Filter로 모두 빠진 페이지는 Items가 비어 있어도 다음 키가 있을 수 있다. 항목 수가 0이라는 이유로 반복을 끝내지 않는다. 페이지네이션 문서

실습과 풀이

  1. ‘모든 사용자의 active 퀘스트’가 새 요구사항이면 어떻게 할까? 풀이: 현재 PK 조건만으로 효율적인 동일 Query가 되지 않는다. 추가 접근 패턴을 위한 인덱스·데이터 중복·집계 설계를 검토한다. 무조건 Scan으로 대체한 뒤 같은 비용이라고 설명하지 않는다.
  2. 결과가 0인데 LastEvaluatedKey가 있다. 풀이: 다음 페이지를 요청한다. 완전한 마지막은 다음 키가 없는 조건으로 판단한다.
  3. SK에 QUEST#1, QUEST#10, QUEST#2를 넣는다. 풀이: 문자열 정렬은 1,10,2다. 생성 규칙을 바꾸거나 숫자 속성·키 구조를 목적에 맞게 설계한다.

확인한 범위

2026년 10월 17일 본문의 JavaScript를 추출해 Node.js 24.15.0에서 실행했고, 표시한 입력의 출력과 일치했다. 이 확인은 독립 수치·응답 모델의 해당 예제 입력을 대상으로 한다.

노션과 AWS Query 문서를 대조해 자체 데이터와 로컬 모델을 작성했다. AWS SDK·DynamoDB Local·실서비스 Query·페이지네이션·처리량·권한은 실행하지 않았다. DCB의 저장 시스템이나 운영 백엔드 성과가 아니다. AI를 작성 보조에 사용했다.

이어 읽기

전체 학습 순서 · 다음 글: HTTP 요청·응답·실패·취소를 작업 API로 이해하기

← 글 모아보기