Tìm kiếm toàn văn trong Postgres: Elasticsearch so với các lựa chọn thay thế
(blog.paradedb.com)Tìm kiếm toàn văn (Full Text Search)
- Tìm kiếm toàn văn là kỹ thuật tìm các mục trong một tập hợp văn bản dựa trên sự hiện diện của từ khóa và cụm từ cụ thể
- Hầu hết các công cụ tìm kiếm như Elasticsearch đều sử dụng thuật toán BM25 để xếp hạng kết quả tìm kiếm
- BM25 xem xét tần suất một thuật ngữ xuất hiện và mức độ độc nhất của thuật ngữ đó trong toàn bộ tài liệu
- Tìm kiếm toàn văn khác với tìm kiếm tương đồng hoặc tìm kiếm vector, vốn tìm và xếp hạng kết quả theo ý nghĩa ngữ nghĩa
- Nhiều ứng dụng hiện đại kết hợp tìm kiếm toàn văn với tìm kiếm tương đồng, gọi là tìm kiếm lai, để đạt kết quả chính xác hơn
Postgres FTS
Ưu điểm
-
Tính đơn giản
- Postgres FTS không cần hạ tầng bổ sung và có thể dùng trên mọi dịch vụ Postgres được quản lý như AWS RDS
- Về lâu dài, không cần điều phối và quản lý một công cụ tìm kiếm bên ngoài, giúp tiết kiệm đáng kể thời gian và công sức
-
Tìm kiếm thời gian thực
- Trong Postgres FTS, dữ liệu có thể được tìm kiếm ngay sau khi commit
- Điều này đặc biệt hữu ích cho các công ty xây dựng trải nghiệm tìm kiếm hướng tới người dùng hoặc nhạy cảm với độ trễ, như thương mại điện tử hoặc fintech
-
Giao dịch Postgres và MVCC
- Giao dịch ACID và cơ chế kiểm soát đồng thời đa phiên bản (MVCC) của Postgres đảm bảo độ tin cậy của kết quả FTS khi có truy cập đồng thời và cập nhật thường xuyên
Nhược điểm
-
Thiếu tính năng
- Bộ tính năng hạn chế của Postgres FTS có thể là yếu tố khiến một số doanh nghiệp không thể chấp nhận
- Các tính năng còn thiếu gồm chấm điểm BM25, tinh chỉnh độ liên quan, tokenizer tùy chỉnh, faceting, v.v.
-
Hiệu năng giảm với tập dữ liệu lớn
- Postgres FTS hoạt động tốt với các bảng có hàng triệu dòng, nhưng hiệu năng giảm đáng kể với các bảng có hàng chục triệu dòng
-
Overhead giao dịch
- Tạo chỉ mục GIN trên một cột sẽ thêm một chút độ trễ cho các giao dịch tác động tới cột đó, thường ở mức mili giây
Tóm tắt chính
- Postgres FTS lý tưởng cho việc tìm kiếm trên các bảng nhỏ đến trung bình khi không cần các truy vấn FTS quá tinh vi
- “Trung bình” và “tinh vi” được diễn đạt một cách có chủ ý là mơ hồ, vì điều đó phụ thuộc vào yêu cầu hiệu năng
- May mắn là việc thử nghiệm và di chuyển sang/từ Postgres FTS rất đơn giản
Elasticsearch
Ưu điểm
-
Bộ tính năng toàn diện
- Elasticsearch có thể xử lý gần như mọi truy vấn FTS
- Elastic Query DSL (ngôn ngữ chuyên biệt theo miền) là tiêu chuẩn cho tính năng tìm kiếm toàn văn
-
Hiệu năng cao
- Theo benchmark, Elasticsearch có thể truy vấn hàng tỷ dòng trong thời gian tính bằng mili giây nhờ công cụ tìm kiếm Lucene cốt lõi đã được kiểm chứng rộng rãi và kiến trúc phân tán
-
Không chỉ là tìm kiếm
- Ngoài FTS, Elasticsearch còn là công cụ truy vấn phân tích, cơ sở dữ liệu vector, nền tảng bảo mật và observability
- Nhiều tổ chức thích sự đơn giản khi hợp nhất nhiều dịch vụ trong Elasticsearch
Nhược điểm
-
Không phải kho dữ liệu đáng tin cậy
- Nhiều doanh nghiệp đã hối tiếc khi quyết định dùng Elasticsearch làm kho dữ liệu chính
- Đây không phải cách được khuyến nghị. Elasticsearch thiếu giao dịch ACID và MVCC, có thể dẫn tới dữ liệu không nhất quán và mất mát dữ liệu; đồng thời thiếu các đặc tính quan hệ và tính nhất quán thời gian thực, khiến nhiều truy vấn cơ sở dữ liệu trở nên khó khăn
-
Cần pipeline ETL
- Vì Elasticsearch không phải kho dữ liệu đáng tin cậy, các tổ chức dùng Postgres thường phải thực hiện ETL dữ liệu từ Postgres sang Elasticsearch
- Lỗi trong pipeline ETL có thể gây ra đủ loại sự cố production, vì vậy cần bảo trì cẩn thận để các thay đổi trong schema Postgres gốc không làm hỏng pipeline
-
Mất độ tươi mới của dữ liệu
- Các job ETL tốn thời gian và chạy theo chu kỳ
- Dữ liệu đến Elasticsearch thường chậm hơn Postgres vài giờ
- Với các ứng dụng cần tìm kiếm thời gian thực trên bảng Postgres, đây có thể là điều tối kỵ
-
Chi phí
- Thật đáng ngạc nhiên khi nghe nhiều công ty nói rằng Elasticsearch đã trở thành khoản chi phần mềm lớn nhất của họ
- Khi chi phí cụm Elasticsearch tăng vọt, nhiều công ty trong số đó đã chuyển từ Elasticsearch Cloud sang tự quản lý, giúp giảm chi phí đám mây nhưng lại tạo ra vấn đề mới
- Elasticsearch nổi tiếng là rất khó vận hành, tinh chỉnh và quản lý
- Các tổ chức này phải thuê các kỹ sư đắt đỏ để quản lý cụm Elasticsearch
Tóm tắt chính
- Elasticsearch mang lại hiệu năng tìm kiếm xuất sắc, đánh đổi bằng overhead vận hành và độ tươi mới của dữ liệu
- Elasticsearch được khuyến nghị khi các lựa chọn thay thế nhẹ hơn là không khả thi hoặc khi bạn dự định dùng các dịch vụ khác trong hệ Elasticsearch
Các công cụ tìm kiếm thay thế
- Trong vài năm gần đây, các công cụ tìm kiếm hiện đại như Algolia, Meilisearch và Typesense đã xuất hiện
- Các công cụ này thường được dùng để xây dựng trải nghiệm tìm kiếm hướng tới người dùng
- Tìm kiếm của Hacker News cũng được xây dựng trên Algolia
- Mỗi dịch vụ có điểm khác biệt riêng ở các chi tiết, nhưng có một lưu ý quan trọng với các nhà phát triển đang tìm giải pháp tìm kiếm cho Postgres
- Không có giải pháp nào trong số này được xây dựng riêng cho Postgres
- Người dùng Postgres có khả năng gặp các vấn đề tương tự như với Elasticsearch khi dùng các dịch vụ này
Liệu có thể có cách tốt nhất của cả hai?
- ParadeDB là công cụ tìm kiếm toàn văn được xây dựng cho Postgres
- Dựa trên extension
pg_search, ParadeDB nhúng Tantivy, một lựa chọn thay thế Lucene viết bằng Rust, vào bên trong Postgres - Giống Postgres FTS, ParadeDB kết nối vào cơ sở dữ liệu Postgres tự quản lý hiện có mà không cần thêm hạ tầng
- Giống Elasticsearch, ParadeDB cung cấp các tính năng của một công cụ tìm kiếm toàn văn nâng cao
- Khả năng tương thích với các dịch vụ Postgres được quản lý như Amazon RDS sẽ sớm có
3 bình luận
Hóa ra Postgres FTS là nói về tính năng tích hợp sẵn.
Mấy bên này liên tục cải tiến và đăng các bài viết liên quan, nên cũng đã được chia sẻ trên GeekNews nhiều lần.
ParadeDB - PostgreSQL cho Search
pg_bm25 - Tiện ích mở rộng tìm kiếm toàn văn cho Postgres mang lại chất lượng ngang tầm Elastic
Các
paradedb,pg_searchvàpg_bm25được nhắc đến trong bài thực ra đều là cùng một dự án.