docs: DynamoDB 싱글 테이블 설계서 작성 by farmer0010 · Pull Request #4 · farmer0010/sample-lambda

farmer0010 · 2026-06-02T03:32:37Z

다이나모 디비 싱글 테이블 설계서 작성입니다!

losnuyh · 2026-06-02T05:49:13Z

use case가 뭐뭐인거야?
나열해봐

dynamodb gsi quota 몇인지 체크해봐
왜케 많이 만들어

지금 설계 완전 이상한거같은데?

losnuyh · 2026-06-02T05:50:45Z

dynamodb 싱글 테이블 설계도는

필드 다 빼고

index들 세팅한거

use case

끝

farmer0010 · 2026-06-02T07:40:20Z

필드 명세 제거, Use Case 및 조회 패턴 추가, Base Table / GSI 구성만 남도록 정리해두면 싱글 테이블에 맞게 수정해보았습니다!
코드 관련 pr은 feat/read-memo-api에 따로 분리하여 올려두었고 추가로 GSI Quota도 확인해봤는데 기본 20개였습니다.
기존에는 조회 조건별로 GSI를 나눠놨는데 단일 GSI로 변경하였고 카테고리나 검색어 조건은 필터링으로 처리하도록 수정했습니다.

losnuyh · 2026-06-02T08:28:22Z

+
+조회 패턴
+
+* GSI1PK = USER#{user_id}


Suggested change

* GSI1PK = USER#{user_id}

* PK = USER#{user_id}

이거 그냥 PK랑 똑같은거아냐? 왜 따로 GSI1PK가 있는거여

losnuyh · 2026-06-02T08:29:23Z

+조회 패턴
+
+* GSI1PK = USER#{user_id}
+* search_content FilterExpression


FilterExpression <- 어떻게 동작하는지 찾아봐

losnuyh · 2026-06-03T09:43:56Z

usecase d

user_id로 해당 유저가 작성한 memo들 조회 가능
user_id로 해당 유저가 작성한 memo중에 특정 카테고리 메모들 조회
memo id로 memo 단건 조회

dynamodb 에서 PK, SK 라고 하는게 index 키를 이야기하는 것과 필드명을 이야기하는 것을 구분해야함

만약에 default table 설정이 아래와 같다면...

key	field	value
PartitionKey	PK	~~값
SortKey	SK	~~값

GSI는 다음과 같이 구성 가능

name: GSI1

key	field	value
PartitionKey	SK	~~값
SortKey	PK	~~값

name: GSI2
??? 필요할까?

모든 id는 ulid로 만든다.

데이터 설계
PK: user#<user_id>
SK: category#<카테고리명>#memo#<memo_id>

user_id로 해당 유저가 작성한 memo들 조회 가능
-> PK=user#<user_id>

user_id로 해당 유저가 작성한 memo중에 특정 카테고리 메모들 조회
-> PK=user#<user_id>, begins_with(SK, "category#<블라블라>")

memo id로 memo 단건 조회 << 해결
-> GIS1, SK="memo#<memo_id>"

공부할 것

다이나모디비가 어떻게 물리적인 데이터베이스를 유연하게 확장하는가?
-> Q. SK를 SK: category#<카테고리명>로만 지정하면 발생하는 문제는???
CAP 이론
ULID, https://en.wikipedia.org/wiki/Snowflake_ID
dynamodb 조회시 제공하는 기능들 (ex, begins_with)

farmer0010 · 2026-06-05T05:22:04Z

SK : category#<카테고리명> 로만 지정하면 생기는 문제점에 관하여 고민해보았는데 SK를 category#<카테고리명> 지정해버리면 같은 유저가 같은 카테고리에 다음 메모를 쓰는 순간에 기존 메모리는 덮어 씌여저버리는 문제가 발생하여 같은 카테고리 안에서도 키 값의 고유성을 보장하기 위해 SK 맨뒤에 memo.id와 같이 유일한 값을 결합해주어야만 데이터가 덮어 씌어지지 않기때문에 이러한 점이 보완되어야 한다고 생각합니다!

GSI1 사용 이유:
메모 수정 및 삭제는 memo_id만으로 수행되지만 기본 테이블은 PK = USER#{user_id} 구조이므로 사용자 정보를 모르면 단건 조회가 불가능한 상황이 생겨 이를 해결하기 위해 Base Table의 PK, SK를 재사용하는 Inverted Index를 구성하여 memo_id만으로 원본 데이터를 찾을 수 있도록 설계하였습니다!

GSI2 사용 이유:
초기에는 Sort Key에 카테고리를 포함하여 카테고리별 조회를 처리하려고 했었는데 이 경우에는 전체 메모 조회 시 정렬 기준이 카테고리가 되어 최신순 타임라인이 깨지는 문제가 발생하게 되서 전체 메모 최신순 조회와 카테고리별 최신순 조회를 모두 만족시키기 위해 Base Table은 전체 타임라인 조회에 집중하고, 카테고리 조회는 별도의 GSI로 분리하였습니다!

losnuyh · 2026-06-09T03:56:28Z

+| Key    | Value         |
+| ------ | ------------- |
+| GSI1PK | Base Table SK |
+| GSI1SK | Base Table PK |


이게 inverted index ??

이 부분은 제가 용어를 잘못 사용했습니다! 인버티드 인덱스라고 적었는데 memo_id가 고유한 ULID 값이라 단건 조회용 룩업 인덱스에 더 가깝습니다. 현재 유즈케이스에서는 수정이나 삭제 및 단건 조회 시 user_id 없이 memo_id만 넘어오도록 구현되어 있어서 해당 메모의 원본 PK(USER#{user_id})를 찾기 위해 GSI1을 추가되어있으며 Base Table은 PK와 SK를 모두 알아야 단건 조회나 수정 및 삭제가 가능하기 때문에, memo_id만으로 접근해야 하는 현재 구조에서는 이를 한 번 찾아주는 역할이 필요하다고 생각했습니다!

losnuyh · 2026-06-09T04:00:44Z

+* GSI2PK = USER#{user_id}#CATEGORY#{category}
+* ScanIndexForward = False


카테고리별 메모 조회가 목적인거면

pk: USER#{user_id}
sk: C#{category name}#M#{memo_id}

로 한 다음에

Suggested change

* GSI2PK = USER#{user_id}#CATEGORY#{category}

* ScanIndexForward = False

* PK=user#1234, begins_with(SK, "C#java")

로 찾아도 되는거 같은데?

너가 남긴 코멘트보면

유저의 전체메모 조회때
sort 기준이 최신 순서를 조회할 때 SK가 카테고리이름의 정렬 순서가 고정이여서 안된다고 말한거 같은데?

설계 잘못됨.

LSI 찾아봐.

넵 확인해서 수정해서 올리겠습니다!

LSI에 대해 다시 찾아보니 현재 카테고리 조회 패턴은 별도의 GSI 없이도 처리 가능하다는 알게 되었고 말씀해주신 것처럼 LSI를 활용하면 기존 GSI2가 담당하던 역할을 대체할 수 있어 이 부분은 LSI 기반으로 수정하겠습니다!

losnuyh · 2026-06-10T07:18:49Z

+| Partition Key | GSI1PK | Base Table SK |
+| Sort Key      | GSI1SK | Base Table PK |


기존 PK, SK 속성을 그대로 인덱스 키로 사용할 수 있는데 제가 GSI용 필드를 별도로 추가하면서 데이터를 중복 저장되는걸 확인해서 PK, SK를 그대로 활용하는 방향으로 설계서랑 레포지토리 코드 수정해두겠습니다!

losnuyh · 2026-06-10T07:19:22Z

+* `GSI1PK = MEMO#{memo_id}`
+* 조회된 원본 PK(`GSI1SK`)와 SK(`GSI1PK`)를 이용하여 수정 및 삭제
+
+### 전체 메모 조회


Suggested change

### 전체 메모 조회

### 특정 유저의 전체 메모 조회

넵 수정완료했습니다!

losnuyh · 2026-06-10T07:23:09Z

+* `PK = USER#{user_id}`
+* `ScanIndexForward = False`
+
+### 카테고리별 메모 조회


Suggested change

### 카테고리별 메모 조회

### 특정 유저의 카테고리별 메모 조회

넵 수정완료했습니다!

docs: DynamoDB 싱글 테이블 설계서 작성

b37544d

docs: DynamoDB 싱글 테이블 설계서 수정

de47298

losnuyh reviewed Jun 2, 2026

View reviewed changes

farmer0010 added 3 commits June 5, 2026 10:06

docs: 싱글테이블 디자인 설계 수정

d9c23b3

fix: docs 수정

fba5b92

fix: 검색 유즈케이스 제외

f2aed67

losnuyh reviewed Jun 9, 2026

View reviewed changes

farmer0010 added 2 commits June 9, 2026 14:35

fix:GSI2제거 및 LSI 수정

267061b

fix: 테이블 표: key, filed, value로 구분

3b549ef

losnuyh reviewed Jun 10, 2026

View reviewed changes

fix: docs 문제 수정

6721a2d

farmer0010 merged commit ded6b59 into main Jun 17, 2026

farmer0010 deleted the docs/dynamodb-design branch June 17, 2026 01:22

		* GSI2PK = USER#{user_id}#CATEGORY#{category}
		* ScanIndexForward = False

	* GSI2PK = USER#{user_id}#CATEGORY#{category}
	* ScanIndexForward = False
	* PK=user#1234, begins_with(SK, "C#java")

		\| Partition Key \| GSI1PK \| Base Table SK \|
		\| Sort Key \| GSI1SK \| Base Table PK \|

	### 전체 메모 조회
	### 특정 유저의 전체 메모 조회

	### 카테고리별 메모 조회
	### 특정 유저의 카테고리별 메모 조회

Conversation

farmer0010 commented Jun 2, 2026

Uh oh!

losnuyh commented Jun 2, 2026

Uh oh!

losnuyh commented Jun 2, 2026

Uh oh!

farmer0010 commented Jun 2, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

losnuyh commented Jun 3, 2026

Uh oh!

farmer0010 commented Jun 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

farmer0010 Jun 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

farmer0010 commented Jun 5, 2026 •

edited

Loading

farmer0010 Jun 9, 2026 •

edited

Loading