CockroachDB：权威指南

第 15 章 集群优化 集群优化

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

无论你负责什么数据库、框架、应用程序或设备，总有人希望它更快。这可能是计算机科学家面临的最持久的挑战之一。可以想象，当艾伦-图灵在二战期间创造出突破性的解码机器后，他的上司说："干得好，艾伦，但还能更快吗？

性能优化是一项长期的工作，这并不奇怪。为用户提供反应灵敏的应用程序并保持批处理的可接受吞吐量一直都很重要。然而，在现代社会，性能变得更加重要。 在互联网时代，面向客户的应用程序如果性能不佳，就会导致客户放弃在线服务，直接影响企业的盈利。在 Cloud 时代，性能优化就是成本优化--性能不佳的应用程序将消耗更多的云计算资源，从而增加您的月账单。

调音与消防

性能优化通常有两种形式：

性能消防

性能出现严重问题，必须立即解决。

性能调整

该系统经过系统优化，以提高其性能并降低运行成本。

性能调优做得越多，需要进行的性能救火工作就越少。不过，对于几乎所有数据库管理员来说，都需要了解如何在两种模式下运行。

在 "灭火 "模式下，您通常会试图找到 "出错 "的地方--这可能是对群集造成拖累的新 SQL 语句或事务、硬件或节点故障，或者是应用程序负载变化导致的性能问题。

在调优模式下，您需要系统地处理数据库集群的各个层面，确保工作负载得到优化，软件和硬件组件配置正确。一般来说，在调优过程中最好 "向下 "处理数据库堆栈的各层。早在第 2 章中，我们就介绍了这些层级；图 15-1概括了这些层级。

图 15-1. CockroachDB 软件层

每一层的负载由上一层的配置决定。因此，在完成上层的调整之前，调整下层是没有意义的。例如，除非确保拥有所有必要的索引，否则就没有必要考虑增加节点的大小。添加索引是一项简单快捷的工作，不需要停机时间或额外成本。根据您的配置，向现有群集添加节点可能是一个耗时且昂贵的过程。

因此，在本章讨论集群优化时，我们将通过应用程序的各层来进行。 即使在灭火时，依次查看集群的每一层也是有意义的，因为需要灭火的很多问题都涉及工作负载的变化，而是最高层。

优化工作量

到目前为止，对 集群性能影响最大的是应用程序产生的工作负载。调整不当的 SQL 可能比调整良好的 SQL 产生更高的逻辑和物理资源需求。特别是，如果没有有效的索引，任何工作负载都不可能得到扩展和优化。

我们在第 5 章专门讨论了高性能数据库模式的设计，在第 6 章专门讨论了有效的应用程序实施，在第 8 章专门讨论了 SQL 的调整。在理想的世界里，应用程序在投入生产前就会得到完美的调整。在现实世界中，未经调优的 SQL 语句、意外的数据分布以及高于预期的争用情况往往会导致应用程序调优问题在生产系统中才显现出来。

在应用程序开发过程中，调整过程包括确保单个 SQL 语句和事务的优化和正确性。在生产过程中，调优过程则有些不同--我们要查找那些消耗系统资源的比例似乎高于预期的 SQL 语句和事务，并寻找可以解决这些问题的方法。

检测有问题的工作量

面对 "缓慢 "的数据库，我们一般会首先查看系统的工作负载。毕竟，数据库的 "慢 "很可能与一条或多条性能低于预期的 SQL 语句有关，因此我们可能首先要找到这些 SQL ...