【DB吐槽大会】第43期 - PG 倒排索引启动和recheck代价高

背景

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消耗.