MySQL 数据库 - 容量规划困境，请指教

Question

我有一个 MySQL 托管和容量规划问题。我想知道托管以下类型和大小的 MySQL 数据库的最低托管要求：

背景：我有一个金融行业的客户，他购买了一个定制软件 CMS 平台，用 PHP 编写并带有 MySQL 数据库。

他们目前的解决方案没有任何报告，提供它的软件供应商只允许他们使用一些 PHP 页面来导出表格的全部内容，然后客户必须在 Excel 中手动操作以获得他们的业务报告。

供应商不允许他们按顺序访问他们的实时数据库 运行 Crystal Reports 说这对数据库有风险，宁愿他们购买昂贵的数据库复制解决方案；所以 客户继续对整个表执行繁琐的手动导出 每天。

数据库： 数据库目前有 90MB 大小，上面有一个自定义的 9 个月大的 PHP 解决方案。客户无权访问它，因为它由他们当前的供应商托管。总共有 43 个表，其中一个 - 一个巨大的日志表占用了 99% 的数据库大小。

包含业务数据的前四个表大小是小表；

• 34.62 MB
• 13.79 MB
• 8.46 MB
• 7.59 MB

绝大多数表都是简单的数据值查找表，只有几行。

然而，数据库中最大的表是一个 1400MB 大小的大型日志表。仅此表就占整个数据库大小的 99.9% 以上。

问题：考虑到解决方案（尽管有日志表）非常小，只有少数员工通过一些简单的 PHP 表单进行数据输入，运行 Crystal Reports 是否存在实际问题在生产中针对这样的数据库？请记住，白天有时（实际上是一天中的大部分时间）根本不使用此数据库。例如午餐时间和非工作时间。

供应商坚持认为，查询实时数据对企业来说存在根本风险，并且针对该数据库运行 Crystal Reports 可能会导致“实时数据库崩溃，企业失去运营”。

客户也渴望拥有一个实时仪表板；这可以用一个非常小的 SQL 查询来编写，以从上面列出的那些小表中聚合一些数字。

我通常使用 SQL Server 和 Oracle，对于允许 Crystal Report 或运行视图以使用来自实时数据库的一些实时数据填充 UI（尤其是这么小的数据库），我完全没有疑虑；毕竟，如果一个人不能一次又一次地从中选择，那么数据库是什么？

为了避免“挂起服务器”和“避免在服务器上发生其他操作时进行查询”，是否有必要将此 MySQL 数据库复制到第二个报告数据库？根据我的经验，这样做的需要仅适用于敏感、安全风险或交易量大的数据库。

系统使用情况：系统严重依赖每半小时安排的 CRON 作业。每周可能有 500 个用户登录并输入一些数据（但数据不多 - 请参阅上面的表格大小）。

热烈欢迎任何cmets。

感谢您的宝贵时间。

Answer 1

1) 您需要 2 台 5 美元的数字海洋服务器。

2）“使实时数据库崩溃，业务失去运营”。绝对是假的。他们是白痴。他们可能隐藏的是他们数据库的不良结构。他们可能为所有客户提供 1 个表架构，仅与 client_id 分开。授予对表的访问权限将授予对所有客户端数据的访问权限，这就是他们强制使用大型复制解决方案的原因，以便他们可以确保您只获取您的数据。

3) 是否有必要避免“挂起服务器”和“避免在服务器上发生其他操作时查询”？是的。

4) 将此 MySQL 数据库复制到第二个报告数据库？是的，这是一种很好的做法，因为您可以在最坏的情况发生时设置故障转移。如果你真的很偏执，你可以设置来自不同公司的远程故障转移。看看金融领域的情况，我很确定你想要这样。

5) 根据我的经验，这样做的需要仅适用于敏感、安全风险或事务量大的数据库。以我的经验，备份您的数据总是好的，因为生活中经常发生这种事，而且通常发生在您最不期望的时候。

至于您的实时使用情况。假设数据库的索引结构正确并使用 InnoDB，您应该在支持每秒 100 个请求时遇到最小的问题，所以我认为您不必担心每周 500 个用户的问题。

就像我提到的那样，您可能想要的是不同提供商的 2 台服务器，这可能是您可以获得的最便宜的实例，因为您不需要大量的空间或资源。您可以设置 DNS 以使 1 个主服务器和 1 个复制从属服务器，然后在灾难情况下更改 DNS 并使另一个成为主服务器。

我希望这会有所帮助。