背景
1、产品的问题点
- PG 不支持索引随机采样
2、问题点背后涉及的技术原理
- 随机采样扫描用于返回随机数据. PG内置了表的随机采样方法, 例如按数据块随机采样、按记录随机采样.
- 但是无法采用固定扫描方法进行随机采样, 例如有where条件的SQL, 符合条件的有10万条, 但是期望随机返回100条. 目前的方法是取得10万条后随机排序返回, 或者给定一个随机数返回.
select * from x where xxx order by random() limit x;机会公平, 但是需要扫描所有符合条件的记录, 同时增加了排序成本select * from x where xxx and random() < xx limit x;跳过不满足条件的行, 但是这种方法的机会不公平, 很容易导致无法获取到索引扫描末尾符合条件的行.- 以上都会导致过度计算, 目前PG无法在索引扫描方法上根据符合条件的index block再随机扫描
3、这个问题将影响哪些行业以及业务场景
- 通常被用于推荐系统, 在满足条件的记录范围内进行随机推荐.
4、会导致什么问题?
- 导致过度计算
5、业务上应该如何避免这个坑
- 暂时没有特别好的方法, 除非改业务逻辑
- 《重新发现PostgreSQL之美 - 26 这个推荐算法价值1亿》
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 需要非常专业的知识
7、数据库未来产品迭代如何修复这个坑
- 希望内核支持 index scan sample method , 对应table sample, 这个是索引扫描的随机采样功能.
- 例如在branch层随机选择leaf page.
