[PostgreSQL] tsvector와 Full Text Search

PostgreSQL에서 전문검색(Full Text Search)을 구현하는 방법을 정리해본다.

단순 포함 검색이라면 Like와 pg_trgm을 써도 충분하지만, 더 자연스러운 단어 수준 자연어 검색을 원한다면 다른 방법을 사용해야 한다.

이 방면에서 PostgreSQL은 Elasticseach/Lucene에 비할 바는 아니지만, 적당한 수준에서는 쓸만한 텍스트 분석&검색 기능을 제공한다.

단, 다국어에 대한 원만한 처리나 엄청난 고성능 인덱싱을 기대해서는 안된다.
작고 간단하게 시작하기에 좋은 정도라서, 요구사항이 어느 정도인지를 파악하고 선택해야 한다.

테이블 & 데이터 셋업

먼저 테이블을 적당히 정의하자.
일단 필요한 것은 텍스트다. 텍스트가 있어야 쪼개서 쓸 수 있을 것이다.

CREATE TABLE search_set (
  id bigserial PRIMARY KEY,
  user_id bigint NOT NULL,
  original_text text NOT NULL,
  search_vector tsvector
);

적당히 깔았다.

여기서 중요한 것은 tsvector라는 전용 타입이다. 저걸 검색 최적화용 컬럼으로 별도 설정을 해야 한다.

토큰화 단위 (tsvector)

그 다음에 해야할 것은 텍스트를 단어 단위로 쪼개는 것이다.
elasticsearch 등에서 tokenizer라고 부르는데 이건데, 토큰 단위가 tsvector라는 타입을 통해 표현된다.

to_tsvector를 사용하면 텍스트를 그 즉시 단어의 벡터로 변환할 수 있다.
여기서는 simple tokenizer를 사용해서 루프를 돌려보겠다.

-- SELECT to_tsvector('토큰화 방식', '텍스트');
SELECT to_tsvector('simple', 'He is good dog');

그럼 이런 식으로, 단어를 쪼갠 다음에 단어별 개수를 표시해준다.

아무튼 적당히 필요한 토큰화 방식을 선택해서, 벡터를 초기화하는 것이 가장 중요하다.

update search_set
set search_vector = to_tsvector('simple', original_Text)

대충 돌려만 보려면 이렇게 하면 되긴 하는데, 다국어처리나 이런저런 요구사항이 있다면 토큰화를 DB 밖에서 하고 tsvector 표현식만 넣어주는게 좋다.

만약 직접 토큰화를 한다면 이런 식으로 넣어줄 수 있다.

select '''openai'':1,3 ''gpt'':2'::tsvector

키:위치1,위치2, ... 쌍이다.

tsquery를 통한 쿼리 표현

데이터를 다 세팅했으면, 이제 검색을 할 차례다.
이건 검색 표현식 자체를 또 tsquery라는 하나의 타입으로 제공한다.

가장 간단한 사용법은, to_tsquery라는 텍스트 기반 생성 함수를 쓰는 것이다.

SELECT to_tsquery('simple', 'openai & gpt');

이건 openai와 gpt가 모두 포함된 텍스트를 찾는 표현식이 된다.
여기서는 토큰화 매커니즘이 크게 중요하지 않다. 저 검색어를 토큰으로 쪼개는 기준이 될 뿐이다.

원한다면 리터럴은 이런 식으로 표현 가능하다.

검색하기: 단어 필터링 검색

검색을 할 때는 @@ 연산자로 대상 벡터에 tsquery를 전달하면 된다.

벡터필드 @@ 쿼리

A. AND 검색: &

AND 절 같은 것도 원하는대로 부여할 수 있다.
&를 붙이면 단어가 전부 존재하는 것만 찾는다.

아러면 이제 치킨과 트렌드가 전부 포함된 벡터만 필터링이 된다. &가 AND 연산자다.

B. OR 검색: |

| 를 넣으면 OR 검색도 된다. 이것도 인덱스를 걸면 잘 탄다.

C. Phrase 검색: <->

phrase는 특정 단어 뭉치가 연속적으로 등장하는 것을 위한 조건이다.

그러니까, A 단어 뒤에 바로 B 단어가 이어지는 것만 보고 싶다면 A <-> B의 형태로 쿼리를 돌릴 수 있다.

D. Distance 검색:

거리 기반 검색이란 것이 있다. 이건 phrase보다 확장된 구조인데, 단어 사이의 거리가 좀 있어도 포함이 되게 하는 것이다. 그 거리를 지정할 수 있다.

select 
	to_tsvector('simple', '빨간색 노란색') @@ to_tsquery('simple', '빨간색 <2> 노란색') as _0 
	, to_tsvector('simple', '빨간색 땡 노란색') @@ to_tsquery('simple', '빨간색 <2> 노란색') as _1
	, to_tsvector('simple', '빨간색 땡 땡 노란색') @@ to_tsquery('simple', '빨간색 <2> 노란색') as _2

E. Prefix 검색: :*

기본적으로 거의 모든 검색은 단어(토큰) 수준의 Exact match다.
하지만 tsvector는 Prefix 포함 검색 또한 지원한다. 그냥 "치킨"만 넣는다면 치킨 단어가 있는 것만 매칭되지만, :*를 붙이면 치킨으로 시작하는 단어들도 함께 매칭된다.

Score로 정렬하기

단어의 포함 개수를 기반으로 랭킹을 하거나 할 수도 있다.
핵심은 to_rank와 to_rank_cd라는 함수다.

이건 쿼리 표현식을 기반으로, 얼마나 단어가 매칭되는지를 계산한다.

ts_rank(tsvector, tsquery)

당연히 단어가 많이 매칭될수록 점수가 높아지고, 없다면 0점이 나온다.

to_rank_cd는 to_rank와 비슷하긴 한데, 검색어들끼리 가까울수록 더 큰 점수가 나온다.
그러니까, "삼성전자"와 "ai"를 AND 조건으로 넣었을때, 데이터에 그 2개 사이에 단어가 적을수록 점수가 커지고, 단어가 많아서 멀어질수록 점수가 작아진다.

실제 사용례에서는 일반 버전과 cd 버전 모두 유용하다.

아무툰 저걸 이제 적절히 ORDER BY 절에만 붙이면 정렬이 된다.

근데, 성능적으로 주의해야 하는 부분이 있다.
ts_rank로 정렬을 거는건 후술할 tsvector 인덱싱의 대상이 아니다. 어쩔 수 없다. tsvector용 인덱스는 필터링용이지, 정렬이나 가중치를 처리하기 위한 것이 아니기 때문이다.

그래서 실제로 쓸때는 먼저 필터링을 하고 후처리로 정렬을 하는 편이 좋다. 안그러면 0점짜리도 전부 계산하고 메모리에 올려서 쓰기 때문이다.

그럼 이렇게 빠르게 탄다. 치킨이 포함된 것만 부분적으로 로드한 다음에 정렬을 하기 때문이다.

Gin 인덱스

tsvector 타입은 전용 인덱스 형식을 지원한다. GIN과 Gist 2가지가 가능한데, 일반적인 경우에는 손실이 없는 GIN을 권장한다.
이건 일반 컬럼 조건과 혼합해서 커버링으로 쓸 수는 없다.

CREATE INDEX  idx_search_set_vector
ON search_set
USING gin (search_vector);

이렇게 만들면 된다. 이게 텍스트가 크면 빌드타임이 꽤 무겁다.
수십만 행 정도인데도 고성능 장비에서 몇분이 걸렸다.

그럼 원래 초 단위로도 걸리는 것이,

(웬만해서는) 밀리초 단위로 처리가 될 것이다.

그리고 이건 tsvector @@ tsquery 형태의 단순 필터링 조건에만 인덱싱이 된다. 위에서 언급한 rank 기반 정렬 같은건 최적화의 대상이 아니다.

참고로 인덱스 크기가 좀 크다.
디스크 압박이나 메모리 사용량 증가를 고려하긴 해야 한다.

Gist 인덱스 (비추천)

tsvector는 Gist 기반의 인덱스도 지원한다.
이건 tradeoff가 확실하게 있다.

장점: 인덱스 빌드가 빠르고 인덱스 크기가 작은 대신
단점: 속도가 느리고, 인덱싱 단계에서 손실이 발생한다.

이게 좀 미묘한데, 인덱싱을 할때 "치킨" 검색을 해도 "치킨"이 없는 행이 반환될 수 있다는 것이다. 물론 그게 사용자에게까지 가진 않고, DB 내부적으로 체크를 해서 교정을 한다.
다만 불필요한 스캔이나 반복이 발생해서 비효율적으로 동작할 수 있다는 것이다.

제한사항 및 한계

tsquery&tsvector는 기능적인 제한사항이나 한계가 좀 있다.

1. 토큰당 길이제한

tsvector를 생성할때, 한 단어(토큰) 당 길이 제한이 있다.
보통 2048자가 제한이고, 2048자 이상의 토큰은 tsvector로 변환되지 않고 버려진다. 오류는 안뜨고 경고만 뜬다.

2. 복잡한 하이브리드 검색은 불가능

Elasticsearch 같은 전문 엔진에서는 BM25 같은 여러가지 변칙적인 개념을 통해 세심한 최적화를 제공하는데, PostgreSQL에는 그 정도까지는 없다. 너무 많이 바라면 안된다.

3. 정렬 최적화 불가능

앞서 언굽했듯이, 스코어 정렬은 인덱스를 최적으로 활용할 수 없다. 기본적으로 풀스캔하고 메모리에 올린 뒤에 정렬하는 일반적인 방법으로 동작한다.

4. 복합적인 필터링 최적화 불가능

Elasticsearch 같은 경우에는 텍스트 검색에 더해서 여러가지 다양한 컬럼으로 조건을 걸어도 기깔나게 최적화를 잘 해주는데, PostgreSQL에서는 그 정도를 기대하긴 어렵다.
BTree 따로 만들어두면 Bitmap 최적화를 하긴 하는데, Elasticsearch에 비하면 성능 수준이 많이 쳐진다.

5. Tokenizer 지원 부실

영어 정도까지는 내장 엔진이나 기본 확장으로 처리할 수 있는데, 그 이상은 안된다. 한국어같은건 포기하는게 맞다. 아예 불가능한건 아니고, 다국어에 대한 지원이 필요하다면 바깥에서 분해해서 직접 넣으면 되긴 한다.

6. 단어 등장 횟수는 처리 불가

tsquery는 기능이 좀 제한적이다. 특정 단어가 포함되는지 여부나, 느슨한 스코어 정도는 계산할 수 있어도 특정 단어가 몇번 등장하는지를 조회하거나 조건으로 거는건 어렵다.

참조
https://www.postgresql.org/docs/current/textsearch.html
https://www.postgresql.org/docs/current/textsearch-controls.html
https://www.postgresql.org/docs/current/textsearch-tables.html
https://www.postgresql.org/docs/current/textsearch-dictionaries.html
https://www.postgresql.org/docs/current/textsearch-indexes.html
https://www.postgresql.org/docs/current/datatype-textsearch.html
https://www.postgresql.org/docs/current/textsearch-intro.html