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 바인딩을 구현하려고 함.