忆梦|「关系型数据库」数据库深度探索：PostgreSQL最有潜力和学习价值( 四 ) 1234567891011121

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