Mysql 最优时间序列表示

我想知道您对MySQL 5.6中时间序列数据的组织方式的看法： 我在一个项目中工作，该项目需要存储来自不同传感器的数据。明确地说，我们正在监测几个工业设施。每个都由PLC设备（或工作站）控制，该设备在本地存储过程的最相关信息。每个传感器都映射到plc中的一个标记中，plc定期以CSV格式将此信息发送到FTP服务器。我们选择innoDB作为存储引擎，并提供了以下表格：

• tbl\u站点（id、名称）

• tbl_标签（站点id、标签id、名称…），其中（站点id、名称）为主键

• tbl\u数据（站点id、标签id、时间、值）和主键（站点id、标签id、时间）

tbl_data

表中的

PK

允许表单的快速范围查询

SELECT * FROM tbl_data WHERE station=x and tag_id=y and time BETWEEN date1 AND date2 

此外，由于一些标记的采样速度非常快，因此表

tbl_data

的增长速度非常快。为了更好地管理它，并且因为我们通常访问最新的信息，我们在

“time”

列（时间戳）上按范围对

tbl_数据进行分区。特别是，我们每年使用4个分区。即使启用了分区，单个分区也会随着工作站数量的增加而大量增加。因此，我们决定按站点id进行分区，这样每个分区只包含几个站点的数据。特别是，我们为此使用了哈希分区

目前，一切都很顺利，但我只是想听听你的意见，以防还有改进的余地。这是我第一次体验时间序列数据。。。所以我可能错过了一些重要的事情

我忘了提到，我们从每个站点接收以下格式的数据：

TAG_ID1
TIME, VALUE
TIME, VALUE
.
.

TAG_ID2
TIME, VALUE
TIME, VALUE
.
.
.

等等。通过这种方式，插入在某种程度上是按
PK
顺序进行的，据我所知，这有助于获得快速插入率。
我建议看三件事：

您需要高分辨率的历史数据吗？如果没有，您应该研究聚合旧数据或自己实现数据聚合的RRD类型数据库（例如，volkszaehler.org项目有一个
vzcompress
工具用于对时间序列数据进行聚合）
您是否经常需要检索聚合的时间序列数据（例如每天的总和）？如果是，一个单独的聚合表可能会有所帮助，例如volkszaehler.org项目正在实施
具有最高选择性的索引可能是时间戳，而不是站点或标记。重建索引顺序可能会有回报，但我不确定，建议进行性能（=负载）测试
我没有回答任何SQL问题，但我正在回答“有待改进的空间”问题

我建议您根据自己的需求手动压缩数据。虽然上面提到的RRD适用于固定大小的数据文件，但如果您希望将数据保留一段未指定的时间，或者使用SQL server的功能来存档数据，则RRD是不好的

我们所做的是使用最大增量算法，每个趋势（温度、电压等）都有自己的dv（值的变化）和dt（时间的变化）存储在每个趋势的一些元数据中，这样，如果
测量的dv
，我们就不会存储新样本，同样，如果
测量的dt

这给了我们很大的压缩和灵活性，因为温度读数通常没有太大的变化（设置dv=0.5，dt=30s）；然而，您需要高分辨率的电压（设置dv=0.01和dt=0）等

这种方法的缺点在于趋势分析。由于我们为此编写了自己的工具，因此最难克服的是：

如何表示两个点之间在x秒内没有变化的曲线：作为点之间的直线？这意味着该值是线性的。最后，我们使用了一条分步线，因此在收到新值之前，该值保持不变
如何检测脱机时段或通信问题？由于您不再具有每次轮询一个样本的隐式心跳，因此我们必须引入另一个元数据趋势，它表明数据是有效的，即使值在一段时间内没有改变，或者类似地，数据在某些部分无效
最终的结果是，即使有很高的投票率，我们也可以用较小的存储容量记录几年来的一些趋势。
非常感谢您的回复@andig。关于第3点，您不认为使用（标记、时间）索引进行时间范围查询更好吗？（正如我上面的查询示例）我真的不知道。我先读了《最高选择性》，但建议在DBA论坛上特别提问。我自己对答案感兴趣；）我已经找到了几个论坛来解释这个问题。似乎正确的顺序（为了在时间范围查询中获得更好的性能）应该是先“标记”，然后“时间”。我认为《有效的Mysql.OptimizationSQL语句（Oracle出版社）》一书也解释了这个问题。