개인적인 경험을 자기 목소리로 쓰는 즐거움이 없다면, 굳이 그 경험을 글로 쓰는 이유가 무엇인지?
D1을 운영 환경에서 사용해 봤는데, 신뢰성이 그리 높지 않음. D1 개발자 중 한 명도 HN에서 D1은 Durable Objects 위에 SQL 인터페이스를 씌운 래퍼라고 밝힌 적이 있음.
그 설명에 따르면 거의 언제나 D1보다 Durable Objects 저장소를 직접 쓰는 편이 나음. 전역 데이터베이스 하나만 필요하더라도 싱글턴 Durable Object로 구현하는 편이 낫다고 함. D1 자체가 결국 SQLite 데이터베이스를 API로 노출하는 싱글턴 Durable Object에 불과하기 때문임.
[1] https://news.ycombinator.com/item?id=48611834.
SQLite 계열의 기능을 한데 갖춘 프로젝트가 있을까? sqlite처럼 내장할 수 있고, dqlite처럼 클러스터를 구성하며, rqlite처럼 독립 실행 노드를 제공하는 것을 찾고 있음.
여기에 litestream처럼 S3로 백업할 수 있고, CP뿐 아니라 cr-sqlite처럼 AP도 선택적으로 지원하면 좋겠음.
직접 만드는 https://github.com/punnerud/mpedb는 아직 그 수준은 아니며, sqlite3·Postgresql·Oracle 간 동기화에 집중하고 있음. sqlite3에서도 Postgresql 수준의 속도로 동시 쓰기가 가능하다는 것을 보여 줌.
재미있게 읽다가, 마지막에 저자가 누가 설계도를 그렸는지 역사에 확실히 남기려는 대목에서 흥이 식었음.
그 정도는 정당하다고 봄. VC 투자를 받은 SQLite 서비스들이 마치 자신들이 처음 고안한 것처럼 홍보해 왔으니, 균형을 맞추는 정도임.
역사를 너무 최근부터 서술한다는 말도 맞음. 최근 5년을 넘어 더 오래된 흐름을 짚는 글이 늘어나면 좋겠음. 데이터베이스는 20년 이상 거슬러 올라갈 수 있는 경우가 많고, 여러 사람이 독립적으로 아이디어를 떠올린 과정과 이후 어떻게, 왜 발전했는지를 읽는 데 가치가 있음.
내게 선을 넘은 부분은 정직함을 내세운 대목임. 12년이나 매달린 일인데, 그 역사를 다루는 천 단어짜리 글조차 직접 쓰지 않는 건 꽤 이상함.
rqlite 클라이언트 라이브러리 하나를 유지보수하고 있는데, 훌륭한 개념을 정말 잘 구현한 프로젝트라고 느낌. 특히 JSON으로 결과를 반환해서 .NET에서 Dapper 같은 방식의 매핑을 아주 쉽게 할 수 있다는 점이 마음에 듦. 다른 언어에서도 비슷할 것으로 보임.
지금껏 자세히 살펴본 적은 없었는데, 대부분의 클러스터형 데이터베이스 아키텍처보다 훨씬 간단해 보임. https://rqlite.io/
제어 계층에 사용 중이며, 지금까지는 꽤 만족함.
최신 Rails는 운영 환경의 선택지로 SQLite도 권장하는 것으로 알고 있음. 다만 동시 접근을 어떻게 처리하는지 이해가 안 돼서, 한번 살펴봐야겠음.
테넌트마다 SQLite를 하나씩 쓰거나, GitHub에 있는 새로운 다중 쓰기 라이브러리를 살펴볼 수 있음.
WAL이나 WAL2가 도움이 될 수 있음.
개발 중인 오픈소스 관측 가능성 솔루션 morio.it의 제어 영역 데이터베이스로 rqlite를 선택해 운영 환경에서 사용하고 있음. 정말 훌륭해서 적극 추천함. Philip은 유난히 헌신적이고 친절하며 도움을 아끼지 않는 유지보수자임. 별 다섯 개를 주고 싶고, 딱히 흠잡을 부분이 없음.
SQLite의 hctree도 있음.
마침 필요한 글임. 작은 클러스터에서 dqlite를 운영 중인데, 더 안정적인 대안으로 옮기려 함. 이 정도 규모에서는 무엇을 추천하는지?