RDB 의 FTS(Full Text Search) 이해하기

RDB 의 FTS(Full Text Search) 란?

배경

이 글의 목적은 FTS(Full Text Search) 로 RDB(Relational Database) 적당한지 판단합니다.

 검색엔진으로서 대부분 ElasticSearch 를 사용하는데요. 간단한 검색엔진으로서는 다소 과한 오버스펙일 수 있어, 조사하는 과정에서 PostgreSQL, MySQL 도 Full Text Search 기능이 있어 기술조사를 진행했습니다. 그 과정에서 RDB 의 FTS 에 대해서 이해하는 것을 목적으로 합니다.

아래 내용은 postgresSQL 기준으로 설명합니다. 왜냐하면 MySQL 보다 기본으로 제공하는 기능이 좀더 많습니다.

비교 기준	PostgreSQL	ElasticSearch	일반 검색 (LIKE/정규 표현식)
아키텍처 및 관리 편의성	내장된 DBMS 기능으로 별도 설치나 관리 필요 없음. 데이터베이스 통합이 용이.	별도의 클러스터 구성 필요. 설치, 관리 및 유지보수가 복잡함. 추가적인 DevOps 리소스 필요.	별도 설치나 관리 필요 없음. 가장 기본적인 검색 방식으로 관리가 쉬움.
성능 및 확장성	단일 서버에서 성능 우수, 인덱스 사용으로 검색 속도 향상. 대규모 데이터에서는 성능 한계가 있을 수 있음.	분산 시스템 아키텍처로 수평적 확장 용이. 대규모 데이터 및 고성능 검색에 최적화. 실시간 데이터 인덱싱과 검색 지원.	대규모 데이터나 복잡한 검색에 성능이 떨어짐. 테이블 전체를 스캔해야 하므로 성능 저하가 심각할 수 있음.
검색 기능 및 유연성	형태소 분석, 불용어 제거, 동의어 처리 등 기본적인 FTS 기능 제공. 복잡한 쿼리도 가능하지만 한계가 있음.	고급 검색 기능 제공(정확도 기반 랭킹, 어간 추출, 자동 완성, 지리적 검색 등). 복잡한 검색 시나리오 처리 가능.	단순 문자열 매칭(LIKE)이나 정규 표현식으로 제한된 검색 기능만 제공.
데이터 일관성 및 유지보수	데이터베이스 내부에서 직접 검색, 데이터 변경 시 자동으로 인덱스 업데이트. 일관성 유지가 쉬움.	데이터베이스 외부 검색 엔진으로, 데이터 동기화 필요. 데이터 일관성 유지에 추가적인 노력 필요.	데이터베이스 내부에서 직접 검색하므로 일관성 유지가 쉬움. 다만, 성능 저하와 기능적 한계 존재.
비용 및 리소스 요구사항	별도의 설치 및 라이선스 비용 없음. 현재 사용 중인 PostgreSQL 인스턴스에서 바로 사용 가능.	초기 설치, 설정, 관리 비용이 높으며, 고성능을 위한 하드웨어 자원이 추가적으로 필요함.	추가 비용 없음. 그러나 대규모 데이터나 고급 검색 기능이 필요한 경우, 성능 문제 해결을 위해 인프라 확장 필요.

 

PostgreSQL FTS의 한계와 ElasticSearch와의 비교

 

1. 형태소 분석의 한계

PostgreSQL FTS:

• PostgreSQL FTS는 기본적으로 형태소 분석을 지원하지만, 지원되는 언어와 분석기의 종류가 제한적이다. 영어와 같은 몇 가지 주요 언어에 대한 기본 분석기를 제공하지만, 한국어와 같은 언어에 대한 기본 분석기를 제공하지 않는다. 따라서, 한국어와 같은 비영어권 언어를 지원하려면 외부 확장 모듈(예: mecab-ko 등)을 사용해야 한다.

• 또한, PostgreSQL의 형태소 분석기는 커스터마이징이 어렵고, 사용자 정의 사전이나 분석기를 통합하는 데 제한적이다.

• ElasticSearch:

• ElasticSearch는 다양한 언어에 대한 고급 형태소 분석기를 내장하고 있으며, 더 많은 언어와 분석기를 기본적으로 지원한다. 또한, 커스텀 분석기를 쉽게 추가할 수 있고, 특정 비즈니스 로직에 맞는 분석기를 설정할 수 있는 유연성이 크다. 예를 들어, ElasticSearch는 한국어 형태소 분석기(예: nori)를 기본적으로 제공하며, 이를 설정하고 튜닝하는 것이 용이하다.

예를 들면, 이런 차이가 있었습니다. /api/example/path 라는 문자열이 있다면, PostgreSQL의 Parser는  /api/example/path 를 하나의 단어로 판단하는 반면에, ElasticSearch 의 경우, api, example, path 로 나누는 것을 확인할 수 있었습니다.

 

2. 불용어 제거의 제한성

• PostgreSQL FTS:

• PostgreSQL FTS는 불용어(stop words)를 제거하는 기능을 제공하지만, 언어별로 고정된 불용어 목록을 사용하며, 이를 커스터마이징하는 데 한계가 있다. 사용자가 불용어 리스트를 변경할 수 있지만, 각 언어별로 제공되는 기본 리스트에 비해 유연성이 떨어진다.

• 또한, 검색 쿼리마다 별도로 불용어 처리를 지정할 수 없고, 시스템 전체적으로 불용어 설정을 적용해야 하므로 특정 검색 요구사항에 따라 불용어 설정을 동적으로 조정하기 어렵다.

• SELECT to_tsvector('english', 'in the list of stop words');
        to_tsvector
----------------------------
 'list':3 'stop':5 'word':6

• ElasticSearch:

• ElasticSearch는 매우 유연한 불용어 처리를 제공하며, 다양한 언어와 사용자 정의 목록을 지원한다. 쿼리마다 다른 불용어 목록을 지정할 수 있어, 특정 검색 시나리오에 맞춘 불용어 처리가 가능하다. 또한, 텍스트 인덱싱 단계에서 불용어 필터를 사용하여 불용어 처리와 관련된 고급 설정을 쉽게 적용할 수 있다.

둘다 불용어를 제공하는 기능을 제공하긴 하나, RDS 의 Stop words의 경우에 설정이 필요했고, 특히 한국어의 불용어를 제거하기 위한 설정은 ElasticSearch에 비해 복잡했습니다.

[참고자료]

PostgresSQL Docs - TEXTSEARCH-STOPWORDS

ElasticSearch - STOPWORDS

3. 동의어 처리의 한계

• PostgreSQL FTS:

• PostgreSQL FTS는 동의어 사전을 활용한 동의어 처리를 제공할 수 있지만, 이 기능은 제한적이다. 동의어 사전은 간단한 매핑 파일로 구성되며, 관리와 확장이 어렵다. 복잡한 동의어 처리나 다중 언어 지원을 위한 설정이 ElasticSearch보다 부족하다.

• 동의어 처리를 위해 별도의 구문 사전을 설정해야 하며, 동의어 처리의 범위나 효과를 세밀하게 조정하기 어렵다. 복잡한 동의어 관계를 설정하고 관리하는 데 있어 유연성이 떨어진다.

• ElasticSearch:

• ElasticSearch는 동의어 필터를 통해 매우 정교하고 유연한 동의어 처리를 지원한다. 동의어 사전을 인덱싱 단계에서 적용하거나, 검색 쿼리에서 동적으로 지정할 수 있다. 동의어 처리 규칙을 다양한 형태로 정의할 수 있으며, 복잡한 동의어 네트워크나 다단계 동의어 매핑을 쉽게 설정할 수 있다.

• ElasticSearch의 동의어 처리 기능은 확장성과 유연성 면에서 PostgreSQL FTS보다 훨씬 강력하다.

4. 복잡한 쿼리의 제한성

• PostgreSQL FTS:

• PostgreSQL FTS는 기본적인 Full Text Search 기능을 제공하지만, 매우 복잡한 쿼리(예: 사용자 정의 점수 계산, 문맥 분석, 고급 필터링 등)를 수행하는 데 제약이 있다. 예를 들어, 특정 검색어에 가중치를 부여하거나, 여러 조건을 조합한 복잡한 쿼리를 작성하는 데 있어 한계가 있다.

• PostgreSQL FTS는 정밀한 랭킹 알고리즘을 제공하지 않으며, 기본적인 tf-idf(문서 내의 단어 빈도 기반 가중치 계산) 수준의 랭킹 기능만을 제공한다.

 

• ElasticSearch:

• ElasticSearch는 다양한 고급 검색 기능(예: 부스팅, 맞춤형 스코어링, 점수 함수)을 통해 복잡한 쿼리를 처리할 수 있다. ElasticSearch는 특정 필드에 가중치를 부여하거나, 여러 검색 조건을 조합해 문맥에 맞는 결과를 제공하는 데 강력하다.

• ElasticSearch는 사용자 정의 분석기와 검색 기능을 손쉽게 추가할 수 있는 API를 제공하여, 비즈니스 요구사항에 맞춘 정교한 검색 로직을 구현할 수 있다.

 

5. 확장성과 성능 튜닝의 제한성

• PostgreSQL FTS:

• PostgreSQL FTS는 단일 서버 환경에서 사용되며, 수평적 확장성(데이터의 수평적 분산 처리)이 제한적이다. 데이터 양이 매우 많아질수록 성능이 저하될 수 있으며, 인덱스 생성 및 업데이트 시 성능 저하가 발생할 수 있다.

• 또한, 성능 튜닝의 옵션이 ElasticSearch에 비해 제한적이며, 고급 검색 기능을 필요로 하는 경우 성능 최적화가 어렵다.

• ElasticSearch:

• ElasticSearch는 기본적으로 분산 시스템으로 설계되어 있어, 대규모 데이터와 높은 요청량을 처리하기 위해 수평적 확장이 가능하다. 데이터 샤딩(sharding)과 복제(replication)을 통해 확장성과 가용성을 극대화할 수 있다.

• 또한, 성능 튜닝을 위한 다양한 설정 옵션(예: 캐싱, 스레드 풀 관리, 인덱싱 전략 등)을 제공하여, 검색 성능을 최적화할 수 있다.