SQLite에 Raft를 얹은 첫 오픈소스, 12년 뒤의 자리
Twelve Years of Distributed SQLite
2014년 Philip O'Toole이 SQLite 앞에 Raft 로그를 두어 쓰기를 클러스터에 복제하는 rqlite를 공개했다. 당시 아무도 하지 않던 조합이었지만 지금은 '분산 SQLite'가 하나의 카테고리가 됐다. dqlite, Litestream, cr-sqlite, libSQL, Cloudflare D1까지 각기 다른 설계가 등장했고, 자본과 인수는 서비스형 플랫폼으로 흘러갔다. 저자는 12년간의 흐름을 직접 겪은 사람으로서 정리한다.
인프라 아이디어의 흔한 운명이고 나는 개의치 않는다. 다만 누군가 그것을 팔기 전까지 이 아이디어가 8년 동안 오픈소스였다는 사실은 기록해 둘 만하다.
HN 토론
51- piterrro
프로덕션에서 D1을 써봤는데 - 그다지 신뢰할 만하지 않습니다. HN에 D1 개발자 중 한 명이 남긴 댓글이 있었는데 [1], D1은 durable objects 위에 얹힌 SQL 래퍼로, 분산된 sqlite의 특성을 흉내 내는 것이라고 하더군요.
> 약간의 더러운 비밀을 하나 알려드리죠:
거의 항상 D1보다 Durable Objects 스토리지를 쓰는 게 낫습니다. 단일 글로벌 데이터베이스만 원하더라도, D1을 쓰는 것보다 그걸 싱글턴 Durable Object로 구현하는 게 낫습니다. 왜냐하면 D1 자체가 실제로 그게 전부이기 때문입니다: 자신의 SQLite 데이터베이스에 API를 노출하는 싱글턴 Durable Object죠. 그냥 래퍼일 뿐입니다.
- AgentME
rqlite와 Litestream을 비롯한 여러 프로젝트 간의 비교가 흥미로웠습니다. (rqlite는 노드 간 합의 알고리즘을 사용해 동기화를 유지하고 프라이머리 노드를 바꿀 수 있게 하는 반면, Litestream은 그냥 자기 자신을 S3에 동기화해서 다른 노드가 그곳의 데이터로 인계받을 수 있게 합니다.)
글쓴이가 곧 D1으로 넘어가서, Cloudflare Durable Objects(D1의 기반)와 S3에 쓰는 Cloudflare Durable Objects의 오픈소스 재구현인 celld 사이의 관계가 거의 비슷하다는 점을 언급할 거라고 완전히 예상했습니다. 그런데 글은 갑자기 아주 비꼬는 듯한 무관심으로 D1을 다루더니, 마지막 섹션은 어색하게도 rqlite를 방어하는 느낌이 듭니다.
- mmnfrdmcx
sqlite와 그 단순함을 사랑하는 사람으로서, 에이전트와 함께라면 postgres를 관리하는 게 극도로 쉽다는 걸 알게 되고 있고, postgres의 모든 SQL 기능을 갖는 게 정말 좋습니다 -- sqlite는 많은 SQL에서 꽤 제한적이죠. 그래서 원격 sqlite니 뭐니를 고민하고 있다면, 그냥 데이터베이스 서버를 쓰기에 지금보다 더 좋은 때는 없는 것 같습니다.
물론 sqlite는 로컬 도구 등에는 훌륭합니다.
- vikrantrathore
재밌네요, 제가 part time parliament 논문(paxos)을 읽으면서 zig와 odin 언어를 배우던 중 순수 paxos 라이브러리를 만들었고, 그 라이브러리의 첫 번째 응용이 멀티마스터 sqlite를 만드는 것이었습니다. 제가 택한 두 접근은 매우 다른데, zig의 경우 zaxonlite(https://github.com/insanai/zaxonlite)를 만들었고 rqlite를 포함한 벤치마크가 있습니다. 전략으로 WAL 복제를 사용합니다. odin으로 시도한 두 번째는 sqlodin(https://github.com/insanai/sqlodin)인데, 이 시스템은 WAL을 쓰지 않고 각 노드에서 sql 쿼리를 실행하며, 그 결과 sqlite의 일부 sql 쿼리는 지원되지 않습니다.
- Kinrany
이 모든 걸 함께 하는 프로젝트가 있을까요?
- sqlite처럼 임베더블
- dqlite처럼 클러스터링
- rqlite처럼 독립 노드 보유
- litesteeam처럼 S3에 백업 가능
- 선택적으로 CP와 함께 cr-sqlite처럼 AP