【问题标题】:Time series data storage时间序列数据存储
【发布时间】:2015-12-16 05:53:56
【问题描述】:

我正在收集来自同一网络上的服务的大量 UDP 数据包(取决于时间)。这些数据包被反序列化为内存中包含数字(float 和 int)的结构并进行处理。我们可以说我们正在收集时间序列数据。但是,这不是您从监督服务中获得的那种时间序列数据(在一段时间内大多是相同的值)。这些值不断变化,真的,变化不大。但是,它们各不相同。

除此之外,我想将该数据发送到云中的服务器,并在该服务器上存储时间序列数据。

我的问题是:为了通过线路向服务器发送较小的数据包(我们可以通过 TCP 批量发送传入的 UDP 数据包)并存储它们,有什么可能压缩数据?我对不使用附加到服务器的整个存储特别感兴趣。一个会话的数据接近 32MB,我会同时有多个会话。一个会话的数据与另一个会话无关。他们是完全独立的。

【问题讨论】:

  • 您问:“[W] 有哪些压缩数据的可能性[?]”,答案很明显:lzh、zip、gzip,随便压缩,随便选。可能你的问题是不同的?
  • 所以你基本上是在重新实现 statsd 和石墨? :)
  • 看看 influxdb。它可能非常适合您的用例。
  • 我不确定您到底在问什么。存储所有数据的服务器是否也是您开发的?您的主要目标是压缩数据以进行传输还是存储在服务器上的数据?如果这两个目标都有效,那么您可能应该使用不同的传输模式和不同的存储模式。但这取决于价值观的种类。价值观变化很快吗?
  • @FlorinDiaconeasa session 能持续多久? 32MB 的原始数据如何转换为时间序列,以时间 + 每秒/分钟的浮点样本数计算。

标签: java sockets go network-programming time-series


【解决方案1】:

您可以使用此库压缩时间序列数据:https://github.com/dgryski/go-tsz

它基于 Facebook 的这篇论文: http://www.vldb.org/pvldb/vol8/p1816-teller.pdf

我们发现大约 96% 的时间戳 可以压缩到一个位。

[...]

大约 51% 的值被压缩为一个位,因为 当前和以前的值是相同的。约 30% 这些值使用控制位“10”进行压缩(情况 b), 平均压缩大小为 26.6 位。剩余的 19% 使用控制位“11”压缩,平均 大小为 36.9 位,因为需要额外的 13 位开销 对前导零位和有意义位的长度进行编码。

您可以使用像bolt这样的键值存储(或者可能更好:支持压缩的rocksdb)并为每个键存储多个点。例如,您可以每 10 分钟存储一个键值对,其中的值将是该 10 分钟窗口内发生的所有点。

这应该为您提供良好的性能和高压缩率。

【讨论】:

  • 不幸的是,我没有那个分布 :) 我用以下内容更新了这个问题:“我们可以说我们正在收集时间序列数据。但是,它不是那种时间序列数据您可以从监督服务中获得(在一段时间内几乎是相同的值)。这些值不断变化,确实,变化不大。但它们仍然不同。”
猜你喜欢
  • 2014-08-03
  • 2012-09-02
  • 2010-12-13
  • 2023-04-01
  • 2016-10-31
  • 1970-01-01
  • 2022-11-15
  • 2013-06-27
相关资源
最近更新 更多