背景

1、产品的问题点

• PG 物化视图不支持基于log的增量刷新

2、问题点背后涉及的技术原理

• PG 的物化视图支持2种刷新方式

• • 1、全量刷新, 相当于重建mv, 然后交换底层数据文件filenode. 会堵塞查询.

• • • 堵塞整个全量刷新过程, 而不仅仅是交换底层filenode时.

• • 2、增量刷新, 物化视图必须有UK, 相当于重新计算一次物化视图的内容, 然后逐条与当前物化视图进行比对(类似full outer join), 发现发生变化的行进行更新, 新增的行写入, 删除的行进行删除.

• oracle mv log https://docs.oracle.com/cd/E18283_01/server.112/e17118/statements_6003.htm

3、这个问题将影响哪些行业以及业务场景

• 通常AP类场景会使用MV

4、会导致什么问题?

• PG 这种基于PK比较(UK diff)的增量刷新需要产生较大查询, 效率更低, 这个操作通常无法频繁进行. 所以需要较为实时的获得物化视图刷新的场景无法满足.
• 增量刷新过程中有merge join的可能, 重新计算变化量时可能会产生大量sort的临时文件.

• • 使用这个方法可以观测到 《PostgreSQL 兼容Oracle sql_trace 10046 10053 方法 - SQL诊断跟踪》

5、业务上应该如何避免这个坑

• 降低增量刷新频率
• 或者不使用物化视图

6、业务上避免这个坑牺牲了什么, 会引入什么新的问题

• 降低刷新频率, 用户查询到的物化视图数据可能比较旧, 无法满足业务较为实时的查询需求
• 放弃使用物化视图, 则无法享受物化视图带来的速度提升

7、数据库未来产品迭代如何修复这个坑

• 希望内核层面支持mv log, 通过mvlog增量刷新不需要重新生成全量物化视图数据做full outer join的逐条比对, 而且两次刷新之间同一条记录如果update多次的话, 刷新时这条记录在物化视图上也只需要更新一次, 从而增量刷新的效率可以大幅度提高, 从而提高物化视图刷新的实时性.

• • https://github.com/sraoss/pgsql-ivm
  • https://github.com/Blazebit/blaze-ivm
  • https://www.postgresql.org/message-id/flat/20181227215726.4d166b4874f8983a641123f5%40sraoss.co.jp