S3에서 250ms 미만의 콜드 JOIN 쿼리를 제공하는 SQLite VFS 'Turbolite' 등장!
'Turbolite'는 Rust로 구현된 SQLite VFS(Virtual File System)로, S3에서 직접 콜드 쿼리를 실행하여 250ms 미만의 응답 시간(Response Time)을 달성함
B-tree 기반의 페이지 그룹화, 압축, 그리고 쿼리 계획(Query Plan)을 활용한 선행 다운로드(Frontrunning)를 통해 성능을 최적화함
커뮤니티에서는 데이터 격리 아키텍처(Data Isolation Architecture)를 위한 'database-per-tenant' 아키텍처에 적합하다는 평가와 함께, 단일 쓰기(Single Writer) 제약에 대한 논의가 진행됨
S3 Express 및 Tigris와 같은 스토리지 백엔드(Storage Backend)에 따라 성능 차이가 발생하며, 튜닝(Tuning)의 중요성이 강조됨
Turbolite의 아키텍처 및 성능 최적화
Turbolite는 S3의 제약 사항을 고려하여 설계되었으며, B-tree(B-tree) 구조를 분석하여 페이지를 그룹화하고 압축한다. 특히, 페이지 그룹(Page Group)을 통해 S3 요청 수를 최소화하고, 쿼리 계획을 활용하여 필요한 데이터를 미리 다운로드하는 선행 다운로드(Frontrunning) 방식을 사용한다. 벤치마크 결과에 따르면, S3 Express 환경에서 콜드 포인트 조회는 77ms, 5-JOIN 쿼리는 188ms의 응답 시간을 보였다.
S3 스토리지 백엔드(Storage Backend)에 따른 성능 차이
Turbolite의 성능은 S3 백엔드(Backend)의 지연 시간에 크게 의존한다. S3 Express는 낮은 지연 시간을 제공하여 포인트 쿼리에 유리하며, Tigris와 같은 다른 백엔드는 더 높은 지연 시간을 갖는다. S3 Express에서는 튜닝의 효과가 작지만, Tigris와 같은 고지연 환경에서는 튜닝을 통해 성능 향상을 기대할 수 있다. 따라서, 스토리지 백엔드(Storage Backend)의 특성을 고려한 튜닝 전략이 필요하다.
데이터 격리 아키텍처(Data Isolation Architecture)를 위한 Turbolite
Turbolite는 데이터베이스-당-테넌트(database-per-tenant) 아키텍처와 같이, 다수의 독립적인 데이터베이스를 관리하는 환경에 적합하다. 이는 각 테넌트(Tenant)에 별도의 볼륨(Volume)을 할당하는 대신, S3를 사용하여 데이터 격리 아키텍처(Data Isolation Architecture)를 구현할 수 있기 때문이다. 하지만, 현재는 단일 쓰기(Single Writer) 환경만을 지원하므로, 다중 쓰기 환경에서의 데이터 일관성(Data Consistency) 확보 방안에 대한 추가적인 연구가 필요하다.
커뮤니티의 다양한 의견 및 관련 프로젝트
커뮤니티에서는 Turbolite와 유사한 기능을 제공하는 다양한 프로젝트가 언급되었다. Graft는 ZStd 압축을 사용하고, Litestream은 WAL(Write-Ahead Log)을 S3로 전송하는 방식을 사용한다. 또한, sqlite_web_vfs와 sqlite_zstd_vfs의 조합은 Turbolite의 읽기 경로와 유사한 기능을 제공한다. 이러한 프로젝트들을 통해, SQLite-over-network 기술의 발전과 다양한 데이터 격리 아키텍처(Data Isolation Architecture)에 대한 가능성을 엿볼 수 있다.
