최근 수정 시각 : 2024-12-24 14:00:14

SQLite

1. 개요2. 비슷한 목적의 데이터베이스3. 파생 프로젝트


공식 홈페이지

1. 개요

SQLite는 클라이언트 응용 프로그램에 임베디드되어 동작하는 DBMS 소프트웨어로서 퍼블릭 도메인 오픈 소스 소프트웨어이다. 안드로이드, iOS, macOS에 기본적으로 포함되어 있다. 각종 기기에 포함되어있다 보니 명실공히 전세계에서 가장 많이 쓰이는 데이터베이스이다. 공식적인 약칭은 아니지만 약칭은 SQL + Lite(Light).[1]

그래서 SQL에서 하는 기능이 SQLite에선 '경량화'의 이유로 제한되는 경우가 많다. 예를 들자면, 프로토콜 조작을 통해 네트워크에 접근할 수는 있지만, 동시 접근은 제한된다. 또한 복잡하거나 큰 데이터를 보관하는 데에는 적절하지 않다. 인코딩 역시 유니코드만 사용할 수 있어, 사용 인코딩이 유니코드가 아닌 경우에는 占쏙옙을 잔뜩 맛볼 수 있다. 사실 개발 당시부터 이지스함에서 구동시키려던 목적을 가졌기에[2] 자질구레한 기능은 원래부터 제거되어 있었다.

데이터베이스 전체를 파일 하나에 저장하기 때문에, 파일을 통째로 복사하면 백업이 끝난다. 또한 모든 기능을 라이브러리 내에서 구동할 수 있기 때문에, 따로 미들웨어를 쓰지 않아도 프로그램에 라이브러리만 포함시켜 사용할 수 있다. 표준 SQL 문법을 지원하기 때문에 따로 학습해야 하는 것도 별로 없다. 다만 성능은 '라이트'에 맞게 열화되었으므로, 그리 큰 기대는 하지 않는 것이 좋다.

MySQL 등에서 여러가지로 제공되던 자료형이 5가지로 대폭 줄어들었다. 우선 정수 계열(INT, TINYINT, SMALLINT 등)은 INTEGER로, 문자열 계열(VARCHAR, TEXT 등)은 TEXT로, 이진 자료형은 BLOB로, 부동소수점 계열은 REAL로, 고정소수점 및 날짜/시간 계열은 NUMERIC으로 통합되어 있다.

한 번에 한 명의 사용자만이 데이터베이스를 사용할 수 있어서 멀티 유저를 지원하려면 프록시 계층을 도입해야 한다. 멀티테넌트 분산도 지원하지 않고 기가 단위의 데이터를 다루기에도 영 좋지 않다. 이 정도로 크고 무거운 환경에는 다른 DBMS 제품(MariaDB 등)을 선택해야 한다. SQLite는 '임베디드 SQL 지원 데이터베이스'에 특화돼있다. 간단한 룩업 테이블 구현으로 버티기에는 무리가 있지만 그렇다고 미들웨어를 도입해야 할 정도로 거대하지는 않은, 어중간하게 큰 데이터를 다루는 데에 쓰기 좋다. 만약 테이블 조인(Join)을 자주 써야 한다거나 두 개 이상의 필드에 대해 빠른 검색이 필요하면 룩업 테이블 구현[3]으로 골치썩지 말고 SQLite를 도입하는 게 나을 수도 있다.

다만 룩업 테이블 구현보다 성능이 많이 저하되는데 SQL파서가 까먹는 성능이 제법 된다. 인덱스 검색 속도 역시 룩업 테이블은 보통 해시 탐색 알고리즘을 사용해서 O(1)이지만 SQLite의 인덱스는 B-Tree 탐색 알고리즘[4]이라 O(log n)의 성능으로 떨어진다.[5] 또한 룩업 테이블은 전체가 메모리에 올라가 있는 반면에 SQLite는 파일 작업이 들어가므로 여기서 성능을 또 대폭 까먹는다. 따라서 대규모 배치 잡(Batch job)에 SQLite는 좋은 선택이 아니다.[6]

지금까지 기능이나 성능이 낮다는 식으로 말했지만, 그렇다고 전세계에서 가장 많이 쓰이는 데이터베이스인 만큼 버그나 안정성에 문제가 있는 건 절대 아니다. SQLite 는 안정성이 절대적으로 요구되는 항공기에서도 쓰이는 데이터베이스이다. 코드는 FAA에서 요구하는 DO-178B 테스트를 만족하며, 이것은 코드의 모든 분기의 100% 테스트 통과가 포함된다.

구현 자체는 C/ C++로 되어 있으나 라이브러리가 이미 수많은 언어로 나왔기 때문에, C# 등 인지도가 있는 언어로 구현할 때에는 서드파티를 통해 사용할 수 있다. JavaScript 런타임인 Bun의 경우 기본적으로 지원하고, Node.js의 경우 22 버전부터 실험적 기능으로 표준 모듈에 내장되어 있다.

경량 구현인 탓에 외부 라이브러리 의존도가 낮아 거의 C 컴파일러만 있으면 빌드가 가능한 수준이다.[7] 또한 SQLite 홈페이지에 가면 아말감버전이 있는데 다운받아 열어보면 소스 코드 2개와 헤더 파일 2개만 달랑 있는 심플한 구성을 자랑한다. 그 중 하나는 쉘 코드이므로 코어 파일만 필요하면 sqlite3.c 와 sqlite3.h 파일 두 개만 프로젝트에 복사해 놓으면 끝이다. 물론 아말감 버전은 코드를 번들링해놓은 것이고 실제 개발용 소스 코드는 많은 수의 파일로 되어 있다.[8] 다행히 번들링하면서 난독화를 하지는 않았기 때문에 주석도 제대로 달려 있고 들여쓰기도 정상적으로 되어 있다.

암호화 모듈인 SEE(SQLite Encryption Extension)가 공식 SQLite 암호화 모듈인데 이것은 유료 프로그램이라 서드파티 암호화 모듈이 다수 나와 있다. 서드파티 모듈은 단순히 암호화 기능만 추가하기보단 여러 부가 API가 들어가는 경우가 많아 주로 SQLite와 통합하여 제공되는 편이다.

2. 비슷한 목적의 데이터베이스

  • Microsoft SQL Server Compact Edition, Local DB: MFC 및 .NET 계열에서 주로 사용
  • Firebird Embedded Server: Delphi 등 파스칼 계열의 언어에서 주로 사용
  • H2, HSQL, Apache Derby: JVM 환경에서 사용가능한 단일 파일 데이터베이스

3. 파생 프로젝트


[1] 그래서 보통 '에스큐엘+라이트' 라고 읽는다. '시퀄라이트'라고 읽는 법도 존재한다. [2] General Dynamics에서 근무하면서 미사일 구축함에서 사용할 미 해군 소프트웨어 개발 프로젝트에 참여한 리차드 힙(Richard Hipp) 박사가 최초로 개발하였다. [3] 자바의 HashMap, 파이썬의 딕셔너리 등 [4] 버전 3.38.0에 BloomFilter가 적용되어 단순히 B-Tree 탐색 알고리즘이라고 보기는 힘들다. 성능도 단순 B-Tree 탐색 알고리즘과 비교하면 매우 빠르다. [5] 룩업 테이블 구현이 미숙해서 선형 탐색(리니어 서치) 알고리즘을 쓰고 있다면 O(n)이라는 처참한 성능이 나오므로 이 경우에는 SQLite가 훨씬 빠르다. [6] 빅 데이터 프로세싱용 테이블 룩업 작업에는 Redis/Memcached를 고려하자. [7] 리눅스의 경우 pthread와 dl라이브러리를 요구하는데 이 두 라이브러리는 멀티스레드 구현, 다이나믹 링커 라이브러리로서 리눅스의 표준 라이브러리이다. [8] 아말감 버전의 sqlite3.c 파일은 무려 211,864라인이나 된다. 상식적으로 개발자가 이런 무식하게 큰 파일로 개발하긴 어렵다.

분류