Limbo - Rust로 완전히 새롭게 작성된 SQLite
(turso.tech)- Limbo는 메모리 안전성을 제공하는 Rust로 SQLite를 재구현하는 실험적 프로젝트
- SQLite의 임베디드 특성을 좋아하지만, 더 개방적인 개발 모델을 원해 libSQL 프로젝트 시작
- SQLite를 포크한 이유: 새로운 기능을 쉽게 통합할 수 있고, 기존 코드와의 호환성 유지 가능
- 단점: SQLite의 테스트 스위트가 독점적이고 C로 작성되어 있어 코드 진화가 어려움
- 새로운 접근 방식
- 벡터 검색 기능 추가를 통해 SQLite의 한계를 경험
- SQLite를 처음부터 다시 작성하여 호환성을 유지하면서도 더 공격적인 기능 추가 가능성 탐색
- 다음 단계
- Limbo를 공식 Turso 프로젝트로 전환
- SQLite와 동일한 신뢰성을 유지하면서 메모리 안전성을 제공하는 새로운 아키텍처 구축 목표
- SQLite의 신뢰성에 도전
- 결정론적 시뮬레이션 테스트(DST)를 통해 높은 신뢰성 확보
- Antithesis와 협력하여 시스템 수준의 DST 프레임워크 사용
- 현재 상태
- 완전 비동기 I/O: Limbo는 완전 비동기 설계로, SQLite의 동기 인터페이스 문제 해결
- WASM을 위한 설계: WASM 환경에서의 사용을 고려한 설계
- 성능: 많은 작업에서 SQLite와 동등하거나 더 빠른 성능
- 단순성: 현대 환경에 덜 중요한 기능 제거로 더 나은 사용자 경험 제공
- 추가 정보
- Limbo는 MIT 라이선스로 GitHub에서 제공
- SQLite의 약속을 다음 단계로 발전시키고자 하는 임베디드 데이터베이스 구축에 관심 있는 사람들을 초대함
GeekNews Weekly에 포함된 글입니다.
에디터 코멘트 보기
댓글과 토론
Hacker News 의견
-
SQLite는 코드 품질과 엄격한 테스트로 인해 재작성할 필요가 없는 프로젝트로 보임
- 다른 C 코드가 먼저 재작성되면 좋겠다는 의견이 있음
-
SQLite가 "오픈 기여"가 아니라는 논의는 기여를 받는다는 것이 항상 기여를 수용한다는 의미가 아님을 간과함
- SQLite는 기여를 위한 절차가 있으며, 제안된 기능을 구현하는 방식임
- Litestream과 LiteFS 같은 SQLite 생태계의 다른 프로젝트들도 비슷한 기여 정책을 가짐
-
SQLite3에서 LibSQL로의 포크 초기 발표에 대해 부정적이었음
- SQLite3의 테스트 스위트가 독점적이기 때문에 포크가 실패할 가능성이 높다고 생각했음
- 그러나 메모리 안전 언어로의 재작성과 같은 큰 제품이 있다면 포크가 의미가 있다고 봄
-
최대 성능을 위해 WAL 모드를 선택해야 하며, POSIX 권고 잠금을 비활성화해야 함
- "wal2" 모드가 프로젝트의 레이더에 있는지 궁금해하는 의견이 있음
-
SQLite의 테스트 스위트가 독점적이라는 사실을 처음 알았다는 의견이 있음
- Android가 비슷한 방식으로 구축되었지만, 이는 다른 문제임
-
"async IO" 섹션의 논리를 받아들이지 않음
- SQLite에 비동기 인터페이스를 추가하기 위해 재작성할 필요가 없다고 봄
- SQLite의 동기 인터페이스 문제는 IO를 기다리는 동안 스레드가 유휴 상태로 남는 것임
- SQLite는 저장소에 매우 가깝게 실행되도록 설계되어 IO 차단이 매우 짧거나 없을 수 있음
-
초기 단계에 있는 프로젝트라는 의견이 있음
- Python과 Limbo를 사용한 코드 예시가 제공됨
-
Fil-C로 컴파일하면 메모리 안전한 SQLite를 얻을 수 있음
- 약간의 변경만 필요하며, 테스트 스위트를 거의 통과함
-
SQLite는 약 156,000줄의 코드와 92,000줄의 테스트 코드로 구성되어 있음
-
Rust 변형의 DO-178B 인증은 고려되지 않는 것으로 추정됨
-
"Limbo"라는 이름은 AT&T의 Inferno 운영 체제를 위한 포스트-C/UNIX 언어에서도 사용됨