数据库容量规划

已发表: 2016-06-21

注意：这篇文章的灵感来自 Julia Evans 最近关于容量规划的文章。

关系型数据库管理系统

首先，让我们建立一些基本规则。 是的……这篇文章是为我们这些使用 MySQL 的人准备的，一次只有一个 writer 和 2 个或更多只读副本。 我将在这里讨论的很多内容都以不同的方式适用于或根本不适用于多写入器集群数据存储，尽管这些也有自己的一套妥协和警告。 所以……你的里程肯定会有所不同。

但是，无论您是使用自托管的物理主机还是在 AWS 中，您都可以使用类似魔术的预留实例和近乎即时的配置，这篇博文都将适用。 在“云”中不会妨碍您了解基础设施的能力和限制，也不会免除您对团队和客户的责任。

分片

在我之前的一篇文章中，我已经对此进行了大量介绍，我主要关注的是功能分片或水平分片的好处。 是的，这是一个绝对的先决条件，因为您用于访问数据库层的内容将决定您必须扩展多少灵活性。

如果您是一家全新的公司，您可能在第一天就不需要功能分片，但是，如果您希望（我怀疑您确实这样做）成长，请不要使用不允许您拆分的开源 ORM您的数据以功能为基础。 如果您也没有在一个模式中使用所有关系数据来创建公司，那么您将获得奖励积分。

能够拆分读取和写入

这是您需要能够做到的事情，但不一定作为一成不变的规则强制执行。 在某些用例中，需要很快读取写入内容，并且对延迟/最终一致性等内容的容忍度很低。 这些是可以的，但是在相同的应用程序中，您还将有可以容忍更长的最终一致性时间跨度的读取场景。 当此类读取量很大时，您是否真的希望该卷发送给您的单个作者（如果不是真的需要）？ 帮自己一个忙，并确保在你成长的日子里，你可以控制代码中读取或写入 IP 的使用。

现在进入实际容量规划的思考过程……数据库集群跟不上，我该怎么办？

确定系统瓶颈

  • 您是否在写入或读取方面遇到瓶颈？
  • 问题是否表现为高 CPU？
  • 它是否显示为 IO 容量？
  • 在没有明确的读取查询罪魁祸首的情况下，副本是否会变得越来越滞后？
  • 是锁吗？
  • 我怎么知道它是什么？

这些中的每一个都可以单独成为一个帖子。 我要说明的一点是，您必须熟悉您的系统和数据库特定指标，才能找出瓶颈所在。

你需要一个基线

始终确保您至少有几周前可用于可视化的基本系统指标。 许多工具都提供了这一点（Cacti、Munin、Graphite……等）。 一旦您知道您最受约束的系统指标，您需要建立基线和峰值。 否则，确定您当前的问题是来自新应用程序的错误还是实际增长将比您想要的更容易出错。

然而，基本的服务器指标只能做到这一点——在某些时候你会发现你还需要基于上下文的指标。 查询性能和应用程序端感知性能将告诉您应用程序对查询的响应时间。 有许多工具可以进行这种上下文重跟踪。 有些是开源的，如 Anemometer 和商业工具，如 Vivid Cortex（我们在 SendGrid 使用这些工具。请参阅我们在这里讨论它。）即使只是从应用程序的角度跟踪这些指标并将它们作为 statsd 指标抛出它们将是一个很好的第一步。 但是，您必须尽早习惯这样一个事实，即您的应用程序所感知的就是您的客户所感知的。 你必须先找到一个知道的方法。

了解您的业务的流量模式

您是一家在特定工作日（例如营销）容易受到极端高峰影响的企业吗？ 您是否定期发布游戏，例如游戏，使您的流量增加三倍或四倍？ 这类问题将决定您应该保留多少预留空间，或者您是否需要投资于弹性增长。

确定原始流量数量与使用容量的比率

这只是对“如果我们不进行代码优化，有多少电子邮件/销售/在线用户/随便什么”的答案，我们可以使用我们现在拥有的数据库实例来提供服务吗？

理想情况下，这是一个特定的值，使规划一年增长的数学成为一个简单的数学方程式。 但是生活从来都不是理想的，这个价值会随着季节或完全外部的快乐因素而变化，比如签约一个新的主要客户。 在早期的初创公司中，这个数字是一个移动速度更快的目标，但随着公司从早期过渡到具有更可预测的业务增长模式的更成熟的业务，它应该会稳定下来。

我真的需要购买更多机器吗？

您需要找到一种方法来确定这是否是真正的容量——我需要拆分写入以支持更多的并发写入负载或添加更多的只读副本。 基于代码的性能瓶颈（最近部署的这个新查询确实可以将其结果缓存在更便宜的东西中，而不是像数据库一样击败）。

你是怎样做的？ 您需要熟悉您的查询。 最重要的一步是 innotop、slow log 和 Percona Toolkit 的 pt-query-digest 的组合。 您可以通过将数据库日志传送到中央位置并自动执行摘要部分来自动执行此操作。

但这也不是全部，如果您将其阈值降低太多，慢速日志会占用大量性能。 如果您可以接受较少选择性的采样，您将需要检测应用程序和数据存储之间的整个对话。 在开源领域，您可以像 tcpdump 一样基本，也可以使用 Datadog、New Relic 或 VividCortex 等托管产品。

打个电话

容量规划可以是 90% 的科学和 10% 的艺术，但那 10% 不应该意味着我们不应该尽可能多地为图片而努力。 作为工程师，我们有时会专注于缺失的 10%，而没有意识到如果我们完成了这项工作，那 90% 可以让我们更好地了解堆栈的健康状况，更有效地利用我们的时间优化性能和规划容量谨慎增加，最终为我们的产品带来更好的投资回报。