不懂文本搜索就无法理解RAG

本期播客

大学生数据库实践课：自定义文本搜索压力测试

在处理海量数据的搜索业务时，我们经常会遇到两类极端挑战：一类是要求 “完全匹配”的语义检索（全文检索），另一类是要求 “长得像就行”的相似度搜索（如海明距离）。

传统数据库在面对这类需求时，往往需要笨重的架构调整，甚至得求助于专门的搜索引擎。但我一直强调，PostgreSQL 强大的插件化生态和索引机制，足以在数据库内部以极高的效率完成这些任务。今天我合并总结了两个典型的 OLTP 字符串搜索场景：海明距离相似查询与全文检索。

场景一：文本特征向量 - 海明距离相似查询

对于长文本语义搜索，全文检索有时并不完美。更专业的做法是提取文本的 SimHash（海明码特征向量）。我们的目标是：在 1 亿条 海明码数据中，快速找回与输入目标距离在 3 以内的记录。

核心设计与实现

• 存储与算法：使用 64 位 bit(64) 存储海明码。为了加速搜索，利用 smlar 插件将海明码切割为多个片段存入数组（text[]）。
• 性能黑科技：

1. 切片索引：将 64 位编码切成 4 段，通过 GIN 索引 加速 Overlap 运算。
2. 二次过滤：利用 bitxor 异或运算和 length(replace(...)) 快速计算精确的海明距离。

除此方法之外, 也可以使用 hnsw 索引的海明距离搜索加速.

压测表现

在 56 核、SSD 存储的 ECS 环境下，对 1 亿数据进行相似度检索：

• 单次响应时间：约 1.14 毫秒。
• 吞吐量 (TPS) ：达到 49,054。

这证明了在高频 OLTP 场景下，PostgreSQL 处理特征向量检索的实力。

场景二：经典字符串搜索 - 全文检索

许多开发者习惯把全文检索丢给 Elasticsearch，但这样会带来架构复杂、数据同步延迟以及索引 Build 与写入冲突等麻烦。PostgreSQL 内置的全文检索不仅支持实时写入索引，还能处理正则、前后模糊匹配。

核心设计与实现

• 数据模型：使用内置的 tsvector 类型存储分词后的文本特征。
• 索引加速：采用 GIN (Generalized Inverted Index) 倒排索引，它是全文检索性能的定海神针。
• 场景模拟：在 1 亿条 随机文本记录中，执行随机单词组合的语义匹配查询。

压测表现

同样的硬件环境下，对 1 亿条文本进行全文检索：

• 单次响应时间：约 1.08 毫秒。
• 吞吐量 (TPS) ：达到 51,369。

深度总结：为什么选 PostgreSQL？

通过这两组测试，我们可以看到 PostgreSQL 在 HTAP（混合负载）场景下的恐怖性能。它的优势在于：

1. 极致的简化：无需同步数据到搜索引擎，开发成本极低，架构极其扁平。
2. 绝对的实时性：写入即查询，索引与事务同步，没有搜索引擎常见的“近实时”延迟。
3. 插件化扩展：无论是 smlar 向量相似度插件，还是内置的 gin 索引，让 PG 具备了处理基因测序、图像分析等前沿领域的能力。

总结一句话：在 1 亿级规模的 OLTP 搜索场景下，PostgreSQL 的平均响应时间稳定在 1 毫秒左右。对于绝大多数互联网和企业级应用，这已经是性能的“天花板”级别了。

详细教程, 点击「阅读原文」