Why PostgreSQL rocks and Oracle & Mysql sucks

1. 引言

在座的各位有认识我的也有不认识我的，但不管认识还是不认识的，以后大家都可以叫我一声彦祖。我呢，仍然是编程的小学生，包括今天话题涉及到的技术，老实说我也没有比大家走了多远。只是对数据库这样一门技术以及 PG 这样一个强大的关系型数据库，我单纯得觉得有趣。包括我在来到森亿之前，并没有使用过 Postgresql，同时对于其他实际数据库的认识也只是浅尝辄止，更多的还是停留在书籍上。所以对于此次能够给大家做这样的演讲，实在有些诚惶诚恐。有讲的不好的地方，还希望大家多多指正，多多包涵。

回到正题上，这次演讲的主题是《Why PostgreSQL rocks and Oracle & Mysql sucks》，一开始佳能看到我提出这样的题目就及时地制止了我，说这次的目的，只是让大家更深入地理解一件事，那就是为什么我们公司一开始乃至之后的每一次技术方案都优先选择 Postgresql 而不是 Oracle 或者 Mysql，为什么 Postgresql 如此适合我们的业务。而我这样的题目，搞得是要把 Oracle 抨击一番一样，有点本末倒置，甚至可能会引起部分 Oracle 支持者先入为主的反感。但可以保证的是，不会有比这个被删除的题目更过分的说法。而且其实我对 Oracle 基本只停留在“由于 Oracle 安装难度过高，所以衍生出了 Oracle 安装收费这样的产业链”的阶段，所以真让我说 Oracle 有什么不好的地方，也是强我所难了。之所以用这个作为题目，纯粹只是我对 C# 的一位大牛，赵姐夫的《Why C# rocks and java sucks》系列的一次致敬而已。技术比不上人家，但是心态上要看看齐。

基于这个初衷，下面会以 Postgresql 所拥有的强大特性和解决方案作为内容组织条目。在此之前，其实我还想声明一下，从数据上来看，前几年 Postgresql 占比远远不如刚才说的三大数据库，份额上只有五分之一甚至更低。所以出现了这样一种情况，很多开发者之前用过 Oracle，用过 Mysql，用过 Sql Server，唯独没有用过 Postgresql 。当然是很正常的一件事情。不过这也引出了一个普遍问题，因为某项技术没有用过而觉得抗拒，或者因为习惯于某项使用过的技术中而排斥学习，这都是常见但是不提倡的行为。我相信大家既然体验了 .NET CORE，了解了 Docker，K8S 等一系列技术，肯定能感觉身边反馈给你们的工程师文化并不是如此，然后这也推动了今天此次主题的诞生。微软 CEO 萨提亚纳德拉 提出过一个理念，叫作“拥抱变化，更新文化”，说的也是这个道理。

2. 介绍

2.1 概述

PostgreSQL 是一个基于 BSD 授权许可的面向 HTAP 场景的开源关系型数据库。很多人应该听过 OLTP 或者 OLAP，而 HTAP 则是时下比较火的概念，可以理解为混合型事务及分析处理，也就是说兼顾优化 OLAP 和 OLTP 场景性能。

PostgreSQL - The world's most advanced open source database

这是挂在 PostgreSQL 官网的一句话，其实仅这一句，就已经违反了中国广告法。但是人家就是有这底气。另外有些人也知道 MySQL 的定位，我也贴了出来。

MySQL - The Most Popular Open-Source Database

MySQL，最受欢迎的开源数据库，这是两家数据库背后的团队对自己的认识，其中说明了什么，大家可以自己去体会。单单在功能集上，PostgreSQL 说完爆 MySQL 可能太狂了，但是小爆还是不成问题的。仅仅索引种类支持一项，PostgreSQL 便是 MySQL 的数倍。同时，不像 MySQL 背后仍然有商业性公司 Oracle 作为决策人，尽管 PostgreSQL 已经诞生三十多年，但仍然称得上是社区兴趣使然的产品，尽管现在围绕 PostgreSQL，已经有很多强大的商业产品和商业公司诞生，这个之后会在生态中介绍。然而 PostgreSQL 仍然保持着它的独立性和纯粹性，只由所谓的PostgreSQL全球开发小组领导，不参与商业决策，不受资本控制。同时，社区中的主要贡献者个个都是人才，代码写得好，说话也好听。

当然很多人可能也会担心仅仅由社区推动，是否会对功能，或者代码质量造成损害。那下面就让我来简单介绍下 PG 的发展历程以打消大家的顾虑。

PostgreSQL 的前身是伯克利源于 1977 年的 Ingres 项目，而 Ingres 的作者正是 2014 年图灵奖得主迈克尔·斯通布雷克。值得一提的是，唯一的华人图灵奖得主姚期智院士还是斯通布雷克的普林斯顿校友。迈克尔斯通布雷克在结束 Ingres 项目后，又重启了一个后 Ingres 项目，也就是 Postgres，而 PostgreSQL 正是由两名中国研究生在 90 年代重写 Postgres 的产物。尽管未由这位图灵奖得主直接干预，但是从其中继承的全部源码，也解决了诸多难点，如UNIX平台支持，多用户、多进程、两个层次的非过程语言，子查询，宿主语言，交互式算法，存取管理、并发和恢复、部分完整性约束，以及查询修改，还有用于完整性约束和视图，等等。

其实除了 PostgreSQL 之外，Ingres 还衍生出了一系列我们耳熟能详的数据库，比如 SQL Server，Oracle。然而除了 PostgreSQL，其他所有的数据库要么由作者自己开了公司继续做大，要么就由商业公司收购了。

诞生至今的三十多年间，PostgreSQL 一直保持着它旺盛的生命力。活跃的代码贡献者中有来自 VMware，Pivotal 这样的知名企业云服务厂商，也有部分高校的教职人员，当然主要的还是类似于 EnterpriseDB 和 2ndquadrant 这样的基于 PostgreSQL 发展的商业公司。

每年一个主版本，每个季度一个次要版本，目前 PostgreSQL 的最新版本已经来到了 11.1，同时项目组保持对最新对 9.3 版本的支持，所以不用担心数据库的生命周期问题，当然了，PG 也提供了诸如 pg_dump 和 pg_upgrade 等系列迁移升级工具用于使用者升级数据库版本，我们当然是强烈建议尽可能地升级到最新版，因为 PG 每一个大版本的发布都意味着性能，功能，安全性的肉眼可见的提升。

最后让我们来看看截止 2015 年为止，PostgreSQL 的一些主要用户。早前都是一些追求稳定性和安全性的企业或教育机构在使用 PostgreSQL，但是我们也能看到越来越多的知名互联网公司投入了 PostgreSQL 的怀抱。

• 生物制药 {Affymetrix(基因芯片), 美国化学协会, gene(结构生物学应用案例), …}
• 电子商务 { CD BABY, etsy(与淘宝类似), whitepages, flightstats, Endpoint Corporation …}
• 学校 {加州大学伯克利分校, 哈佛大学互联网与社会中心, .LRN, 莫斯科国立大学, 悉尼大学, …}
• 金融 {Journyx, LLC, trusecommerce(类似支付宝), 日本东京证券交易交所, 邮储银行, 同花顺，平安银行…}
• 游戏 {MobyGames, …}
• 政府 {美国国家气象局, 印度国家物理实验室, 联合国儿童基金, 美国疾病控制和预防中心, 美国国务院, 俄罗斯杜马…}
• 医疗 {calorieking, 开源电子病历项目, shannon医学中心, …}
• 制造业 {Exoteric Networks, 丰田, 捷豹路虎}
• 媒体 {IMDB.com, 美国华盛顿邮报国会投票数据库, MacWorld, 绿色和平组织, …}
• 开源项目 {Bricolage, Debian, FreshPorts, FLPR, PostGIS, SourceForge, OpenACS, Gforge, …}
• 零售 {ADP, CTC, Safeway, Tsutaya, Rockport, …}
• 科技 {去哪儿, 腾讯, 华为, 中兴, 网飞, Ins, 阿里，亚马逊，Uber，Sony, MySpace, Yahoo, Afilias, APPLE, 富士通, Omniti, Red Hat, Sirius IT, SUN, 国际空间站, Instagram, Disqus…}
• 通信 {Cisco, Juniper, NTT(日本电信), 德国电信, Optus, Skype, Tlestra(澳洲电讯), 中国移动…}
• 物流 {SF}

2.2 流行趋势

2014 年至今，PostgreSQL 算是引来了它的黄金期，三十多年的沉淀厚积薄发，才有了这一张图。这图是我从全世界最知名的数据库图库网站 DBEngine 收集的，可以看到如今的 PostgreSQL 气势凶猛，已经接近前三大流行数据库一般的份额，而关键的 2013 后半年节点则是 PostgreSQL 9.3 大版本的发布时间。老实说这个版本亮点不多，主要是增强了垃圾回收和查询优化器性能。

可以看到商业数据库日渐式微，可能在2020年，开源数据库便能实现对商业数据库的完全超车。11 月底亚马逊官方表示，将在 2019 年底全面弃用 Oracle 数据库，报道中还透露亚马逊的数据库已经在 11 月份初就从 Oracle 迁移到了其自主研发的 Redshift 上，当然了，Redshift 也是基于 PostgreSQL 源码修改的。而近年来国内去 O 的趋势也是愈演愈烈，比如 13 年底前阿里便完成了全部的去 O 工作，后面蓬勃诞生的互联网公司更是在最开始的技术选型时便没有考虑过使用 Oracle 数据库。可能有人说这是互联网开发自由的基因天生容不下 Oracle，那让我们来看看传统行业。据有效数据显示，中国移动，联通，电信，从 11 年就已经分别开始了去 O 政策。这是在 2015 年第六届中国数据库技术大会由浙江移动信息技术部王晓征在他的演讲《运营商去O浅析》中提及的。扩展性差，采购和维护成本高，无法掌握核心技术，技术成长停滞都是企业去 O 的重要动力。

而在一向重度依赖 Oracle 的金融业，其实这股风气也早已经刮了起来。2014 年银监会就发布了一篇名为《关于应用安全可控信息技术加强银行业网络安全和信息化建设的指导意见》，里面提到在保证信息数据安全稳定可靠的情况下，加强技术创新，摆脱在关键信息和网络基础设施领域对单一技术和产品的依赖，并给出了相应的银行信息化技术指标。以小见大，传统行业中，通信也好，金融也好，包括医疗也好，国家对于信息化建设的要求，已经不止停留在安全可靠的程度上，自主可控和知识产权，同样是考量的要点。再说，刚才提到的几款数据库中，难道真的就是 Oracle 最安全了吗？这个问题放到后一节中简要地谈谈。这里先卖个关子。

2.3 代码质量

说完出身和最新的发展态势，在进入 PostgreSQL 功能特性展示前，我还想引入一个有趣的话题。想必大家私下也去找过 PostgreSQL 与其他数据库诸如 MySQL 或者 Oracle 的对比，先不说性能上的较量，很多人都会提到一个名词，叫作代码质量，是的，作为开源数据库，你可以对项目代码一览无余，所以这时候我们常常会听到，MySQL 的代码质量极差，而 PostgreSQL 的代码质量则很高。我前前后后找了一些论证，最后发现国外最大的数据库社区 DZone 上有人做了比对，博文的名字叫作《Code Quality Comparison of Firebird, MySQL, and PostgreSQL》，Firebird 是另一款关系型数据库。文章在这里就不摘抄了，总之最后的评判结果毫无疑问是 PostgreSQL 胜出。后来我也是去 GITHUB 简单翻了下 MySQL 和 PostgreSQL 的源码，也不掺杂主观意见的话，MySQL 在重要的查询优化器以及存储引擎上，单个代码文件行数接近或超过万行也是司空见惯，而 PostgreSQL 很难见到有内容超过两千行的代码文件。但是这种意见，包括刚才的博客中的评判结果，其实都不能算作公论，但是毕竟管中窥豹，可见一斑。

而 Oracle 更是饱受诟病，上个月 14 号国外有人在发了个帖子，标题是“你见过的最糟糕的代码是什么样子”，有个 Oracle 的员工就在下面吐槽，当时就引起了热议，传到中国又火了一把，我大概把中文翻译摘抄几段下来。

Oracle 数据库 12.2。它有近 2500 万行 C 代码。

这有多恐怖，简直难以想象！你无法在不破坏成千上万个现有测试的情况下更改产品中的单行代码。好几代程序员在有限的项目期限内编写了这些代码，其中充斥着大量的垃圾代码。

甚至可能需要一两天才能真正理解某个宏命令的作用。

开发一个小功能需要6个月到1年的时间（如果是添加一种新的身份验证模式，比如支持 AD 身份验证，可能需要2年）。

这款产品本身就是一个奇迹！

我不再为 Oracle 工作了。永远不会再为 Oracle 工作了！

看看这种描述，可能有些祖传代码，确实得把老祖宗的棺材给撬开才有读得懂的鬼。

3. 安全

一个数据库是否安全，得从连接的安全性、密码的可管理性、访问的可控制性、数据的
可靠性等多方面衡量。在后面的数据中，大家可以看到，在主流的商业数据库和开源数据库中，PostgreSQL 在这些方面可以说是做得最好的，并且 PG
完整支持 PCI DSS。PCI DSS 全称为第三方支付行业(支付卡行业PCI DSS)数据安全标准，是由PCI安全标准委员会的创始成员(visa、mastercard、American Express、Discover Financial Services、JCB等)制定，主要是为了使目标行业采用一致的数据安全措施。以下是一份国内厂商提供的关于 Oracle 和 PostgreSQL 在数据库功能实现的安全性上的对比。由于 MySQL 在这点上实在是比较吃亏，就没有贴出来了。

接下来的一份报告是截止目前为止，最新的一份关于数据库漏洞报告的数据。也是由国内知名数据库安全研究厂商安华金和公开。

Oracle 安全漏洞，63个

PostgreSQL 安全漏洞，30个

Mysql 安全漏洞，惨不忍睹了

而在权限管理上，PostgreSQL 和 Oracle 都支持基于角色与用户的权限配置，权限单元的最小粒度也可以锁定到行和列。也就是说，一张完整的表，不同用户看到的只是所有数据的不同子集。

这些都是客观实在的数据，然后再讲一个我们碰到的小故事。上个月参加在苏州举办的“中国数字医学前沿论坛”时，有一个 Oracle 的 DBA 说过一个关于触发器使用的安全漏洞。在 Oracle 中，触发器提供的权限是定义者的权限，也就是假如有一个 System 用户定义了一个触发器函数，低权限级别用户就可以写一个恶意函数，比如获取 Sys 用户密码的函数，虽然这个用户不能运行这个函数，但是可以将其放入早先定义好的触发器函数中，从而通过 Sys 用户权限执行函数，逐步地获取对整个数据库的控制权。其他的诸如常见的索引提权等漏洞在目前主流的版本中仍未修复。触发器和索引可能是开发和优化中使用的最多的功能，只希望 Oracle 的开发者能尽快地向那 2500 万行代码中提交补丁吧。

不要小看这些安全漏洞因为不能及时修复带来的影响，前不久国家信息安全漏洞共享平台也发布了一个通告，“Oracle数据库勒索病毒RushQL死灰复燃”。这个RushQL勒索病毒已经不是第一次肆虐Oracle数据库，早在2016年11月就已经在全球掀起了一场血雨腥风。当然，那时候它有个更响亮的名字“比特币勒索病毒”。也就是说，你要么交钱，要么丢数据。两年时间，Oracle 对此仍然是束手无策。

老实说，我觉得对于数据系统是否安全而言，操作系统的安全性和运维人员的素养更要紧一些，比如你硬要把主要的访问端口暴露出来，或者把密码设成全球通用的 admin 和 123456，那不管是什么背景的企业，都有吃亏的时候。然而仅从刚才提到的数据和案例而言，相信大家也有了一些自己的看法。

4. 特性

做完了前面几节的铺垫，这一节里我们将看到 PostgreSQL 为什么如此受欢迎的重要特性和功能。毕竟对于绝大部分开发者而言，所谓的背景，开发流程，代码质量甚至是高级安全特性都不是他们所在意的，数据类型，索引类型，与外部编程语言或者外部数据源的直接集成功能，可靠性以及可用性，往往才是左右开发者是否选择的重点。

关键词. SQL 标准功能支持

PostgreSQL 是所有主流关系型数据库中对 SQL 标准最完善的数据库。目前的 SQL 标准最近的一次更新在 2011 年，在 179 个完整核心符合所要求的强制特性中，PostgreSQL 至少符合 160 个。这也意味着在其他关系型数据库编写的 SQL 语句拿到 PostgreSQL 中，甚至不需要作修改便可以直接运行，提供了强大了可移植性和兼容性。包括你能想得到数据类型，操作符，窗口函数，CTE 表达式，递归和树操作。

1. 数据类型
   整数，浮点，小数，字符串（可变），二进制，时间戳，布尔，ROWID，XML，键值对，JSON，JSONB，比特，数组，树，地理信息，网络信息，DNA，复合类型等。
2. 函数和操作符
   逻辑，比较，模式匹配等相关函数和操作符，数据类型对应函数和操作符，条件表达式，子查询表达式，触发器函数，事件触发器函数（DDL 等），系统信息函数等。
3. 高级特性
   临时表，存储过程，分区（范围，Hash，列表，复合，间隔），视图（物化视图），国际编码字符集支持，Transaction DDL，窗口函数，CTE 表达式，表继承等。

除此以外， PostgreSQL 还提供了非常多的函数糖，可以这么说的是，PostgreSQL 绝对不会成为业务系统中增删改查和数据库设计的 Runtime 瓶颈。

值得一提的是，PostgreSQL 现在一机多用的能力特别强，不仅能作为关系型数据库，文档存储和键值对操作能力也特别强悍。PG 9.2 引入了 JSON 类型，9.4 引入了JSONB类型，直接对彪 MongoDB 的 BSON，同时内置的函数和操作符支持也远远超过其他几家同样支持 JSON 存储的关系型数据库。在 2014 年刚推出时，国外最大的 PG 厂商之一 EnterpriseDB 发表了一篇关于 PG 9.4 与 MongoDB 2.6 性能对比的文章。

• 在插入方面将近比 MongoDB 快 3 倍
• 查询方面比 MongoDB 快 2.5 倍以上
• 数据加载方面比 MongoDB 快约 2.1 倍
• 相同情况下，MongoDB 消耗将近 3 倍多的磁盘空间

当然了，很多人使用 MongoDB 看中的也是其分布式功能，而一开始 MongoDB 也并未将全部重心放在性能优化上，所以这样的结果也是可以理解的。如今 MongoDB 4.0 也已经发布，除了磁盘空间的消耗仍然比 PostgreSQL 高出很多，性能在各种相对正规的社区评测中也已经能慢慢看到 PostgreSQL 的尾气了。

关键词. 索引

数据库支持多种数据类型和数据操作方式，为了提供最优的性能，数据库也必须支持
多种类型的索引。PostgreSQL 在这方面有自己的独到之处，不仅提供了在主流关系型数据库最多种类的索引，而且面向的场景基本覆盖了日常和部分特殊领域的需求。

1. btree
   b-tree适合所有的数据类型，支持排序，支持大于、小于、等于、大于或等于、小于或等于的搜索。
2. hash
   hash索引特别适用于字段VALUE非常长的场景，例如很长的字符串，并且用户只需要等值搜索，建议使用hash index。
3. gin
   倒排索引，适合多值类型搜索，例如数组、全文检索、TOKEN；单值稀疏数据搜索；多列任意搜索。此外还有一个索引插件 rum，属于 GIN 的功能增强版本，同样适合全文搜索。
4. gist & sp-gist
   用于位置搜索，GIS 大杀器。
5. brin
   BRIN 索引是块级索引，占用空间极小，特别适合时序数据的等值，范围查询。
6. bloom （扩展）
   bloom索引适合多列任意组合等值查询。

通过对上述索引的组合和使用，很多文章都喊出了诸如“百亿级数据毫秒响应”，“轻松击败搜索引擎”的口号，特别是机器成本可控，案例贴近实际的情况下，一方面不排除有夸大的成分，另一方面却也说明了 PostgreSQL 的性能上限极高。除此以外 PostgreSQL 还通过插件支持其他索引种类或功能性增强。之所以说 PostgreSQL 如此适合 OLAP 场景，种类丰富的索引确实占了很重要的原因。

关键词. 开放

PostgreSQL 本身的架构设计十分优秀，除了无法更换存储引擎为人诟病意外，其他的开放特性一应俱全。而且由于这种插件式的接口设计，对于性能的损耗在理论上也是微乎其微。

• 自定义函数
• 自定义数据类型
• 自定义操作符
• 自定义聚合、窗口
• 自定义数据扫描方法
• 自定义数据采样方法
• 自定义外部数据访问接口
• 自定义存储过程语言
• 自定义索引接口
• 自定义WAL日志接口
• 自定义逻辑订阅接口
• 自定义工作进程接口
• 自定义存储接口
• 自定义压缩接口
• 自定义加密接口

下面先简要提及两个只有 PostgreSQL 才提供的实用功能。

• 开放的外部数据源接口

PostgreSQL 支持称为外部数据包装器的功能，简称 FDW。FDW 由 SQL 2003 标准制定。

安装必要的扩展并进行适当的设置后，您可以访问远程服务器上的外部数据，例如我们有一个本地的 PostgreSQL 数据库和一个远程的 MySQL 数据库，在本地写好查询 sql，便能查询到远程数据信息，这对于数据集成，屏蔽多数据源细节，以及数据迁移都有十分重要的意义。目前 PostgreSQL 的数据源支持以及扩展到了市面上所能见到的绝大部分数据库，如 Redis，ElasticSearch 等。值得一提的是，citus，另一个知名 PG 厂商，还利用此功能实现了分布式列存储功能。

但比较遗憾的是，尽管很早就有了这个功能，而且很多数据源的 FDW 开源项目很早也上了马，但是除了由 PG 官方维护的 PostgreSQL FDW，一个直接访问远程 PG 数据库的扩展外，其他的项目并没有得到良好持续的开发。不过随着这几年 PostgreSQL 火箭般的蹿升，相信这种局面已经在慢慢改观。

• 开放的语言接口

PostgreSQL允许用户定义的函数使用 SQL 和 C 之外的语言编写。 通常这些额外的语言叫过程语言(PLs)。目前在标准的 PostgreSQL 发布里有四种过程语言可用：PL/pgSQL, PL/Tcl , PL/Perl和 PL/Python 。除了标准的四种，还有以下列出的条目。这些项目在当下都十分活跃，如今 Python，Java，Javascript 如此火爆，直接使用这些语言在 PostgreSQL 中编程其实已经很常见了。

• pl/pgsql
• pl/perl
• pl/python
• pl/tcl
• PL/sh
• PL/R
• pl/java
• pl/lua (ng)
• pl/v8

得益于 PostgreSQL 开放的特性和优秀的架构设计，围绕 PostgreSQL 开发的一系列数据库和工具集也是越来越多。图中的这些工具都能以插件的形式集成到 PostgreSQL 数据库中直接使用。

简单介绍几个目前比较流行的开源项目。

1. PIPELINEDB，流式计算数据库，自动处理流式数据，不存储原始数据，只存储处理后的数据，非常适合当下流行的实时流式数据处理，例如网站流量统计，服务监控统计，甚至是医疗数据 ETL 中间结果处理。
2. TIMESCALEDB，时序数据库，针对时序数据的写入存储优化和时间过期窗口，完美支持横向纵向扩展，适用于金融医疗数据分析和物联网数据集成统计
3. CITUS，分布式数据库插件，随 PostgreSQL 版本更新而更新。CITUS 更偏向于 TP 场景，支持绝大部分 AP 功能。官方在 Youtube 发布的 Benchmark 结果显示数据写入或简单 AP/TP 性能都要超过对应版本的单机 PG，同时为多租户和实时在线分析场景做了优化。
4. agensgraph，基于 PostgreSQL 的图数据库扩展，C/C++ 编写，支持 SQL 和 Cypher 混合查询，常见图查询的性能比 Neo4J 快数十倍。
5. 此外还有知名的 MPP 数据库，Greenplum，老牌 OLAP 场景标杆工具，支持 PB 级数据的快速分析查询。背后的支持公司是 由 VMware 和 EMC 联合创办的 Pivotal。优点在于支持行列存储，完整的 SQL 支持和高性能 AP 查询。当然现在 PostgreSQL 11 版本对 OLAP 场景的优化已经相当不错的，普通的亿级数据更推荐放在 PostgreSQL 中。

关键词. 性能

讲了这么多 PostgreSQL 本身的特性和功能，接下来让我们来了解一下 PostgreSQL 更直观的几个为 HTAP 设计的特性。其实讲到现在，我们介绍的始终是 PostgreSQL 直接提供的功能，比如数据类型，索引 等等，再往下一步的表结构，进程模型，MVCC，都只是为了实现 PostgreSQL 上层功能的细节，在这个场合中没有探讨的必要，不然只是 MVCC，就我个人而言，又能再写个万字长文了。

下面列出的功能和评测主要针对 OLAP 场景，这和我们的实际场景更切合。

• PostgreSQL 9.6 or higher AP

  1. jit
  2. 向量计算
  3. cpu 并行计算（单个查询语句能利用多核），GPU 加速
  4. ...

然后下面是对应的性能检测，检测数据使用了全球 OLAP 工业标准 TPC-H，大概 200G 的数据，22 条 AP 相关的 SQL 语句，覆盖了绝大部分场景，所有测试 20 分钟全部跑完。测试环境为 PostgreSQL 11, 64 核 512G 内存云计算主机。

从以上数据大家大概能感受到 PostgreSQL 的威力了，而在更多的社区评测中，也可以看到 PG 的单机 AP 性能已经接近了相同成本的 MPP 分布式数据库方案。

5. 高可用

无论是高可用性方案还是生态，其实 MySQL 都比 PostgreSQL 或者 Oracle 要强，这没什么要回避的，就跟 C# 与 Java 的困境一般。所以剩下的两个章节也会更注重 PostgreSQL 自身。可以这么说，虽然 PostgreSQL 在各个运维领域的解决方案少，但是都是精品。

首先介绍两个连接池组件。PgBouncer 和 PgPool2。

• PgBouncer

  1. 低资源消耗
  2. 会话保持
  3. 多个后端数据库
  4. 多种模式
     
     • session pooling
     • transaction pooling
     • statement pooling

• PgPool2

  1. 连接池模式
  2. 复制管理
  3. 读写分离
  4. 负载均衡
  5. 并行查询

两种技术可以一起使用，完全可以把 PoBouncer 放在 PgPool2 之前联合使用。

接下来讲复制，Replication。PostgreSQL 很早就支持了物理流式复制，同时在 9.4 版本后引入了逻辑复制。物理流式复制作用在数据库级别，可以实现容灾库与主库的完全一致。同时也实现了主从同步，主从异步，从库与从库的级联复制模式，保证不同场景下的性能和数据备份要求。物理复制可以保证物理层面的完全一致，同时数据可见延迟低，一致性、可靠性都达到了金融级的需求。但是物理复制要求主备块级完全一致，所以有一些无法覆盖的应用场景，例如备库不仅要只读，还要可写。又比如备库不需要完全和主库一致，只需要复制部分数据，或者备库要从多个数据源复制数据，等等。

PostgreSQL 在 9.4 版本引入的逻辑复制解决了物理复制的不少问题。

1. 物理流复制只能做到整个集群的复制，而逻辑复制可以做到表级。
2. 物理复制的备库只读，不能写入。逻辑复制读写都可以。
3. 逻辑复制可以支持 DDL 命令的订阅发布。
4. PostgreSQL 的大版本升级，可以使用逻辑复制做增量数据同步，停机服务时间会非常短。
5. PostgreSQL 自定义逻辑拆库。由于是逻辑数据，所以很容易自定义分发规则。例如按表拆，逻辑分表，白名单，黑名单等等。
6. PostgreSQL 增量同步到其他异构数据库，例如 PG 同步到 Mysql，PG 同步到 Oracle。
7. 逻辑主备同步，逻辑多节点同时可写集群。
8. 逻辑复制支持跨版本、跨平台升级。

当然相对的，逻辑复制对于主库的性能影响也会更大。对于大事务，物理复制的延迟也会比逻辑订阅更低。

• 逻辑订阅，适合于发布端与订阅端都有读写的情况。
• 逻辑订阅，更适合于小事务，或者低密度写（轻度写）的同步。如果有大事务、高密度写，逻辑订阅的延迟相比物* 理复制更高。
• 逻辑订阅，适合于双向，多向同步。
• 物理复制，适合于单向同步。
• 物理复制，适合于任意事务，任意密度写（重度写）的同步。
• 物理复制，适合于高可用、容灾、读写分离。
• 物理复制，适合于备库没有写，只有读的场景。

剩下的一幅图则是目前针对 PostgreSQL 实现服务和存储高可用的架构图，左侧是我们的 master 节点，右侧是复制节点，两者通过物理流复制或是逻辑流复制交流。Patroni 是一个用于 PostgreSQL 高可用方案的组件，内部使用 etcd 或者 zookeeper 保存监控集群状态并选举 leader 节点。当我们左侧的主库发生宕机，右侧从库自动提升为主库，Patroni 可以自动通知负载均衡节点主库已经发生切换，完全无需人工干预，old master 恢复后又可以自动加入集群。Patroni 和 etcd 在开源社区中都是十分活跃的项目，同时图上的各个组件和 K8s 运维环境可以说是无缝兼容，甚至于负载均衡以及服务注册都可以直接使用 K8s 为我们提供的组件功能。

图中实现了存储层和 PostgreSQL 数据库服务的高可用，至于应用端的高可用，则没有在图上给出方案。

6. 结语

至此，关于《Why PostgreSQL rocks》的所有内容就分享完毕了，在以上的内容中，我们先了解了 PostgreSQL 的前身，发展以及生态，然后分享了 PostgreSQL 的优秀设计和强大的功能特性，在第五节中我们也介绍了 PostgreSQL 在高可用场景下的支持特性以及成熟方案。虽然 PostgreSQL 以及历经数十年的发展，但它并没有像一个迟暮的老人一般，反而依然在社区的支持下不断推陈出新，和目前互联网上的前沿技术仍然配合得很好。

但是上文中我们没有提到的包括，PostgreSQL 设计架构，MVCC 实现，垃圾回收等重要的细节，也是一种遗憾，但是这些话题都要求更深入的探索，有机会的话，希望在之后的分享中带来。

另外值得一提的是，虽然目前 PostgreSQL 暂时不支持更换存储引擎，但是插件化的存储引擎开放接口已经被纳入开发提案了。PG 12 中应该就能看到。

最后，If in doubt, use PostgreSQL。