▲

GN⁺: Apache Lucene에서 영감을 받은 Tantivy 풀텍스트 검색 엔진 라이브러리

 (github.com/quickwit-oss)
1P by neo 2달전 | favorite | 댓글 1개

Rust로 작성된 빠른 전체 텍스트 검색 엔진 라이브러리

소개

  • Tantivy는 Apache Lucene의 디자인을 강하게 참고한 검색 엔진 라이브러리임.
  • Elasticsearch나 Apache Solr의 대안으로 사용할 수 있는 Quickwit라는 분산 검색 엔진도 있음.
  • Tantivy는 검색 엔진 서버가 아니라 검색 엔진을 구축할 수 있는 크레이트임.

벤치마크

  • 다양한 쿼리/컬렉션 유형에 대한 성능 벤치마크 제공.
  • 쿼리의 성격과 부하에 따라 성능이 달라질 수 있음.

주요 기능

  • 전체 텍스트 검색: 다양한 언어에 대한 토크나이저 지원.
  • 빠른 성능: 빠른 시작 시간과 멀티스레드 인덱싱 지원.
  • BM25 스코어링: Lucene과 동일한 스코어링 방식.
  • 자연어 쿼리: 복잡한 쿼리도 자연스럽게 처리 가능.
  • 구간 쿼리 및 계층적 패싯 필드: 다양한 데이터 타입 지원.
  • 압축된 문서 저장소: LZ4, Zstd 등 다양한 압축 방식 지원.
  • JSON 필드 및 집계 수집기: 히스토그램, 범위 버킷, 평균 및 통계 메트릭 지원.

비기능

  • 분산 검색은 Tantivy의 범위 밖임. 분산 검색이 필요하면 Quickwit을 참고할 것.

시작하기

  • Tantivy는 안정적인 Rust에서 작동하며 Linux, macOS, Windows를 지원함.
  • tantivy-cli: 검색 엔진을 쉽게 만들고 인덱싱 및 검색을 할 수 있는 명령줄 인터페이스 제공.
  • 참고 문서: 최신 릴리스 버전에 대한 참고 문서 제공.

프로젝트 지원 방법

  • Tantivy를 사용하고 경험을 공유.
  • 버그 리포트 제출.
  • 블로그 포스트 작성.
  • 문서화에 도움.
  • 코드 기여.

코드 기여

  • GitHub Pull Request 워크플로우 사용.
  • 기여 시 GitHub 티켓 참조 및 포괄적인 커밋 메시지 작성.

FAQ

  • 다른 언어 지원: Python, Ruby 등 다양한 언어 바인딩 제공.
  • 사용 예시: seshat, tantiny, lnx 등 다양한 프로젝트에서 사용.
  • 속도 비교: Lucene보다 약 2배 빠름.
  • 증분 인덱싱 지원: 예.
  • 문서 편집: 문서는 불변. 삭제 후 재인덱싱 필요.
  • 인덱싱 중 검색 가능 시점: commit 호출 후 검색 가능.

GN⁺의 의견

  • Rust 기반의 빠른 성능: Rust의 성능과 안전성을 활용한 빠른 검색 엔진으로, 성능이 중요한 프로젝트에 적합함.
  • 다양한 언어 지원: Python, Ruby 등 다양한 언어 바인딩을 통해 여러 환경에서 사용 가능.
  • 증분 인덱싱: 대규모 데이터 처리 시 유용한 기능.
  • 문서 불변성: 데이터 일관성을 유지하지만, 문서 수정 시 재인덱싱 필요.
  • Quickwit과의 연계: 분산 검색이 필요한 경우 Quickwit을 함께 사용하면 좋음.
▲
neo 2달전  [-]
Hacker News 의견

  • 프로젝트 경험 공유: 오래된 Python2 AppEngine 코드베이스를 대체하기 위해 이 라이브러리를 사용하여 <a href="https://progscrape.com" rel="nofollow">progscrape.com</a>을 재구축했음. 라이브러리는 매우 빠르고, Raspberry Pi에서 1M 스토리를 몇 초 만에 인덱싱할 수 있었음. CPU 사용률이 매우 낮고, 검색 성능도 뛰어남.

  • ParadeDB와 Tantivy: 최근 ParadeDB(Postgres 확장)에서 Tantivy를 발견했음. 고성능 분석을 위해 Postgres를 확장하는 데 사용됨.

  • Quickwit와 Clickhouse: 다국어 검색 프로젝트에서 Quickwit와 Clickhouse의 결합된 성능이 매우 좋았음. 특히 중국어, 일본어, 한국어 검색에 유용했음.

  • to_tsvector의 한계: PostgreSQL의 to_tsvector가 특정 사용 사례에 잘 맞지 않았음. Tantivy의 성공을 기원함.

  • Quickwit의 생산 환경 배포: Quickwit를 사용해 수십억 개의 객체를 인덱싱했으며, 인덱싱 속도와 쿼리 지연 시간이 경쟁력 있음. 컴퓨팅과 스토리지의 분리가 매우 유용했음.

  • Tantivy의 성능: Tantivy의 성능과 창립자들의 노력에 감명받았음. 팀의 성공을 확신함.

  • Etsy/Hound의 트라이그램 검색: Russ Cox의 정규 표현식 매칭을 기반으로 한 Go 언어의 트라이그램 검색 인덱스를 사용한 경험이 있음.

  • Tantivy 선택 이유: Elasticsearch의 자원 소모에 실망하여 Tantivy를 선택했음. Rust로 프로젝트를 진행하고 싶었고, Tantivy의 성능과 문서화가 뛰어났음.

  • Lucene과 Solr의 업그레이드 문제: Lucene과 Solr의 인덱스 업그레이드 지원이 부족함. 많은 대형 프로젝트에서 재인덱싱이 매우 비싸고 때로는 불가능함.

  • 필드 추가/제거의 한계: Tantivy에서는 필드를 추가하거나 제거할 수 없으며, 모든 데이터를 다른 검색 인덱스로 재인덱싱해야 함.

  • Meilisearch 대안: Meilisearch의 텔레메트리 문제로 Tantivy를 대안으로 찾았음. 설정이 간단해 보임.

  • LanceDb와 Tantivy: LanceDb라는 벡터 데이터베이스 제품에서 Tantivy를 사용하여 전체 텍스트 검색 기능을 제공함. 현재는 Python 바인딩을 통해서만 가능하지만, Rust 바인딩을 구현하려고 함.

답변달기