见招拆招-PostgreSQL中文全文索引效率优化 (2)

这时候,我们也并不需要很愣地把全国名字中带有饭店、宾馆的地点都拿出来排序,这样的排序结果用户也不一定满意。 我们可以只取一部分 Poi 地点给用户,如果结果用户不满意,会再完善关键词,而关键词稍有完善,结果集就会极大地减小。

子查询用来实现结果集过滤非常有效,如我们可以在极大页码查询分页时使用子查询先过滤掉一大批无用数据。

本例中,我们在子查询语句中使用 limit 语句限制取的结果集条数,从而大大减小排序压力,查询语句类似 SELECT id FROM (SELECT * FROM table WHERE tsv @@ tsq OR name LIKE 'keyword%' LIMIT 10000) AS tmp ORDER BY score DESC。

这样优化过后,查询语句的最差性能也可以稳定在 170ms 以下了。

替换B树索引消灭慢查询 多索引效率问题

本以为优化到此为止了呢,可是有次在试着查询 中关村 和 东 两个关键词时,我明确感觉到了响应时间的差异, 100ms 左右的时间差还是很明显的。

子查询语句才是这条 SQL 语句的效率关键,于是我开始分析 东 这个关键词的 子查询SQL 语句,首先我试着调整语句中 limit 的限制值,发现即使只取 1000条,响应时间也在 100ms 以上。

接着我又尝试改变 SQL 语句的 WHERE 条件,去除 OR name LIKE 'keyword%' 后, 总条数并没有太大的变动,结果集由 13w 减小到了 11w, 但 添加 limit 后的效率却急剧提升:

SQL 结果条数 响应时间 添加 limit 后 SQL 响应时间
WHERE tsv @@ tsq OR name LIKE 'keyword%'   13W   2400ms       WHERE tsv @@ tsq OR name LIKE 'keyword%' LIMIT 10000   170ms  
WHERE tsv @@ tsq   11W   1900ms       WHERE tsv @@ tsq limit 10000   25ms  

这样对比起来就很明显了, 分词查询的 GIN 索引和前缀词查询的 B树索引之间配合并不完美。

想想也是,如果在一个索引上取 1w 条数据,直接取就行了,而如果在两个索引上取 1w 数据,那么还得考虑每个索引上各取多少,取完后还要排重。

替换B树索引

问题分析完,那么就得根据问题寻找解决方案了,怎么能把两个索引并到同一索引上呢?把分词 GIN 索引并到 B树索引显然是不可能的,只能试着使用分词来替代 B树索引。

当时有三种方案:

修改开源分词库 scws,添加一个分前缀词的功能。不过我担心改出 Bug,而且还要改 PostgreSQL 的分词插件 zhparser 以适应 scws 的参数变动。

使用 PostgreSQL 的数组类型(text[])存储分词结果,后续往此字段内灵活添加前缀词。但填充数组字段需要调用 SELECT to_tsvector('parser', 'nane') 查询后使用脚本处理结果后再写入数组,比较麻烦。

修改 tsvector 分词向量字段,手动向此字段添加前缀词的分词向量。但分词向量不同于文本,不能直接拼接。

最好的方案当然是最后一种,改动最小,于是我就查询了一下 PostgreSQL 向量拼接,还是找到了向量拼接的方法,使用 ::tsvector 将字符串强转成向量,再使用 || 拼接到原来的分词向量上,SQL 语句类似 SELECT to_tsvector('parser', 'keyword') || 'prefix'::tsvector。

在查询时,就可以直接使用 WHERE tsv @@ to_tsquery('parser', 'keyword') 查询前缀了。这样,子查询语句的响应时间就可以大大降低了,在 50ms 左右,而且还可以通过减小 LIMIT 值来加快响应。

此后,B树索引就可以退休啦~

小结

以上就是我对 PostgreSQL 关键词查询从效果到效率优化的全过程了,效果和效率已经完全达标了。当然,还可以对用户体验进行再优化,比如添加错别字识别、拼音首字母智能识别等,打磨好一款产品当然是非常不容易的,还需要继续努力。

顺便吐槽几句周边同事对 PostgreSQL 的态度,理由竟然是认为它是一个开源产品,可能会有各种埋得深的坑,所以不信任。

比较想不到比较前沿的互联网公司也会有人对开源抱如此看法,不可否认很多开源产品或工具都有各种各样的坑,但为此因噎废食大可不必,我们一直在用的 Linux/Git 还是开源产品呢,可有多少人离不开它们?而且闭源产品就不会出现问题么?也不可否认 PostgreSQL 小众,但它也有自己的特色,而且近年来它的占有率一率攀升,未来什么样,还未可知。

关于本文有什么问题可以在下面留言交流,如果您觉得本文对您有帮助,可以点击下面的 推荐 支持一下我,博客一直在更新,欢迎 关注

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpyfyp.html