首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >Timescale 太迟钝了,起了个大早赶了个晚集

Timescale 太迟钝了,起了个大早赶了个晚集

作者头像
用户4035096
发布2026-07-09 20:20:03
发布2026-07-09 20:20:03
00
举报

Timescale 太迟钝了, 才想到开源 pg_textsearch

timescale 还是太迟钝了, 起了个大早干了个晚集,相当年可是为数不多拿到融资的PG时序数据库插件,我记得没错的话可能还是第一个拿到融资的PG插件,可是后面切换赛道有点慢,AI这趟车似乎一直没动作,没neon,crunchydata甚至后面的vectorchord,mooncake,paradedb动作快。现在才放出关键词搜索插件 pg_textsearch.

  • https://github.com/timescale/pg_textsearch

我早就说过 AI 搜索需要的是全家桶, 你先别管数据在什么产品里面, 我们就说AI 搜索, AI 没外脑, 仅仅凭它那训练过时数据生成的LLM的小脑瓜子, 能顶啥用?

AI 离了搜索就是过了气的老头, 脱离时代, 脱离社会, 脱离新技术, 脱离年轻人, 没啥鸟用.

所以搜索是AI 必须的.

那问题就来了, 谁说了搜索仅限于语义搜索? 这个不用争了吧, 不同的场景需要的数据是不一样的, 所以也需要关键词搜索、精确的标量搜索.

谁说了以上就够了呢? 还是场景、场景、场景啊~~~ 不同场景对数据的需求不一样啊同志们.

跟买房一样嘛, 地段地段还是地段嘛

你今天看到进入AI 搜索赛道的数据库还只有: 向量搜索、关键词搜索、标量搜索、混合搜索的能力.

未来, 马上就会出现OLAP的搜索需求、GIS的搜索需求、图的搜索需求、甚至更多, 总结一句话: 多模搜索能力.

AI 搜索要的是全家桶 !

好在国内已经很多产品意识到这点,开始面向AI搜索陆续推出产品了,例如:有分布式的全面解耦的晨章Eloq,单机加嵌入式的Oceanbase的seekdb。还有单机版的海量v100等。

回过头来看timescale 决定开源 pg_textsearch, 是不是有点迟钝. (之前开源的pg_vectorscale负责语义搜索)

vectorchord 早早就开源了三大件: vectorchord(负责向量语义搜索)、vectorchord-bm25和pg_tokenize(负责关键词搜索).

再回到数据库领域: 又回出现几大流派, 至少2大: 解决方案派、大一统派.

解决方案派:

你别管数据存哪里, 反正需求都满足你, 你要搜啥都行. 至于后面用什么技术、数据存多少份、有没有延迟、会不会经常出现数据错乱, 你别管.

大一统派:

数据就一份, 上面有多种计算引擎, 加速引擎, 你要的都在这. 全面解耦.

反正PG肯定是大一统派的, 插件太多了. 不过好在PG是单机版, 国产分布式版的全面解耦产品机会很多.


说了这么多, 我们还是看看pg_textsearch是啥吧?

pg_textsearch 是由 Timescale 团队开发的一个 PostgreSQL 扩展,旨在为 Postgres 提供高性能、现代化的全文搜索能力,特别针对 AI 工作负载和混合搜索(Hybrid Search)进行了优化。

以下是该产品的核心要点总结:

1. 核心功能

  • BM25 算法支持:引入了工业标准的 BM25(Best Matching 25)排名算法。相比 Postgres 原生的 ts_rank,BM25 在相关性评分上更精准,能够提供类似 Elasticsearch 等专业搜索引擎的搜索质量。
  • 极致性能:采用内存表(Memtable)架构和共享内存存储,设计目标是实现毫秒级的响应速度。
  • 混合搜索(Hybrid Search) :它可以与 pgvectorpgvectorscale 配合使用。开发者可以在同一个数据库、同一个查询中结合“语义搜索”(向量)和“关键词搜索”(BM25),从而大幅提升搜索的准确性。

2. 产品特点

  • 事务一致性:作为 Postgres 的原生扩展,它完全遵循事务原则。当你在数据库中更新或删除数据时,搜索索引会同步更新,无需像外部搜索引擎(如 Elasticsearch)那样处理复杂的数据同步或“最终一致性”问题。
  • 语法简洁:使用自定义操作符(如 <@>),让用户可以通过简单的 SQL 语句执行复杂的排名搜索。例如:ORDER BY content <@> 'search terms'
  • 高度兼容:支持 Postgres 原生的文本配置(如英语、中文等分词器),并支持分区表,适合处理大规模数据集。

3. 适用场景

  • RAG (检索增强生成) :在构建 AI 应用或聊天机器人时,需要快速且准确地从大量文档中检索上下文。
  • 替代外部搜索系统:如果你希望简化技术栈,不想维护单独的 Elasticsearch 或 Algolia 实例,pg_textsearch 可以让你直接在 Postgres 内部完成高质量的搜索。

总结

pg_textsearch 的出现让 PostgreSQL 变成了一个更强大的集成式 AI 数据库。它消除了在数据库和搜索引擎之间同步数据的痛苦,同时通过 BM25 算法显著提升了内置搜索的质量。

PG 的AI搜索插件现在也是够卷的, 对用户来说是好事.

你怎么看?欢迎留言

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2025-12-21,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 digoal德哥 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • Timescale 太迟钝了, 才想到开源 pg_textsearch
    • 1. 核心功能
    • 2. 产品特点
    • 3. 适用场景
    • 总结
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档