磁盘和内存容量规划

规划数据库服务器的磁盘和内存容量是一门黑色艺术。 越多越好。 更快更好。

作为一般准则，我提供以下内容：

• 你想要更多的磁盘空间比你所需要的。
  对未来3 – 5年需要多less磁盘空间进行最佳估计，然后将其加倍。
• 你需要足够的内存来保存内存中的数据库索引，至less处理两倍以上的最大查询，并且还有足够的空间留给健康的操作系统磁盘caching。
  索引大小将取决于您的数据库，其他一切都严重依赖于您的数据集和查询/数据库结构。 作为一个build议，我会提供“至less是你最大的表的两倍”，但是要注意的是，这个build议打破了真正的大型数据仓库操作，其中最大的表可以是几十或几百兆字节。

每个数据库供应商都有一些关于性能调优的说明 – 在部署之前花点时间阅读本文档。 我会帮你的。

工作负载基准testing和容量规划

假设你还没有部署…

许多数据库系统都带有基准testing工具 – 例如， PostgreSQL附带pgBench 。
这些工具应该是您在基准数据库性能方面的第一站。 如果可能的话，你应该在所有新的数据库服务器上运行它们，以便了解数据库服务器可以做多less工作。

现在已经准备好了一个完全没有意义的原始基准，让我们考虑一个更现实的基准testing方法：加载数据库模式并编写一个程序，用虚拟数据填充它，然后运行应用程序对这些数据的查询。
这基准三个重要的事情：1.数据库服务器（硬件）2.数据库服务器（软件）3.您的数据库devise，以及它如何与上面的（1）和（2）交互。

请注意，这需要比简单的预build基准testing（比如pgBench更多的工作：您需要编写一些代码来完成填充，并且您可能需要编写一些代码来执行查询和报告执行时间。
这种testing也大大更加准确：由于您正在处理模式和查询，您可以看到它们将如何执行，并为您提供了configuration和改进数据库/查询的机会。

这些基准的结果是数据库的理想化视图。 为了安全起见，假设在生产环境中你只能达到这个性能的50-70％（剩下的就是一个可以让你处理意外增长，硬件故障，工作负载变化等的缓冲）。

太晚了！ 它在生产中！

一旦你的系统在生产中，“基准testing”实在太晚了 – 你可以简单地打开查询logging/时序，看看事情要执行多长时间，并且你可以在closures期间对大数据集执行一些“压力testing”查询小时。 您还可以查看系统的CPU，RAM和I / O（磁盘带宽）利用率，以了解其负载有多重。
不幸的是，所有这些事情都会给你一个关于系统在做什么的概念，以及一个模糊的概念。
这使我们…

持续监测

如果您的系统突然看到新的/不同的使用模式，那么世界上的所有基准都不会对您有所帮助。
对于更好或更糟糕的数据库部署不是静态的：开发人员将会改变事情，数据集将会增长（他们似乎永远不会缩小），而且用户会以某种方式创build你在testing中从未预测过的事件的疯狂组合。

为了对数据库进行适当的容量规划，您需要实施某种性能监视，以在数据库性能不再满足您的期望时提醒您。 此时，您可以考虑补救措施（新硬件，数据库架构或查询更改以优化资源使用等）。

注意：这是一个非常高的级别和通用的指南，以确定您的数据库硬件的大小，并确定可以采取多less滥用。 如果您仍然不确定如何确定特定的系统是否满足您的需求，则应该与数据库专家联系。
还有一个专门用于数据库pipe理的Stack Exchange站点： dba.stackexchange.com 。 search他们的问题档案或浏览特定于您的数据库引擎的标签，以获得关于性能调整的更多build议

一般来说，你需要真实的用例来testing性能。 最好的做法是让应用程序开发人员和最终用户参与。

logging他们通常在做什么，为每个用例参数化（内容，并发动作的数量）。

然后build立客户端。 一台物理机器往往不足以build立生产负载。

然后开火，保养，再次加强和testing。

你会惊讶瓶底上涨。