DuckDB Full-Text Search vs PostgreSQL FTS vs Meilisearch: 1억 문서 인덱스 — Build Time, Query Latency, Memory

Source: Dev.to

테스트 설정: 실제 워크로드, 실제 하드웨어

• 코퍼스: 1억 개의 Reddit 댓글 (~50 GB 원시 텍스트, 14.8 GB 압축 Parquet)
• 서버: Hetzner AX‑52 (AMD Ryzen 7 7700, 64 GB RAM, 2 × 1 TB NVMe)
• 쿼리: 실제 검색 로그에서 추출했으며, 단순 매치, 다중 단어 구문, 퍼지 매치, 불리언 쿼리 네 가지 유형을 포함합니다.
• 버전: DuckDB 1.1, PostgreSQL 17.4, Meilisearch 1.10 – 각각 성능에 맞게 튜닝되었습니다.

주요 발견 1: 인덱스 구축 시간 — DuckDB의 놀라운 성능

• DuckDB: 38분 (PostgreSQL보다 2.4배 빠름)
• PostgreSQL: 91분
• Meilisearch: 44분

DuckDB의 장점은 컬럼형 I/O와 파이프라인 토큰화에 있습니다—Parquet 파일에서 인덱싱된 컬럼(body)만 읽어 불필요한 데이터 이동을 피합니다. PostgreSQL은 GIN 인덱스를 만들기 전에 행을 힙 페이지에 적재해야 하므로 I/O 오버헤드가 두 배가 됩니다.

Meilisearch는 빠르긴 하지만 인덱싱 중 29 GB RAM에 도달했으며, 이는 작은 규모 배포에서는 부담이 될 수 있습니다. PostgreSQL은 GIN 인덱스 덕분에 증분 업데이트(새 문서 100만 개에 14초)에서 뛰어난 성능을 보였으며, DuckDB는 컬럼형 아키텍처 덕분에 전체 재구축보다 부분 업데이트가 더 저렴했습니다.

주요 발견 2: 쿼리 지연 시간 — 특화가 중요

• PostgreSQL의 성숙한 쿼리 플래너는 단순 불리언 쿼리에서 뛰어납니다.
• DuckDB는 퍼지 및 분석 쿼리를 장악하며, 빠른 컬럼형 스캔과 집계를 활용해 “검색을 분석 원시 연산으로” 활용하기에 이상적입니다.
• Meilisearch는 최고의 오타 허용 순위를 제공하지만, 단일 샤드 설계 때문에 대규모에서는 어려움을 겪는 것으로 보입니다.

주요 발견 3: 자원 효율성 — DuckDB의 디스크 이점

• DuckDB 인덱스: 압축된 컬럼형 저장 덕분에 Meilisearch보다 약 3배 작습니다.
• PostgreSQL GIN 인덱스: DuckDB보다 크지만 Meilisearch보다 더 컴팩트합니다.

디스크 용량이 제한된 환경에서는 DuckDB의 작은 발자국이 결정적인 요인이 될 수 있습니다.

결론: 보편적인 승자는 없음

전체 분석과 추가 예시 및 벤치마크는 novvista.com에서 전체 기사를 읽어보세요.

원본은 NovVista에서 게시되었습니다.