SQLite를 사용해야 하는 이유
SQLite를 사용해야 하는 이유
1. SQLite
- 내장 가능한 오픈소스 데이터 베이스
- C로 작성
- 일반적 SQL 쿼리 가능
- 빠른 속도, 이식성, 안정성 제공
2. SQLite의 사용 환경
- 거의 어디에서나 실행 가능
- 윈도우, 맥OS, 리눅스, iOS, 안드로이드를 비롯한 다양한 플랫폼에 이식
- 대상에 맞는 SQLite가 있거나 C 소스코드를 타겟으로 이식할 방법이 존재함
- 간단한 배포
- SQLite의 바이너리는 그 자체로 완성되어 있으므로 배포를 위한 특별한 방법이 필요 없음
- 그냥 애플리케이션과 동일한 디렉토리에 넣으면 됨
- SQLite를 위한 고수준 바인딩
- 많은 언어에는 SQLite를 위한 고수준 바인딩이 라이브러리로 존재
- 이 라이브러리를 해당 언어를 위한 다른 데이터베이스 액세스 계층과 함께 사용할 수 있음
- 예를 들어 파이썬은 파이썬 인터프리터 기본 버전과 함께 SQLite 라이브러리를 표준 번들 요소로 제공
- SQLite를 사용하는 다양한 서드파티 ORM 및 데이터 계층이 있으므로 원시 SQL 문자열(불편할 뿐만 아니라 위험하기도 함)을 통해서만 SQLite에 액세스할 필요도 없음
- 재사용
- SQLite의 소스 코드는 공개돼 있으므로 실질적으로 아무런 제약 없이 다른 프로그램에서 재사용 가능
3. SQLite의 장점
1) 전통적인 테이블 지향 관계형 데이터베이스
SQLite는 트랜잭션과 원자성 동작을 지원하므로 프로그램 충돌이나 정전이 발생하더라도 데이터베이스가 손상되지 않는다.
2) 고급 데이터베이스에서 볼 수 있는 여러 기능
- 전체 텍스트 인덱싱, JSON 데이터 지원
- 반구조적인 형식(YAML, XML)으로 저장되는 애플리케이션 데이터는 SQLite 테이블로 저장할 수 있음
- 데이터에 더 쉽게 액세스하고 더 신속하게 처리 가능
3) 프로그램의 구성 데이터를 저장하는 빠르고 강력한 수단 제공
- YAML과 같은 파일 형식을 파싱하는 대신 SQLite를 이러한 파일의 인터페이스로 사용
- SQLite는 메모리 내 데이터로 작업하거나 외부 파일(CSV 파일 등)을 네이티브 데이터베이스 테이블처럼 사용할 수 있으므로 편리한 데이터 쿼리가 가능
4) 단일 독립형 바이너리
- SQLite는 단일 독립형 바이너리이므로 앱과 함께 배포하고 필요에 따라 앱과 함께 이동하기 쉬움
- SQLite에 의해 생성되는 각 데이터베이스 역시 하나의 파일로 구성
- SQL 명령으로 이 파일을 압축하거나 최적화 가능
4. SQLite vs MySQL
SQLite와 가장 자주 비교되는 대상은 MySQL(또는 마리아DB)이다. MySQL은 오늘날 애플리케이션 스택의 주된 요소로 광범위하게 사용되는 오픈 소스 데이터베이스 제품이다. SQLite와 MySQL은 비슷한 점 못지않게 차이점도 많으므로 각 사용 사례에 따라 적합한 쪽을 선택하면 된다.
1) 지원 데이터 형식
SQLite : 적음 (BLOB, NULL, INTEGER, TEXT)
비교적 적은 수의 데이터 형식을 저장하거나 데이터 계층을 사용하여 데이터 검증 시 유용MySQL : 많음 (날짜와 시간을 위한 전용 데이터 형식, 정수와 실수를 위한 다양한 정밀도 포함)
데이터 계층에서 자체 검증 및 정규화 기능을 제공하도록 하려면 MySQL(또는 마리아DB) 사용
2) 구성 및 튜닝
SQLite : 최소한의 구성 및 튜닝 옵션만 제공
MySQL : 콜레이션(collation), 인덱싱, 성능 튜닝 등 데이터베이스 및 설치 관련 구성 옵션이 다양함
MySQL이 훨씬 더 많은 기능을 제공한다. MySQL을 사용하는 경우 손을 댈 부분이 더 많지만, 그 이유는 대부분 애초에 MySQL을 사용해서 더 많은 일을 하고자 하기 때문
3) 단일 사용자 대 복수 사용자 데이터베이스
SQLite : 데스크톱 또는 모바일 앱과 같이 동시 사용자가 한 명인 애플리케이션에 가장 적합
MySQL : 여러 명의 동시 사용자에 대응하도록 설계, 클러스터 및 수평 확장 솔루션을 제공
5. SQLite가 적합하지 않은 경우
1) SQLite가 지원하지 않는 기능을 사용하는 앱
QLite는 여러 가지 관계형 데이터베이스 기능을 지원하지 않으며 많은 경우 앞으로도 지원할 예정이 없다. 대체로 코너 케이스에 해당하는 기능이지만, 그 기능이 필요하다면 사용할 수 없다.
2) 수평 확장 설계가 필요한 앱
SQLite 인스턴스는 단일체이며 독립적이고, 인스턴스 간 기본 동기화 기능이 없다. 또한 여러 개를 연합하거나 클러스터를 만들 수 없다. 따라서 수평 확장 설계를 사용하는 애플리케이션에서는 SQLite를 사용할 수 없다.
3) 여러 연결에서의 동시 쓰기 작업을 실행하는 앱
SQLite는 쓰기 작업 시 데이터베이스를 잠그므로 여러 동시 쓰기 작업이 실행되는 앱에서는 성능 문제가 발생할 수 있다. 다만 여러 동시 읽기 작업을 실행하는 앱은 대체로 빠르게 실행된다. SQLite 3.7.0 이상은 여러 쓰기 작업의 속도를 높이기 위한 로그 선행 기입(Write-Ahead Logging)을 제공하지만 몇 가지 제약이 따른다. 대안으로는 위에 언급한 버클리 DB가 있다.
4) 강한 데이터 형식 지정이 필요한 앱
SQLite의 데이터 형식은 비교적 소수다. 예를 들어 기본 datetime 형식이 없다. 따라서 애플리케이션에서 이러한 형식을 처리해야 한다. 애플리케이션이 아닌 데이터베이스에서 datetime 값을 위한 입력을 정규화하고 제약하고자 한다면 SQLite는 적합하지 않다.
🔗 관련 링크
SQLite와 MySQL의 차이점