본문 바로가기
C.W.K.
Stream
Lesson 04 of 10 · published

SQLite Limits

~10 min · limits, scale, production

Level 0Scout
0 XP0/80 lessons0/10 achievements
0/120 XP to next level120 XP to go0% complete

놀랄 사람 없는 숫자들 — 너무 커서

SQLite의 한계 수치는 웬만한 앱이 부딪히는 지점보다 한참 위에 있어. 알아둘 건 이 정도야.

  • DB 크기 — 최대 281 TB, 그러니까 2^48 byte야. page size에 최대 page 수를 곱한 값인데, 이 숫자는 page size를 최대치인 65536으로 잡았을 때 나와. 기본값인 4096으로 두면 43억 page를 다 채워도 17 TB쯤에서 멈춰.
  • row 크기 — row 하나에 약 1 GB야. 성능을 생각하면 실질적인 한계는 훨씬 아래고.
  • String과 BLOB 컬럼 길이 — 기본 1 GB인데 바꿀 수 있어.
  • 컬럼 수 — 기본 2,000개고, 더 늘리려면 다시 컴파일해야 해.
  • DB 하나에 들어가는 테이블 수 — 수십억이라 사실상 한계가 아니야.
  • 동시 writer — 파일마다 한 번에 하나야. 이게 네가 실제로 부딪힐 한계고, 크기가 아니야.
Tip: SQLite의 크기 한계가 걱정된다면, 거의 언제나 writer가 하나뿐이라는 한계에 먼저 부딪히게 돼. 그쪽을 돌아갈 계획부터 세워. tenant별로 쪼개거나, write를 묶어서 처리하거나, 뜨거운 데이터와 찬 데이터를 나누는 식으로. 281 TB 천장을 걱정하기엔 아직 한참 멀었어.

Code

내 빌드의 실제 limit 검사·sql
PRAGMA page_size;
PRAGMA max_page_count;
SELECT page_size * max_page_count AS max_db_bytes FROM
  (SELECT 4096 AS page_size, 4294967294 AS max_page_count);
-- 17,592,186,040,320  (~17 TB — 더 늘리려면 max_page_count 증가)

External links

Exercise

Implementation limits 문서를 읽어. 네 제품 하나를 놓고 지금의 10배 규모에서 실제로 발목을 잡을 한계가 뭔지 짚어봐. 대부분의 프로젝트는 하나도 못 찾을 거야. 그러면 진짜 병목 — write 처리량, query 지연, 배포 모양 —이 뭔지, 그리고 SQLite가 문제가 되기 전에 뭘 바꿔야 하는지 적어.

Progress

Progress is local-only — sign in to sync across devices.
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

댓글 0

🔔 답글 알림 (로그인 필요)
로그인댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.