# Postgres에서의 전문 검색: Elasticsearch vs. 대체제들

> Clean Markdown view of GeekNews topic #16311. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=16311](https://news.hada.io/topic?id=16311)
- GeekNews Markdown: [https://news.hada.io/topic/16311.md](https://news.hada.io/topic/16311.md)
- Type: news
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2024-08-14T10:52:02+09:00
- Updated: 2024-08-14T10:52:02+09:00
- Original source: [blog.paradedb.com](https://blog.paradedb.com/pages/elasticsearch_vs_postgres)
- Points: 22
- Comments: 3

## Summary

Postgres FTS는 DB에 기본 내장된 전문 검색 방식으로 추가 인프라 없이 간단하게 설정할 수 있으며, 실시간 검색과 ACID 트랜잭션을 지원하여 신뢰성을 보장합니다. 반면, ElasticSearch는 포괄적인 기능 세트와 높은 성능을 제공하지만, 데이터 신선도 손실과 높은 운영 비용 등의 단점이 있습니다. ParadeDB는 Postgres를 위해 특별히 구축된 전문 검색 엔진으로, Postgres FTS의 간편함과 Elasticsearch의 고급 기능을 결합한 대안으로 주목받고 있습니다.

## Topic Body

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

## Comments



### Comment 28016

- Author: galadbran
- Created: 2024-08-14T13:29:15+09:00
- Points: 1

Postgres FTS 가 뭔가 했더니 내장 기능을 말하는 거였군요

### Comment 28007

- Author: xguru
- Created: 2024-08-14T10:53:02+09:00
- Points: 1

이 친구들 지속적으로 개선하면서 관련 글을 올리고 있어서, 긱뉴스에도 여러번 공유했습니다.   
  
[ParadeDB - PostgreSQL for Search](https://news.hada.io/topic?id=12779)  
[pg_bm25 - Postgres에서 Elastic 수준의 품질을 제공하는 Full-Text 검색 확장](https://news.hada.io/topic?id=11287)

### Comment 28030

- Author: cometkim
- Created: 2024-08-14T19:53:50+09:00
- Points: 1
- Parent comment: 28007
- Depth: 1

글에서 언급된 paradedb, pg_search, pg_bm25 모두 같은 프로젝트입니다.