云栖社区明星专家德哥日前在IT168的盛会——2016 第七届中国数据库技术大会做了分享。整理文章见《从Oracle DBA到PostgreSQL布道者》 ，很有价值，转载到社区，分享给更多朋友。
嘉宾介绍：
PostgreSQL 中国社区发起人 周正中
周正中，网名德哥 ( digoal )，PostgreSQL 中国社区发起人之一，PostgreSQL 象牙塔发起人之一，DBA+社群联合发起人之一，10余项数据库相关专利，曾就职于斯凯网络，负责数据库部门。主导了集团数据库系统、存储、主机、操作系统、多IDC的架构设计和建设;完成了对数据库HA、容灾、备份、恢复、分布式、数据仓库架构设计和建设;数据库管理和开发的标准化体系建立。于纳斯达克上市前成功使用PostgreSQL完成去O，并顺利通过SOX审计。现就职于阿里云数据库内核技术组。
正文：
大家好，今天我要给大家分享的话题是从Oracle DBA 到PostgreSQL布道者，首先先做一下自我介绍。
我是在2006、2007年开始接触数据库，09年的时候成为Oracle DBA,2010年，接触到了PostergreSQL，之后就一直在做PostergreSQL的布道工作。目前，我已经分享技术类文章2000余篇，我的目标是写到1万篇。
2005年，我从学校毕业拿到了我的第一份工作，是一份技术支持类的文章。为什么会去学Oracle呢?其实是有一个契机的，当时我们公司是乙方，甲方把数据库的一些东西删除了，数据库就起不来了，然后Oracle的技术人员过来把数据库恢复了。当时我就感觉真是太牛了，所以就开始接触Oracle。
我的第一份DBA工作是在2008年，我在那家公司第一次听到了PostgreSQL。PostgreSQL数据库挂了之后业务还能继续跑，它只会丢掉一部分数据，其它的数据库还活着，可以继续服务。Sharding是一个基于PostgreSQL的一个插件，最早是在国外流行起来的。
这家公司在之后大量使用PostgreSQL有原因的。因为在08年到09年的时候，PostergreSQL有了一定的发展，产品推陈出新，公司的业务也有了飞速的增长。下面就简单介绍一下我们当时的应用系统。
当时我们的应用有基于地理位置的位置交友应用、社区，网游，虚拟的货币系统交易、游戏平台。我们当时的数据量是普通的企业数据量，单库的数据量是200GB到500GB，当时的服务器全是X86的机器。
在这使用的一年中，不管是从稳定性还是从性能、功能、可靠性的方面来讲，PostergreSQL都满足了我们的需求，另外我们还使用了其他数据库所没有的特性。
我们基于位置的交友应用，现在是有MongoDB支撑的，之前是由基于地理位置应用的插件支撑。我们的社交系统里面有比较复杂的关系，所以会有比较多的递归。如果当时我们没有采用PostergreSQL，而是选用其它开源数据库，恐怕是不能达到这个效果的。
当时PostergreSQL支撑了我们所有的业务应用，性能完全满足要求，从未因数据库问题crash，从未丢失数据，也没有遇到bug。这也给我们之后全面应用PostergreSQL提供了信心。
2009年到2010年，我们公司准备在纳斯达克上市，当时我们的商业数据库在成本核算方面是无法满足上市的需求，所以当时我们CFO决定要用PostgreSQL替代商业数据库。
如果公司上市的话，要替换原来的数据库，就要评估这个数据库能不能满足上市的需求，尤其是在审计方面。
帐户安全必须有一个密码复杂度的详细策略，包括用户管理和认证管理，比如密码的更改周期，账户锁定等等。
链路安全，这是数据库一定要满足的，一般是通过链路加密来进行的。
数据安全，尤其是敏感数据一定要加密，加密的收到有很多，比如可以通过PostgreSQL加密的数据类型来存储你的数据，或者是使用业务加密，把加密的阶段放在业务存储。
数据库用户操作审计，需要制订内容策略，可以支持具体的业务。
开源数据库有很多，支持的数据类型也很多。很多企业都是有特殊的业务场景的需求，不能简单用普通数据来描述，比如基因序列或者是化学方程式这类的数据常用数据库是没有办法来编码的。这时候就需要一个扩展能力强的数据库PostgreSQL提供了非常丰富的接口，可以自己编写数据类型，也可以基于开放的索引接口定义数据类型。
虽然分数据库发展了这么多年，性能的差别不是特别大，但是还是有些微差距的，所以还是需要根据业务场景建模测试、工业标准测试。
代码成熟度对于一般的用户来说难度是很高的，这里有一个小技巧，你去看社区发布的代码数量，就可以推测你的产品代码成熟度。
平台的兼容性，目前PostergreSQL是可以兼容各个平台的。
除了以上的能力，PostergreSQL还有两个重要的能力，一个是scale up，另一个是scale out。scale up能力主要考量的是是否能够充分利用计算机资源。scale out能力主要是指是否支持读写分离，sharding。
社区的活跃度和生态也是要考虑的因素。很多公司都会忽略掉生态，其实生态是很重要的，传统企业和互联网企业的需求是不一样的。社区的软件开发商、数据库的厂商以及服务的提供商，人才储备，国家整体的软件研发能力都要纳入考量的范围。
很多企业也是很关注案例的，他们会关注同行业的竞争对手在使用哪款数据库产品。
学习成本和开发成本，如果你要独立研究的话，这方面的支出就会很大，所以很多企业都选择投身参与到社区中。
我为什么要做PostgreSQL布道，其实和传教士为什么跑到偏远的地方传道是有一定的相互性，PostgreSQL确实是非常好的产品，我们企业也从中获益很多，它的代码优雅，稳定性好、性能佳、扩展性强、接口丰富等等，这么多的优点都值得我们宣扬。最主要的是当时我们成立中国用户会的时候，中国对PostgreSQL数据库认知非常少，酒香巷子深，从现在看，也证明了我们当时的选择是没有错的。
PG在国内关注的增长趋势是在往上走的。
百度的搜索指数代表中国市场，谷歌的搜索指数代表国际市场，从全球的角度来看，中国市场对PostgreSQL的认知和国外市场还有一定的差距。
国内的用户没有听说过PostgreSQL，那么就会对PostgreSQL充满疑问。例如它的性能怎么样，它能管理多大的数据量，它能不能用好硬件资源，使用哪些方式来提升我的性能，以及和其它的数据库相比有哪些优缺点。以上疑问都是我们布道者要做的工作。
接下来给大家来普及几个PostgreSQL的案例，可能会颠覆大家对数据库产品的认知。
第一个例子，我们看这个图，从左边到右边是一个数据聚集的过程，这个在数据分析或者数据挖掘领域是非常常见的案例。比如说我对一些用户的行为做分类，在PG里面可以通过kmeans做到。
实时计算某WEB站点的请求延迟， 90%的请求低于多少毫秒， 95%的请求低于多少毫秒，99%的请求低于多少毫秒。这个的处理方法也是很简单，数据采集到性能数据，我只要建一个模式统计就可以了。除此之外，在加一个窗口查询，就能得到我们想要的结果。
第三个例子，我在数据库里面能不能做多元的信息反馈，这个在数据仓库或者是一些BI系统里面也是非常常见的，但是在关系型数据库里是不常见的。P元线性回归，通过图上的公式求得截距和斜率，然后就可以预测yn。
这里用到linregr训练方法，训练source_table然后放到out_table里，通过这样的一个函数就可以解决这样的应用需求。
除了刚刚举的例子之外，madlib库还有很多作用，它将很多东西封装成了函数，通过这些函数就能够实现深度学习的某些东西。
第四个例子颠覆了大家对数据类型的理解，大家可能认为数据库只能存储long、int、text这类的数据，实际上数据库还可以存储更多的数据类型。比如范围搜索的数据，可能在传统数据库里面是两个字段，startvalue和endvalue，但是在PostgreSQL只需存储一个字段，就可以表示一个数据范围，甚至就可以建索引。这个索引是基于range建立的，在做范围搜索的时候查询效益非常高。
下面是一个查询效益差别的对比。
第五个例子是一个流式数据的应用场景。这个应用场景在物联网的大背景下的用户需求也是非常大的。这种场景有两个特点，第一个特点是大量的数据积累，第二个是要基于时间分析。
我们以往是使用Btree索引来实现的，我们发现数据量是非常庞大的，执行效率并不是很高。后来我们采用了BRIN的索引。
下图是两种索引性能差异的对比。
第六个例子是排他约束，排他约束和唯一约束也是相关的，唯一约束是根据排他约束来建立的。
第七个例子是外部表，PostgreSQL通过接口连接到后端的数据源，数据源的类型十分多样化。
第八个例子是秒杀，这里讲的是PostgreSQL自带的一个类似于自选锁的功能，这个锁是非常短暂，用于秒杀的网站的话，能够提升近百倍的性能。
所谓布道不仅仅只是分享案例，还包括贡献核心代码、review代码、报告BUG、开发插件、开发驱动、维护打包程序(bin,rpm,deb....)、port流行的软件到PostgreSQL、开发支持PostgreSQL的程序、翻译文档、维护官网手册和插件手册、维护HOWTO、维护迁移guide(mysql,oracle,infomix,sqlserver,....to PostgreSQL)、分享文档、写书、写博客、组织用户会议、帮助其他用户、测试patch、测试性能等等。
PostgreSQL是从伯克利写的 POSTGRES 软件包发展而来，在1995年的时候有了社区管理的概念，目前PostgreSQL的大版本更新几乎是一年一迭代。
PostgreSQL的代码活跃度做的也是比较好，比如我提交一个代码，里面会有代码审核，告诉你哪有问题，然后针对性的修改代码。
上图是PostgreSQL近几年的里程碑，我们可以看到每一年新版本的发布都有不同的东西。很多功能的实现都是一次次迭代出来的。
本次测试模型选用的PostgreSQL的8.4到9.5版本，数据量为305GB，测试结果发现各个版本的性能差异不是特别大，原因是IO的瓶颈。
第二次测试我们采用的是一亿的数据量，数据全部在内存中，考量的是数据库的代码效率，我们看到从8.4到9.5，性能几乎翻了一倍。
这是另外一个场景，一共有64张表，每张表有1000万的数据，64个并发连续压测2个小时，压测结果大家可以参考上图。
自从我们成立中国用户会以后，我们中国的用户发生了非常巨大的变化。之前我了解到几乎没有公司在使用PostgreSQL，但是我们现在看，已经有这么多的公司都在用PostgreSQL，而且很多是国字头的。我们可以看到PostgreSQL在中国发展势头非常好。
整个PostgreSQL社区的核心成员是六个，主要贡献者有40多个。PostgreSQL在中国的发张最早可以追溯到1999年，那时我们只是在做一些文档的推广，直到2011年PostgreSQL社区成立，这期间是完全没有社区的概念。现在，我们每年会在各地举办会议、会有免费的DBA培训，也会和高效合作项目。用户会把整个生态的用户、企业集合起来，大家一起把这个产品做好。
我们看一下截止到现在，社区发生什么变化。目前整个社区在中国大概有超过一万的人员，研发人员超过三百个。为什么说研发人员的占比这么少呢?因为PostgreSQL数据库的开源协议是BSD，你把PostgreSQL数据库拿过来一行代码不改，可以直接包装成自己的产品拿去售卖，但如果你把MySQL数据拿过来一行代码不改直接使用是要追究你的法律责任的。
用户会的主要工作是维持生态，当然也会有很多文档翻译，案例分享，主持会议，联合其它的社区一起来推动PostgreSQL等等的工作来做。从用户会参会来看，基本上已经接近十倍的增长。
学习任何一个产品都是多实践、多分享、有问题多翻手册和源码、多和社区小伙伴交流，开源的产品可以参与到社区中，这时你会发现你要成为一个PostgreSQL DBA花费的时间成本不是很多，比如说你是一个有一定数据库基础的DBA，你花一个月时间去学，肯定没问题。如果你是有Linux管理基础的SA或者是有服务端开发经验的开发人员，那么差不多需要三个月。如果你是完全没有基础，半年的时间你基本也可以上手了。
最后是给大家分享一下我对PostgreSQL市场的判断。商业数据库这块主要凭借PostgreSQL BSD许可，其实有很多国产数据库是基于PostgreSQL，另一块是MPP DB市场，有超过一半的MPP数据库是基于PostgreSQL，比如Greenplum、Deepgreen、redshift、PG-XL、ASTERDATA、ParStream、ParAccel等等，如果大家有兴趣或者是有很好的渠道，可以考虑一下MPP PostgreSQL。高校方向主要是科研。公有云市场也大有可为，比如上云、中间件、培训等等。其实现在在国内还没有一家做PostgreSQL的培训，这是空白的市场，发展空间巨大，大家可以去尝试。
阿里云的ApsaraDB PostgreSQL团队拥有很多PG源码专家，我们基于PostgreSQL做了很多优化，另外还提供一个高度兼容Oracle的产品PPAS。
