数据库设计 - 有多少数据存储，性能VS质量

Question

有一定的价值，X，其中我记录每30秒，目前正在与三个字段数据库：

• ID
• 时间
• 价值

我然后创建一个移动应用程序将利用这些数据来绘制图表的看法：

• 最后一小时
• 过去24小时。
• 7日
• 30日
• 年

显然，每30秒保存的最后一年，然后将该数据发送到移动设备将太多（这将意味着发送1051200个值）。 我的第二个想法可能是我可以使用MySQL中的平均函数，例如，收集每7天的所有平均值（创建一年52点），并发送这些点。这会起作用，但MySQL仍然会通过创建平均值来拖网，如果有许多用户连接，这将会很糟糕。因此，简单地说，如果这些是我的观点，那么我不需要跟踪所有的数据。没有人应该关心一年前x的精度为每30秒，这很好。我应该可以使用“触发器”来创建一些平均值。

我找人来检查我有什么下面是合理的：

• 商店每隔30s值表（这将被用于小时来看，120点）
• 当在30s表格中120行（120 * 30s = 60分钟= 1小时），使用触发器在“半小时平均”表格中存储前半个小时，从30s表格中删除前60个条目。这张新表格需要有一个ID，开始时间，结束时间和价值。这个半小时平均值将用于24小时视图（48个数据点）。
• 当半小时表超过24个条目（12小时）时，将前6个平均值存储在6小时平均表中，然后从表中删除。这个6小时平均值将用于7天视图（28个数据点）。
• 当6小时表中有8个条目时，删除前4个并将其存储为平均一天，以便在30天视图（30个数据点）中使用。
• 当日视图中有14个条目时，删除前7个并存储在星期表中，这将用于年视图。

这似乎不是对我来说最好的方式，因为它似乎比我想象的要复杂得多。

另一种方法是保留所有数据并让mysql在需要时查找平均值。这将创建一个巨大的庞大数据库。我还没有关于性能的想法。该id是一个int，时间是一个日期时间，值是一个浮点数。 1051200记录太多了吗？现在是加入的好时机，我想在一个覆盆子pi上运行它，但是如果没有，我确实有我可以使用的主机。

Answer 1

您提出的设计看起来不错。也许有更优雅的方式来做到这一点，但你的建议也应该起作用。

RRD（http://en.wikipedia.org/wiki/Round-Robin_Database）是一个专门设计用来自动执行所有这些操作的专用数据库，为了这个专业化目的，它应该比MySQL更具性能。

另一种方法如下：只保留原始表（1051200条记录），但每次添加新记录（例如每隔30秒）都会产生一个触发器，用于生成最后一个小时/天/年等视图/在某处缓存结果。然后，您的数字处理工作量与您必须提供的请求/客户端数量无关。

1051200记录可能会或可能不会太多。测试你的树莓派找出答案。

Answer 2

让我给一个建议，你的桌子上的物理布局，无论你是否决定保留所有的数据或不时“修剪”这......

既然你生成一个新的行“每30秒“，那么Time可以作为一个自然键，而不用担心超出底层数据类型的分辨率并导致重复的键。你不需要ID在这种情况下，使你的表很简单：

Time (PK) 
Value 

而且，由于InnoDB tables are clustered，没有二级指标意味着整个表存储在一个单一B树，它从存储和查询角度来看效率很高。最重要的是，Value自动covered，这可能不是你的原始设计的情况，除非你专门设计了你的索引。

使用时间作为关键一般来说可能会非常棘手，但我认为在这种特殊情况下可能是值得的。

---

除非有引用它通过外键与其它表，或者你已经写依赖于它太多的代码。

在原始设计中，为了支持高效聚合，这是非常必要的。