原文标题 ：Throwing More Compute at the Problem

在问题上投入更多计算

为什么从长期或短期来看这不是一个好策略

Background

是的，这是查询编写者在面对他们编写了错误查询的事实时通常会采取的第一种方法。有时，他们有能力获得更多的计算来解决问题。大多数时候，事实并非如此。在过去的十年中，我为多个产品和公司设计和扩展了数据库和数据仓库，我非常详细地理解了这个问题。在这篇文章中，我将分享我的观察并提出一些解决这个问题的好策略。

在我们更深入地研究解决方案之前，我想从我自己的工作中为您提供一些示例，您可能会很容易地联系到这些示例。这将帮助您更好地理解问题。考虑以下场景：

😕 你有一个复杂的 MySQL 复制拓扑，混合使用本地和第三方复制器。数据库托管在 EC2 实例上（这不是最近的事；当时 RDS 并不流行）。为您拥有的负载过度配置了这些实例。尽管如此，当有人查询终端从数据库实例时，他们有时会由于负载峰值而停止复制。他们还因为各种锁而阻止了其他想要查询数据库的用户。这直接影响业务。

😞 你刚刚加入了一个团队。该团队已经建立了一个 Redshift“数据仓库”。他们实质上是从他们的关系数据库、第三方集成 API 和应用程序流中转储所有数据。将数据转储到 Redshift 的过程非常有效，但是当分析师在该数据之上编写查询并连接所有数据源时，它似乎不起作用。为什么？好吧，将所有数据转储到允许数据仓库的平台并不会自动使您的转储成为数据仓库。一半的表没有正确的分布和排序键。其中一些有很大的偏差。了解将哪些工具用于什么目的也非常重要。

😭 你有很多数据。其中大部分来自结构化来源。您想使用 Spark 进行并行处理。您为您的团队提供了一个 Spark EMR 集群以供使用。集群设置为自动缩放，但有一个上限。您的数据在您从中获取数据的对象存储中被正确分区，但仍然存在一些偏差。您混合使用 Python 和 SQL 来到达您想要的位置，但您注意到与在小得多的关系数据库上相比，执行查询所花费的时间更多。这怎么可能？

让我们一个一个地看这些例子。

Identifying the Problem

乍一看，似乎基础设施可能配置不足，但仔细观察，您可以通过这些示例清楚地识别出一些事情：

• 对于第一个示例，手头有一个查询优化问题，需要快速处理。
• 在第二个示例中，“数据仓库”一词被误用，并且对查询性能成功的期望是错误的。
• 在第三个示例中，还有一个查询优化问题需要研究。

这只是三个例子。我相信你们中的许多人已经看到了更多。

Some Questions & Suggestions

通过提出以下问题，您可以做一些简单的事情来解决这个问题：

• 导致问题的查询数量/强度是否激增？如果是，并且您的系统大部分时间都严重未得到充分利用，那么最好转向无服务器基础架构。
• 你真的需要数据仓库吗？如果是的话，如果您构建一个而不是将 Redshift 垃圾箱称为数据仓库不是更好吗？那是不诚实的工程。
• 通过查看执行计划来分析查询是否有帮助？是的，它可以，而且确实如此。无论您使用哪种数据库技术，您始终可以选择查看查询优化器并查看数据库如何执行您的查询；这将告诉您需要修复的内容。

投入更多计算

对上述问题投入更多的计算并没有多大帮助。有时，它会，但它不值钱。如果您的查询很糟糕，或者您使用了错误的数据库来解决问题，那么数据库系统甚至不会记录计算（资源）的增加。他们会吃掉他们遇到的任何东西。

当投入更多计算是好的时候，你可能会问！嗯，答案并不简单，但也不是很复杂。您需要同时查看几个因素，例如数据库配置、计算和内存利用率、数据量、并发用户、数据访问模式（尤其是读取模式）、索引（和/或分区）等等。在某种程度上，即使在短期内，投入更多的计算也可能是最糟糕的解决方案，因为它也可能无法解决您的错误查询问题。

使用可观察性了解更多信息

市场上的许多工具可以让您了解这些事情。一个例子可能是 NewRelic 和 Percona 工具包的组合。据我所知，它将结合应用程序可观察性和数据库性能管理工具，让您全面了解数据库的情况。如果您将数据库托管在 AWS 等云平台上，则可以使用 RDS Performance Insights 等工具查看数据库。这就是为什么使用云数据库进行扩展会更容易一些，因为它们从一开始就与一些支持工具打包在一起。

Conclusion

一旦您更全面地掌握了数据库性能，您就可以更好地判断是否需要为数据库提供更多功能！

如果您觉得我的文章有用，请订阅并查看我在 🌲 Linktree 上的文章。您也可以考虑通过使用我的推荐链接购买中等会员资格来支持我。[0]