GN⁺: SQLite에 관한 재미있는 사실들
(avi.im)-
SQLite는 가장 많이 배포되고 사용되는 데이터베이스임
- 1조 개 이상의 SQLite 데이터베이스가 사용 중이며, 세 명의 사람이 유지 관리함
- 외부 기여를 허용하지 않음
-
SQLite는 다른 모든 데이터베이스 엔진을 합친 것보다 더 많이 사용됨
- 수십억 개의 SQLite 복사본이 존재하며, 어디에나 있음
-
SQLite는 가장 많이 배포된 소프트웨어 모듈 중 하나임
-
Hwaci는 SQLite를 개발한 회사이며, 음악에도 관심이 있음
-
SQLite는 미국 전함에서 시작됨
- D. Richard Hipp(DRH)는 USS Oscar Austin이라는 해군 구축함을 위한 소프트웨어를 개발 중이었음
- 서버가 다운될 때마다 기존 소프트웨어가 작동을 멈추는 문제가 있었음
- DRH는 서버 없이도 작동하는 데이터베이스를 구상함
-
SQLite는 법적 의미에서 오픈 소스가 아님
- 오픈 소스는 특정 정의와 OSI의 승인을 받은 라이선스가 필요함
- 대신 SQLite는 퍼블릭 도메인에 속하며, 오픈 소스 라이선스보다 제한이 적음
-
외부 기여를 허용하지 않음
- 초대받은 사람만 기여 가능하며, 기여는 퍼블릭 도메인에 헌신해야 함
-
SQLite의 테스트 코드
- SQLite의 코드 한 줄당 600줄 이상의 테스트 코드가 존재함
- 테스트는 라이브러리의 모든 분기를 100% 커버함
-
일부 SQLite 테스트는 독점적임
- TH3라는 테스트 스위트는 독점적이며, 접근하려면 SQLite 컨소시엄에 가입해야 함
-
SQLite의 비즈니스 모델
- 유료 지원, 유지보수 서비스, 컨소시엄 멤버십, 상업적 확장을 통해 수익을 창출함
-
SQLite는 행동 강령 대신 윤리 강령을 가짐
-
SQLite는 매우 빠르며, 일부 사용 사례에서는 파일 시스템보다 35% 빠름
-
SQLite는 단일 작성자 모델을 가짐
- 여러 작성자를 동시에 허용하지 않음
-
다른 데이터베이스와의 차이점
- 기본적으로 롤백 저널 모드를 사용하며, 외래 키는 비활성화 상태임
- 약한 타입을 사용하며, 강한 타입은 선택 사항임
-
SQLite는 타입이 없다는 점이 불편함
- 타입 제약 없이 데이터를 삽입할 수 있음
-
SQLite는 호환성을 매우 중요시함
- 모든 SQLite 3 버전은 초기 버전의 데이터베이스 파일을 읽고 쓸 수 있음
-
SQLite의 저자인 DRH는 기존 버전 관리 시스템이 적합하지 않다고 판단하여 Fossil을 개발함
-
DRH는 비행기에서 TAOCP 책의 알고리듬을 기반으로 B-Tree를 코딩함
-
SQLite의 발음은 "Ess-Cue-El-Lite"로 권장되지만, 공식적인 가이드는 없음
SQLite는 생각보다 빠른 DB는 아닙니다. 이제는 지원 중단된 MongoDB Realm이 훨씬 빠릅니다. 사람들에게 속도는 그렇게 중요한 선택 요인은 아니었던 것 같습니다.
왜 Realm이 빠르냐고 질문을 하고 근거를 요청하신 분이 있는데 MongoDB가 지원 중단을 하며 글을 삭제한 것 같네요.
그래서 한 때 일했던 입장에서 기억나는 기술적인 이유를 설명해드리려고 합니다. 가장 큰 이점은 Realm이 SQLite 대비해 더 적은 메모리를 사용하고 캐쉬 히트율이 높았던 점이 가장 큰 이유였다고 생각됩니다.
Realm은 기본적으로 사용하는 사이즈를 기반으로 메모리에 저장되는 용량을 선택합니다. 그래서 사용자가 큰 사이즈의 자료형을 선택하더라도 수 비트의 작은 사이즈로 직렬화를 하는 경우가 많습니다. 실제로 사용자가 더 큰 자료를 쓰는 경우에 컨버전을 합니다.
Realm은 같은 자료형끼리 묶어서 인접해서 저장합니다. 사용자는 테이블의 모든 데이터에 접근하지 않고 일부 데이터를 연속으로 접근 하는 경우가 많습니다. 위에 이야기했던 적은 사이즈의 인코딩 때문에 한번에 캐쉬에서 찾을 수 있는 데이터가 훨씬 더 많아지겠죠.
Realm은 POJO 객체에 hydrate를 하지 않고 getter와 setter에서 필요할 때 자료를 전달하는 형식입니다. 이를 위해 자바의 경우에는 바이트 코드 수준에서 조작을 합니다. Protobuf와 같은 자료형이 그 당시 Meta의 Facebook 앱 클라이언트에 쓰였던 이유가 이 hydrate 과정이 성능상의 큰 단점이 되고 필요한 데이터만 접근하는게 이점이 있기 때문입니다.
Realm은 SQLite에 비해서 대부분의 시나리오에서 훨씬 빨랐지만 이 부분이 시장에서 큰 요인은 아니었다고 생각합니다.
Realm의 가장 큰 경쟁자는 Facebook에서 만들었던 파스였던 것으로 기억을 합니다. 그 이후에는 Google의 Firebase가 경쟁자가 되었고요. 이 둘은 로컬 모바일 데이터베이스는 아니고 원격에 데이터를 간단하게 저장할 수 있는 서비스입니다. 어떻게 Realm의 경쟁자가 이 둘이 될 수 있냐 싶지만 실제 유저는 그냥 어디든 저장하면 되고 속도는 크게 중요하지는 않았던 것 같습니다.
그리고 이후 에릭슨이 투자하게 되며 Realm의 범위는 축소되었습니다. 에릭슨은 Realm이 iOS에서 어느 정도 점유를 하고 있는데 더 기능 개발하는 것을 이해하지 못했습니다. 그리고 동기화 솔루션으로서의 가치를 더 인정했고요. 이후 MongoDB에 Realm은 합병되었습니다.
이것도 중요한 이유중 하나로 생각합니다. Realm은 스레드 로컬 기반으로 사용법을 제공했고, 자동 업데이트를 제공했으며, 다른 스레드에서 새로 질의를 하면 매우 적은 비용으로 같은 데이터를 전달한다고 이야기했고, 다른 스레드로 자료를 전달하지 말 것을 권고했지만 이런 이야기를 설명하기는 쉽지 않았습니다.
Hacker News 의견
-
OSI가 오픈 소스의 기준이 아니라는 의견이 있음. OSI의 오픈 소스 정의는 유용하지만 비판과 논란이 있음. SQLite는 법적으로 오픈 소스가 아니라고 하는 것은 잘못된 주장임
- OSI의 승인에 의존하는 것은 바람직하지 않음. OSI 승인 라이선스 목록은 실용적이고 정치적인 역사만을 반영함
- SQLite가 오픈 소스인지에 대한 논란이 있음. 공공 도메인 헌신은 라이선스가 아니기 때문에 OSD를 충족하지 않지만, 더 개방적임
-
블로그가 인기 주제에 대한 재활용된 오래된 포인트를 사용하여 조회수와 참여를 유도하려는 시도로 보임
- 블로그의 이전 게시물은 기술적 깊이가 부족하고 과장된 내용이 많음
-
SQLite는 행동 강령(CoC)이 아닌 윤리 강령(CoE)을 가지고 있음. CoC는 외부 기여자의 행동을 제어하기 위한 도구로 사용되며, CoE는 SQLite 개발자가 다른 사람에게 의도한 행동을 선언하는 것임
-
SQLite의 발음에 대한 혼란이 있음. "Ess-Cue-El-Lite"로 발음된다고 하지만, "S-Q-L-ite"로 발음하는 사람도 있음
-
SQLite는 선택적으로 엄격한 테이블을 지원함.
CREATE TABLE name (stuff TEXT) STRICT를 사용하여 타입을 강제할 수 있음 -
SQLite는 SQL 데이터베이스일 뿐만 아니라 NoSQL 데이터베이스로도 사용 가능함. JSON 컬럼을 사용하여 데이터를 저장하는 방식이 유용함
-
Richard Hipp와 함께 프로젝트를 진행한 경험이 있음. 그는 지원 계약을 통해 안정적인 수익을 얻고 있음
-
SQLite의 한 릴리스에서 많은 마이크로 최적화를 통해 성능이 50% 향상됨
-
SQLite를 빠른 프로토타이핑과 로그 덤프에 사용하지만, 멀티 라이터를 원할 때 어려움이 있음. 이는 SQLite를 벗어나게 되는 주요 이유 중 하나임
-
SQLite는 단일 작성자 모델을 가지고 있음. Redis도 단일 스레드 모델임
-
SQLite의 재미있는 사실 중 하나는 사용자들이 개발자에게 밤중에 전화를 걸기 시작했을 때 기본 접두사를 sqlite_에서 etilqs_로 변경해야 했던 일임