DynamoDB의 GSI 대 LSI
글로벌 보조 인덱스(GSI)와 로컬 보조 인덱스(LSI) 모두 테이블의 키가 아닌 속성으로 Query할 수 있게 해 줍니다. 둘은 서로 바꿔 쓸 수 없으며 — 그 차이가 어떤 패턴에 어느 쪽이 필요한지를 결정합니다.
중요한 차이
| GSI | LSI | |
|---|---|---|
| 파티션 키 | **모든 속성 | 테이블과 동일** |
| 정렬 키 | 모든 속성 | 모든 속성 |
| 생성 시점 | 언제든지 | 테이블 생성 시에만 |
| 일관성 | 최종적 일관성만 | 강력한 일관성 가능 |
| 용량 | 자체 용량 | 테이블 용량 공유 |
| 쓰기 전파 | 비동기(최종적 일관성) | 동기(원자적) |
| 테이블당 최대 | 20(기본, 상향 가능) | 5(고정) |
| 10 GB 파티션 한도 | 없음 | 있음(PK당) |
경험 법칙
- 다른 파티션 키가 필요한가요(예:
customer가 아니라status로 주문 조회)? 그렇다면 GSI가 필요합니다 — LSI는 재파티션을 할 수 없습니다. - 같은 파티션 내에서 두 번째 정렬 순서가 필요한가요 — LSI는 테이블의 정확한 파티션 키를 유지하고 다른 정렬 키만 바꿔 끼웁니다 — 미리 결정하고 강력한 일관성 읽기까지 원하나요? 그렇다면 LSI가 맞습니다.
선택은 한 가지 질문으로 귀결됩니다 — 어떤 키를 바꾸고 있나요:
다른 파티션 키는 GSI를 강제하고, 같은 파티션에 다른 정렬 키를 두는 것이 LSI가 맞는 유일한 경우입니다.
실제로 대부분의 팀은 거의 GSI만 사용합니다: 나중에 추가할 수 있고, 독립적으로 확장되며, 파티션당 10 GB 한도의 영향을 받지 않습니다. 단일 GSI의 키를 오버로딩하여 여러 패턴을 처리하세요 — 싱글 테이블 디자인을 참조하세요.
Scan을 없애려고 GSI를 추가한다면, 그 GSI에는 자체 읽기/쓰기 용량이 있다는 점을 기억하세요. 추가 비용은 요금 계산기로 계산하고, DynoTable을 사용해 인덱스를 확정하기 전에 그 프로젝션 속성을 확인하세요.