这是一个典型问题关于数据库的容量规划。
有关的：
我想创建一个关于数据库容量规划工具和方法的典型问题。这旨在成为一个典型问题。
显然，一般的工作流程是：
- 将您的场景放在适当位置
- 添加监控
- 添加流量
- 评估结果
- 根据结果进行补救
- 冲洗，重复，直到满意为止
请随意描述针对不同网络服务器、框架等的不同工具和技术以及最佳实践。
答案1
磁盘和 RAM 容量规划
规划数据库服务器的磁盘和内存容量是一门玄学。容量越大越好。速度越快越好。作为一般指导原则，我提供以下内容：
- 您需要比实际更多的磁盘空间曾经需要。
尽量估计一下未来 3-5 年需要多少磁盘空间，然后将其翻倍。 - 您需要足够的 RAM 来将数据库索引保存在内存中，处理最大的查询至少两次，并且还有足够的剩余空间用于健康的操作系统磁盘缓存。
索引大小取决于您的数据库，其他一切都在很大程度上取决于您的数据集和查询/数据库结构。我将提出“至少是最大表大小的 2 倍”作为建议，但请注意，此建议不适用于真正大型的数据仓库操作，其中最大的表可能有数十或数百 GB。
每个数据库供应商都有一些关于调整磁盘/内存/操作系统内核性能的说明 - 在部署之前花一些时间阅读这些文档。这会有所帮助。
工作负载基准测试和容量规划
假设您尚未部署...
许多数据库系统都附带基准测试工具——例如，PostgreSQL附带基准测试。这些工具应该是您对数据库性能进行基准测试的第一站。如果可能的话，您应该在所有新的数据库服务器上运行它们，以了解数据库服务器可以完成“多少工作”。
现在有了原始基准，ABSOLUTELY MEANINGLESS让我们考虑一种更现实的基准测试方法：加载数据库架构并编写一个程序，用虚拟数据填充它，然后针对该数据运行应用程序的查询。
这将对三个重要方面进行基准测试：1. 数据库服务器（硬件）2. 数据库服务器（软件）3. 您的数据库设计，以及它如何与上面的 (1) 和 (2) 交互。
请注意，这比简单的预构建基准测试需要付出更多的努力，例如pgBench：您需要编写一些代码来进行填充，并且可能需要编写一些代码来进行查询和报告执行时间。
这种测试也更加准确：由于您正在使用架构和查询，因此您可以看到它们的执行情况，并且它为您提供了分析和改进数据库/查询的机会。
这些基准测试的结果是数据库的理想化视图。为安全起见，假设您在生产环境中只能实现此性能的 50-70%（其余部分作为缓冲，可让您处理意外增长、硬件故障、工作负载变化等）。
太晚了！正在制作中！
一旦您的系统投入生产，进行“基准测试”就为时已晚——您可以短暂打开查询日志/计时，查看执行操作需要多长时间，并且可以在下班时间对大型数据集运行一些“压力测试”查询。您还可以查看系统的 CPU、RAM 和 I/O（磁盘带宽）利用率，以了解系统的负载有多重。
不幸的是，所有这些事情都只能让您了解系统正在做什么，以及它距离饱和有多近的模糊概念。
这就引出了……
持续监控
如果您的系统突然出现新的/不同的使用模式，世界上所有的基准测试都帮不了您。
无论好坏，数据库部署都不是静态的：您的开发人员会改变一些东西，您的数据集会增长（它们似乎永远不会缩小），您的用户会以某种方式创建您在测试中从未预测过的疯狂事件组合。
为了对数据库进行适当的容量规划，您需要实施某种性能监控，以便在数据库性能不再满足您的期望时向您发出警报。此时，您可以考虑采取补救措施（新硬件、数据库架构或查询更改以优化资源使用等）。
注意：这是一份非常高级的通用指南，用于确定数据库硬件的大小并确定它可以承受多少滥用。如果您仍然不确定如何确定特定系统是否满足您的需求，您应该咨询数据库专家。
还有一个专门用于数据库管理的 Stack Exchange 网站：dba.stackexchange.com。搜索他们的问题档案或浏览特定于您的数据库引擎的标签，以获得有关性能调整的进一步建议。
答案2
通常，您需要实际用例来测试性能。最佳做法是让应用程序开发人员和最终用户参与进来。
记录他们通常在做什么，并针对每个用例对其进行参数化（内容、并发操作的数量）。
然后建立客户端。单台物理机器通常不足以建立生产负载。
然后启动它，评估、增强并再次测试。
您将会惊讶于瓶颈出现的地方。