Question

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

tbl_stations (id,name)
tbl_tags (station_id, tag_id, name ... ) with (station_id, name) being the PK
tbl_data (station_id, tag_id, time, value) with PK (stations_id, tag_id, time)

PK表中的tbl_data允许对表单进行快速范围查询

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

此外，由于某些标签的采样速度非常快，因此表格tbl_data的增长速度非常快。为了更好地管理它，并且因为我们通常访问最新信息，我们在tbl_data列（时间戳）上按范围"time"进行了分区。特别是，我们每年使用4个分区。即使启用了分区，随着站点数量的增加，单个分区也会增长很多。所以我们决定通过station_id进行子分区，这样每个子分区只包含几个站的数据。特别是，我们为此目的使用了HASH分区。

目前，一切都运作良好，但我想听听你的意见，以防万一还有改进的余地。这是我对时间序列数据的第一次体验......所以我可能会错过一些重要的事情。

我忘了提到我们以下列格式从每个电台收到数据：

TAG_ID1
TIME, VALUE
TIME, VALUE
.
.

TAG_ID2
TIME, VALUE
TIME, VALUE
.
.
.

等等。这样，插入在某种程度上是PK顺序，这对于获得快速插入比率是有益的。只要我知道。

Answer 1

我建议看看三件事：

您需要高分辨率的历史数据吗？如果没有，您应该查看聚合旧数据或实现数据聚合的RRD类型数据库（例如，volkszaehler.org项目有一个vzcompress工具，用于处理时间序列数据）。
您是否经常需要检索汇总的时间序列数据（例如每天的总和）？如果是，则单独的聚合表可能有助于例如volkszaehler.org项目正在实施。
具有最高选择性的索引可能是时间戳，而不是站点或标记。重建索引的顺序可能会有所回报，但是我不确定并会建议性能（=负载）测试。

Answer 2

我没有解决任何SQL问题，但我正在回答“改进的空间”问题。

我建议您根据自己的要求手动压缩数据。虽然提到的RRD适用于固定大小的数据文件，但如果您希望将数据保留一段不确定的时间，或者使用SQL服务器的功能来存档数据，那就不好了。

我们所做的是使用max-delta算法，每个趋势（温度，电压等）都有自己的dv（值的变化）和存储在每个趋势的一些元数据中的dt（时间变化），例如如果measured dv < required dv，则我们没有存储新样本，而measured dt < required dt也是如此。

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

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

你如何表示两个没有改变x秒的点之间的曲线：作为点之间的直线？这意味着该值是线性的。最后我们使用了一个步骤线，因此在收到新值之前，该值保持不变。
您如何检测离线时段或通讯问题？由于每次轮询都不再有一个样本的隐含心跳，我们不得不引入另一个元数据趋势，表明数据有效，即使该值在一段时间内没有变化，或类似的数据无效某些部分。

最终结果是，即使投票率很高，我们也可以记录一些存储量较小的趋势。

最佳时间序列表示

2 个答案: