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

Question

有一些值x，我每30秒录制一次，目前进入一个有三个字段的数据库：

• ID
• 时间
• 值

然后我创建了一个移动应用程序，它将使用该数据绘制以下视图中的图表：

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

显然，去年每30秒保存一次，然后将该数据发送到移动设备将太多（这意味着发送1051200值）。 我的第二个想法也许是我可以使用MySQL中的平均功能，例如，每7天收集一次平均值（一年创造52点），然后发送这些点数。这样可行，但MySQL仍然会通过创建平均值进行拖网搜索，如果有很多用户连接，那就太糟糕了。

简单地说，如果这些是我的观点，那么我不需要跟踪所有数据。没有人应该关心一年前x的每30秒精度，这很好。我应该可以使用“触发器”来创建一些平均值。

我正在找人检查下面的内容是否合理：

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

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

另一种方法是保留所有数据，让mysql在需要时查找平均值。这将创建一个巨大的数据库。我还不知道性能。 id是一个int，time是一个datetime，value是一个float。 1051200记录太多了吗？现在是添加的好时机，我想在覆盆子pi上运行它，但如果没有..我确实有我可以使用的主机。

Answer 1

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

RRD（http://en.wikipedia.org/wiki/Round-Robin_Database）是一个专门的数据库，旨在自动完成所有这些工作，并且为了这个专门的目的，它应该比MySQL更高效。

另一种选择是：仅保留原始表（1051200条记录），但每次添加新记录（例如每30秒）并存储/时，触发器会生成最后一小时/日/年等视图将结果缓存到某个地方。然后，您的数字运算工作量与您必须服务的请求/客户端数量无关。

1051200条记录可能会也可能不会太多。在你的Raspberry Pi中测试一下。

Answer 2

让我对您桌子的实际布局提出建议，无论您是否决定保留所有数据或不时“修剪”......

由于您“每30秒”生成一个新行，因此Time可以作为自然键，而不必担心超出基础数据类型的分辨率并导致重复键。在这种情况下，您不需要ID ¹ ，因此您的表格只是：

Time (PK)
Value

从InnoDB tables are clustered开始，没有二级索引 ² 意味着整个表存储在单个B-Tree 中，这与它获得的效率一样高从存储和查询的角度来看。最重要的是，Value会自动covered，除非您专门为此设计了索引，否则原始设计可能不是这种情况。

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

---

¹ 除非有其他表通过FOREIGN KEY引用它，否则你已经编写了太多依赖它的代码。

² 在原始设计中，有必要支持高效聚合。