时间序列数据库概览——基于文件（RRD）、K/V数据库（influxDB）、关系型数据库

一般人们谈论时间序列数据库的时候指代的就是这一类存储。按照底层技术不同可以划分为三类。

直接基于文件的简单存储：RRD Tool，Graphite Whisper。这类工具附属于监控告警工具，底层没有一个正规的数据库引擎。只是简单的有一个二进制的文件结构。
基于K/V数据库构建：opentsdb（基于hbase），blueflood，kairosDB（基于cassandra），influxdb，prometheus（基于leveldb）
基于关系型数据库构建：mysql，postgresql都可以用来保存时间序列数据

另外一类数据库其表结构是：

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

其优化的查询方式不限于查询原始数据，而是可以组合查询条件并且做聚合计算，比如：

SELECT d2, sum(v1) / sum(v2) FROM metric WHERE d1 =

 “A” AND timestamp >= B AND timestamp < C GROUP BY d2

我们希望时间序列数据库不仅仅可以提供原始数据的查询，而且要支持对原始数据的聚合能力。这种聚合可以是在入库阶段完成的，所谓物化视图。也可以是在查询阶段完成，所谓实时聚合。根据实际情况，可以在这两种方式中进行取舍。

想要在在查询阶段做数据的聚合和转换，需要能够支持以下三点。

要想尽可能快的完成整个查询过程，需要在三个环节上都有绝招。传统上说，这三个步骤是三个不同的技术领域。

前面提到的时间序列库（比如opentsdb）有不少从功能上来说是没有问题。它们都支持过滤，也支持过滤之后的聚合计算。在数据量小的时候勉强是可用的。但是如果要实时从十亿条里取百万记录出来，再做聚合运算，对于这样的数据量可能就勉为其难了。满足海量数据实时聚合要求的数据库不多，比较常见的有这么几种：

基于Lucene构建的“搜索引擎”：Elasticsearch, Crate.io（虽然是基于Elasticsearch，但是聚合逻辑是自己实现的），Solr；
列式存储数据库：Vertica（C-store的后裔）Actian（Monetdb的后裔）等；
Druid.io。

摘自：http://www.infoq.com/cn/articles/database-timestamp-01

巴特西