标签
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的顶尖产品)。
