重构我的数据库架构

Question

我正在重构我当前的架构，它对我来说太抽象了。

我使用自制的监控软件监控我的服务器。该软件向 Rails Web 服务器发送 HTTP 请求，其中包含大约十个不同字段的信息，因此我可以快速了解所有内容。

我目前的实现：

server [id, name, created_date, edited_date, ..., etc ]
status_update [id, server_id, field1, field2, field3, created_date, edited_date, ..., etc] 

我将服务器视为用户，将状态更新视为推文。我删除了比第十个更早的 server_id 上的任何 status_update，只是为了防止增长到无穷大。

虽然我开始遇到一些并发症。我需要在索引页面上显示来自最新 status_update 的信息，我需要根据 status_update 信息对服务器进行排序，我需要存储来自某些 status_updates 的信息，这些信息可能比 10 个 status_updates 旧。似乎我将开始需要将来自 status_updates 的信息存储在服务器和 status_update 中，这将导致在插入时多次命中数据库。因此，我正在寻求重构。

我的要求： 我只需要显示最近更新的信息。 如果系统脱机，拥有接下来的 9 个 status_updates 有助于调试。 我需要能够根据最近 status_update 中的一些信息进行排序。 我需要数据库保持较小（Heroku 免费）。 理想的性能，除非必要，IE 不会多次访问数据库。 不复杂的数据库结构，所以我可以传递它。

编辑：附加信息 => 我希望最终监控大约 150-200 台服务器（对于业余开发者来说很多，但我很便宜）。每个监控服务每五分钟左右发布一次，除非出现问题。因此，最坏的情况是我每四个小时达到最大容量。

我想跟踪上次 X 事件发生的时间以及结果是什么会很好。因此，跟踪该信息必须移动到server 模型本身，因为我正在清除旧记录并且会在一个小时左右后丢失信息。虽然回想起来，我可以使用监控服务将这些信息保存在内存中，然后每五分钟发送一次，或者每次更改时只发送一次。我也可以仅在该信息发生更改时简单地编辑该信息，以便处理每个请求的更少信息。嗯！

Answer 1

效率

包括 ActiveRecord 在内的所有 ORM 都是围绕某些权衡而设计和构建的。 ORM 使用几个简单的 SELECT 语句来完成 SQL 开发人员使用单个 SELECT 语句所做的事情是司空见惯的。您的查询可能不会压倒 Heroku。

这个问题没有合理的结构性解决方案。

尺寸

您的“status_update”表应该能够容纳大量行。 Heroku 的爱好开发计划允许 10,000 行。您真的希望在免费计划中监控多少台服务器？如果我是你，我每天最多会删除一次旧行，或者当我遇到权限错误时。 （在 Heroku 上，某些权限错误意味着您超出了行数限制。）

看来我也开始需要存储信息了 来自服务器和 status_update 中的 status_updates，这将 导致在插入时多次命中数据库。

这真的没什么意义。推文不需要更新用户帐户；状态更新不需要关于服务器的更新。 这可能表明重构是有序的，但我想看看你的模型或你的 CREATE TABLE 语句来确定。 （您可以将这些粘贴到您的问题中，并在此处发表评论。）

替代品

我会认真考虑在本地机器上运行这个 Rails 应用程序，将数据写入本地机器上的数据库，特别是如果您打算以 200 个 Web 服务器为目标。这将消除所有 Heroku 行限制，如果这只是一种爱好，你真的不需要每天 24 小时运行它。如果您是专业从事这项工作的，那么您从中获得的收入应该可以轻松支付 Heroku 上的爱好基础计划的成本。 （目前每月 9.00 美元。）但即便如此，我还是会认真考虑在本地托管它。