【DB吐槽大会】第39期 - PG 物化视图不支持基于log的增量刷新

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 大家好,这里是DB吐槽大会,第39期 - PG 物化视图不支持基于log的增量刷新

背景


1、产品的问题点

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

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

  • PG 的物化视图支持2种刷新方式
  • 1、全量刷新, 相当于重建mv, 然后交换底层数据文件filenode. 会堵塞查询.
  • 堵塞整个全量刷新过程, 而不仅仅是交换底层filenode时.
  • 2、增量刷新, 物化视图必须有UK, 相当于重新计算一次物化视图的内容, 然后逐条与当前物化视图进行比对(类似full outer join), 发现发生变化的行进行更新, 新增的行写入, 删除的行进行删除.

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

  • 通常AP类场景会使用MV

4、会导致什么问题?

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

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

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

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

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

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

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

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
2月前
|
SQL 关系型数据库 MySQL
Hadoop-25 Sqoop迁移 增量数据导入 CDC 变化数据捕获 差量同步数据 触发器 快照 日志
Hadoop-25 Sqoop迁移 增量数据导入 CDC 变化数据捕获 差量同步数据 触发器 快照 日志
44 0
|
6月前
|
SQL DataWorks Oracle
DataWorks产品使用合集之datax解析oracle增量log日志该如何操作
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
62 0
|
存储 分布式计算 算法
基于 Log 的通用增量 Checkpoint
本文将从 Checkpoint 的性能优化历程出发,介绍 ChangelogStateBackend 的基本机制、应用场景和未来规划,同时介绍最新版本在 State 上的一些优化工作。
7501 2
基于 Log 的通用增量 Checkpoint
|
7月前
|
canal 消息中间件 关系型数据库
大数据数据库增量日志采集之Canal
大数据数据库增量日志采集之Canal
|
7月前
|
存储 数据库
HBR混合云备份中,累计增量备份和日志备份
【1月更文挑战第3天】【1月更文挑战第15篇】 HBR混合云备份中,累计增量备份和日志备份
63 1
|
canal 负载均衡 关系型数据库
Flink CDC如何获得增量binlog,可能是跟canal一样,伪装成从节点获取日志?
Flink CDC如何获得增量binlog,可能是跟canal一样,伪装成从节点获取日志?
168 1
|
存储 消息中间件 机器学习/深度学习
基于 Log 的通用增量 Checkpoint 在美团的进展
美团计算引擎工程师王非凡,在 Flink Forward Asia 2022 核心技术专场的分享。
5585 0
基于 Log 的通用增量 Checkpoint 在美团的进展
|
关系型数据库 MySQL
日志开始恢复后8小时,连接会断开 Aborted connection 4 to db
从日志中观察到,日志开始恢复后8小时,连接会断开
171 0
|
canal 消息中间件 关系型数据库
使用阿里的增量日志解析工具canal
canal [kə'næl],译意为水道/管道/沟渠,主要用途是基于 MySQL 数据库增量日志解析,提供增量数据订阅和消费早期阿里巴巴因为杭州和美国双机房部署,存在跨机房同步的业务需求,实现方式主要是基于业务 trigger 获取增量变更。从 2010 年开始,业务逐步尝试数据库日志解析获取增量变更进行同步,由此衍生出了大量的数据库增量订阅和消费业务。
343 0
使用阿里的增量日志解析工具canal
|
SQL 存储 安全
MySQL日志管理和完全备份增量备份与恢复(二)
MySQL日志管理和完全备份增量备份与恢复(二)
MySQL日志管理和完全备份增量备份与恢复(二)