digoal
2021-09-08
PostgreSQL , 物化视图 , 增量刷新 , 增量日志 , mv log
1、产品的问题点
- PG 物化视图不支持基于log的增量刷新
2、问题点背后涉及的技术原理
- PG 的物化视图支持2种刷新方式
- 1、全量刷新, 相当于重建mv, 然后交换底层数据文件filenode. 会堵塞查询.
- 堵塞整个全量刷新过程, 而不仅仅是交换底层filenode时.
- 2、增量刷新, 物化视图必须有UK(唯一索引), 相当于重新计算一次物化视图的内容, 然后逐条与当前物化视图进行比对(类似full outer join), 发现发生变化的行进行更新, 新增的行写入, 删除的行进行删除.
- 1、全量刷新, 相当于重建mv, 然后交换底层数据文件filenode. 会堵塞查询.
- oracle mv log技术: https://docs.oracle.com/cd/E18283_01/server.112/e17118/statements_6003.htm
3、这个问题将影响哪些行业以及业务场景
- 通常OLAP类场景会使用MV(物化视图)
4、会导致什么问题?
- PG 这种基于PK比较(UK diff)的增量刷新需要产生较大查询, 效率更低, 这个操作通常无法频繁进行. 所以无法满足需要较为实时的获得物化视图刷新场景的需求.
- 增量刷新过程中有merge join的可能, 重新计算变化量时可能会产生大量sort的临时文件.
5、业务上应该如何避免这个坑
- 降低增量刷新频率.
- 使用视图, 而不使用物化视图. 视图是实时计算的.
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 降低刷新频率, 用户查询到的物化视图数据可能比较旧, 无法满足业务较为实时的查询需求
- 放弃使用物化视图, 使用普通视图, 无法享受物化视图(已计算得出结果)带来的速度提升的效果.
7、数据库未来产品迭代如何修复这个坑
- 希望内核层面支持mv log, 通过mv log增量刷新不需要重新生成全量物化视图数据做full outer join的逐条比对, 而且两次刷新之间同一条记录如果update多次的话, 刷新时这条记录在物化视图上也只需要更新一次, 从而增量刷新的效率可以大幅度提高, 从而提高物化视图刷新的实时性.
您的愿望将传达给PG kernel hacker、数据库厂商等, 帮助提高数据库产品质量和功能, 说不定下一个PG版本就有您提出的功能点. 针对非常好的提议，奖励限量版PG文化衫、纪念品、贴纸、PG热门书籍等，奖品丰富，快来许愿。开不开森.
