https://www.notion.so/blog/sharding-postgres-at-notion - 올해초 5분간 노션을 다운시키고 몇달간 진행해온 PostgreSQL 샤딩을 진행 ㅤ→ 엄청 빨라 졌다고 즉각적으로 반응이 나오기 시작 - 샤딩하기로 언제 결정 했나 ㅤ→ 5년간 몇만배 성장하면서, 잘 사용하던 Postgres Monolith가 용량을 초과하기 시작 ㅤ→ VACUUM이 지속적으로 중단되기 시작했고, 곧 TXID wraparound 가 발생할 것으로 예상되어 샤딩 작업 시작
- 샤딩 스킴 설계하기 ㅤ→ 어플리케이션 레벨 샤딩 ㅤㅤ⇨ 어떤 데이터를 샤딩할 것인가 ㅤㅤ⇨ 어떤 키로 파티셔닝 해서 데이터를 분할할것인가 ㅤㅤ⇨ 얼마나 많은 샤드를 만들고, 어떻게 구성해야 하나 ㅤ→ 결정 #1 ㅤㅤ⇨ 노션은 block 단위로 데이터 모델이 구성됨 ㅤㅤ⇨ block 테이블에서 연결되는 모든 테이블을 샤딩하기로 함 (Space, Discussion, Comment 등) ㅤ→ 결정 #2 ㅤㅤ⇨ block 은 workspace ID로 파티셔닝 ㅤㅤ⇨ 각 workspace는 UUID가 부여되므로 이걸 이용 ㅤ→ 결정 #3 ㅤㅤ⇨ 480개의 논리적 샤드 와 32개의 물리적 DB로 구성 ㅤㅤㅤㅤ2의 제곱수인 512가 아닌 480을 선택한 이유는, 더 유연하게 나누어 지는 숫자이기 때문
- 샤드로 이관하기 ㅤ→ 1. Old & New DB에 이중으로 쓰기 (Audit Log와 함께) ㅤ→ 2. 이중 쓰기 시작후 올드DB의 데이터를 새 DB로 Backfill 시작 ㅤ→ 3. 새 DB의 데이터 검증 ㅤ→ 4. 새 DB로 변경 (Incremental로 진행)
- 어렵게 배운 교훈들 ㅤ→ 더 일찍 샤딩 하세요 : 기존 DB부담이 커질때까지 기다렸기 때문에, 마이그레이션 자체도 부담을 주는게 되어서 천천히 할 수 밖에 없었음 ㅤ→ Zero 다운타임 이관을 목표로 하세요 : 이중 쓰기의 처리량이 최종 전환시에 핵심 병목이었음. ㅤ→ 별도 파티션 키 대신, 복합 PK를 이용하세요 : 기존 DB의 PK인 id와 파티션 키인 space_id 를 묶어 버리면 앱 내에서 space_id 들을 패스할 필요를 없앨수 있었을 것 | 
