时间序列数据库概览——基于文件(RRD)、K/V数据库(influxDB)、关系型数据库
2017-02-23 11:12
537 查看
一般人们谈论时间序列数据库的时候指代的就是这一类存储。按照底层技术不同可以划分为三类。
直接基于文件的简单存储:RRD Tool,Graphite Whisper。这类工具附属于监控告警工具,底层没有一个正规的数据库引擎。只是简单的有一个二进制的文件结构。
基于K/V数据库构建:opentsdb(基于hbase),blueflood,kairosDB(基于cassandra),influxdb,prometheus(基于leveldb)
基于关系型数据库构建:mysql,postgresql 都可以用来保存时间序列数据
另外一类数据库其表结构是:
[timestamp] [d1] [d2] .. [dn] [v1] [v2] .. [vn]
其优化的查询方式不限于查询原始数据,而是可以组合查询条件并且做聚合计算,比如:
我们希望时间序列数据库不仅仅可以提供原始数据的查询,而且要支持对原始数据的聚合能力。这种聚合可以是在入库阶段完成的,所谓物化视图。也可以是在查询阶段完成,所谓实时聚合。根据实际情况,可以在这两种方式中进行取舍。
想要在在查询阶段做数据的聚合和转换,需要能够支持以下三点。
用索引检索出行号:能够从上亿条数据中快速过滤出几百万的数据。
从主存储按行号加载:能够快速加载这过滤出的几百万条数据到内存里。
分布式计算:能够把这些数据按照GROUP BY 和 SELECT 的要求计算出最终的结果集。
要想尽可能快的完成整个查询过程,需要在三个环节上都有绝招。传统上说,这三个步骤是三个不同的技术领域。
检索:这是搜索引擎最擅长的领域。代表产品是Lucene。其核心技术是基于高效率数据结构和算法的倒排索引。
加载:这是分析型数据库最擅长的领域。代表产品是C-store和Monetdb。其核心技术是按列组织的磁盘存储结构。
分布式计算:这是大数据计算引擎最擅长的领域。代表产品是Hadoop和spark。其核心技术是sharding 和 map/reduce等等。
前面提到的时间序列库(比如opentsdb)有不少从功能上来说是没有问题。它们都支持过滤,也支持过滤之后的聚合计算。在数据量小的时候勉强是可用的。但是如果要实时从十亿条里取百万记录出来,再做聚合运算,对于这样的数据量可能就勉为其难了。满足海量数据实时聚合要求的数据库不多,比较常见的有这么几种:
基于Lucene构建的“搜索引擎”:Elasticsearch, Crate.io(虽然是基于Elasticsearch,但是聚合逻辑是自己实现的),Solr;
列式存储数据库:Vertica(C-store的后裔)Actian(Monetdb的后裔)等;
Druid.io。
摘自:http://www.infoq.com/cn/articles/database-timestamp-01
直接基于文件的简单存储: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
我们希望时间序列数据库不仅仅可以提供原始数据的查询,而且要支持对原始数据的聚合能力。这种聚合可以是在入库阶段完成的,所谓物化视图。也可以是在查询阶段完成,所谓实时聚合。根据实际情况,可以在这两种方式中进行取舍。
想要在在查询阶段做数据的聚合和转换,需要能够支持以下三点。
用索引检索出行号:能够从上亿条数据中快速过滤出几百万的数据。
从主存储按行号加载:能够快速加载这过滤出的几百万条数据到内存里。
分布式计算:能够把这些数据按照GROUP BY 和 SELECT 的要求计算出最终的结果集。
要想尽可能快的完成整个查询过程,需要在三个环节上都有绝招。传统上说,这三个步骤是三个不同的技术领域。
检索:这是搜索引擎最擅长的领域。代表产品是Lucene。其核心技术是基于高效率数据结构和算法的倒排索引。
加载:这是分析型数据库最擅长的领域。代表产品是C-store和Monetdb。其核心技术是按列组织的磁盘存储结构。
分布式计算:这是大数据计算引擎最擅长的领域。代表产品是Hadoop和spark。其核心技术是sharding 和 map/reduce等等。
前面提到的时间序列库(比如opentsdb)有不少从功能上来说是没有问题。它们都支持过滤,也支持过滤之后的聚合计算。在数据量小的时候勉强是可用的。但是如果要实时从十亿条里取百万记录出来,再做聚合运算,对于这样的数据量可能就勉为其难了。满足海量数据实时聚合要求的数据库不多,比较常见的有这么几种:
基于Lucene构建的“搜索引擎”:Elasticsearch, Crate.io(虽然是基于Elasticsearch,但是聚合逻辑是自己实现的),Solr;
列式存储数据库:Vertica(C-store的后裔)Actian(Monetdb的后裔)等;
Druid.io。
摘自:http://www.infoq.com/cn/articles/database-timestamp-01
相关文章推荐
- 关于时间序列数据库的思考——(1)运用hash文件(例如:RRD,Whisper) (2)运用LSM树来备份(例如:LevelDB,RocksDB,Cassandra) (3)运用B-树排序和k/v存储(例如:BoltDB,LMDB)
- 时间序列数据库概览
- 试用时间序列数据库InfluxDB
- 重新定义数据库历史的时刻——时间序列数据库Schwartz认为InfluxDB最有前途,Elasticsearch也不错
- InfluxDB 分布式时间序列数据库环境搭建——据qcon大会2016qiniu说集群很坑且闭源了
- 时间序列数据库KDB 与Java结合使用介绍 -- 3 基于KDB JDBC的写入实现
- OpenTSDB介绍——基于Hbase的分布式的,可伸缩的时间序列数据库,而Hbase本质是列存储
- influxdb时间序列数据库版本升级
- 基于时间轴的视频文件检索
- “关系型数据库”和“基于海量数据的分布式非关系数据库”
- linux 中使用ls命令对文件进行排序-- 基于文件大小或者修改时间
- 基于B族树的关系型数据库IO瓶颈分析
- R工具:连接数据库,查数据,画时间序列图,加点、文本
- 基于PHP读取TXT文件向数据库导入海量数据的方法
- 介绍一款基于分布式文件存储的数据库--MongoDB
- oracle基于时间恢复整个数据库
- 基于关系型数据库的WEB OA公文流转系统
- MongoDB 一个基于分布式文件存储的数据库
- 基于C#的Access MsSQL MySQL 三种数据库访问演示(含源文件Demo)
- 【原创】分布式大数据时间序列数据库设计概述