消息见: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,其中可玩的花样又是多了很多。