2019.02.20

SQLite를 사용해야 하는 이유

Serdar Yegulalp | InfoWorld
모든 비즈니스 애플리케이션의 내부에는 구조적 데이터를 저장하고 사용하는 나름의 방법이 구현돼 있다. 클라이언트 측 앱이든 웹 프론트엔드를 사용하는 앱이든 에지 디바이스 앱이든 대부분의 경우 내장 데이터베이스가 필요하다.

이런 경우를 위해 설계된 SQLite는 내장 가능한 오픈소스 데이터베이스로, C로 작성됐으며 일반적인 SQL로 쿼리가 가능하다. SQLite는 킬로바이트의 데이터를 저장하든 수 기가바이트의 블롭(blob)을 저장하든 빠른 속도와 이식성, 안정성을 제공하도록 설계됐다.

ⓒ GettyImagesBank
 

SQLite의 사용 환경

SQLite의 가장 큰 장점 중 하나는 거의 어디에서나 실행 가능하다는 데 있다. SQLite는 윈도우, 맥OS, 리눅스, iOS, 안드로이드를 비롯한 다양한 플랫폼에 이식됐다. 특히 윈도우 사용자는 일반적인 Win32, UWP, WinRT, 닷넷용으로 사전 컴파일된 바이너리를 사용할 수 있다. 앱의 배포 대상이 무엇이든 십중팔구는 그 대상에 맞는 SQLite가 있거나 C 소스 코드를 해당 타겟으로 이식할 방법이 존재한다고 보면 된다.

SQLite를 사용하는 앱은 C로 작성된 외부 라이브러리를 바인딩하고 작업할 수 있는 수단이 있는 한 특정 언어로 작성하지 않아도 된다. SQLite의 바이너리는 그 자체로 완성되어 있으므로 배포를 위한 특별한 방법이 필요 없으며, 그냥 애플리케이션과 동일한 디렉토리에 넣으면 된다
.
많은 언어에는 SQLite를 위한 고수준 바인딩이 라이브러리로 존재한다. 또한 이 라이브러리를 해당 언어를 위한 다른 데이터베이스 액세스 계층과 함께 사용할 수 있다. 예를 들어 파이썬은 파이썬 인터프리터 기본 버전과 함께 SQLite 라이브러리를 표준 번들 요소로 제공한다. 또한 SQLite를 사용하는 다양한 서드파티 ORM 및 데이터 계층이 있으므로 원시 SQL 문자열(불편할 뿐만 아니라 위험하기도 함)을 통해서만 SQLite에 액세스할 필요도 없다.

마지막으로, SQLite의 소스 코드는 공개돼 있으므로 실질적으로 아무런 제약 없이 다른 프로그램에서 재사용할 수 있다.
 

SQLite의 장점

SQLite의 가장 일반적이며 대표적인 사용례는 전통적인 테이블 지향 관계형 데이터베이스 역할이다. SQLite는 트랜잭션과 원자성 동작을 지원하므로 프로그램 충돌이나 정전이 발생하더라도 데이터베이스가 손상되지 않는다.

SQLite에는 전체 텍스트 인덱싱, JSON 데이터 지원 등 고급 데이터베이스에서 볼 수 있는 여러 기능이 있다. 일반적으로 YAML 또는 XML과 같이 반구조적인 형식으로 저장되는 애플리케이션 데이터는 SQLite 테이블로 저장할 수 있으므로 데이터에 더 쉽게 액세스하고 더 신속하게 처리할 수 있다.

SQLite는 프로그램의 구성 데이터를 저장하는 빠르고 강력한 수단도 제공한다. 개발자는 YAML과 같은 파일 형식을 파싱하는 대신 SQLite를 이러한 파일의 인터페이스로 사용할 수 있다. 대부분의 경우 이 편이 수작업보다 훨씬 더 빠르다. SQLite는 메모리 내 데이터로 작업하거나 외부 파일(CSV 파일 등)을 네이티브 데이터베이스 테이블처럼 사용할 수 있으므로 편리한 데이터 쿼리가 가능하다.

SQLite는 단일 독립형 바이너리이므로 앱과 함께 배포하고 필요에 따라 앱과 함께 이동하기도 쉽다. SQLite에 의해 생성되는 각 데이터베이스 역시 하나의 파일로 구성되며 SQL 명령으로 이 파일을 압축하거나 최적화할 수 있다.

SQLite용 서드파티 바이너리 확장으로 더 많은 기능을 추가할 수 있다. SQLCipher는 SQLite 데이터베이스 파일에 256비트 AES 암호화를 추가한다. SQLite-Bloomfilter는 특정 필드의 데이터에서 블룸 필터를 생성할 수 있게 해준다.

그 외에도 많은 서드파티 프로젝트가 SQLite를 위한 부가적인 도구를 제공한다. 예를 들어 비주얼 스튜디오 코드 내에서 데이터베이스를 탐색할 수 있게 해주는 비주얼 스튜디오 코드 확장 또는, SQLite용 LiteCLI 인터랙티브 명령줄이 있다. 그 외에도 깃허브의 추천 SQLite 리소스 목록에서 많은 도구를 찾을 수 있다.
 

SQLite vs. MySQL

SQLite와 가장 자주 비교되는 대상은 MySQL(또는 마리아DB)이다. MySQL은 오늘날 애플리케이션 스택의 주된 요소로 광범위하게 사용되는 오픈 소스 데이터베이스 제품이다. SQLite와 MySQL은 비슷한 점 못지않게 차이점도 많으므로 각 사용 사례에 따라 적합한 쪽을 선택하면 된다.

- 데이터 형식
SQLite의 데이터 형식은 비교적 소수다(BLOB, NULL, INTEGER, TEXT). 반면 MySQL(또는 마리아DB)의 경우 날짜와 시간을 위한 전용 데이터 형식, 정수와 실수를 위한 다양한 정밀도를 비롯해 훨씬 더 많은 형식이 있다.

비교적 적은 수의 데이터 형식을 저장하거나 데이터 계층을 사용하여 데이터 검증을 수행하려면 SQLite가 유용하다. 그러나 데이터 계층에서 자체 검증 및 정규화 기능을 제공하도록 하려면 MySQL(또는 마리아DB)을 사용해야 한다.

- 구성 및 튜닝
SQLite에는 최소한의 구성 및 튜닝 옵션만 제공된다. SQLite의 내부 또는 명령줄 플래그는 대부분 극한 사례(edge case)나 하위 호환성 문제와 관련된다. 이는 간소함을 추구하는 SQLite의 원칙에도 부합한다. 즉, 대부분의 사용 사례에서는 기본 옵션으로 충분하다.

MySQL(또는 마리아DB)에는 콜레이션(collation), 인덱싱, 성능 튜닝 등 데이터베이스 및 설치 관련 구성 옵션이 까마득하게 많다. 옵션이 풍부한 만큼 MySQL이 훨씬 더 많은 기능을 제공한다. MySQL을 사용하는 경우 손을 댈 부분이 더 많지만, 그 이유는 대부분 애초에 MySQL을 사용해서 더 많은 일을 하고자 하기 때문이다.

- 단일 사용자 대 복수 사용자 데이터베이스
SQLite는 데스크톱 또는 모바일 앱과 같이 동시 사용자가 한 명인 애플리케이션에 가장 적합하다. MySQL과 마리아DB는 여러 명의 동시 사용자에 대응하도록 설계됐다. 또한 MySQL과 마리아DB는 클러스터 및 수평 확장 솔루션을 제공할 수 있지만 SQLite는 할 수 없다.
 

SQLite vs. 임베디드 베이스

SQLite 외에도 내장 가능한 데이터베이스는 많다. 비슷한 기능을 제공하는 데이터베이스도 여러 개 있지만 중점을 두는 사용 사례나 배포 모델은 각기 다르다.

- 아파치 더비(Apache Derby) : 내장 가능한 SQL 엔진이며 오라클이 자바 DB로 리패키징했다. 더비는 자바로 작성됐고 JVM이 필요하므로 주로 자바 앱에 내장하는 용도에 적합하다.

- 파이어버드 임베디드(Firebird Embedded) : 크로스 플랫폼이며 많은 고급 기능을 자랑하는 파이어버드 데이터베이스는 클라이언트 애플리케이션에 내장 가능한 라이브러리 형태로 제공된다. 기능은 SQLite와 비슷하지만 사용자 커뮤니티와 지원 기반은 SQLite 쪽이 훨씬 더 넓다.

- 렐름(Realm) : 고성능 관계형 데이터베이스로 모바일 환경, 주로 안드로이드에 맞게 설계됐지만 윈도우와 같은 데스크톱 환경도 지원할 수 있다. 단, 렐름은 객체 기반이며 SQL 쿼리를 사용하지 않는다. SQL을 사용하지 않는 편을 선호하는 경우 적합하지만 SQL이 익숙하고 편안한 사람에게는 적합하지 않다.

- 비스타DB(VistaDB) : 닷넷 런타임용 내장 데이터베이스다. 비스타DB는 닷넷의 다양한 변형에 맞는 여러 버전으로 제공되며, 전체 데이터베이스 암호화와 같은 엔터프라이즈 기능을 다수 제공한다. 오픈소스가 아닌 상용 제품이다.

- 버클리 DB(Berkeley DB) : 오라클 프로젝트로, 명목상 키/값 저장소지만 최근 버전에서는 SQL 쿼리를 처리하기 위한 방편으로 SQLite를 사용한다. 여러 개의 동시 쓰기 작업을 처리하는 기능 등 버클리 DB 기반 데이터베이스 엔진의 향상된 성능은 SQLite가 따라가지 못하는 부분이다.
 

SQLite가 적합하지 않은 경우

SQLite는 설계 원칙상 잘 맞는 시나리오와 그렇지 않은 시나리오가 뚜렷이 구분된다. SQLite가 적합하지 않은 경우는 다음과 같다.

- SQLite가 지원하지 않는 기능을 사용하는 앱. SQLite는 여러 가지 관계형 데이터베이스 기능을 지원하지 않으며 많은 경우 앞으로도 지원할 예정이 없다. 대체로 코너 케이스에 해당하는 기능이지만, 그 기능이 필요하다면 사용할 수 없다.

- 수평 확장 설계가 필요한 앱. SQLite 인스턴스는 단일체이며 독립적이고, 인스턴스 간 기본 동기화 기능이 없다. 또한 여러 개를 연합하거나 클러스터를 만들 수 없다. 따라서 수평 확장 설계를 사용하는 애플리케이션에서는 SQLite를 사용할 수 없다.

- 여러 연결에서의 동시 쓰기 작업을 실행하는 앱. SQLite는 쓰기 작업 시 데이터베이스를 잠그므로 여러 동시 쓰기 작업이 실행되는 앱에서는 성능 문제가 발생할 수 있다. 다만 여러 동시 읽기 작업을 실행하는 앱은 대체로 빠르게 실행된다. SQLite 3.7.0 이상은 여러 쓰기 작업의 속도를 높이기 위한 로그 선행 기입(Write-Ahead Logging)을 제공하지만 몇 가지 제약이 따른다. 대안으로는 위에 언급한 버클리 DB가 있다.

- 강한 데이터 형식 지정이 필요한 앱. SQLite의 데이터 형식은 비교적 소수다. 예를 들어 기본 datetime 형식이 없다. 따라서 애플리케이션에서 이러한 형식을 처리해야 한다. 애플리케이션이 아닌 데이터베이스에서 datetime 값을 위한 입력을 정규화하고 제약하고자 한다면 SQLite는 적합하지 않다.
editor@itworld.co.kr


2019.02.20

SQLite를 사용해야 하는 이유

Serdar Yegulalp | InfoWorld
모든 비즈니스 애플리케이션의 내부에는 구조적 데이터를 저장하고 사용하는 나름의 방법이 구현돼 있다. 클라이언트 측 앱이든 웹 프론트엔드를 사용하는 앱이든 에지 디바이스 앱이든 대부분의 경우 내장 데이터베이스가 필요하다.

이런 경우를 위해 설계된 SQLite는 내장 가능한 오픈소스 데이터베이스로, C로 작성됐으며 일반적인 SQL로 쿼리가 가능하다. SQLite는 킬로바이트의 데이터를 저장하든 수 기가바이트의 블롭(blob)을 저장하든 빠른 속도와 이식성, 안정성을 제공하도록 설계됐다.

ⓒ GettyImagesBank
 

SQLite의 사용 환경

SQLite의 가장 큰 장점 중 하나는 거의 어디에서나 실행 가능하다는 데 있다. SQLite는 윈도우, 맥OS, 리눅스, iOS, 안드로이드를 비롯한 다양한 플랫폼에 이식됐다. 특히 윈도우 사용자는 일반적인 Win32, UWP, WinRT, 닷넷용으로 사전 컴파일된 바이너리를 사용할 수 있다. 앱의 배포 대상이 무엇이든 십중팔구는 그 대상에 맞는 SQLite가 있거나 C 소스 코드를 해당 타겟으로 이식할 방법이 존재한다고 보면 된다.

SQLite를 사용하는 앱은 C로 작성된 외부 라이브러리를 바인딩하고 작업할 수 있는 수단이 있는 한 특정 언어로 작성하지 않아도 된다. SQLite의 바이너리는 그 자체로 완성되어 있으므로 배포를 위한 특별한 방법이 필요 없으며, 그냥 애플리케이션과 동일한 디렉토리에 넣으면 된다
.
많은 언어에는 SQLite를 위한 고수준 바인딩이 라이브러리로 존재한다. 또한 이 라이브러리를 해당 언어를 위한 다른 데이터베이스 액세스 계층과 함께 사용할 수 있다. 예를 들어 파이썬은 파이썬 인터프리터 기본 버전과 함께 SQLite 라이브러리를 표준 번들 요소로 제공한다. 또한 SQLite를 사용하는 다양한 서드파티 ORM 및 데이터 계층이 있으므로 원시 SQL 문자열(불편할 뿐만 아니라 위험하기도 함)을 통해서만 SQLite에 액세스할 필요도 없다.

마지막으로, SQLite의 소스 코드는 공개돼 있으므로 실질적으로 아무런 제약 없이 다른 프로그램에서 재사용할 수 있다.
 

SQLite의 장점

SQLite의 가장 일반적이며 대표적인 사용례는 전통적인 테이블 지향 관계형 데이터베이스 역할이다. SQLite는 트랜잭션과 원자성 동작을 지원하므로 프로그램 충돌이나 정전이 발생하더라도 데이터베이스가 손상되지 않는다.

SQLite에는 전체 텍스트 인덱싱, JSON 데이터 지원 등 고급 데이터베이스에서 볼 수 있는 여러 기능이 있다. 일반적으로 YAML 또는 XML과 같이 반구조적인 형식으로 저장되는 애플리케이션 데이터는 SQLite 테이블로 저장할 수 있으므로 데이터에 더 쉽게 액세스하고 더 신속하게 처리할 수 있다.

SQLite는 프로그램의 구성 데이터를 저장하는 빠르고 강력한 수단도 제공한다. 개발자는 YAML과 같은 파일 형식을 파싱하는 대신 SQLite를 이러한 파일의 인터페이스로 사용할 수 있다. 대부분의 경우 이 편이 수작업보다 훨씬 더 빠르다. SQLite는 메모리 내 데이터로 작업하거나 외부 파일(CSV 파일 등)을 네이티브 데이터베이스 테이블처럼 사용할 수 있으므로 편리한 데이터 쿼리가 가능하다.

SQLite는 단일 독립형 바이너리이므로 앱과 함께 배포하고 필요에 따라 앱과 함께 이동하기도 쉽다. SQLite에 의해 생성되는 각 데이터베이스 역시 하나의 파일로 구성되며 SQL 명령으로 이 파일을 압축하거나 최적화할 수 있다.

SQLite용 서드파티 바이너리 확장으로 더 많은 기능을 추가할 수 있다. SQLCipher는 SQLite 데이터베이스 파일에 256비트 AES 암호화를 추가한다. SQLite-Bloomfilter는 특정 필드의 데이터에서 블룸 필터를 생성할 수 있게 해준다.

그 외에도 많은 서드파티 프로젝트가 SQLite를 위한 부가적인 도구를 제공한다. 예를 들어 비주얼 스튜디오 코드 내에서 데이터베이스를 탐색할 수 있게 해주는 비주얼 스튜디오 코드 확장 또는, SQLite용 LiteCLI 인터랙티브 명령줄이 있다. 그 외에도 깃허브의 추천 SQLite 리소스 목록에서 많은 도구를 찾을 수 있다.
 

SQLite vs. MySQL

SQLite와 가장 자주 비교되는 대상은 MySQL(또는 마리아DB)이다. MySQL은 오늘날 애플리케이션 스택의 주된 요소로 광범위하게 사용되는 오픈 소스 데이터베이스 제품이다. SQLite와 MySQL은 비슷한 점 못지않게 차이점도 많으므로 각 사용 사례에 따라 적합한 쪽을 선택하면 된다.

- 데이터 형식
SQLite의 데이터 형식은 비교적 소수다(BLOB, NULL, INTEGER, TEXT). 반면 MySQL(또는 마리아DB)의 경우 날짜와 시간을 위한 전용 데이터 형식, 정수와 실수를 위한 다양한 정밀도를 비롯해 훨씬 더 많은 형식이 있다.

비교적 적은 수의 데이터 형식을 저장하거나 데이터 계층을 사용하여 데이터 검증을 수행하려면 SQLite가 유용하다. 그러나 데이터 계층에서 자체 검증 및 정규화 기능을 제공하도록 하려면 MySQL(또는 마리아DB)을 사용해야 한다.

- 구성 및 튜닝
SQLite에는 최소한의 구성 및 튜닝 옵션만 제공된다. SQLite의 내부 또는 명령줄 플래그는 대부분 극한 사례(edge case)나 하위 호환성 문제와 관련된다. 이는 간소함을 추구하는 SQLite의 원칙에도 부합한다. 즉, 대부분의 사용 사례에서는 기본 옵션으로 충분하다.

MySQL(또는 마리아DB)에는 콜레이션(collation), 인덱싱, 성능 튜닝 등 데이터베이스 및 설치 관련 구성 옵션이 까마득하게 많다. 옵션이 풍부한 만큼 MySQL이 훨씬 더 많은 기능을 제공한다. MySQL을 사용하는 경우 손을 댈 부분이 더 많지만, 그 이유는 대부분 애초에 MySQL을 사용해서 더 많은 일을 하고자 하기 때문이다.

- 단일 사용자 대 복수 사용자 데이터베이스
SQLite는 데스크톱 또는 모바일 앱과 같이 동시 사용자가 한 명인 애플리케이션에 가장 적합하다. MySQL과 마리아DB는 여러 명의 동시 사용자에 대응하도록 설계됐다. 또한 MySQL과 마리아DB는 클러스터 및 수평 확장 솔루션을 제공할 수 있지만 SQLite는 할 수 없다.
 

SQLite vs. 임베디드 베이스

SQLite 외에도 내장 가능한 데이터베이스는 많다. 비슷한 기능을 제공하는 데이터베이스도 여러 개 있지만 중점을 두는 사용 사례나 배포 모델은 각기 다르다.

- 아파치 더비(Apache Derby) : 내장 가능한 SQL 엔진이며 오라클이 자바 DB로 리패키징했다. 더비는 자바로 작성됐고 JVM이 필요하므로 주로 자바 앱에 내장하는 용도에 적합하다.

- 파이어버드 임베디드(Firebird Embedded) : 크로스 플랫폼이며 많은 고급 기능을 자랑하는 파이어버드 데이터베이스는 클라이언트 애플리케이션에 내장 가능한 라이브러리 형태로 제공된다. 기능은 SQLite와 비슷하지만 사용자 커뮤니티와 지원 기반은 SQLite 쪽이 훨씬 더 넓다.

- 렐름(Realm) : 고성능 관계형 데이터베이스로 모바일 환경, 주로 안드로이드에 맞게 설계됐지만 윈도우와 같은 데스크톱 환경도 지원할 수 있다. 단, 렐름은 객체 기반이며 SQL 쿼리를 사용하지 않는다. SQL을 사용하지 않는 편을 선호하는 경우 적합하지만 SQL이 익숙하고 편안한 사람에게는 적합하지 않다.

- 비스타DB(VistaDB) : 닷넷 런타임용 내장 데이터베이스다. 비스타DB는 닷넷의 다양한 변형에 맞는 여러 버전으로 제공되며, 전체 데이터베이스 암호화와 같은 엔터프라이즈 기능을 다수 제공한다. 오픈소스가 아닌 상용 제품이다.

- 버클리 DB(Berkeley DB) : 오라클 프로젝트로, 명목상 키/값 저장소지만 최근 버전에서는 SQL 쿼리를 처리하기 위한 방편으로 SQLite를 사용한다. 여러 개의 동시 쓰기 작업을 처리하는 기능 등 버클리 DB 기반 데이터베이스 엔진의 향상된 성능은 SQLite가 따라가지 못하는 부분이다.
 

SQLite가 적합하지 않은 경우

SQLite는 설계 원칙상 잘 맞는 시나리오와 그렇지 않은 시나리오가 뚜렷이 구분된다. SQLite가 적합하지 않은 경우는 다음과 같다.

- SQLite가 지원하지 않는 기능을 사용하는 앱. SQLite는 여러 가지 관계형 데이터베이스 기능을 지원하지 않으며 많은 경우 앞으로도 지원할 예정이 없다. 대체로 코너 케이스에 해당하는 기능이지만, 그 기능이 필요하다면 사용할 수 없다.

- 수평 확장 설계가 필요한 앱. SQLite 인스턴스는 단일체이며 독립적이고, 인스턴스 간 기본 동기화 기능이 없다. 또한 여러 개를 연합하거나 클러스터를 만들 수 없다. 따라서 수평 확장 설계를 사용하는 애플리케이션에서는 SQLite를 사용할 수 없다.

- 여러 연결에서의 동시 쓰기 작업을 실행하는 앱. SQLite는 쓰기 작업 시 데이터베이스를 잠그므로 여러 동시 쓰기 작업이 실행되는 앱에서는 성능 문제가 발생할 수 있다. 다만 여러 동시 읽기 작업을 실행하는 앱은 대체로 빠르게 실행된다. SQLite 3.7.0 이상은 여러 쓰기 작업의 속도를 높이기 위한 로그 선행 기입(Write-Ahead Logging)을 제공하지만 몇 가지 제약이 따른다. 대안으로는 위에 언급한 버클리 DB가 있다.

- 강한 데이터 형식 지정이 필요한 앱. SQLite의 데이터 형식은 비교적 소수다. 예를 들어 기본 datetime 형식이 없다. 따라서 애플리케이션에서 이러한 형식을 처리해야 한다. 애플리케이션이 아닌 데이터베이스에서 datetime 값을 위한 입력을 정규화하고 제약하고자 한다면 SQLite는 적합하지 않다.
editor@itworld.co.kr


X