在最新一期的数据库深度挖掘中，我们采访了Brad Nicholson和Dave Cramer，了解了他们在 PostgreSQL 世界中的经历。

来自Crunchy Data的Dave (@dave_cramer)是PostgreSQL JDBC驱动程序的维护者。来自IBM的Brad是IBM云数据库组合的架构师和工程师。

阅读下面的采访，了解PostgreSQL社区是如何成为其最大的优势——但有时也是弱点——以及新的可插拔存储引擎如何帮助Postgres从数据库变成应用程序开发平台。

跟我们谈谈你自己和你今天在做什么?

戴夫·克莱默(华盛顿特区):我目前住在加拿大安大略省的一个小镇上，我很幸运，在我的职业生涯中一直在家工作。为了乐趣和刺激，我喜欢在赛道上开车探索我目前对物理学的理解。

至于我今天在做什么，复杂的数据让我可以全职工作在Postgres上，这真的，真的很酷。我目前正在JDBC驱动程序上工作，修复bug;实际上，正如我们所说的，在PostgreSQL的后端添加一些东西来帮助JDBC驱动程序和其他驱动程序处理像人们改变它们的搜索路径这样的事情。

我还帮助使用了Joe Conway编写的PL/R过程语言(他也处理复杂的数据)。还有一堆其他有趣的技术我正在帮助或参与。我最喜欢的一个是逻辑解码，它以一种只有Postgres才能做到的独特方式支持更改数据捕获。最近在Java PostgreSQL中，有许多我非常感兴趣的反应/异步驱动程序。

布拉德·尼科尔森(BN):我住在多伦多。今天，我在IBM Cloud数据库工作。我是一名架构师和工程师，在Postgres空间和其他数据库工作。真正处理将数据库即服务从内部自主开发的解决方案引入成熟的kubernet本地平台和产品的挑战。

你是如何加入PostgreSQL的?

完全是意外。我的职业生涯是从web开发人员开始的。我所从事的工作是 MySQL (在事务出现之前)，当时发生了各种奇怪的事情，比如列被悄悄地截断，人们会在那一天停止浏览器，让一个表写入，而不是另一个表。我在想，肯定有比这更好的方法，而那正是在Postgres成为一个可行的开源产品的时候。

我不记得具体的版本了，但是像Tom Lane这样的人接管了它，并开始在它上面做很多工作。所以，我打开它，它很快就解决了我的问题，因为它像你期望的那样工作。从那以后，我开始了一份博士后DBA的工作。

DC:这几乎是一种意外，有点……也许吧。这里有一个故事——大约在1998年，我辞去了工作，成为了一名顾问。该合同支持一个 Java 应用程序，在那时，这意味着获得微软网络订阅。

我遇到了一个问题，我打电话给支持部门，他们说需要三周时间。我说，“啊，这怎么可能呢?”我是按小时计酬的，所以三周的时间看起来有点长。我想一定会有更好的方法，于是我开始关注开源。

(一开始)我对它一无所知，所以我问一个朋友如何开始。他说:“打开邮件列表，开始回答你能回答的所有问题。”我对Java很感兴趣，所以我找到了JDBC列表，开始回答每个问题。第一次花了几天时间才弄明白，第二次花得少一些，一两个月后，我就可以不用做研究就能回答问题了。

在某个时候，维护JDBC驱动程序的家伙决定辞职，于是Bruce Momjian问我是否有兴趣支持它。我说，“是的。”现在我已经做了20年了。这就是我如何融入社区的。

在你看来，PostgreSQL的优点和缺点是什么?

DC:哦，哇，这是个有趣的挑战。我认为优势和劣势在于社区，而不是技术。引用路线图——我要总结一下，因为它有点长——它说这是一个“非商业的，全是志愿者的，自由的软件项目，因此，开发不需要正式的功能需求列表。”我们喜欢让开发者探索他们所选择的主题。”还有更多，但这就是要点。

我在某些方面看到了它的优势，因为项目往往不会被锁定在一个特定的解决方案上，因为有公司在营销特定的解决方案。因为它是完全开源的，当我们意识到我们所做的是错误的或者有更好的方法去做的时候，我们对维持现状没有既得利益。所以，我们放弃它，改变我们的路径。

举一个具体的例子，几年前，有一个关于复制的事实标准，这是一个基于触发器的解决方案。它有很多挑战，从那时起，社区开发了一种叫做逻辑复制的东西，它取代了基于触发的复制。我们现在有一个更好的解决方案。

在我看来，优势实际上也是劣势——认为我们有这个大项目和所有这些不同的解决方案。通常，在公司开发的产品中，只有一种方法来做一件特定的事情，这也是唯一的方法。

在PostgreSQL中，做一件事有10到15种方法。现在，Postgres正在被大量的人采用，这意味着有很多新用户试图找到做事情的正确方法。可能没有正确的方法，但可能有一大堆错误的方法。

对于习惯于使用商业软件的人(其中有一种受支持的解决方案)来说，弄清楚如何使用Postgres来架构您的解决方案是相当具有挑战性的。的好事,我和松脆的数据,这为公司提供了一个机会脆数据为已知的工作提供支持解决方案(至少知道工作的解决方案,我们理解,可以支持)。这就是为什么我认为这是一个优点和一个缺点。

BN:当然，社区是优势之一。与之相吻合的是许可证。最近有很多关于Mongo, Redis和Elasticsearch的开源许可的新闻。

在Postgres中，许可证是开放的——人们不能改变它或从它那里拿走东西。没人能买到Postgres;只要它还存在，它就会是一个开源项目。这是一个非常非常大的好处。

在更技术的方面，以及一个明显而乏味的事情，是稳定。总的来说，这是一个非常可靠的数据库，只要你远离一些可能会有一些边缘情况的前沿事物。

(它也)非常安全。我真正喜欢它的一点是——尤其是与大多数数据库相比——它的可预测性。总的来说，它的运作方式和失败方式都是可以预测的。它如何失败的可预测性是非常非常好的，特别是当你要为它进行自动化解决方案时。在我所使用的其他一些数据库中，缺乏可预测性是最大的挑战之一(有太多奇怪的边界情况)。

另一件事是可扩展性。当你研究扩展系统时，你可以在Postgres上构建的东西，而不需要派生主代码基，这实际上是很了不起的。你看一下这个东西，它在30年前以关系数据库的形式出现，现在正逐渐成为应用程序开发平台，甚至是数据库开发平台。这是很酷的。

在缺点方面，我们开始越来越多地看到的一件事是缺乏本地扩展故事，比如本地分片，它允许在Postgres上本机运行更大的工作负载。

我认为连接模型也确实有局限性。整个进程连接以及使用外部连接池;我们有一些第三方工具可以解决这个问题，但它们在多租户中并不能很好地工作，因为需要将连接总数保持在相对较低的水平，并且不能在数据库用户之间共享连接，因此您必须在某些时候放松您的安全模型。

逻辑解码和本地Postgres逻辑复制也非常酷。我认为现在有一个大漏洞——它实际上并不能很好地与流复制一起工作。您不能切换或故障转移一个成员并让它同步您的位置。构建下游系统来使用它们的更改确实很好，但是一旦您必须切换或故障转移，您就会失去位置。你必须考虑重新同步你的系统，这很麻烦。

我要提到的最后一个问题是过度依赖外部工具来正确地完成许多基本工作。Postgres为您提供了这个坚如摧的数据库，它带有用于部署、备份、复制等的钩子，但将解决方案组合在一起取决于您。我想Dave之前提到过，这样做会很复杂。您必须具备丰富的知识，才能组织可靠的Postgres部署，使用DbaaS解决方案，或者花钱请人来为您完成这些工作。

我认为，如果你看更现代的数据库，设置复制和故障转移等等并不是那么困难。这是一种配置，它内置在系统中，可以正常工作。

说到现代数据库，PG 12很快就会面世。你在那里期待什么?

DC:这和我之前说的很酷的新功能以及人们的各种各样的痒感是一致的。发生的一件事基本上是Postgres能力的下一个飞跃的基础——可插拔表存储接口。这是我感兴趣的“开发酷东西”。

从一开始，就像Postgres做事情的方式一样——在一个版本中，我们将开始一个特性的框架，它不会特别有用，但下一个版本会更有用一些，[下一个版本会更有用。Pluggable table storage接口将支持柱状存储、加密列和其他特定于领域的存储系统。此外，我们开始看到分区方面的改进。我们在每个主要版本中都为分区添加了功能。这将使PostgreSQL能够处理更大的工作负载。

BN:对我来说也是可插拔的表存储。这对Postgres来说是非常令人兴奋的事情。我之前提到了可扩展性这与之相吻合，对吧?一旦您开始考虑将扩展和可插拔表存储组合在一起，您就有了这个开发平台，您可以在上面开始构建各种很酷的东西。

另一件更以开发人员为中心的事情是JSON路径。Postgres具有非常棒的JSON功能。但如果你不是一个Postgres用户，你从使用一个文档存储来使用它，它使用起来会很奇怪。JSON路径更接近于能够在Postgres中以一种开发人员会觉得更友好的方式使用JSON。

你会给那些想要在Kubernetes上部署PostgreSQL的人什么建议?

BN:不要。说真的，现在每个人都想这么做，因为这是buzz技术。它确实解决了某些问题，但它引入了另一组问题。这一切都是关于权衡和理解你需要做出的选择。

你必须问问自己为什么要运行它。当你进入Kubernetes的世界时，你需要真正理解你在购买什么。从一个更加标准的部署配置文件来看，你完全改变了你的部署平台——事情如何被部署，事情如何移动。

很可能您还没有在容器中运行数据库。所以，当你来到Kubernetes，你就进入了集装箱化。你将不得不把很多你所知道的(关于内存管理和资源利用的)知识扔到一边，然后重新学习。这是一项伟大的事业。

您还可能需要熟练地破解Kubernetes的源代码，并弄清楚为什么它在做您认为它不应该做的事情(因为它有时会做)。

从那以后，如果你想继续前进，就不要白费力气了。基本上，有几家运营商(比如Dave, Crunchy有一家Postgres运营商)，而经营Patroni(我们很喜欢)的Zalando也有一家Postgres运营商。所以，如果你真的想这么做，看看这些运算符，然后从那里开始。不要从零开始。

DC:与“不做”相反，我想说的是，调用复杂的数据。您知道，Kubernetes最初是为无状态的工作负载设计的。当你使用PostgreSQL时，这当然是一个挑战;两者有一些阻抗不匹配。

Crunchy数据对Kubernetes世界和Postgres世界有深刻的见解。正如Brad指出的，尝试自己做这是相当艰巨的。在这里你必须是两个世界的主人!一个人同时做到这两点是一个相当大的挑战。如果你想在Kubernetes上运行它，你必须雇人或者打电话给我们。

BN:还有一件事——博客圈有很多关于在Kubernetes上运行数据库的东西。他们非常专注于第一天:建立一个数据库。现在那些东西很容易。这之后发生的所有事情——数据库的生命周期——都变得非常困难。

DC:同样的，我们有很多问题的解决方案。如果你想让数据库运行，那很好。但如果你想让它继续运行，这是一个更大的问题。例如，Kubernetes可能会决定关闭您的pods。重新安排一个运行后的时间——我们有这类事情的解决方案。我告诉你，有人揪头发来找那些东西。我要重申布拉德说过的话:“不要白费力气。”

自己在Kubernetes上运行可能会犯一个错误，那么人们在使用PostgreSQL时还会犯哪些错误呢?

BN:我想说的是，最上面的一个没有使用连接池，不理解Postgres连接模型及其限制。人们启动了20份应用程序。每一个都试图打开几百个连接，接下来您就会发现连接不足或出现性能问题。您必须了解Postgres中的连接模型是如何工作的，并使用像PgBouncer这样的池程序将事情简化到更易于管理的数量。

DC:差不多是一样的。我认为这取决于项目的规模。有一些大型项目可以从一些初步的建筑咨询中受益。他们不是数据库专家(尤其是Postgres专家)。

实际上，有一天有人给我打电话说关于物联网项目，那个人有一个特别的解决方案，我知道这个方案行不通。他有一个天真、简单的解决方案，但这个方案注定会失败。阅读、研究，或者给有这方面知识的人打电话(并且说，“这是我想做的，有什么工具可以做吗?”)在项目的开始会有很长的路要走。

当然，在较小的规模上，如果你不试图做一些具有建筑挑战性的东西，学习如何调整Postgres。至少，阅读有关设置和安全性的文档对简化您的工作大有帮助。我们有一个很棒的文档网站，只是看起来没有多少人会读它。我猜这有点像试图吃掉一头大象，你从哪里开始呢?但我认为一些阅读是很有帮助的。

您有什么秘密的性能调优技巧吗?

BN:我不认为有任何秘密的性能调优技巧。我想对人们说的是

• 学习如何读取查询计划和优化查询。
• 调整数据模型。
• 修复错误的访问模式。

老实说，根据我的经验，你可以调整旋钮来改变计划，增加内存，诸如此类的事情。但是，总的来说，最大的好处来自于正确地修复错误的查询和错误的访问模式。为此，安装pg_stat_statements扩展并学习如何使用它。分析访问模式，验证访问模式。用一种迭代的方式去做——不要只做一次就忘记它。在你的产品发展的过程中就这样做。

在Postgres和大多数数据库中，更为微妙的一点是 索引 开销很大。Postgres深受文字放大的困扰。人们会抛出一堆索引来处理任何类型的查询，但他们没有意识到作为其中一部分的所有写操作的总体影响。因此，要仔细索引，查找您没有使用的索引并删除它们。你可以很容易地在网上找到你想要的东西。

DC:和布拉德说的差不多。在一天结束时，在数据库中，读和写磁盘花费的时间最多。这是非常简单的数学——I/O通道有一定的带宽，并且您试图在磁盘上读/写一定数量的字节，并且您有一定数量的时间。这个问题无法解决，但可以确保查询正常运行。

我所见过的每一个擅长于此的人都对监控他们的数据库保持警惕和无情。他们确保他们添加到代码中的每个查询不会爆炸。当他们发布新代码时，他们检查回归，他们测量每条 SQL 语句或测量应用程序。只是要确保你明白自己在做什么。

另一件重要的事情是他们的开发系统和开发数据比他们的生产数据要小几个数量级。然后他们在制作中得到了这些巨大的惊喜!有这样一个典型的时刻:“为什么不使用索引?”因为索引实际上更慢。这是因为他们没有足够的开发数据或测试数据来实际“测试”他们在生产中所做的事情。说到底，这是常识。测试一切，再次检查它，验证它，测量它，并修复损坏的部分。

PostgreSQL vs. MySQL:应用程序开发人员在选择数据库时应该考虑哪些事情?

DC:我对MySQL不是很熟悉，不能很好地回答这个问题。但是我可以谈谈他们在Postgres中应该注意什么。他们应该理解这个问题，“什么是事务?”他们应该理解问题的答案，“什么是事务隔离?”

我们今天在大型应用中看到的是，应用框架本身非常大。它们是大型的、复杂的框架，需要花费时间和精力来掌握它们。他们倾向于把数据库看作是一种“愚蠢”的存储。他们不会真的去注意它，直到它做了一些他们没有预料到的事情。所以，我认为他们至少应该知道什么是事务，什么是事务隔离。他们应该叫人……复杂的数据会很乐意提供帮助。

BN:我在这里没有太多的贡献，因为我不太了解MySQL从应用程序开发的角度。我已经很长时间没有在这种情况下使用它了，它已经改变了很多。

最后，你认为Postgres在未来5-10年里会走向何方?

DC:这是一个非常好的问题，这意味着我真的没有答案。我确实认为有些事情我们可以看看。

我可以给你们一些猜测;我们已经克服了在大企业中使用开源的污名。我敢打赌，没有一家《财富》500强公司是没有Postgres的。这意味着它的受欢迎程度将呈几何级数增长。使用它的人越多，就会有越多的人告诉他们的朋友。他们告诉朋友的越多，使用它的人就越多。对于这个项目来说，这意味着我们将有更多的人致力于代码库。

我发现在开源社区工作的人非常聪明。这是一种羞辱。有一些聪明的人将会解决我们今天遇到的一些难题。最大的挑战是，社区将不得不弄清楚如何与更多的人打交道。我不知道未来会发生什么，但我知道我们会有更多的人。

BN:我想补充一下Dave的观点，这是一个很好的观点。我认为Postgres做事情的方式将会有摩擦——他们有自己的方式来做事情，这与当今大多数人所习惯的github风格的工作流程不同。这并没有什么错，但是对于那些来自GitHub工作流之类的平台的人来说，这是一个更高的门槛。

在这方面会有一些挑战。我认为作为一个数据库，没有人能预测未来。但是如果你看看它是从哪里来的，它是从一个学术性的关系数据库到一个可靠的、开放源码的关系数据库到一个混合模型系统的关系和非关系的东西。

当您开始研究可插拔表存储和扩展框架时，我认为您会开始看到Postgres更像是一个瑞士军刀数据库。您将开始看到它处理更多的工作负载。

这是它。非常感谢Brad和David加入我们并分享他们对PostgreSQL的看法。请留意我们未来几周的下一次采访。特别感谢Emily Hu对这次采访的帮助。如果你还没有，看看我们的其他部分。