【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消耗.
上一篇:MGR重启


下一篇:MYSQL MGR 从入门到精通 02