时间序列数据库的选择条件

1

最后再感叹一下,我们为什么到今天还要去寻找好用的时间序列数据库。因为传统的实现约束太多,而且效率也不佳。

最完整的时间序列的逻辑数据模型如下:

[timestamp],[d1],[d2]...[dn],[v1],[v2]...[vn]

d1 ~ dn 是维度,比如 ip, idc, country 之类的值
v1 ~ vn 是值列,比如 cpu_usage, free_memeory_bytes 之类的值

一些时间序列数据库在实现的时候为了简化实现,提高性能约束了一个更简化的数据模型:

[timestamp],[metric],[value]

opentsdb稍微要好一些,支持了tag,但是也是不完整的模型

[timestamp],[metric],[tagk=tagv],...[value]

我们希望有一个什么样的时间序列数据库:

  1. 不要限制数据模型。支持多个维度,支持多个值。维度要可以支持中文。允许一个周期内存多个值。
  2. 能够按时间范围快速读取原数据 (索引首先为时间维度优化)
  3. 对于选择性高,或者常用的维度,希望能够彼此隔离。也就是指定了维度去查的时候可以不用扫描所有的数据。(索引可选的为重要维度优化)
  4. 服务器端高效地完成维度聚合
  5. 聚合不用每次都做,支持预先计算
  6. 尽可能的利用时间维度和其他维度的重复性减少存储空间,存储自身是压缩的,占用越小越好
  7. 分布式,能够用加机器解决性能和可靠性问题

很多现成的时间序列数据库在这两个方面做得非常糟糕:

  1. 限制数据模型,必须把所有信息都编码到一个metric名上
  2. 读取原数据都相对比较快,但是一旦数据需要聚合就变得很慢,甚至无法在服务器端完成维度聚合
    这些数据库逼迫其用户把所有的视图都物化成表。如果你看的视图和存的格式不一样,那么就不行,或者很慢。

参见:


如果觉得我的文章对你有用,请随意赞赏

你可能感兴趣的

陌辞寒 · 2015年06月11日
[timestamp],[d1],[d2]...[dn],[v1],[v2]...[vn]

[timestamp],[metric],[tagk=tagv],...[value]

如果把metricvalue也看成一个tagktagv,为什么不是一样的呢?
当然Open TSDB没有对tag索引就是另一回事了。

回复

载入中...