파일 형식으로서의 SQLite 의 이점
파일 형식으로서의 SQLite 의 이점
SQLite를 애플리케이션의 온-디스크 파일 형식으로 쓰면 어떤 점이 좋은지 짧게 정리한 페이지예요. 왜 좋은 파일 형식인지에 대한 더 자세한 내용은 별도의 기술 문서에서 다루고 있어요.
본문
(참고: 이 페이지는 SQLite가 좋은 애플리케이션 파일 형식이 되는 이유에 대한 간단한 요약이에요. 이 주제는 별도의 기술 문서에서 더 자세히 다루고 있어요.)
SQLite는 버전 관리 시스템, 금융 분석 도구, 미디어 카탈로그·편집 제품군, CAD 패키지, 기록 관리 프로그램 같은 데스크톱 애플리케이션의 온-디스크 파일 형식으로 아주 성공적으로 사용돼 왔어요. 전통적인 File/Open 동작은 sqlite3_open()을 호출해서 데이터베이스 파일에 연결해요. 애플리케이션 콘텐츠가 수정될 때 업데이트는 자동으로 일어나므로 File/Save 메뉴 옵션은 불필요해져요. File/Save_As 메뉴 옵션은 backup API를 이용해 구현할 수 있어요.
SQLite를 애플리케이션 파일 형식으로 사용하면 장점이 많은데, 그중 일부는 다음과 같아요:
- 더 나은 성능 (Better performance)
- SQLite 데이터베이스에서 읽고 쓰는 것이 디스크에서 개별 파일을 읽고 쓰는 것보다 훨씬 빠른 경우가 많아요. 35% Faster Than The Filesystem와 Internal Versus External BLOBs를 참고해 보세요.
- 애플리케이션은 전체 파일을 읽어서 메모리에 완전한 파싱 결과를 들고 있을 필요 없이, 필요한 데이터만 불러오면 돼요.
- 작은 수정은 변경된 부분만 덮어쓰므로 쓰기 시간이 줄고 SSD 드라이브의 마모도 줄어들어요.
- 애플리케이션 비용과 복잡성 감소 (Reduced application cost and complexity)
- 작성하고 디버깅해야 할 애플리케이션 파일 I/O 코드가 없어요.
- 콘텐츠는 길고 오류가 발생하기 쉬운 절차적 루틴 대신 간결한 SQL 쿼리를 사용해 접근하고 갱신할 수 있어요.
- 파일 형식은 나중 버전에서 새 테이블이나 컬럼을 추가하는 것만으로 확장할 수 있어서 하위 호환성을 유지해요.
- 애플리케이션은 전문 검색(full-text search)과 RTREE 인덱스를 활용하고, 트리거를 사용해 자동화된 undo/redo 스택을 구현할 수 있어요.
- 성능 문제는 개발 주기의 후반에도 CREATE INDEX를 사용해 해결하는 경우가 많아서, 값비싼 재설계·재작성·재테스트 노력을 피할 수 있어요.
- 이식성 (Portability)
- 애플리케이션 파일은 모든 운영 체제, 32-bit와 64-bit, 빅-엔디언과 리틀-엔디언 아키텍처에 걸쳐 이식 가능해요.
- 서로 다른 프로그래밍 언어로 작성된 프로그램들의 연합이 호환성 걱정 없이 같은 애플리케이션 파일에 접근할 수 있어요.
- 여러 프로세스가 같은 애플리케이션 파일에 접근해 서로 간섭하지 않고 읽고 쓸 수 있어요.
- 원래는 "파일 더미(pile-of-files)"로 저장되었을 다양한 콘텐츠가 단일 디스크 파일로 캡슐화되어, scp/ftp, USB 스틱, 이메일 첨부로 더 간단하게 전달할 수 있어요.
- 신뢰성 (Reliability)
- 콘텐츠는 연속적이고 원자적으로 갱신되므로 정전이나 크래시로 인해 잃는 작업이 거의 또는 전혀 없어요.
- SQLite의 버그는 직접 작성한 파일 I/O 코드보다 훨씬 적을 가능성이 높아요.
- SQL 쿼리는 동등한 절차적 코드보다 몇 배나 작고, 코드 한 줄당 버그 수는 대략 일정하므로 전체적으로 버그가 더 적어요.
- 접근성 (Accessibility)
- SQLite 데이터베이스 콘텐츠는 다양한 서드파티 도구로 볼 수 있어요.
- SQLite 데이터베이스에 저장된 콘텐츠는 수십 년 후, 원래 애플리케이션의 흔적이 모두 사라진 뒤에도 복구될 가능성이 훨씬 높아요. 데이터는 코드보다 오래 삽니다.
- SQLite 데이터베이스 파일은 디지털 콘텐츠의 장기 보존을 위한 저장 형식으로 미국 의회도서관이 권장 해요.
SQLite는 데이터베이스 파일이 원하는 어떤 파일명 확장자를 가질 수 있게 허용하므로, 애플리케이션은 필요하다면 자체적인 커스텀 확장자를 고를 수 있어요. application_id pragma를 사용해 데이터베이스 파일에 "Application ID" 정수를 설정하면, file(1) 같은 도구가 그 파일이 단순한 범용 SQL 데이터베이스가 아니라 애플리케이션과 연결된 것임을 알아낼 수 있어요.