消息见：https://greenplum.cn/2019/03/20/greenplum6-0/?from=timeline&isappinstalled=0

Greenplum 6.0在社区陆陆续续也是做了很久，从2017年就开始规划功能，到如今落地历时两年。诸多新特性算是颇有吸引力，无论从运维方面、事务能力、功能丰富程度等方面都有提升。这里仅就文章中所描述的特性做下分析。

1. PGSQL版本升级

Greenplum最开始基于 PGSQL 8.3（开发时最新），已经有近十年的时间（最早的8.3在2008年，参考https://www.postgresql.org/docs/8.3/release.html ）。在此期间，PGSQL演化的速度是非常可观的，尤其是从2015年之后，每年一个大版本的迭代更新，都会有很大性能上、功能上的提升，各种特性层出不穷。而这些，却无法在Greenplum直接体现。

原因在于，Greenplum在PGSQL 8.3内核中直接修改，而不是类似CitusDB等采取插件的方式。这样的好处是，能够充分修改优化器、执行器、事务、存储等各个模块，达到最优的效果；坏处自然也很明显，与PGSQL社区长期脱节，无法充分利用社区红利。

也因此，在Greenplum中升级PGSQL版本是非常痛苦的一件事。而且，Greenplum长期处于闭源状态，其内部开发者对此的动力未必足够。有意思的是，Greenplum在开源之后，有些PGSQL社区的老杆子参与进来，也引来了不少原来使用PGSQL的客户。自然而然地，会更多地考虑升级PGSQL的版本。如今，也算是众望所归。

PGSQL版本升级带来的好处是很明显的，且不说第一个特性“内核升级”里带来的诸多特性，后面的“2. HTAP （OLAP + OLTP）性能大幅提升”和“8. 基于流复制的全新高可用机制“多多少少都跟这个有关系。而在这些特性中，安全性、权限管理增强、JSONB（应该是由我们的PGSQL团队提交的PATCH）、GIN索引、SP-GiST索引、并行vacuum、CTE等，都是属于客户比较期待的功能。

2. HTAP （OLAP + OLTP）性能大幅提升

OLAP对事务正确性的需求一直存在，只不过被各种各样的中间工具自己解决了一部分，也就是各种数据同步、清洗、转换等工作中较为重要的一部分。剩余不好解决的部分，相当于一直被忍受着，比如T+1的分析、隔夜快变味儿的报表等。

HTAP虽然不能说包治百病的良药，但其适用场景也是有足够诱惑力。TP、AP 都在一个系统里，节约了数据存储成本、少了数据传输等操作成本、不同系统的运维成本等，更有价值的则是数据实时分析，可以及时掌握业务运行情况，不必等待一段时间之后再做决策。

sharding + 2PC看起来似乎都不够完美，如果实现细节做得足够好，其实已经足够解决问题。有多少业务，TPS能够达到几万几十万每秒？这里的TPS，是指类似TPCC等复杂的事务模型，不是TPCB等互联网里简单的点写、点查。PGSQL从8.3到9.4的增长，是很多细节实现上的累积，在性能方面的提升也很明显，能够覆盖的场景已经足够多样。如果对数据感兴趣，可以测试一下两阶段方面的性能。

在Greenplum中，根据分布键做sharding已经与PGSQL中操作单表在用户体验方面相差无几。在分区表等方面甚至更胜一筹。PGSQL MVCC和Snapshot Isolation实现的2PC已经给了Greenplum足够的事务能力和无缝的事务体验。

然而，Greenplum在HTAP方面也不是没有问题存在。

一个是MPP对资源的极度消耗，如果每个Segment配上8个CPU，则8个SQL大查询就会将CPU吃得死死的，渣都不会给TP业务留，从而影响TP业务的响应时间和并发能力。这个问题，恐怕大部分HTAP系统都要小心处理才行（比如大池子下的租户、以serverless方式提供AP业务等）。

第二个则是分布键带来的倾斜问题。个别业务可能会对多个字段有JOIN需求，那么分布键的选择就成为性能优化的第一考虑。分布键选择不好，JOIN引起的数据传输过多不说（比如随机分布），还会导致某个节点数据过多，从而拖累整个SQL性能（木桶效应）。虽然可能有Range Partition等方法能够缓解（比如腾讯就曾在PGXC上做了Group Partition的东西），还是不可避免地提高了运维复杂度并需要各种取舍。后面提到的一致性Hash和“7. 灵活数据分布”，一定程度上可以缓解这个问题。

3. 支持复制表（Replicated Table）

这也是一个有意思的功能，典型的以空间换时间。印象中，AWS Redshift老早就有了这个功能（应该在2016年以前）。功能虽然不复杂，在实际场景中，却会有非常明确的用处。

一个典型的例子就是维度表，比如人员信息、机构信息等。这类数据表的特点是，数据量不大、很多查询/分析都会与此关联，导致这类表在查询时经常被全量传到各个节点中去。当有这类查询时，现在则不用进行数据的motion，减少网络开销和CPU开销。

简单有效、好理解。

4. 在线扩容（Online expand)和一致性哈希（Jump Consistent Hash）

这个功能，可能DBA或运维系统感受最为深刻。多少运维的同学，经受过磁盘满的恐惧？一致性Hash的引入，一定程度上可能缓解倾斜问题，更大的好处在于扩容更方便了。

现在Greenplum在扩容时有两种方式：

• 添加节点，然后对每张表进行重分布，即复制一份出来后切换表名
• 新建集群，数据以表为单位导入过去后，切换VIP

基于Greenplum的HDB For PGSQL目前主要采用的是第二种方式，借公共云大池子堆资源，简单有效。在之前的版本中，第一种方式脚本问题颇多、资源占用也没少多少、磁盘空间管理也更复杂，实现下来运行过程中发现并不值得。

与消息中描述的不同，在云上主要采用了第二种方式，不用停机，只是让实例只读半个小左右和两次连接闪断重连即可完成。

而在有了一致性Hash之后，则可以更细粒度的调度，比如以表为单位进行操作，实现上面第一种方式。配合第二种方式，达到更理想的运维效果。

5. 磁盘配额（Disk Quota）

之前的版本中，就已经有Resource Queue用于资源细粒度调度，此次算是功能丰富了一些。目前不是很清楚客户对这块的需求如何，暂不评论。

6. 支持Zstandard压缩算法

Facebook新的压缩算法，加上之前就支持的LZ4、zlib等，算是更丰富了些。在建表时可选择，包括分区子表。

7. 灵活数据分布

这个就比较有意思了，典型PGSQL的玩法（自定义类型和操作接口等）。分布不再是简单的根据计算得来的Hash结果，可以是自定义的算法，那么给用户的空间瞬间大了很多。毫无疑问对写入是有影响的，影响多大跟这个Operator关系很大。比如，基于时间的顺序、业务单元（很容易做到类似TDDL）等。问题在于怎么跟查询情况匹配起来，使用上提高了复杂度。

8. 基于流复制的全新高可用机制

这个功能有很多潜在的好处，充分利用能够玩出很多花样。毕竟，Replication是PGSQL连续搞了好多年的功能，在HA、备份、恢复（到时间点）等诸多场景中必不可少，提供了非常高的灵活度。

Greenplum的结构是一个Master下面挂多个Segment（分片），Master有自己的Slave，两者数据同步走Replication；Segment也有主备，被称为Primary / Mirror，通过类似于文件内容传输的方式进行数据传输，只能以同步的方式进行，其原因主要是列存储没有支持WAL。列存储数据同步走Replication，就是Primary和Mirror之间数据同步走Replication的最大的障碍。

如果Replication支持了Primary和Mirror间数据同步的话，则意味着列存储数据也应该是写入WAL了。那么，两个比较大的花活就可以玩了起来：

• 增量备份
  全量备份集加上各节点WAL日志，应该可以做到恢复到时间点。RDS For PGSQL / MySQL借助WAL和逻辑日志，已经做到了这一点；HDB For PGSQL，因为节点上不支持WAL，就只能支持恢复到备份集。RDS恢复到时间，一直都很受客户喜欢。相信Greenplum如果实现这个功能，应该会有一定市场。
• 增量同步
  乍看起来，好像对于一个AP系统意义不大。但回想上面集群扩容的第二种方案，如果从实例的备份集恢复，然后建立起到源实例的Repliation，那么实例扩容就可以做到秒级切换，且对用户没有除了一次闪断外的其他影响。但需要评估一下，相比于一致性Hash扩容，新建集群的优势在哪里，比如一次扩容较大的情况。两种可以相互配合，覆盖不同的场景。

这两点，是在看到这个功能后的猜想，需要实际验证是否存在什么不足和限制。总之，Replication其中价值的挖掘还是有一些想像力在的。

总结

除了以上几点特性以外，另外一个隐形的好处是：与PGSQL的代码基线差别更小了。下一个版本估计是10.0甚至12，那么又将是另外一个大的breakthrough。

PGSQL 10.0的并行查询已经完备，配合MPP，则会成为性能巨兽，但也是资源吞噬者。对于云产品来说，资源的消耗带来性能的提升是好事情，可以刺激客户买单。 如果再能配合PGSQL 12中的Pluggable Storage，其中可玩的花样又是多了很多。