PostgreSQL 问对

你对 PostgreSQL 的整体印象是怎样的？

我从第一份工作开始，就大量的参与数据分析工作，也参与过大量互联网项目的开发，这二十多年的开发工作中，我用过 MS SQL Server、Oracle、MySQL、PostgreSQL、Firebird、Sybase SQL Anywhere 等等各种各样的数据库产品，就我个人的趣味来说，PostgreSQL 是最符合我预期的，这是我心目中最好的关系型数据库产品。

PostgreSQL 多年来被视作 MySQL的竞争对手，这一点你怎么看？

实际上，PostgreSQL 不仅仅在互联网行业被视作MySQL的竞争对手，还在企业应用中被视作 Oracle 的竞争对手，甚至，PostgreSQL 的前身 Ingres，它的查询语言QUEL，还曾经是 SQL 标准的竞争对手。
作为一个 PostgreSQL 的忠诚用户，我可以调侃一句 PG 几乎在每一场次重要的竞争中都没有胜利，但是这似乎也说明了它广泛的适用性和活跃的社区发展。这种既宽容对待挑战又温和的坚持立场的社区文化，或许也是它的魅力之一。
MySQL 是一个伟大的产品，无论社区建设，还是技术路线，抑或一些功能实现，都有值得 PG 社区学习的地方。但是 PG 也有很多独特的优势，特别是在技术实力上，PG社区应该有自信成为任何关系型数据库的对手。
互联网行业日趋复杂，我们需要解决更多，更复杂的问题，需要充分利用各种技术工具。作为一个数据库产品的用户，我希望 MySQL 和 PostgreSQL 都越来越壮大，至于谁能在这场竞争中胜出，我并不在乎。十多年前我正式开始成为一个 PG DBA的时候，并不太在乎它是否是一个冷门技术，我只是喜欢它的技术风格，未来如果我需要使用 MySQL 的时候，也不会是因为它是否是主流产品，而是因为它有我需要的功能。

PostgreSQL 提供了很多功能，但是这些功能，似乎并不会总是用得到？

回想一下，我最早喜欢上这个数据库产品，应该是因为它的 SQL 语法直接支持正则表达式，然后是 XML 和 TEXT 类型，还有JSONB和全文检索，这些功能支持我在工作中实现了一些非常有价值的功能，例如当年我写了一个企业内部的全文搜索引擎，因为有 PG 的 TSearch2 支持，整个系统只用了五百多行 Python 代码。
一个好的通用产品，经过几十年的积累，有很多功能对于某个团队用不上，这是非常正常的。但是它是否没有意义，还是要看两方面，一是这些功能的存在，是否对用不上它们的用户造成困扰，二是真正需要使用它们的时候，是否可以方便的融合进来。
PG在这两方面做的都非常好，这些年来，我不断的在 PG 的文档中挖掘到我需要的新功能，去年我用上了它的几何功能，因为它内置了对地球球面坐标系的计算能力，对于LBS应用非常方便。
而这些年来，JSONB 和倒排索引，一直是我在 PG 项目里非常常用的东西，它可能对另一些团队并不重要，这很正常。重要的是，我们需要用到的时候，这些都是现成的，而不需要的时候，它不会造成任何困扰。我用过一些昂贵的商用数据库系统，只是安装一个供开发者使用的版本，就要几张光盘，相比之下，就算带上完整的 contribs 包，PG也仍然是一个不大的数据库软件。

些年，基于 PG 的分支数据库似乎很多，这个你怎么看？

其实，这算是 PG 社区的传统，如果追溯起来，很多商用数据库产品，包括 Sybase 、Informix 等等，最初都来自 Ingres ，2014年，Ingres 的作者迈克尔·斯通布雷克获得图灵奖，授奖理由之一就是“他的工作广泛的影响了整个数据库产业”。
得益于 PG 友好的 BSD 授权，数据库研究者，特别是高校师生，很多都基于 PostgreSQL 的源代码工作，这里面也衍生了一些数据库品牌，包括一些国产的数据库产品。例如我有一个私人朋友，在 PG 的基础上默默耕耘几年，开发了一套分布式数据库系统，拿下了一个很大的银行大单。总的来说，PG众多的衍生产品，可以看作是社区活跃的表现，也确实诞生了一些很优秀的特色产品，例如分布式的数据挖掘产品 Greenplum，这也证明了PG的源代码质量非常好，提供了很高的起点。

PostgreSQL 是你心目中的完美数据库吗？

不是，我想我心目中的完美的数据库产品，可能永远也不会存在。但是 PG 在我使用过的各种数据库产品中，确实是最能满足我需要的。也是最有趣的。

你提到有趣？

也许这样评论一个生产工具是比较奇怪，但是 PosgreSQL 对我来说，不仅仅是一个强大的数据库软件，它确实也是一个有趣的东西，例如前几年我在 QCon 演示过，用 PG 的递归查询，就可以实现一个玩具级别的深度学习算法，我甚至没有用到任何过程化语法，完全使用 SQL。
PG 设计的非常优雅，它的 SQL 实现统一，干净，并且扩展方便，无论正则表达式、JSONB、地理信息计算，都可以平滑的集成在查询中，绝非简单的堆砌一些扩展函数。

你想对 PG 的初学者提什么建议？

现代的 PG 对于学习者已经算得上非常友善，主流的 Linux 软件服务，都提供了 PG 安装包，并且安装程序提供完整的用户环境部署、数据区初始化等工作，几乎是开箱可用。MacOS 流行的 homebrew ，也提供 PG 的安装和服务管理。只要几行命令，就可以得到一个便利的学习环境。
并且主流的编程语言，基本都有非常高质量的 PG 驱动，Python 的 psycopg2和 asyncpg，Java 的 postgresql jdbc，go 的 lib/pq ，我都用过，都是非常可靠的工具库。无论是应用开发方向，还是数据分析方向，都可以短时间完成 PG 的环境准备，投入使用。对于一个关系型数据库产品，在使用中学习，是最有效的。

PostgreSQL 如此优秀，为何当下最流行的关系型数据库是 MySQL？

嗯……这个问题有点引战的危险。老实说我并不觉得这有什么奇怪，大概二十年前，我第一次接触到 MySQL 的时候，没费什么力气就在 windows 上安装成功，然后摸索着就用上了，虽然 3.x 的 MySQL 确实让我觉得太过简陋了，但是它并不难用。而同样是那个时代，我第一次接触 PostgreSQL 7.4 的时候，使用体验就差得多。在 .com 时代，MySQL是一个简陋，但是足够用的产品，而PG虽然功能更完整一些，但是不够好用。举个例子，MySQL很早就支持对某一个字段单独设置访问权限，而这个功能，PG晚了很多年。再比如 MySQL 的慢查询日志，这个功能对于应用开发者是极为有用的工具。
时至今日，PostgreSQL有了长足的进步，在市场上逐渐热门起来，它也是我心目中最好的数据库产品，但是 MySQL 作为互联网时代最成功的关系型数据库，仍有大量值得PG学习的地方。

很多学习者，会担心市场上缺少 PG 的工作岗位，在 PG上投入的学习成本，得不到足够的回报，你怎么看这个问题？

我个人的经历可能确实不太值得借鉴，因为我总是基于个人的兴趣去学习技术，并不太关注它是否在市场上流行。在我看来，我这样的普通人能接触到的技术，无论如何也不至于冷门到真的没有工作岗位，相反，如果足够深入，就可以得到更强的竞争力。所以个人是否有兴趣学习下去，才是最根本的理由。基于这一点，我九十年代开始接触 Interbase和Firebird，2002年开始学习C Sharp和Python，2008年开始接触 Haskell，2009年正式的开始用 PostgreSQL 工作， 这些在当时都不是最主流的技术。
PG 是一个设计优雅，体系完备的数据库产品，通过学习PG，不仅仅可以得到使用 PG的知识，还可以更好的理解关系型数据库的功能设计，如何编写查询，这些技能在使用其它数据库时也会非常有用。
即使在普遍认为 PG 是冷门技术的时代，雅虎曾经运营了一个 3PB 的 PG 集群。日本电信（NTT）有一个庞大的PG集群，可以在必要时倒回到两周内的任意时刻。十多年前，腾讯的 PG集群就达到 70PB的规模，跟不用说阿里云的 PG RDS，已经运行了很多年。
总的来说，PG的工作岗位越来越多，很多大厂都有基于 PG 工作的团队，小企业选择功能齐全的 PostgreSQL，作为自己起步的助推器。我自己近几年，也遇到了越来越多使用 PostgreSQL 的团队。各大云服务商，也都提供 PostgreSQL 的RDS，对于互联网企业，PG使用起来也已经非常方便。
近些年去 IOE 的风潮推动，PG在国内的企业应用也越来越流行。这个方向，也有很多值得关注的工作机会。

你怎么看待 PG 和其它 NoSQL、NewSQL数据库的关系？

首先，我一向反对简单粗暴的把非关系型数据库都归类于“NoSQL”或“NewSQL”，在“非关系型数据库”这个庞大的补集中，包含了非常不一样的各种产品，就拿我们比较熟悉的键值数据库和文档数据库来说，通常我们都期待文档数据库具有一定的查询能力，能够支持复杂的数据结构和索引，最好有分布式能力。但是对于键值数据库，我们通常不需要它提供索引和查询，只要能够快速的读写，以及，要能够集群。
同样，这些产品对关系型数据库，并非替代关系，在一个朴素的互联网项目中，我们往往希望围绕关系型数据库建立业务模型，用KV作为高速缓存，可能还会需要基于文档数据库的全文检索引擎等服务。
但是另一方面，关系型数据库自身，也提供了很多重叠的功能。例如 MySQL的内存表，小数据读写性能远超普通的数据表，可以说非常适合作为会话缓存使用。再例如 PG强大的 JSONB ，在我的十多年PG经验中，经常代替专门的文档数据库使用，既能够享受到 JSON 数据结构的灵活便利，又能充分运用 PG 强大的查询能力。在一个不断发展的项目中，可能最理想的是先围绕关系型数据库充分发展，然后根据需要补充各种不同功能的产品。