Postgres에서의 전문 검색: Elasticsearch vs. 대체제들
(blog.paradedb.com)전문 검색 (Full Text Search)
- 전문검색은 특정 키워드와 구문의 존재 여부에 따라 텍스트 모음에서 항목을 찾는 기술
- Elasticsearch와 같은 대부분의 검색 엔진은 검색 결과 순위를 매기기 위해 BM25 알고리듬을 사용
- BM25는 용어가 얼마나 자주 나타나는지, 그리고 모든 문서에서 해당 용어가 얼마나 고유한지를 고려함
- 전문 검색은 의미론적 의미로 결과를 검색하고 순위를 매기는 유사성 검색 또는 벡터 검색과는 다름
- 많은 최신 애플리케이션은 전문 검색과 유사성 검색을 결합하여 사용하는데, 이를 하이브리드 검색이라고 하며 더 정확한 결과를 얻을 수 있음
Postgres FTS
장점
-
단순성
- Postgres FTS는 추가 인프라가 필요 없으며 AWS RDS와 같은 모든 관리형 Postgres 서비스에서 사용할 수 있음
- 장기적으로 외부 검색 엔진을 오케스트레이션하고 관리할 필요가 없어 상당한 시간과 고민을 절약할 수 있음
-
실시간 검색
- Postgres FTS에서는 커밋 즉시 데이터를 검색할 수 있음
- 이는 사용자 대상 검색 경험이나 지연 시간에 민감한 검색 경험을 구축하는 기업(예: 전자상거래 사이트 또는 핀테크)에 매우 유용할 수 있음
-
Postgres 트랜잭션 및 MVCC
- Postgres의 ACID 트랜잭션 및 다중 버전 동시성 제어(MVCC)는 동시 액세스 및 빈번한 업데이트 시 FTS 결과의 신뢰성을 보장함
단점
-
기능 불완전성
- Postgres FTS의 제한된 기능 세트는 일부 기업에게 있어 딜 브레이커가 될 수 있음
- 누락된 기능으로는 BM25 점수 매기기, 관련성 조정, 사용자 정의 토크나이저, 패싯팅 등이 있음
-
대용량 데이터 세트에 대한 성능 저하
- Postgres FTS는 수백만 행이 있는 테이블에서는 잘 수행되지만, 수천만 행이 있는 테이블에서는 성능이 상당히 저하됨
-
트랜잭션 오버헤드
- 컬럼에 GIN 인덱스를 생성하면 해당 컬럼에 영향을 미치는 트랜잭션에 약간의 지연 시간(일반적으로 밀리초)이 추가됨
핵심 요약
- Postgres FTS는 정교한 FTS 쿼리가 필요하지 않은 소규모에서 중간 규모의 테이블 검색에 이상적임
- "중간 규모"와 "정교한"이 의미하는 바는 의도적으로 모호하게 표현되었는데, 이는 성능 요구 사항에 따라 다르기 때문임
- 다행히 Postgres FTS로/에서 테스트 및 마이그레이션하는 것은 매우 간단함
Elasticsearch
장점
-
포괄적인 기능 세트
- Elasticsearch는 거의 모든 FTS 쿼리를 처리할 수 있음
- 엘라스틱 쿼리 DSL(도메인 특화 언어)은 전문 검색 기능의 표준임
-
높은 성능
- 벤치마크에 따르면 Elasticsearch는 기본 배틀 테스트된 Lucene 검색 엔진과 분산 아키텍처 덕분에 수십억 개의 행을 밀리초 단위로 쿼리할 수 있음
-
검색 이상의 기능
- FTS 외에도 Elasticsearch는 분석 쿼리 엔진, 벡터 데이터베이스, 보안 및 관찰 가능성 플랫폼이기도 함
- 많은 조직에서 Elasticsearch 내에서 여러 서비스를 통합하는 단순성을 즐김
단점
-
신뢰할 수 있는 데이터 스토어가 아님
- 많은 기업들이 Elasticsearch를 주요 데이터 스토어로 사용하기로 결정한 것을 후회한 경우가 있음
- 이는 권장하지 않는 방식임. Elasticsearch는 ACID 트랜잭션과 MVCC가 부족하여 데이터 불일치와 손실이 발생할 수 있으며, 관계형 속성과 실시간 일관성이 부족하여 많은 데이터베이스 쿼리가 어려움
-
ETL 파이프라인 필요
- Elasticsearch는 신뢰할 수 있는 데이터 스토어가 아니기 때문에 일반적으로 Postgres를 사용하는 조직은 데이터를 Postgres에서 Elasticsearch로 추출, 변환 및 로드(ETL)함
- ETL 파이프라인의 장애는 모든 종류의 프로덕션 중단으로 이어질 수 있기 때문에 기본 Postgres 스키마의 변경 사항이 파이프라인을 손상시키지 않도록 주의 깊게 유지 관리되어야 함
-
데이터 신선도 손실
- ETL 작업은 시간이 많이 걸리고 주기적으로 실행됨
- Elasticsearch에 도달하는 데이터는 종종 Postgres보다 몇 시간 늦음
- Postgres 테이블에 대해 실시간 검색을 수행하는 애플리케이션에는 이것이 금기 사항일 수 있음
-
비용
- 여러 기업에서 Elasticsearch가 가장 큰 소프트웨어 비용 항목이 되었다는 이야기를 듣고 놀람
- Elasticsearch 클러스터 비용이 급증함에 따라 이러한 많은 기업이 Elasticsearch Cloud에서 자체 관리로 전환했는데, 이는 클라우드 지출을 줄였지만 새로운 문제를 야기함
- Elasticsearch는 운영, 조정 및 관리가 매우 어려운 것으로 악명 높음
- 이 조직들은 Elasticsearch 클러스터를 관리하기 위해 (비용이 많이 드는) 엔지니어를 고용함
핵심 요약
- Elasticsearch는 운영 오버헤드와 데이터 신선도를 희생하여 우수한 검색 성능을 제공함
- 보다 경량의 대안으로는 불가능하거나 다른 Elasticsearch 서비스를 사용할 예정인 경우 Elasticsearch를 권장함
대체 검색 엔진
- 지난 몇 년 동안 Algolia, Meilisearch, Typesense 같은 현대식 검색 엔진이 등장함
- 이러한 엔진은 일반적으로 사용자 대상 검색 경험을 구축하는 데 사용됨
- Hacker News 검색도 Algolia에 구축되어 있음
- 각 서비스는 가장자리에서 차별화되지만 Postgres에 대한 검색을 찾는 개발자에게는 중요한 주의 사항이 있음
- 이러한 솔루션 중 어느 것도 Postgres를 위해 특별히 구축되지 않음
- Postgres 사용자는 Elasticsearch와 마찬가지로 이러한 서비스에서 유사한 문제를 경험할 가능성이 있음
최선의 방법이 가능할까?
- ParadeDB는 Postgres를 위해 구축된 전문 검색 엔진임
-
pg_search라는 확장을 기반으로 ParadeDB는 Postgres 내부에 Rust 기반 Lucene 대안인 Tantivy를 내장함 - Postgres FTS와 마찬가지로 ParadeDB는 추가 인프라 없이 기존의 자체 관리형 Postgres 데이터베이스에 연결함
- Elasticsearch와 마찬가지로 ParadeDB는 고급 전문 검색 엔진의 기능을 제공함
- Amazon RDS와 같은 관리형 Postgres 서비스와의 호환성은 곧 제공될 예정임