第43期吐槽:PG GIN倒排索引启动和recheck代价高
文中参考文档点击阅读原文打开, 同时推荐2个学习环境:
1、懒人Docker镜像, 已打包200+插件:《最好的PostgreSQL学习镜像》
2、有web浏览器就能用的云起实验室: 《免费体验PolarDB开源数据库》
3、PolarDB开源数据库内核、最佳实践等学习图谱: https://www.aliyun.com/database/openpolardb/activity
第43期吐槽:PG GIN倒排索引启动和recheck代价高
1、产品的问题点
• PG 倒排索引启动代价较高, 什么是启动代价呢? 就是返回第一行之前需要花费的代价.
2、问题点背后涉及的技术原理
• gin索引是多值列的索引方法, 多值列内的TOKEN/元素作为索引KEY、对应的多个行号作为value, 构建索引树.
• 使用gin索引搜索数据时分为3个阶段
• 1、bitmap index scan, 取得符合条件的所有行号(ctid), 获得对应的block id.
• 2、bitmap heap scan, 根据block id按顺序从heap 表搜索数据. (这一步会放大搜索结果, 因为一个block里面哪怕只有1条符合条件的记录, 也需要返回这个block内的所有记录).
• 3、recheck, 根据查询条件再做一次 recheck , 过滤被放大的无效记录.
• 显然, 第1步bitmap index scan的启动成本较高, 因为不管要不要limit结果或者流式返回, 都需要执行这一步
3、这个问题将影响哪些行业以及业务场景
• 使用GIN倒排索引的场景, 例如全文检索、根据数组条件进行的用户圈选、JSON条件筛选
4、会导致什么问题?
• 启动成本过高 , 即使如下限制, index扫描依旧是全代价.
• 使用 limit 限制返回结果数
• 翻页或游标返回时,
• 不需要返回所有结果时
• 除了启动成本的问题, 另一个问题是recheck, 会带来较大的cpu开销, 高并发时尤为明显.
• 使用explain analyze可以看到bitmap index scan阶段的耗时.
5、业务上应该如何避免这个坑
• 可以采用rum索引代替gin索引
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
• 引入了第三方插件, 增加了风险
• rum 插件的wal日志效率较低, 在它的roadmap中已经表明
7、数据库未来产品迭代如何修复这个坑
• 希望gin可以同时支持index scan和bitmap scan
• 当有效ctid较少时, 同时使用ssd时, 实际上index scan效率可能更高, 可以避免recheck带来的高cpu消耗.
如果你对索引原理感兴趣, 可以参考我其他的文章:
• 《从难缠的模糊查询聊开 - PostgreSQL独门绝招之一 GIN , GiST , SP-GiST , RUM 索引原理与技术背景》
• 《PostgreSQL 9种索引的原理和应用场景》
• 《PostgreSQL GIN索引实现原理》
• 《自动选择正确索引访问接口(btree,hash,gin,gist,sp-gist,brin,bitmap...)的方法》
• 《PostgreSQL bloom 索引原理》
• 《PostgreSQL RUM 索引原理》
• 《PostgreSQL SP-GiST 索引原理》
• 《PostgreSQL GiST 索引原理 - 4》
• 《PostgreSQL GiST 索引原理 - 3》
• 《PostgreSQL GiST 索引原理 - 2》
• 《PostgreSQL GiST 索引原理 - 1》
本期彩蛋-招商中,有需要的小伙伴可联系嵌入...
文章中的参考文档请点击阅读原文获得.
欢迎关注我的github (https://github.com/digoal/blog) , 学习数据库不迷路.
近期正在写公开课材料, 未来将通过视频号推出, 欢迎关注视频号: