Gravity, ClickHouse보다 최대 3배 빠른 쿼리 엔진을 만들다
Programming at Light Speed: Building the Gravity Query Engine
pgrust v0.4-beta의 새로운 쿼리 엔진 Gravity는 ClickHouse가 자사 성능을 자랑하려고 만든 ClickBench에서 최대 3배 빠른 속도를 기록했다. Postgres SQL 전체 방언과 타입 시스템을 지원하면서도 이룬 성과다. 팀은 기존 엔진을 조금씩 개선하는 대신 하드웨어와 파일 포맷의 물리적 한계에서 출발해 역으로 설계했고, Claude가 작성한 손수 최적화된 Rust 코드와 비교해 20% 이내로 따라잡는 것을 목표로 삼았다. Gravity는 SQL 쿼리를 Postgres 플랜, 파이프라인 그래프, Lisp IR, 어셈블리로 단계적으로 내리는 컴파일러 파이프라인이다.
우리는 스스로에게 물었다. 데이터베이스는 도대체 얼마나 빨라질 수 있을까? 기존 쿼리 엔진을 점진적으로 빠르게 하는 대신, 우리는 하드웨어와 파일 포맷의 물리적 속도 한계에서 출발해 거꾸로 작업하고 싶었다. 나는 이것을 '빛의 속도로 프로그래밍하기'라고 부른다.
- landhar
> 보통 엔지니어들이 소프트웨어를 더 빠르게 만들려고 할 때는 상향식으로 작업합니다. 벤치마크를 돌리고, 플레임그래프를 보고, 핫스팟을 찾아서 코드를 15%나 20% 빠르게 만드는 방법을 찾아내죠. 상향식으로 작업할 때의 문제는 한계가 어디인지 모른다는 겁니다. 하드웨어가 낼 수 있는 최고 속도에서 20% 차이일 수도 있고, 100배 차이일 수도 있죠.
> Gravity를 만들기 시작했을 때, 우리는 이 질문을 뒤집었습니다. 스스로에게 물었죠: 데이터베이스는 실제로 얼마나 빨라질 수 있을까? 기존 쿼리 엔진을 점진적으로 빠르게 만드는 대신, 하드웨어와 파일 포맷의 물리적 속도 한계에서 시작해서 거꾸로 작업하고 싶었습니다. 저는 이걸 "광속 프로그래밍"이라고 부르고 싶습니다.
코드를 최적화하는 "보통" 접근법이라고 묘사된 것은 사실상 "순진한" 접근법에 더 가깝습니다. 진지한 성능 최적화 작업이라면 누구든 먼저 하드웨어가 허용하는 한계가 무엇인지 정의하고 그것에 대고 벤치마크하는 접근법을 따를 겁니다. 그리고 그건 LLM 이전에도 이미 사실이었죠.
예를 들어: https://www.marginalia.nu/log/a_106_native_calls/
사소한 것에 트집 잡는 것 같아 죄송하지만, 다른 독자들이 이 접근법의 이 부분이 새롭지 않다는 맥락을 파악하는 데 도움이 될 것 같아서요. 그들이 Claude를 사용해 최적화된 벤치마크를 생성한 것은 그 자체로 이미 충분히 흥미롭기 때문에, 글에서 이 부분에 굳이 더 주목할 필요는 없다고 느낍니다.
- cube2222
최근에 뉴스가 된 clickbench 관련 다소 낙담스러운 일 이후로, 이 블로그 글은 정말 멋지다고 말하지 않을 수 없네요.
Claude로 이 문제를 해결하기 위해 문제를 구조화하는 훌륭한 방법을 찾으신 것 같습니다(글을 클릭하지 않은 분들을 위해 말하자면 - 각 쿼리에 대해 수작업/Claude 최적화 Rust 코드를 작성하고, 그 어셈블리를 확인하고, 자체 옵티마이저가 동일한 어셈블리에 가깝게 생성하도록 시도하는 것), 그리고 글도 매우 흥미롭고 읽기 쉽습니다!
수고하셨습니다, 이런 블로그 글이 더 나오길 기대합니다.
- agumonkey
pgrust 팀원들은 역사적으로 리스퍼였나요?