原文地址： https://sendgrid.com/blog/capacity-planning-for-databases/


拆分

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


能够分割读写

这是你需要做的事情，但不一定强制执行石头规则。将会有一些用例需要很快读取写入，并且对滞后/最终一致性等内容的容忍度较低。这些都可以，但在相同的应用程序中，您还将拥有可以容忍最终一致性更长时间的读取方案。当这样的读取数量很大时，如果真的不需要那么你真的希望那个音量发给你的单一作家吗？帮自己一个忙，并确保在成长期很快就可以控制代码中读写IP的使用。

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

确定系统瓶颈

  • 您是在写入还是读取时遇到瓶颈？

  • 该问题是否表现为高CPU？

  • 它是否表现为IO容量？

  • 如果没有明确的读取查询罪魁祸首，副本是否会越来越滞后？

  • 它锁定了吗？

  • 我怎么知道它是哪个？

这些中的每一个都可以是一个帖子。我想说的是，你必须熟悉你的系统和数据库特定的指标才能找出哪个部分是瓶颈。

你需要一个基线

始终确保您有可用的基本系统指标，以便至少在几周前可视化。许多工具提供此功能（Cacti，Munin，Graphite等）。一旦知道了您主要使用的系统指标，就需要建立基线和峰值。否则，确定您当前的问题是否是一个新的应用程序源错误与实际增长相比，将比您想要的更容易出错。

但是，基本的服务器指标只能到目前为止 - 在某些时候您会发现您还需要基于上下文的指标。查询性能和应用程序端感知性能将告诉您应用程序看到的查询响应时间。有许多工具可以执行此上下文重度跟踪。有些是开源，如风速计和商业工具，如Vivid Cortex（我们在SendGrid使用这些工具。请参阅我们在此处讨论它。）即使只是从应用程序角度跟踪这些指标并将它们作为统计指标抛出也将是一个良好的开端。但是，在早期您必须习惯这样一个事实，即您的应用所感知的是您的客户所感知的内容。你必须找到一种先知道的方法。

了解您的业务流量模式

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

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

这只是答案，“如果我们没有进行代码优化，有多少电子邮件/销售/在线用户/无论什么”我们可以使用我们现在拥有的数据库实例？

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

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

您需要找到一种方法来确定这是否真的是容量 - 我需要拆分写入以支持更多的并发写入负载或添加更多的read replica-vs。基于代码的性能瓶颈（来自最近部署的这个新查询实际上可以将其结果缓存在更便宜的东西中，并且不会超过数据库）。

你是怎样做的？您需要熟悉您的查询。婴儿步骤是innotop，慢日志和Percona Toolkit的pt-query-digest的组合。您可以通过将DB日志传送到中央位置并自动化摘要部分来自动执行此操作。

但这也不是整个画面，如果你将阈值降低太多，那么慢速日志是性能密集的。如果您可以采用选择性较低的采样，则需要检测应用程序与数据存储之间的整个对话。在开源领域，您可以像tcpdump一样基本使用，也可以使用Datadog，New Relic或VividCortex等托管产品。


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