Full-text search hoạt động như thế nào trong PostgreSQL?

Question

Accepted Answer

PostgreSQL có **full-text search tích hợp sẵn** — tìm kiếm từ ngữ trong văn bản/tài liệu với khả năng stemming, xếp hạng và nhận biết ngôn ngữ, mạnh hơn nhiều so với `LIKE`. Nó sử dụng kiểu **`tsvector`** (tài liệu đã được xử lý) và **`tsquery`** (truy vấn tìm kiếm), cùng với GIN index để tăng tốc.

## Vấn đề mà LIKE không giải quyết được

```text
LIKE '%word%' → không có stemming (không khớp "running" với "run"), không xếp hạng, không
  nhận biết ngôn ngữ, và không tận dụng được index (wildcard ở đầu) → chậm và hạn chế.
Full-text search → stem các từ, bỏ qua stop words, xếp hạng theo độ liên quan, có thể đánh index.
```

## tsvector và tsquery

```sql
-- to_tsvector — xử lý văn bản thành các lexeme có thể tìm kiếm (đã stem, đã loại stop-words)
SELECT to_tsvector('english', 'The cats are running fast');
-- → 'cat':2 'fast':5 'run':4  (đã stem: cats→cat, running→run; "the"/"are" bị loại bỏ)

-- to_tsquery / plainto_tsquery — phân tích một truy vấn tìm kiếm
SELECT to_tsvector('english', body) @@ to_tsquery('english', 'running')
FROM articles;   -- @@ = toán tử khớp (match); khớp với stem "run"
```

`to_tsvector` chuyển văn bản thành các **lexeme** đã chuẩn hóa (stem các từ, loại bỏ stop words), còn `to_tsquery` phân tích các từ khóa tìm kiếm. Toán tử `@@` kiểm tra sự khớp — nên "running" sẽ khớp với các tài liệu chứa "run," "runs," v.v.

## Cột tìm kiếm + GIN index (thiết lập thực tế)

```sql
-- thêm một cột tsvector generated và đánh index bằng GIN
ALTER TABLE articles ADD COLUMN search_vector tsvector
  GENERATED ALWAYS AS (to_tsvector('english', title || ' ' || body)) STORED;
CREATE INDEX idx_search ON articles USING GIN (search_vector);

-- tìm kiếm nhanh nhờ sử dụng index
SELECT title FROM articles
WHERE search_vector @@ plainto_tsquery('english', 'machine learning');
```

## Xếp hạng kết quả theo độ liên quan

```sql
SELECT title, ts_rank(search_vector, query) AS rank
FROM articles, plainto_tsquery('english', 'database') query
WHERE search_vector @@ query
ORDER BY rank DESC;          -- liên quan nhất lên đầu
```

`ts_rank` chấm điểm mức độ khớp của mỗi tài liệu, cho phép trả về kết quả được sắp xếp theo độ liên quan.

## Tại sao điều này quan trọng

Full-text search tích hợp sẵn của PostgreSQL là một tính năng giá trị cho phép bạn triển khai **chức năng tìm kiếm ngay trong database** — mà không cần một search engine riêng (như Elasticsearch) cho nhiều trường hợp sử dụng — nên hiểu nó rất hữu ích cho các ứng dụng cần tìm kiếm văn bản.

Giá trị cốt lõi là nó mạnh hơn `LIKE` rất nhiều (vốn không thể stem từ, xếp hạng kết quả, hay đánh index hiệu quả): full-text search cung cấp **stemming từ** (khớp "running" với "run"), **loại bỏ stop-word**, **nhận biết ngôn ngữ**, **xếp hạng độ liên quan**, và quan trọng là **có thể đánh index** (với GIN index để tìm kiếm nhanh) — mang lại khả năng tìm kiếm thực sự (kiểu mà người dùng mong đợi: khớp các biến thể của từ, xếp hạng theo độ liên quan) ngay trong Postgres.

Hiểu các khái niệm cốt lõi — **`tsvector`** (văn bản tài liệu đã xử lý, đã stem), **`tsquery`** (các từ khóa tìm kiếm đã phân tích), toán tử khớp **`@@`**, và **`ts_rank`** để xếp hạng độ liên quan — cùng với thiết lập thực tế (một cột `tsvector` generated được đánh index bằng GIN để có hiệu năng) bao quát cách triển khai tìm kiếm hiệu quả.

Mặc dù các search engine chuyên dụng cung cấp nhiều hơn cho nhu cầu phức tạp, full-text search của Postgres là đủ và tiện lợi cho nhiều ứng dụng (tránh được sự phức tạp vận hành của một hệ thống tìm kiếm riêng và giữ dữ liệu tìm kiếm nhất quán với dữ liệu quan hệ của bạn).

Vì tìm kiếm văn bản là một yêu cầu phổ biến của ứng dụng, và vì Postgres cung cấp full-text search tích hợp đầy đủ năng lực (mạnh mẽ, có thể đánh index, với stemming và xếp hạng) mà thường đủ dùng mà không cần search engine riêng, hiểu nó — mô hình tsvector/tsquery, thiết lập có index, và xếp hạng — là kiến thức giá trị, thực tiễn cho phép bạn thêm chức năng tìm kiếm thực sự bằng các khả năng tích hợp sẵn của PostgreSQL, một tính năng hữu ích thường bị bỏ qua để chọn các giải pháp bên ngoài phức tạp hơn trong khi Postgres đã đủ dùng.