개발자

"가볍고 빠르다" SQL라이트 기초 다지기

Serdar Yegulalp | InfoWorld 2024.05.24
대부분 비즈니스 애플리케이션에는 구조적 데이터를 저장하고 사용하는 방법이 내장돼 있다. 웹 프론트 엔드를 사용하는 클라이언트 측 앱이든 엣지 디바이스 앱이든 비즈니스 애플리케이션에는 데이터베이스가 필요하다. 대부분은 임베디드 데이터베이스로 충분하다. 임베디드 데이터베이스는 가볍고 작고 이동이 가능하며, 일부 애플리케이션에서는 전통적인 서버보다 더 나은 선택이 되기도 한다. 

SQL라이트(SQLite)는 C로 작성된 오픈소스 데이터베이스로, 임베딩이 가능하고 일반적인 SQL로 쿼리할 수 있다. SQL라이트는 몇 킬로바이트의 데이터부터 몇 기가바이트의 블롭에 이르기까지 무엇을 저장하든 빠르고 이동 가능하며 안정적으로 작동하도록 설계됐다. 여기서는 SQL라이트를 언제, 어디서 사용해야 하는지, 마이SQL, 마리아DB 및 기타 인기 있는 임베디드 데이터베이스와 같은 대안과 비교할 때 장단점은 무엇인지 살펴본다. 
 
ⓒ Getty Images Bank


SQL라이트의 용도는? 

SQL라이트의 가장 일반적이고 명확한 사용례는 전통적인 테이블 지향 관계형 데이터베이스다. SQL라이트는 트랜잭션과 원자적 동작을 지원하므로 프로그램 충돌은 물론 정전이 발생해도 데이터베이스가 손상되는 일은 없다. 또한 전체 텍스트 인덱싱, 대용량 데이터베이스 지원(최대 281테라바이트, 최대 행 크기 1GB) 등 고급형 데이터베이스에서 찾아볼 수 있는 여러가지 기능도 갖췄다. 

SQL라이트는 프로그램의 구성 데이터를 저장하는 빠르고 강력한 수단도 제공한다. 개발자는 JSON 또는 YAML과 같은 파일 형식을 파싱하는 대신 SQL라이트를 파일에 대한 인터페이스로 사용할 수 있으며, 많은 경우 이런 방법은 수동으로 파일을 다루는 방법보다 속도가 훨씬 더 빠르다. SQL라이트는 인메모리 데이터 또는 외부 파일(CSV 파일 등)을 네이티브 데이터베이스 테이블처럼 다룰 수 있으므로 데이터를 편리하게 쿼리할 수 있다. 또한 JSON 데이터를 기본 지원하므로 데이터를 JSON으로 저장하거나 인플레이스(in-place) 쿼리할 수 있다. 


SQL라이트의 이점

SQL라이트에는 플랫폼 및 언어 이동성을 비롯한 많은 이점이 있다. SQL라이트를 사용할 때 얻는 주요 혜택은 다음과 같다. 
 
  • 크로스 플랫폼 : SQL라이트의 가장 큰 장점은 거의 어디서나 실행이 가능하다는 점이다. SQL라이트는 윈도우, 맥OS, 리눅스, iOS, 안드로이드를 비롯한 다양한 플랫폼에 이식됐다. 특히 윈도우 사용자는 일반적인 Win32, UWP, WinRT, 닷넷을 위한 사전 컴파일된 바이너리를 사용할 수 있다. 앱의 배포 대상이 무엇이든 대부분은 그 대상을 위한 SQL라이트 버전이 있거나 C 소스 코드를 그 대상으로 이식할 방법이 있다. 
  • 프로그래밍 언어 대부분과 호환 : SQL라이트를 사용하는 애플리케이션은 C로 작성된 외부 라이브러리를 바인딩하고 다룰 방법만 있다면 특정 언어로 작성될 필요가 없다. SQL라이트의 바이너리는 독립적이므로 배포하기 위해 따로 필요한 요소가 없다. 그냥 애플리케이션과 같은 디렉터리에 집어넣기만 하면 된다. 
  • 파이썬과의 조합 : 많은 언어에는 SQL라이트를 위한 고수준 바인딩이 라이브러리로 있고, 이를 언어의 다른 데이터베이스 액세스 계층과 함께 사용할 수 있다. 예를 들어 파이썬은 SQL라이트 라이브러리를 파이썬 인터프리터 기본 버전과 함께 표준 요소로 제공한다. 또한 서드파티에서도 SQL라이트를 사용하는 다양한 ORM과 데이터 계층을 만들었으므로 원시 SQL 문자열을 통한 SQL라이트 액세스에 묶이지 않는다(이 방법은 불편할 뿐만 아니라 잠재적으로 위험하기도 함). 
  • 독립형 : SQL라이트는 하나의 독립적인 라이브러리이므로 손쉽게 앱과 함께 배포하고 필요에 따라 옮길 수 있다. 또한 SQL라이트에 의해 생성되는 각 데이터베이스는 하나의 파일로 구성되며, SQL 명령을 사용해서 이 파일을 압축하거나 최적화할 수 있다. 
  • 서드파티 확장 : SQL라이트를 위한 서드파티 바이너리 확장은 기능의 범위를 더 넓혀준다. SQL사이퍼(SQLCipher)는 SQL라이트 데이터베이스 파일에 256비트 AES 암호화를 추가한다. sqlean은 SQL라이트의 기본 기능을 확장해서 UUID 생성, 정규식 대조 등 기본적으로는 제공되지 않는 많은 기능을 추가한다. 
  • 폭넓은 툴 : 다른 많은 서드파티 프로젝트가 SQL라이트를 위한 부가적인 툴을 제공한다. 예를 들어, 비주얼 스튜디오 코드 내에서 데이터베이스 탐색을 가능하게 해주는 비주얼 스튜디오 코드 확장, 또는 SQL라이트를 위한 LiteCLI 인터랙티브 명령줄이 있다. 깃허브의 선별된 SQL라이트 리소스 목록에서 그 외에도 많은 옵션을 찾아볼 수 있다. 
  • 오픈소스 : 마지막으로, SQL라이트의 소스 코드는 공개되어 있으므로 다른 프로그램에서 사실상 아무 제한 없이 재사용할 수 있다. 


SQL라이트 vs. 마이SQL 

SQL라이트는 마이SQL과 자주 비교된다. 널리 사용되는 마이SQL은 현대 애플리케이션 스택의 대표적인 요소로 꼽히는 오픈소스 데이터베이스다. SQL라이트와 마이SQL은 비슷한 부분이 많지만 사용례에 따라 각자의 이점이 뚜렷하게 나뉜다. 또 다른 인기 있는 데이터베이스로 SQL라이트과 종종 비교되는 마리아DB도 마찬가지다. 

데이터 형식 
SQL라이트의 기본 데이터 형식은 BLOB, NULL, INTEGER, REAL, TEXT로, 비교적 적다. 마이SQL과 마리아DB에는 날짜와 시간, 다양한 정밀도의 정수와 부동 소수점 등을 위한 전용 데이터 형식이 있다. 

저장하는 데이터 형식의 수가 비교적 적거나 데이터 계층을 사용해서 데이터에 대한 검증을 수행하려는 경우 SQL라이트가 유용하다. 그러나 데이터 계층이 자체적인 검증 및 정규화를 제공하기를 원한다면 마이SQL 또는 마리아DB를 선택해야 한다. 

구성과 튜닝 
SQL라이트의 구성과 튜닝 옵션은 최소한으로 제공된다. 내부 또는 명령줄 플래그는 가장자리 사례 또는 하위 호환성을 처리한다. 이는 단순함이라는 SQL라이트의 전체적인 철학과도 부합한다. 대부분의 일반적인 사용례에서는 기본 옵션을 사용하면 된다.  

마이SQL과 마리아DB는 세부적인 데이터베이스 및 설치별 구성 옵션(콜레이션, 인덱싱, 성능 튜닝, 스토리지 엔진 등)을 제공한다. 풍부한 옵션을 제공하는 이유는 훨씬 더 많은 기능을 제공한다는 데 있다. 조정하는 데 손이 더 많이 가겠지만 이는 애초에 더 많은 작업을 하고자 하기 때문일 가능성이 높다. 

단일 사용자 vs. 다중 사용자 데이터베이스 
SQL라이트는 예를 들어 데스크톱 애플리케이션이나 모바일 앱과 같이 한 명의 동시 사용자가 있는 애플리케이션에 가장 적합하다. 마이SQL과 마리아DB는 여러 동시 사용자를 처리하도록 설계됐다. 또한 이 둘은 클러스터링된 스케일 아웃 솔루션을 제공하는 반면 SQL라이트는 그렇지 않다. 

마이SQL 또는 마리아DB를 직접적으로 대체하는 정도는 아니지만 SQL라이트에 확장 기능을 추가해주는 프로젝트도 있다. 캐노니컬(Canonical)은 클러스터로 스케일 아웃이 가능하도록 설계된 자체 SQL라이트 버전인 dqlite를 만들었다. 데이터는 래프트(Raft) 알고리즘을 통해 노드 전반에서 일관성을 유지한다. 또한 dqlite 배포에 따르는 관리 오버헤드는 SQL라이트보다 아주 약간 더 높은 수준이다. 


SQL라이트 vs. 임베디드 데이터베이스 

SQL라이트 외에도 임베딩이 가능한 데이터베이스는 많다. 다양한 데이터베이스가 비슷한 기능을 제공하지만 각자 중점을 두는 사용례 또는 배포 모델은 다르다. 
 
  • 아파치 더비(Apache Derby) : 임베딩 가능한 SQL 엔진이며, 오라클이 자바 DB로 리패키징하기도 했다. 아파치 더비는 자바로 만들어졌고 JVM이 필요한 만큼 자바 앱 임베딩이 주 용도다. 
  • 파이어버드 임베디드(Firebird Embedded) : 많은 고급 기능을 자랑하는 크로스 플랫폼 파이어버드 데이터베이스는 클라이언트 애플리케이션에 임베딩할 수 있는 라이브러리로 제공된다. SQL라이트와 비슷한 기능을 제공하지만 사용자 커뮤니티와 지원 기반은 SQL라이트 쪽이 훨씬 더 크다. 
  • 렘(Realm) : 모바일 환경(주로 안드로이드)에 맞게 설계됐으면서 윈도우와 같은 데스크톱 환경도 지원할 수 있는 고성능 관계형 데이터베이스다. 다만 렘은 객체 지향이며 SQL 쿼리를 사용하지 않는다. SQL을 멀리하는 사람에게는 좋지만 SQL이 친숙하고 편안한 사람에게는 좋지 않은 점이다. 렘은 현재 몽고DB 프로젝트이며, "그 자체로는 안정적이고 지원되는 API를 갖춘 '최종 사용자' 제품이 아니라는 점"에 유의해야 한다. 
  • 비스타DB(VistaDB) : 닷넷 런타임을 위한 임베디드 데이터베이스다. 비스타DB는 닷넷의 다양한 변형에 맞는 버전이 제공되며, 전체 데이터베이스 암호화와 같은 다수의 기업용 기능을 갖췄다. 그러나 오픈소스가 아니며 상용 제품이다. 
  • 버클리 DB(Berkeley DB) : 오라클 프로젝트이며, 명목상 키/값 쌍 저장소지만 최근 버전에서는 SQL 쿼리를 처리하기 위한 수단으로 SQL라이트를 사용한다. 버클리 DB의 기반 데이터베이스 엔진의 강화된 성능은 SQL라이트가 따라갈 수 없다. 예를 들어 여러 개의 쓰기 작업을 동시에 처리할 수 있다. 버클리 DB는 사용 사례에 따라 GNU 아페로(Affero) GPL 3, 또는 상용 라이선스의 이중 라이선스 구조를 갖고 있다. 


SQL라이트의 한계 

SQL라이트는 설계상 잘 맞는 시나리오가 있고 그렇지 않은 시나리오가 있다. 다음과 같은 환경에서는 SQL라이트가 적절하지 않다. 
 
  • SQL라이트가 지원하지 않는 기능을 사용하는 앱 : SQL라이트는 다양한 관계형 데이터베이스 기능을 지원하지 않으며, 많은 경우 지원하려고 시도도 하지 않는다. 상당수는 예외적인 경우지만 그 예외적인 경우로 인해 사용이 불가능할 수 있다. 
  • 스케일 아웃 설계가 필요한 앱 : SQL라이트 인스턴스는 독립적인 단일 인스턴스로, 인스턴스 간의 기본 동기화가 없으며 함께 페더레이션하거나 클러스터를 구성할 수도 없다. 스케일 아웃 설계를 사용하는 모든 소프트웨어 애플리케이션은 SQL라이트를 사용할 수 없다. 위에서 언급했듯이 일부 써드 파티에서 SQL라이트를 확장해 이러한 기능을 추가했지만 이는 SQL라이트의 기본 설계가 아니다. 
  • 여러 연결에서의 동시 쓰기 작업이 있는 앱 : SQL라이트는 쓰기 작업을 위해 데이터베이스를 잠근다. 따라서 여러 동시 쓰기가 포함된 모든 작업은 성능 문제를 유발할 수 있다. 다만 여러 동시 읽기 작업이 있는 앱은 대체로 빠르다. SQL라이트 3.7.0 이상은 쓰기 전 로깅(Write-Ahead Logging) 모드를 제공해서 여러 쓰기 작업의 속도를 높이지만 여기에는 몇 가지 제약이 따른다. 대안으로 위에서 언급한 버클리 DB를 고려할 만하다. 
  • 강력한 데이터 형식 지정이 필요한 앱 : SQL라이트에는 데이터 형식이 비교적 적다. 예를 들어 기본 날짜시간 형식이 없다. 따라서 애플리케이션이 대부분의 형식을 강제해야 한다. 애플리케이션이 아닌 데이터베이스에서 날짜시간 값에 대한 입력을 정규화하고 제한하려는 경우 SQL라이트는 적합하지 않다. 
editor@itworld.co.kr
 Tags SQL라이트
Sponsored

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.