最后再感叹一下，我们为什么到今天还要去寻找好用的时间序列数据库。因为传统的实现约束太多，而且效率也不佳。
最完整的时间序列的逻辑数据模型如下：
[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]
我们希望有一个什么样的时间序列数据库：
- 不要限制数据模型。支持多个维度，支持多个值。维度要可以支持中文。允许一个周期内存多个值。
- 能够按时间范围快速读取原数据 （索引首先为时间维度优化）
- 对于选择性高，或者常用的维度，希望能够彼此隔离。也就是指定了维度去查的时候可以不用扫描所有的数据。（索引可选的为重要维度优化）
- 服务器端高效地完成维度聚合
- 聚合不用每次都做，支持预先计算
- 尽可能的利用时间维度和其他维度的重复性减少存储空间，存储自身是压缩的，占用越小越好
- 分布式，能够用加机器解决性能和可靠性问题
很多现成的时间序列数据库在这两个方面做得非常糟糕：
- 限制数据模型，必须把所有信息都编码到一个metric名上
- 读取原数据都相对比较快，但是一旦数据需要聚合就变得很慢，甚至无法在服务器端完成维度聚合
这些数据库逼迫其用户把所有的视图都物化成表。如果你看的视图和存的格式不一样，那么就不行，或者很慢。
参见：
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。