标签
PostgreSQL , 共享分布式存储 , 存储计算能力。
背景
随着互联网的发展,数据爆炸性的增长,数据库逐渐成为了很多业务的绊脚石,很多业务也哭着喊着要上分布式数据库(个人认为大部分是高估了自己的业务)。
分布式数据库又分很多流派,比如重点要说的sharding和共享分布式存储的架构,它们有着什么样的优缺点呢?
sharding vs 共享分布式存储 数据库架构
如果要在单机并行能力的前提下,再实现多机器并行,可以有两种玩法:
第一种玩法,可以带其他产品一起玩,用PostgreSQL 10+的fdw+append parallel+继承+pushdown(join,agg,where,sort,...)+merge sort,可以实现对任意产品的多机并行(比如后端可以是MySQL)。
第二种玩法,更加的先进,节点间不仅共享数据,而且能直接通讯,每个节点运算数据的一部分(至少需要改进优化器实现这个功能),多机并行,任意表任意字段JOIN,多阶段聚合等都能上阵,简单来说就是具备MPP的能力。
citus有这样的潜质,当然需要适配共享存储架构进行改造。
点评
1、作为OLTP业务,使用sharding带来的问题较多,有点得不偿失。
1、1. 扩容不方便(数据重分布)
1、2. 分布键变更很麻烦
1、3. 分布键选择(架构设计)谨慎
1、4. 跨库JOIN性能差,甚至只能按分布键JOIN,其他字段不支持JOIN。(因为这种产品架构数据节点之间是孤岛,数据需要在孤岛之间交互,需要通过上层的中间件节点,而这样的话,如果有跨库JOIN,就需要将数据收到中间件节点再JOIN,性能差是可想而知的。)
1、5. 分布式事务性能差,甚至不支持分布式事务。
1、6. SQL限制多、功能缺失多
1、7. 应用改造成本巨大
1、8. 全局一致性时间点恢复几乎不可实现
2、作为OLAP业务,如果使用sharding(MPP)架构,是值得的,可以充分利用多机的计算能力、IO能力,提高处理吞吐,例如阿里云的HybridDB for PG。
而如果使用中间件的sharding形态,则不适合OLAP业务。(原因是节点间不支持互通,在AP中有大量的JOIN需求,节点间不同带来一个问题,JOIN需要将数据汇聚到中间件节点执行,导致非常慢,几乎不可用)
HDB PG是MPP形态的产品,计算节点之间可以相互通讯,任意列的JOIN都不存在问题,同时还支持行列混合,多阶聚合的功能,是专门为OLAP场景打造的一款PB级分布式分析数据库。
《阿里云HybridDB for PostgreSQL实践 - 多阶聚合》
HDB PG支撑了很多海量分析的业务场景。
3、作为HTAP(oltp+olap)业务,使用共享分布式存储,一写多读的架构,是目前最先进的架构。
3、1. 实例扩容方便(秒级新增只读节点)
3、2. 存储扩容方便(几乎无限扩展IO、带宽)
3、3. 不存在分布键问题
3、4. 不存在跨库JOIN问题
3、5. 不存在分布式事务问题
3、6. SQL没有任何限制
3、7. 应用无需改造
3、8. 支持全局一致性时间点恢复
3、9. 只读节点延迟毫秒内
3、10. 所有节点都支持并行计算
3、11. 分布式存储:存储和引擎分离后,存储可以专心支持多副本,支持跨域容灾,支持高带宽,支持几乎无限的扩容能力。同时与数据库引擎深度结合,支持硬件级计算、加解密、加解压、数据过滤、类型预处理等能力。大幅度降低数据传输和上层处理的压力。
目前阿里云推出的PolarDB正是这种架构,已支持MySQL协议,正在支持PostgreSQL协议(PostgreSQL具备了先天的优势(向量计算、并行计算、JIT、哈希聚合、扩展列存、继承、等一系列特性),势必成为HTAP的顶尖产品)。