Tin：Postgres 的全文搜索

客户最向我们要求的 Postgres 功能之一是全文搜索。今天，我们很高兴地推出 TIN：一个快速、功能齐全、可靠的 Postgres 全文搜索扩展。 TIN 代表“文本索引”，这就是它的作用。 TIN 作为所有 Postgres 和 Neki 数据库的 GA 版本立即可用。检查一下：CREATE INDEX an_index_name ON table_name USINGtin(text_column_name); SELECT * FROM table_name WHERE text_column_name ==> '一些单词' ;我们构建 TIN 是因为我们相信良好的文本索引应该支持： 布尔表达式、短语查询和跨度查询 术语的模糊、通配符和正则表达式匹配 大小写和重音折叠 COUNT(*) 查询和 BM25 评分的 top-k 查询 Postgres 中良好的文本索引必须支持所有这些功能，同时还处理联接、跨全文和其他列类型的复杂 WHERE 子句、连续更新、复制、备份和正确的事务可见性。尽管 Postgres 至少已有三个文本搜索索引，但没有一个满足所有这些要求。 TIN 确实如此。 TIN 的速度也确实快得令人难以置信。应用程序开发人员使用文本索引来构建各种搜索功能。电子商务平台可能需要搜索包含搜索中所有关键字的前十个产品： SELECT * FROM products WHERE description ==> 'stretch denim jeans' ORDER BYtin 。 Score (ctid) DESC LIMIT 10 法律发现平台可能需要返回包含一个或多个关键字的每个文档，但根本不关心排名： SELECT * FROM emails WHERE body ==> '[内幕交易阴谋]' 照片标记平台可能会显示带有特定标签的照片的精确计数： SELECT COUNT ( * ) FROM photos WHERE Tags ==> '"san francisco"' ;大多数应用程序还需要插入、更新和删除文档，甚至在继续查询索引的同时也是如此。搜索查询必须在提交新行或更改行后立即返回匹配项。我们运行基准测试来评估所有上述用例及更多用例的性能。我们尝试了工作负载：连词（必须包含所有单词）、析取（必须包含任何单词）和短语（必须按顺序包含所有单词）查询以及这三种查询的混合。计数文档或要求 BM25 分数的前 k 个。无论客户端是否与基准查询工作负载同时将新数据写入索引。我们根据各种文本语料库测量了 TIN：所有维基百科、总计 2.3 TB 的 Reddit 评论集合，以及我们简单称为“堆”的混合工作负载，其中包括 797 GB 的开放获取研究论文、法律文件、公共领域书籍和安然电子邮件。我们在本文中分享的基准测试结果来自 Stack Exchange 的问题和答案导出：一个包含 1.5 亿个文档的 85 GB 语料库。由于语料库没有标准查询跟踪，因此我们通过对 2 到 15 个术语范围内的子字符串进行采样来生成一个合成的查询跟踪。我们以三种方式解释每个子字符串：作为连词、作为析取词和作为短语查询，总共 1,719 个查询。我们在具有本地 NVMe 存储和支持 AVX-512 的现代 CPU 的 AWS i7i.8xlarge EC2 实例上运行了基准测试。对于每个文本搜索扩展，我们在一个仅限 8 个 vCPU 和 32 GB RAM 的隔离容器中设置 Postgres 18.6。它足够小，足以显示当索引不适合 Postgres 缓冲区时每个索引系统的执行情况。基准测试阶段按顺序运行，因此引擎不会争夺资源。我们选择了独立的 EC2 实例，以最大程度地减少运营开销和复制的影响，并确保任何想要重现我们的竞争文本搜索索引基准的人都可以使用相同的实例类型和容器限制来实现。为了推动 Postgres 容器的搜索流量，我们使用了 ParadeDB Benchmarker 。我们有一个分叉版本，可以在开始测量之前进行预热，并添加读取字节和写入 WAL 字节的指标。我们将所有 Postgres 参数保留为 Benchmarker 提供的默认值，除了三个参数：我们将 max_parallel_workers 设置为 8（从 40），shared_buffers 设置为 24 GB（从 128 MB），将maintenance_work_mem 设置为 24 GB（从 64 MB），以最好地匹配容器的资源。我们在与目标 Postgres 服务器相同的 EC2 实例上运行 Benchmarker，以确保网络延迟不会影响测量结果。对于每种场景，我们都针对能够运行工作负载的所有其他 Postgres 文本搜索索引（ParadeDB v0.25.2、pg_textsearch v1.4.0 和 Postgres v18.6 中内置的 GIN 索引）测量了 TIN v1.0.2 的性能。除了 TIN 之外，只有 ParadeDB 能够完成所有基准测试。索引占语料库大小的 33% 到 61%，准备、构建和最终确定需要 8 到 129 分钟。除了 TIN 之外的三个引擎因容器配置的 32 GB 限制而失败，因此对于索引