【问题标题】:How to store historic time series data如何存储历史时间序列数据
【发布时间】:2015-10-13 17:44:57
【问题描述】:

我们正在存储来自多个测量设备的大量时间序列数据。 所有设备都可能提供不同的维度(能量、温度等)

目前我们使用 MySQL 将所有这些数据存储在不同的表中(根据维度),格式为 idDevice, DateTime, val1, val2, val3

每次我们插入新数据时,我们还会从 min -> Hour -> Day -> Month -> Year 聚合这些数据

这运行得很好,但是随着我们的增长,我们的磁盘空间已经用完了,总的来说,我怀疑 RDBMS 是否是保存存档数据的正确答案。

所以我们正在考虑在 Amazon S3 上移动旧/冷数据并编写一些可以接收这些数据的奇特 getter。

所以我的问题来了:什么是支持以下需求的好数据格式:

数据必须是可扩展的:有时设备会提供更多数据,然后在过去 -> 行数可以增长/增加

必须更新数据。当客户提供历史数据时,我们需要能够更新过去的数据。

我们正在使用 PHP -> 有连接器/类会很好:)

我看过 HDF5,但似乎没有 PHP 库。 我们也愿意看看基于云的时间序列数据库。

提前感谢您! 乙

【问题讨论】:

  • 你有多少数据?如今,磁盘空间并不是特别昂贵。
  • 目前我们即将达到 1TB,但我们的预测似乎在明年达到 4TB。我们的目标也是在 S3 等云服务上扩展数据

标签: mysql amazon-s3 time-series hdf5 influxdb


【解决方案1】:

您可能会考虑迁移到专用的时间序列数据库。我为 InfluxDB 工作,我们的产品现在可以满足您的大部分要求,尽管它仍然是 1.0 之前的版本。

每次我们插入新数据时,我们还会从 min -> Hour -> Day -> Month -> Year 聚合这些数据

InfluxDB 具有自动下采样和过期数据的内置工具。您只需编写原始数据并设置一些查询和保留策略,其余的由 InfluxDB 内部处理。

数据必须是可扩展的:有时设备会提供更多数据,然后在过去 -> 行数可以增长/增加

只要历史写入相当少,它们对 InfluxDB 来说就没有问题。如果您经常写入非顺序数据,则写入性能可能会降低,但仅在复制非顺序点时才会如此。

InfluxDB 不是完全无模式,但模式不能预先定义,并且是从插入的点派生的。只需编写包含它们的新点即可添加新标签(元数据)或字段(指标),并且可以在查询时通过排除或包含相关标签来自动组合或分解系列。

必须更新数据。当客户提供历史数据时,我们需要能够更新过去的数据。

当新的匹配点进来时,InfluxDB 会默默地覆盖点。(匹配意味着相同的系列和时间戳,到纳秒)

我们正在使用 PHP -> 有连接器/类会很好:)

有一些用于 InfluxDB 0.9 的 PHP 库。没有一个是官方支持的,但可能有一个足以满足您的需求来扩展或分叉。

【讨论】:

  • 我们已经看过 InfluxDB,但它缺少几个主要特性: * 健壮且经过生产验证的集群(当前集群被称为 alpha) * 分片。目前所有数据都在 1 个巨大的数据库中。有时这会超过 IOPS 和存储容量
  • 所有推迟的非常正当的理由。集群预计将在今年第四季度初投入生产。
【解决方案2】:

你没有指定你想要什么。

您关心延迟吗?如果不关心,只需将所有数据点写入 S3 中的每个间隔文件,然后定期收集并处理它们。 (不需要 Hadoop,只需一个简单的脚本下载新文件通常就足够快了。)这就是 S3 中的日志记录工作方式。

这方面真正好的部分是您永远不会超过 S3 或进行任何维护。如果您正确地为文件添加前缀,则可以轻松获取一天的数据或最后一小时的数据。然后您对这些数据进行日/周/月汇总,然后仅将汇总存储在常规数据库中。

您需要高分辨率的旧数据吗?您可以使用 Graphite 自动汇总数据。缺点是随着年龄的增长,它会失去分辨率。但好处是您的数据是固定大小的,永远不会增长,并且可以快速处理写入。您甚至可以结合上述方法并将数据发送到 Graphite 以便快速查看,但将数据保留在 S3 中以供以后使用。

我还没有广泛研究各种 TSDB,但这里有一个很好的HN thread 关于它。 InfluxDB 很好,但很新。 Cassandra 更加成熟,但将其用作 TSB 的工具还不具备。

您有多少新数据?大多数工具每秒可以轻松处理 10,000 个数据点,但并非所有工具都可以扩展。

【讨论】:

  • tnx 为您解答。对于历史数据,我们并不真正关心延迟。基本上我们也在考虑将我们的数据存储在普通的 S3 文件中。我的一个问题是:在文件中存储时间序列数据的良好可扩展数据格式是什么?我们收到的数据来自不同的供应商,它们都有不同的数据格式(CSV、XML、json)->我们已经在预处理这个->但是如何存储呢?目前我们以数据库的 CSV 格式对其进行处理,但是每当我们进行架构更新时,所有旧的 CSV 文件都不再有效。
  • 对此没有简单的答案。一个有用的想法是标记每个文件的架构版本。然后你的进口商可以说“哦,对于 v1 模式,我们需要在这里创建一个虚拟字段”。但是没有魔法可以为你解决它。
【解决方案3】:

我在开发Axibase Time-Series Database 的团队。它是一个非关系型数据库,可让您有效地存储各种维度的带时间戳的测量值。您还可以将设备属性(id、位置、类型等)存储在同一数据库中以进行过滤和分组聚合。

默认情况下,ATSD 不会删除原始数据。每个样本每个元组占用 3.5+ 个字节:time:value。周期聚合在请求时执行,函数列表包括:MIN、MAX、AVG、SUM、COUNT、PERCENTILE(n)、STANDARD_DEVIATION、FIRST、LAST、DELTA、RATE、WAVG、WTAVG 以及一些附加函数计算每个周期的阈值违规。

完全支持回填历史数据,但时间戳必须大于 1970 年 1 月 1 日。时间精度为毫秒或秒。

至于部署选项,您可以在 AWS 上托管此数据库。它在大多数 Linux 发行版上运行。如果您想在此处发布数据集中的示例数据,我们可以为您运行一些存储效率和吞吐量测试。

【讨论】:

  • 集群/分片怎么样?
  • ATSD 使用 HBase 进行原始存储,因此吞吐量和存储容量都可以通过添加节点(也称为区域服务器)来扩展。在完全分布式安装中,为了容错,数据被复制 3 次,但您也可以配置主从复制:axibase.com/products/axibase-time-series-database/download-atsd/…
猜你喜欢
  • 2011-04-21
  • 1970-01-01
  • 2012-02-12
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-01-21
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多