背景
1、产品的问题点
- PG 倒排索引启动代价较高
2、问题点背后涉及的技术原理
- gin索引是多值列的索引方法, 多值列内的TOKEN作为索引KEY、对应的多个行号作为value, 构建索引树.
- 使用gin索引搜索数据时分为3个阶段
- 1、bitmap index scan, 取得符合条件的所有行号, 获得对应的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消耗.
