0

我想知道您对在 MySQL 5.6 中组织时间序列数据的方式的看法：我正在从事一个需要存储来自不同传感器的数据的项目。需要明确的是，我们正在监控几个工业设施。每一个都由一个 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)

PKintbl_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有序，据我所知，这有利于获得快速的插入率。

4

2 回答 2

0

我没有解决任何 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）等。

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

  1. 您如何将 x 秒内没有变化的两点之间的曲线表示为两点之间的直线？这意味着该值是线性的。最后我们使用了一个 step-line，所以在接收到新值之前，值保持不变。
  2. 您如何检测离线时间或通讯问题？由于您不再有每个民意调查的一个样本的隐式心跳，我们不得不引入另一种元数据趋势，该趋势表明数据是有效的，即使值在一段时间内没有变化，或者类似地表明数据在某些部分。

最终结果是，即使轮询率很高，我们也可以用小存储容量记录多年的一些趋势。

于 2014-01-09T02:13:57.163 回答
0

我建议看三件事：

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