今天我来聊聊PG的生态。PostgreSQL似乎是目前除了Mysql之外最火的开源关系型数据库了。大家可能觉得PG是一个后来者,实际上PG这个80后足足比Mysql早诞生了6年。不过在随之而来的开源数据库浪潮中,PG起了个大早,赶了个晚集。哪怕是1996年Postgres改名为PostgreSQL以后,也没有赶上以SQL为核心的关系型数据库大行其道的这火红二十年。
2013年一个客户让我帮助分析一下,如果他们必须去IOE,那么Mysql和PostgreSQL这二者中,用哪个数据库来替代Oracle比较合适呢?我们团队通过一系列的分析,最后给出的答案是Mysql,因为那时候的PostgreSQL还不够成熟,在RDBMS产品上,vacuum导致的问题对高并发的核心应用系统来说,运维难度很大。其周边的生态建设更是落后Mysql太多了。
不过这些年PG数据库已经逐渐赶上来了。大家可以看到从2013年开始PG在DB-ENGINES上的只有不足200分,到2021年底突破600分,PG数据库只用了8年时间。在最近几年的DB-ENGINES的DBMS OF THE YEAR中,PG摘取了2017/2018/2020,MYSQL摘取了2019。不出意外的话,今年的DBMS OF THE YEAR 2021又将被PG摘取。
为什么现在应该是看好PG数据库的时候了呢?这和PG已经逐渐形成的生态有很大的关系。PG的生态发展与MYSQL有所不同。MYSQL的生态是在大量的互联网公司中的成功应用下逐渐发展起来的,大家用的好造就了MYSQL生态的快速发展。基于Mysql的各种数据库产品、存储引擎、高可用集群、云平台、运维工具营运而生,最终推动了Mysql数据库的十年繁华。
从上表中我们可以看出,PG的生态产品也已经不少了,基本上涵盖了企业信息化中数据库应用的主要领域,在表格里我还没有列出国产数据库相关的信息以及高可用集群、应用解决方面的生态产品。从上面的表格中我们还可以看出另外一个信息,PG生态产品的创建时间普遍晚于Mysql的生态产品,大部分项目是2012年以后才创建的,不过几乎所有的生态产品都已经经历了最痛苦的5年,已经进入了成熟期。
PG生态的发展虽然也和它的用户群体不断壮大有关,不过PG生态发展过程中,出现了一些与MYSQL生态发展不同的特征,PG数据库的发展的推动主力并不是互联网企业,而是企业用户。2000年以来,PG数据库在日本企业界得到了相当好的应用。近年来,中国的PG应用时长也蓬勃发展。那就是围绕PG的核心代码,发展出了大量的开源与商用数据库系统和PG数据库插件。在国产数据库厂商中,基于PG开源代码的数据库产品数量也十分庞大。这种生态发展得益于PG数据库的较为宽松的BSD开源协议,而对源代码贡献者提供较好保护的GPL开源协议在某些方面影响了MYSQL向商业应用发展的动力。
Mysql的生态发展是互联网企业先打了个样板,然后推动企业市场发展起来的。PG生态的发展起源于企业应用市场,互联网企业也随之发现了其中的商机,很快将其纳入到云服务平台之中。大量的国产数据库产品也以PG的开源项目为基础,包括人大金仓、神通、瀚高、优炫、华为Opengauss、海量G100、腾讯TBASE、阿里Polardb-PG等一系列国产数据库都是基于BSD授权的PG源码。也正是因为大量的国产数据库厂商纷纷以PG数据库源码作为产品起点,也培养了一大批熟悉PG代码,掌握PG数据库运维关键技术的人才,这也会极大的推动PG数据库在商业领域的应用。
-
-
-
- 从一个Oracle DBA的角度来谈谈PG数据库的优化
-
-
PG数据库目前已经成为最热门的开源数据库之一,特别是因为其开源协议十分适合商业化,因此大量的商用数据库,包括大量的国产数据库也都基于PG的开源代买进行研发。作为一个曾经的Oracle DBA,如果在现阶段要转型的话,学习一下PG数据库的运维,也算是未雨绸缪了。我搞了差不多30年Oracle数据库,不过我估计在我退休前的这几年里,Oracle方面的活会有所减少,而开源和国产数据库方面的运维优化需求会大大增加。于是从2017年开始,我和我团队的小伙伴们就开始对PG数据库进行系统的学习了。Oracle DBA转而学习PG数据库,实际上还是比较容易的,因为大型关系型数据库的基本概念是相通的,而且PG数据库因为没有了共享池和全局共享CURSOR这个超级复杂的机制,也要简单的多。
如果按照上面的维度把Oracle数据库与PG数据库的运维做个比对。PG是开源数据库,无原厂支持,第三方服务水平较低,,代码BUG可通过阅读源码定位,需要通过社区修复。在这里,第三方服务厂商就可以为客户提供很多服务,比如数据库的安装和初步调优,以及定期的补丁与安全漏洞检查,打补丁升级,解决日常遇到的BUG等。与拥有原厂标准化补丁和服务的Oracle相比,PG数据库这方面相对较弱,需要第三方服务来加以支持。
对于运维监控与优化而言,PG数据库提供了同样丰富的监控接口和指标体系,不过部分监控接口需要安装插件,包括一些十分重要的监控采集内容,比如TOP SQL,都需要安装插件来实现。PG的第三方服务上应该帮助用户提供这方面的安装服务。
另外一方面,PG数据库和操作系统结合的十分紧密,运维工作与OS关联紧密,相对简单,没有复杂的共享池,运维关注点较为集中。在我个人的感觉离,PG数据库的运维更像是Oracle 9i时代的数据库运维。
与Oracle数据库不同的是,PG数据库的大版本升级对运维细节影响较大,甚至很多运维细节都是颠覆性的。因此需要PG的运维人员不断的更新版本信息,否则很容易出现认知错误。
最后一方面,PG开源的第三方工具和第三方生态产品较多,而且这些工具与Oracle的第三方工具、生态产品不同,如果不能很好的掌握这些工具和生态产品,会对PG数据库的运维产生比较大的影响。如果你去运维Oracle数据库,那么只要把Oracle自身玩好就行了,Oracle数据库自身构成了一个十分完善的体系,周边工具与Oracle RDBMS之间是紧密集成,而且从底层是贯通的。而PG数据库则不同,PG社区仅仅提供了一个RDBMS和一些必要的外围工具,剩下的应用所需要的功能都是其他的开源项目提供的。因此PG周边的生态工具数量庞大,功能也存在差异,与PG数据库的集成也是应用级的,没有在RDBMS底层进行打通。最大的问题是用户在选择这些产品的时候也比较随意,你去服务的不同客户可能会选择不同的高可用解决方案,选用不同的读写分离集群方案,使用不同的第三方插件来解决一些数据库的功能问题。因此作为PG数据库的DBA或者运维服务人员,你需要全面的掌握这些第三方生态工具,才能够真正的把PG数据库的运维服务做好。
在PG数据库的运维中,从一个ORACLE DBA的角度,我也总结了一些日常运维与优化的工作内容。因为今天下午我还要赶到东莞去参加华为的鲲鹏昇腾开发者峰会,所以今早的事情比较多,我就不展开介绍了,如果大家有兴趣,明后天我会把上面这个片子详细的介绍一下。大家有兴趣的话,就在下面留言吧。