【重新发现PostgreSQL之美】- 46 既要又要还要

背景

场景:

• 实时分析行业SaaS, 低代码场景满足客户个性化分析的诉求.
• 单个用户的数据总量T级别.
• 业务数据需要实时写入.
• 用户分析师拖拽式试错, 产生合理的分析模板. 结果则需要实时高并发查询(例如为不通属性用户定制的动态页面, 需要实时识别用户的属性(即分析结果)), 结果还有二次分析诉求.

挑战:

• 既要又要还要:

• 用户拖拽式试错, 需要实时分析计算能力.
• 分析框架固定后, 需要实时查询, 结果有高并发诉求.
• 业务数据实时写入, 用业务+大数据库成本高, 同步延迟高、一致性等问题突出.
• 单个用户的数据总量T级别, 不大不小. 用大数据成本高.
• 如果拖拽后的固定结果使用普通视图, 那么它只是SQL语句, 不存储结果数据, 也无法支持索引, 查询视图时耗费计算, 效率低, 无法支持高并发.
• 如果存储结果, 那么对于采用逻辑复制的数据库, 需要等事务结束客户端才能apply事务, 只读实例延迟高. 物化视图刷新是大事务, 因此这种场景无法通过只读实例扩展性能.

PG解决方案:

• 并行计算+JIT满足TB级别拖拽式实时分析需求.
• 物化视图, 已经算好, 查询效率高.
• 支持在物化视图上创建索引, 效率高.
• 定时任务增量刷新物化视图, 可以反映基表变更实时信息.
• 流复制只读实例, 流式复制, 不需要等事务结束, 解决只读实例延迟高问题.
• 支持物化视图与基表采用不一致的存储引擎, 例如基表要高并发dml使用行存储, 物化视图如果要大量二次分析可以使用列存储. 使得可以适合最好的效率.