▲

더 빠른 SQLite를 찾아서

 (avi.im)
2P by GN⁺ 4달전 | ★ favorite | 댓글 1개
  • SQLite는 이미 빠른 데이터베이스 시스템이지만, 연구자들은 이를 더 빠르게 만들 수 있는 방법을 찾는중
  • 헬싱키 대학교와 케임브리지의 연구자들이 "비동기 I/O를 통한 서버리스 런타임/데이터베이스 공동 설계"라는 논문을 발표하며, 꼬리 지연(latency)을 최대 100배 줄일 수 있음을 보여줌. 이 논문은 Rust로 다시 작성된 SQLite인 Limbo의 기초가 됨.

io_uring

  • io_uring 설명: Linux 커널의 io_uring 서브시스템은 비동기 I/O를 위한 인터페이스를 제공함. 이는 사용자 공간과 커널 공간 사이의 링 버퍼를 통해 버퍼 복사 오버헤드를 줄임. 애플리케이션은 I/O 요청을 제출하고, OS로부터 I/O 작업 완료 알림을 받을 때까지 다른 작업을 수행할 수 있음.

  • SQLite의 쿼리 실행: SQLite는 데이터 저장에 파일을 사용하며, sqlite3_open() 함수로 데이터베이스를 열고, sqlite3_prepare() 함수로 SQL 문을 바이트코드로 변환함. sqlite3_step() 함수는 바이트코드 명령을 실행하여 쿼리를 처리함.

전제

  • 서버리스 컴퓨팅의 부상: 서버리스 환경에서 데이터베이스 지연이 문제로 작용할 수 있음. 데이터베이스를 엣지 런타임에 직접 내장하면 지연이 없으며, SQLite는 이러한 환경에 적합함.

  • SQLite의 문제점: 동기 I/O 사용으로 인해 리소스 사용이 최적화되지 않으며, 동시성과 다중 테넌시 문제를 야기함.

  • io_uring으로의 전환: POSIX I/O 호출을 io_uring으로 대체하는 것은 간단하지 않으며, SQLite를 비동기 I/O 모델에 맞게 재설계해야 함.

Limbo

  • 비동기 I/O 지원: VM과 BTree 구성 요소를 수정하여 비동기 I/O를 지원하고, 동기 바이트코드 명령을 비동기 명령으로 대체함. 비동기 I/O는 블로킹을 제거하고 동시성을 향상시킴.

  • 쿼리와 저장소 엔진의 분리: 리소스 사용을 극대화하기 위해 쿼리 엔진과 저장소 엔진을 분리하는 것을 제안함.

평가 및 결과

  • 벤치마킹: 멀티 테넌트 서버리스 런타임을 시뮬레이션하여 각 테넌트가 자체 내장 데이터베이스를 갖도록 함. SQLite와 Limbo의 쿼리 지연을 비교한 결과, Limbo는 p999에서 꼬리 지연을 100배 줄임.

  • 미래 작업: 여러 독자와 작성자를 포함한 추가 벤치마크를 계획 중이며, p999 이후에서만 성능 이점이 두드러짐.

  • 오픈 소스 코드: Limbo의 코드는 오픈 소스로 제공됨: Limbo GitHub

▲
GN⁺ 4달전  [-]
Hacker News 의견

  • 서버리스 컴퓨팅의 특정 사용 사례, 예를 들어 AWS Lambda와 중앙 데이터베이스가 서버리스 방식으로 구성된 앱과 항상 잘 맞지 않는다는 점에 대한 논의가 있음

    • 6-7년 전 복잡한 계층적 파일을 처리하고 특정 정보를 추출해야 했던 문제를 해결하기 위해 작업한 경험이 있음
    • FaaS는 계산적으로 비싼 작업에 비싸며, 큰 XML 파일을 로드하고 매번 파싱하는 것은 비효율적이었음
    • 해결책으로 타이머로 파일을 읽고 파싱하여 SQLite 데이터베이스에 로드하고 인덱싱한 후 S3에 파일을 저장하는 중앙 기능을 사용했음
    • Lambda 함수는 S3에서 파일을 다운로드하여 로컬 복사본보다 최신이거나 콜드 스타트 시 조회를 수행했음
    • Lambda에는 로컬 /tmp 디렉토리가 있으며 Python 런타임에 SQLite가 포함되어 있어 함수 외에 코드를 업로드할 필요가 없음을 알게 되었음
    • 이러한 솔루션이 더 빨라질 수 있는 작업이 진행 중인 것에 대해 흥미로움을 느낌

  • 두 명의 연구자 중 한 명이 저자의 상사라는 점을 명시할 가치가 있을 수 있음

    • 저자와 연구자가 관련이 없다고 잘못 생각했음

  • "p999 이상에서만 이점이 눈에 띄며, p90과 p99에서는 성능이 SQLite와 거의 동일함"이라는 점에 동의함

    • SQLite와 최적화를 좋아하지만 이 점은 사실임

  • SQLite는 광범위한 테스트 스위트를 가지고 있어 철저히 테스트됨

    • 리라이트가 유사한 테스트를 받을 것인지, 특히 io_uring과 같은 빠르지만 작성하기 어렵고 잠재적으로 버그가 있는 기능을 사용하는 경우에 대해 의문이 있음

  • 벤치마킹을 위해 각 테넌트가 자체 임베디드 데이터베이스를 갖는 멀티 테넌트 서버리스 런타임을 시뮬레이션함

    • SQLite는 테넌트당 자체 스레드를 가지며 각 스레드에서 쿼리를 실행하여 측정함
    • 서버리스 SQLite 설정이 요청당 SQLite 프로세스를 사용할 것인지에 대한 의문이 있음

  • 이전에 Postgres에 비동기 io를 도입하려는 시도가 있었으나 중단됨

    • 최근 제안은 코드베이스를 포크하지 않고도 스토리지 관리자를 사용자 정의로 교체할 수 있게 하는 것임
    • 새로운 제안에 많은 관심이 있으며, 스토리지와 컴퓨팅을 분리하는 움직임과 관련이 있음

  • 비동기 io가 작동 중일 때 다른 작업을 수행할 수 있다는 아이디어에 대한 질문이 있음

    • 데이터베이스 작업 시 트랜잭션 완료를 기다려야 하는지에 대한 의문이 있음

  • 블로그 게시물의 저자로서 이 글이 첫 페이지에 올라온 것을 예상하지 못했음

    • Turso에서 일하며, 논문은 2024년 4월에 발표되었고 이후 많은 개선이 이루어졌음

  • SQLite는 오픈 소스이지만 중요한 테스트 하네스는 아님

    • 대안이 호환성을 어떻게 보장할 것인지에 대한 질문이 있음

  • SQLite 파일 형식의 엄격한 하위 집합으로 JSON 유사 형식을 만드는 간단한 경로를 찾으려 했으나 실패함

    • 파일 형식의 임의성이 많아 흥미를 잃었으나, 다른 사람이 성공할 수 있을 것임
답변달기