Postgresql生态

今天我来聊聊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数据库在商业领域的应用。

1. 1. 1. 1. 从一个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的角度，我也总结了一些日常运维与优化的工作内容。因为今天下午我还要赶到东莞去参加华为的鲲鹏昇腾开发者峰会，所以今早的事情比较多，我就不展开介绍了，如果大家有兴趣，明后天我会把上面这个片子详细的介绍一下。大家有兴趣的话，就在下面留言吧。