ParadeDB, Tantivy 최적화로 BM25 벤치마크서 TIN 추월

ParadeDB가 PlanetScale의 TIN 확장 프로그램 벤치마크 주장에 대응하여, 초기 8배 성능 격차(ParadeDB 0.25 대비 TIN 우위)는 아키텍처 차이(ctid vs u32 DocId)가 아닌 최적화 부재와 벤치마크 이상 현상 때문임을 입증했다. StackExchange 데이터셋(1억 5천만 문서)을 활용해 Tantivy 내부 최적화로 격차를 해소했다.

주요 최적화

1. BM25 스코어링 시 랜덤 접근 감소

• 문제: Tantivy가 fieldnorms를 별도 배열에 저장해 Postgres에서 산발적 조회가 발생했다. Hacker News 데이터셋(2,870만 문서)에서 fieldnorms가 페이지 접근의 83%를 차지했다.
• 해결: fieldnorms 배열을 postings 리스트와 함께 DocId 순서로 순차 저장했다.
• 결과: fieldnorm 페이지 접근이 1,500에서 30으로 감소했다. 저장 공간은 약 9% 증가했으나, 짧은 postings 리스트를 가진 대부분의 용어에는 영향이 제한적이다.

2. Blockmax Pruning 알고리즘 선택

• 문제: 다중 용어 OR 쿼리에서 기본 Blockmax WAND 알고리즘의 CPU 오버헤드가 높았다.
• 해결: 3개 이상 용어와 dense postings가 포함된 OR 쿼리에는 MAXSCORE를, 그 외에는 WAND를 사용하는 휴리스틱을 구현했다.
• 결과: HN 벤치마크(10개 용어 OR 쿼리)에서 p50 지연은 약 6배, p95는 약 8배 개선됐다. 공정한 조건에서 ParadeDB는 344.6 QPS를 기록해 TIN의 145.7 QPS보다 2배 빨랐다.

벤치마크 공정성 및 정확성

ParadeDB는 PlanetScale의 원본 벤치마크에서 TIN에 유리했던 두 가지 의도치 않은 이상 현상을 발견했다.

• 구문 실수: 원본 테스트는 ParadeDB의 @@@ 파서를 사용하며 필드를 지정하지 않아 StackExchange에서 id와 body 열을 모두 검색했다. 반면 TIN은 하나만 검색했다. ParadeDB는 공정한 비교를 위해 네이티브 연산자(|||, &&&, ###)로 전환했다.
• Dense-term Elision: TIN은 코퍼스의 10% 이상에서 나타나는 용어에 대해 스코어링을 생략한다(dense_ratio=0.1). 이로 인해 순위가 부정확해져 쿼리의 47.8%에서 진짜 Top 10 결과 중 하나가 누락됐다. ParadeDB는 정확한 BM25 비교를 위해 elision을 비활성화했다(dense_ratio=2).

StackExchange Mixed Top K 결과 (1억 5천만 문서, 8 클라이언트, 5분):

• ParadeDB: 81.9 QPS
• ParadeDB (stopwords 활성화): 161.9 QPS
• TIN (elision 비활성화, dense_ratio=2): 35.5 QPS
• TIN (elision 활성화, dense_ratio=0.1): 114.4 QPS

문서 식별자 논쟁

ParadeDB는 컬럼형 통합을 위해 ctid보다 u32 DocId가 우수하다고 주장한다. ctid는 단순 스코어링에는 효율적이지만, 필드별 Top K, 범위 필터, 페이팅 같은 컬럼형 작업을 위해서는 추가 매핑이 필요하다. u32 DocId는 컬럼 행 인덱스에 직접 매핑되어 컬럼형 스토리지와의 통합이 용이하다.

릴리스 정보

• 버전: 재현을 위해 0.26.0-rc.2가 제공된다.
• 안정 릴리스: 다음 주 출시 예정.
• 조치 필요: 모든 최적화를 적용하려면 재색인(reindex)이 필요하지만, 업데이트는 하위 호환성을 유지한다.