由 John Doe 十二月 12, 2025
在为 PostgreSQL 中存储的数据寻找全文搜索的解决方案时，最终的选择往往聚焦于Elasticsearch 与 PostgreSQL 原生全文搜索之间。
什么是全文搜索？
全文搜索是一种基于特定关键词和短语的存在率，在文本集合中查找条目的技术。大多数搜索引擎（如 Elasticsearch）采用 BM25 算法对搜索结果进行排序。该算法会综合考虑某个术语的出现频率以及其在所有文档中的独特性。
全文搜索与相似性搜索（也称为向量搜索）有所不同，后者是根据语义含义搜索并排序结果。许多现代应用会结合使用全文搜索和相似性搜索，这种方式被称为混合搜索，能够产出更精准的结果。
PostgreSQL 原生全文搜索
PostgreSQL 全文搜索是所有 PostgreSQL 数据库均具备的原生功能。它利用tsvector数据类型（将文本存储为可搜索的标记）和 GIN 索引（提升搜索速度）来实现功能。
优势
- 简洁易用：PostgreSQL 全文搜索无需额外的基础设施，且在所有托管 PostgreSQL 服务（如AWS RDS）中均可直接使用。从长远来看，无需编排和管理外部搜索引擎，能节省大量时间并减少麻烦。
- 实时搜索：借助 PostgreSQL 全文搜索，数据提交后可立即被搜索到。这对于要构建面向用户或对延迟敏感的搜索体验的公司（例如电子商务网站或金融科技公司）来说，极为实用。
- 完善的事务与多版本并发控制：PostgreSQL 的 ACID 事务和多版本并发控制（MVCC）机制，确保了在并发访问和频繁更新的场景下，全文搜索结果的可靠性。
劣势
- 功能不完善：PostgreSQL 全文搜索的功能集较为有限，这可能成为部分公司的决策障碍。缺失的功能包括 BM25 评分、相关性调优、自定义分词器和分面搜索。
- 大数据集性能不佳：虽然 PostgreSQL 全文搜索在处理数百万行数据的表格时表现良好，但当表数据量达到数千万行时，其性能会显著下降。
- 事务开销：在某一列上创建 GIN 索引后，会给影响该列的事务增加少量延迟（通常为毫秒级）。
核心结论
PostgreSQL 全文搜索适用于无需复杂全文搜索查询的中小型表。而对于“中型表”和“复杂查询”的应用场景，会因性能要求的不同，出现很大的表现差异。幸运的是，测试 PostgreSQL 全文搜索以及与之相关的迁移操作都相对简单易行。
Elasticsearch
Elastic 旗下拥有多种产品，但其核心产品 Elasticsearch 是一款数据存储与全文搜索引擎。
优势
- 功能全面：Elasticsearch 几乎能够处理所有类型的全文搜索查询。其专属的查询领域特定语言（Elastic Query DSL）是全文搜索功能的业界标杆。
- 性能卓越：我们的基准测试显示，得益于其底层经过实战检验的 Lucene 搜索引擎和分布式架构，Elasticsearch 能够在毫秒级内完成对数十亿行数据的查询。
- 不止于搜索：除全文搜索外，Elasticsearch 还是一款分析查询引擎、向量数据库、安全与可观测性平台。许多组织倾向于将多项服务整合在 Elasticsearch 中，享受其带来的简洁性。
劣势
- 非可靠数据存储：在尝试将 Elasticsearch 作为主数据存储时，存储的数据很难实现高可靠性，Elasticsearch 缺乏 ACID 事务和 MVCC 机制，可能导致数据不一致和丢失；同时，其不具备关系型特性且缺乏实时一致性，使得许多数据库查询操作难以实现。
- 需依赖ETL管道：由于 Elasticsearch 并非可靠的数据存储，使用 PostgreSQL 的组织通常需要通过提取、转换和加载（ETL）流程，将数据从 PostgreSQL 迁移至 Elasticsearch。而 ETL 管道的故障可能引发各类生产环境中断，因此必须精心维护这些管道，以避免因PostgreSQL底层架构变更而导致故障。
- 数据新鲜度不足：ETL 作业耗时较长且按固定周期运行，导致 Elasticsearch 中的数据往往比 PostgreSQL 滞后数小时。这对于需要对PostgreSQL表格进行实时搜索的应用来说，可能是无法接受的。
- 成本高昂：很多企业表示 Elasticsearch 已成为其最大的软件支出项。随着 Elasticsearch 集群成本的飙升，许多企业从 Elasticsearch 云服务转向了自托管模式。虽然这降低了云服务支出，但却带来了新的问题：Elasticsearch 的运行、调优和管理难度众所周知。这些组织随后不得不聘请高薪工程师来管理其 Elasticsearch 集群。
核心结论
Elasticsearch 以牺牲运维开销和数据新鲜度为代价，提供了出色的搜索性能。如果更轻量级的替代方案无法满足需求，或者你打算使用 Elasticsearch 的其他服务，我们建议选择 Elasticsearch。
其他替代搜索引擎
近年来，一批现代搜索引擎应运而生，例如 Algolia、Meilisearch 和 Typesense。这些引擎常用于构建面向用户的搜索体验（例如，Hacker News 的搜索功能便是基于 Algolia 构建的）。
尽管这些服务在细节上各有差异，但对于寻求适配 PostgreSQL 搜索方案的开发者而言，存在一个重要注意事项：这些方案均非专门为 PostgreSQL 设计。因此，PostgreSQL 用户使用这些服务时，可能会遇到与使用 Elasticsearch 类似的诸多问题。
ParadeDB
ParadeDB 是一款专为 PostgreSQL 打造的全文搜索引擎。它基于名为pg_search的扩展，将 Rust 语言开发的 Lucene 替代方案 Tantivy 嵌入 PostgreSQL 内部。与 PostgreSQL 原生全文搜索类似，ParadeDB 可接入任何现有的自托管 PostgreSQL 数据库，无需额外基础设施；同时，它又具备 Elasticsearch 那样的高级全文搜索引擎功能。
目标应用场景
目前，ParadeDB 专注于为希望搜索 PostgreSQL 数据库的用户打造一套核心应用场景。ParadeDB 的主要特点：
- 基于 Postgres 构建单一数据源，而非在多个服务中重复数据。
- 可以对存储在 Postgres 中的大量文档执行全文搜索，同时又不影响性能或可扩展性。
- 将人工神经网络/相似性搜索与全文搜索相结合，以提高语义匹配效果。
产品
ParadeDB 使 PostgreSQL 具备了专用搜索引擎的功能。
- BM25评分：全文搜索，支持布尔查询、模糊查询、增强查询和关键词查询。搜索结果使用 BM25 算法进行评分。
- 分面搜索：轻松对全文搜索结果进行分类和指标收集。
- 混合搜索：结果根据语义相关性（即向量搜索）和全文相关性（即 BM25）进行评分。
- 实时搜索：文本索引和向量列与底层数据自动保持同步。
参考
ParadeDB：https://github.com/paradedb/paradedb