这是关于数据库容量规划的规范问题。
有关：
我正在寻找一个有关数据库容量规划的工具和方法的规范问题。这是一个典型的问题。
显然，一般的工作流程是：
请随意描述用于不同Web服务器，框架等的不同工具和技术以及最佳实践。
Answers:
作为一般准则，我提供以下内容：
每个数据库供应商都有一些有关调整磁盘/内存/ OS内核的性能的说明-在部署之前花一些时间阅读本文档。我会帮你的。
现在可以使用原始基准测试，该基准测试是ABSOLUTELY MEANINGLESS让我们考虑一种更实际的基准测试方法：加载数据库架构并编写一个程序，该程序使用虚拟数据填充该模型，然后针对该数据运行应用程序的查询。
这对三个重要的方面进行了基准测试：1.数据库服务器（硬件）2.数据库服务器（软件）3.您的数据库设计及其与上述（1）和（2）的交互方式。
请注意，这比简单的预先建立的基准测试pgBench需要付出更多的努力，例如：您需要编写一些代码来进行填充，并且可能需要编写一些代码来进行查询和报告执行时间。
这种测试也实际上更加准确：由于您正在使用架构和查询，因此您可以查看它们的性能，并为您提供剖析和改进数据库/查询的机会。
这些基准测试的结果是数据库的理想视图。为安全起见，假设您在生产环境中只能获得此性能的50-70％（其余的信息可以缓冲您的意外增长，硬件故障，工作负载变化等）。
一旦系统投入生产，“基准测试”就来不及了–您可以短暂地打开查询日志记录/计时，并查看执行所需的时间，并且可以在停机期间针对大型数据集运行一些“压力测试”查询小时。您还可以查看系统的CPU，RAM和I / O（磁盘带宽）利用率，以了解系统的负载量。
不幸的是，所有这些事情都会使您对系统的工作情况有个大概的了解，并且对系统的饱和程度有一个模糊的概念。
那把我们带到…
如果您的系统突然发现新的/不同的使用模式，那么世界上所有的基准测试都将无法为您提供帮助。
无论是好是坏，数据库部署都不是一成不变的：您的开发人员将改变事情，数据集将增长（它们似乎从未收缩），并且用户将以某种方式创建在测试中从未预料到的疯狂事件组合。
为了对数据库进行适当的容量规划，您将需要实施某种性能监视，以在数据库性能不再符合您的期望时向您发出警报。此时，您可以考虑采取补救措施（新硬件，数据库架构或查询更改以优化资源使用等）。
注意：这是一个非常高级的通用指南，用于确定数据库硬件的大小并弄清楚它可能遭受多少滥用。如果您仍然不确定如何确定特定系统是否满足您的需求，则应咨询数据库专家。
还有一个专门用于数据库管理的Stack Exchange网站：dba.stackexchange.com。搜索他们的问题档案或浏览特定于您的数据库引擎的标签，以获取有关性能调整的更多建议。