Scale에서 SQLite 운영 — 진짜 패턴 · SQLite Quest

계속 되풀이되는 패턴

규모를 키운 SQLite는 '거대한 DB 하나'인 경우가 거의 없어. 거의 언제나 'SQLite 여러 개'야. 반복해서 나오는 패턴이 다섯 있어.

tenant마다 DB 하나 — 고객이나 유저마다 자기 파일을 가져. 백업도 마이그레이션도 삭제도 전부 tenant 단위로 끝나고, tenant 수만큼 옆으로 늘어나.
Litestream으로 만드는 read replica — writer 하나에 읽기 전용 replica 여럿을 붙여. 당겨오는 방식이라 시차가 조금 있어.
뜨거운 데이터와 찬 데이터 나누기 — 지금 쓰는 데이터는 작은 SQLite에 두고, 보관용은 별도 파일에 두다가 필요할 때 ATTACH해.
Edge replica — Turso나 D1이 같은 logical DB를 여러 지역으로 밀어줘. 읽기는 가까운 데서 하고 쓰기는 primary로 보내는 거야.
유저 id 해시로 쪼개기 — tenant 단위가 안 맞지만 SQLite의 단순한 배포는 그대로 누리고 싶은 제품에 써.

Self-reference: 피파는 가장 단순한 경우야. 유저 한 명(아빠), DB 하나. 위 패턴은 아직 하나도 필요 없어. 언젠가 피파가 다른 아빠들을 만나게 된다면, local-first로 설계했으니 인스턴스마다 자기 DB를 갖게 될 거야. 그게 곧 tenant마다 DB 하나인 셈이지.

Code

Hot/cold split용 ATTACH·sql

ATTACH DATABASE '/path/to/archive.db' AS archive;

-- 양쪽 across query
SELECT id, body FROM messages
UNION ALL
SELECT id, body FROM archive.messages;

-- 옛 row 를 archive 로 이동
INSERT INTO archive.messages SELECT * FROM messages
WHERE created_at < datetime('now', '-1 year');

DELETE FROM messages WHERE created_at < datetime('now', '-1 year');

DETACH DATABASE archive;

Exercise

네가 작업했던 제품 중에 거대한 공용 Postgres를 쓰는 걸 하나 골라. tenant마다 SQLite를 두면 어떤 모양이 될지 스케치해봐. 경계를 어디에 그을지(고객 단위? 조직 단위? 유저 단위?), 뭐가 어려워지는지(tenant를 가로지르는 분석?), 뭐가 쉬워지는지(삭제, 백업, 마이그레이션). 그리고 이 맞바꿈이 남는 장사인지 결론을 내.

Scale에서 SQLite 운영 — 진짜 패턴

계속 되풀이되는 패턴

Code

External links

Exercise

Progress

댓글 0