turbopuffer v3는 벡터 중심 인덱스를 버리고 보조 ANN 인덱스를 채택합니다

TL;DR – turbopuffer v3는 벡터 중심 스토리지 레이아웃을 폐기합니다

turbopuffer v3는 ANN 인덱스를 기본 키가 아닌 보조 구조로 변경하여, 막대한 스토리지 및 쓰기 증폭을 제거하고 훨씬 더 큰 벡터화 처리 블록을 허용함으로써 벡터 검색, 전문 검색, 집계 및 기타 쿼리 계획의 속도를 높입니다.

turbopuffer가 스토리지 아키텍처를 재설계하는 이유

turbopuffer의 원래 설계(v1)는 각 문서를 ID + 벡터로 저장하고 ANN 주소(클러스터 + 로컬 ID)를 기본 키로 사용했습니다. 이는 객체 스토리지에서의 근사 최근접 이웃(ANN) 검색에 매우 효과적이었으며, 100B 개 이상의 벡터로 구성된 단일 인덱스에서 200ms p99 지연 시간과 1k QPS 이상의 성능을 가능하게 했습니다.

그러나 벡터 중심 레이아웃은 비벡터 워크로드에 대해 세 가지 치명적인 비효율성을 야기합니다:

스토리지 증폭 – 다중 벡터 문서(예: late-interaction 모델)는 각 벡터가 고유한 ANN 주소를 가지기 때문에 모든 속성 및 텍스트 페이로드를 벡터마다 중복 저장합니다.
쓰기 증폭 – 삽입, 업데이트 또는 삭제 시 SPFresh 벡터 재조정이 트리거되며, 이 과정에서 전체 문서 페이로드와 이전 ANN 주소를 가리키는 모든 역색인 항목이 이동합니다.
제한된 벡터화 – 최신 쿼리 엔진은 대규모 블록(수천 개의 행) 단위로 데이터를 처리합니다. ANN 주소가 블록 크기(클러스터당 약 100-200개 문서)를 결정하기 때문에, 다른 모든 쿼리 계획은 이러한 작은 블록으로 제한되어 전체 CPU 파이프라인 활용을 방해합니다.

이러한 문제들은 turbopuffer가 속성 필터링, 전문 검색, 집계 및 정규식 쿼리에서 최첨단 성능을 제공하는 것을 방해합니다.

turbopuffer 쿼리 기능의 진화

v1 – ID + 벡터 전용

계층적 클러스터링 인덱스(SPANN → SPFresh)는 벡터를 중심점 트리로 저장했습니다.
키는 ClusterId + LocalId(예: C0L1)였으며, 이것이 ANN 주소를 형성했습니다.

v2 – 속성 필터링 및 전문 검색

속성 값이나 용어를 ANN 주소에 매핑하는 역색인을 추가했습니다.
문서 속성을 벡터와 함께 동일한 ANN 키 아래에 저장했습니다.
BM25, 정규식, 퍼지 매칭, 희소 벡터 및 속성별 정렬을 지원했으며, 이 모든 것이 동일한 벡터 중심 레이아웃 위에 구축되었습니다.

핵심 문제: 기본 인덱스로서의 ANN

모든 문서의 페이로드가 ANN 주소 아래에 존재하기 때문에, 벡터 레이아웃이 변경될 때마다 관련된 모든 데이터의 연쇄적인 이동이 강제됩니다. 이 설계는 고전적인 MySQL 스타일의 기본 인덱스가 행을 가리키는 방식과 유사하며, 보조 인덱스가 안정적인 기본 키를 가리켜 업데이트 시 대규모 재작성을 방지합니다. 반면, PostgreSQL 스타일 설계는 보조 인덱스가 물리적 행 위치를 직접 가리키므로 읽기 시간 조회는 최적화되지만 막대한 쓰기 증폭 비용이 발생합니다.

turbopuffer의 원래 설계는 사실상 검색을 위한 PostgreSQL 모델이었습니다. 즉, 뛰어난 ANN 조회 성능을 제공하지만 쓰기 비용이 과도하고 다른 쿼리 형태에 대한 블록 크기가 제한적이었습니다.

turbopuffer v3의 해결책 – ANN을 보조 인덱스로 만들기

“ANN 주소를 키로 사용하지 마십시오” – turbopuffer v3는 ANN 주소 기본 키를 기존 문서 ID 기본 인덱스로 대체합니다. 이제 ANN 인덱스는 InnoDB의 보조 인덱스-기본 키 모델과 유사하게 문서 ID를 가리키는 보조 인덱스처럼 작동합니다.

예상되는 이점

스토리지 증폭 감소 – 문서 속성은 벡터 수와 관계없이 문서당 한 번만 저장됩니다.
쓰기 증폭 감소 – 벡터 재조정 시 전체 문서 페이로드나 역색인을 이동할 필요가 없으며, ANN 인덱스 항목만 업데이트하면 됩니다.
더 큰 벡터화 처리 블록 – 쿼리 엔진은 이제 집계, 정규식 및 전문 검색 점수 계산을 위해 수천 개의 행을 배치 처리할 수 있어 SIMD 및 더 나은 CPU 활용을 가능하게 합니다.
쿼리 지연 시간 개선 – 초기 벤치마크(예: FTS v2)에 따르면 포스팅 리스트가 ANN 클러스터에서 분리되었을 때 포스팅 리스트가 10배 작아지고 쿼리 속도가 최대 20배 빨라졌습니다. v3는 이러한 이득을 모든 쿼리 계획으로 확장하는 것을 목표로 합니다.

커뮤니티 반응 및 유사 사례

gopalv는 이 변화를 고전적인 Postgres와 MySQL의 트레이드오프에 비유하며, 안정적인 기본 키(MySQL 스타일)로 이동하는 것이 쓰기 측면의 증폭을 줄인다고 언급했습니다.
blakeashleyjr는 이 비유에 동의하며, 인덱스가 물리적 저장 위치를 가리키지 않도록 하는 것이 Uber가 PostgreSQL 쓰기 증폭에 대해 설명한 해결책과 동일하다고 강조했습니다.
Tsarp는 ANN이 보조 인덱스이고 행이 불변 조각(immutable fragments)에 존재하는 LanceDB의 접근 방식을 강조했으며, 이는 turbopuffer v3의 설계와 직접적으로 비교됩니다.
marekgalovic과 gk1은 “벡터 데이터베이스”가 마케팅 용어일 뿐이며, 진정한 변화는 벡터 중심 스토리지 레이아웃을 버리는 것이라고 주장했습니다.
sreekanth850과 peterpanhead는 별도의 벡터 저장소가 운영 복잡성을 가중시킨다고 지적하며, 완전한 기능을 갖춘 SQL 엔진 내에서의 네이티브 벡터 지원을 옹호했습니다.

turbopuffer v3의 다음 단계는 무엇인가요?

정확성 우선 – 팀은 새로운 스토리지 계층에서 100% CI 통과율을 달성했습니다.
성능 동등성 – 기존 ANN 성능 보장을 유지하면서 속도를 최적화함에 따라 향후 몇 주 내에 공개 벤치마크가 발표될 예정입니다.
롤아웃 계획 – 동등성에 도달한 후, turbopuffer v3는 프로덕션에 배포될 예정이며, 대규모 환경에서 더 빠른 벡터, 텍스트 및 집계 쿼리를 약속합니다.

결론

turbopuffer v3의 아키텍처 전환(ANN을 보조 인덱스로 만들고 안정적인 문서 ID 기본 키를 채택)은 비벡터 쿼리 성능을 제한하던 스토리지 및 쓰기 증폭 문제를 직접적으로 해결합니다. 검증된 데이터베이스 인덱싱 전략을 따름으로써, turbopuffer는 강력한 ANN 기능을 유지하면서 모든 쿼리 유형에 걸쳐 더 빠르고 확장 가능한 검색을 제공하는 것을 목표로 합니다.