时序数据库性能比较

时序数据库使用排名：（https://db-engines.com/en/ranking/time+series+dbms）

单机版时序数据库

****InfluxDB

---

使用TSM存储引擎（读写性能好，存储压缩率高）

优点：

一是TSM针对时序数据在内存以及文件格式上做了针对性的优化，优雅地实现了时序数据的高效率写入以及高压缩率存储，保证了写入性能和存储空间的较小占用，同时文件级别的B+树索引可以有效提高时序数据根据SeriesKey查询时间序列的性能；

二是InfluxDB系统还实现了内存以及文件级别的倒排索引，有效实现了根据给定维度fieldKey查询对应SeriesKey的功能，这样再根据SeriesKey、fieldKey和时间间隔就可以在文件中查找到对应的时序数据集合
多线程写入效果好

三使用自研数据存储方式，数据存储前会进行压缩存储，轻量型数据库，不依赖其他数据库或组件，安装简单且方便容器化部署

四支持分片和水平扩展，便于后期的过滤查询，同时通过Retention Policies数据保留策略提高支持连续查询，降低数据查询对系统资源的消耗

缺点：集群只支持商业版，数据只能查询和写入，不能够删除，修改，对数据的处理不友好，同时在聚合查询方面随着聚合列的增加，查询性能会反比下降，

实际压测过：内存8g，字段3个，能存储的数据量在5000万条左右，还是可以满足一定的需求。

若对数据量要求较大时建议用一个设备作为一条数据，表的字段将会比较多。

实际压测过：内存8g，表字段在500个左右，能存储数据量在1000万左右。

单机版受部署环境影响容易数据丢失，需要做高可用

InfluxDB高可用方案：

gateway（https://github.com/pingliu/influxdb-gateway）
用于检测和压缩influxdb的数据，用于跨机房传输，采用udp接受数据。

influxdb-relay（https://github.com/influxdata/influxdb-relay）
是官方提供的高可用方案，但是它只提供简单的写入功能。

influxdb-proxy（https://github.com/shell909090/influx-proxy）是用于替代 influxdb-relay 的高可用方案

参考文献：

InfluxDB 详解之 TSM 存储引擎解析（http://blog.fatedier.com/2016/08/05/detailed-in-influxdb-tsm-storage-engine-one/）

饿了么 Influxdb 实践之路：https://mp.weixin.qq.com/s?__biz=MzIwNjEwNTQ4Mw%3D%3D&mid=2651576941&idx=1&sn=69e6eddc2598908d48853676c04ce3c5&chksm=8cd9c489bbae4d9fa8ce0c6d0bb09e09788e6feec4a3e756e06c9c2d445713cb08dff0b90f9b：

InfluxDB的关键特性（Retention Policies - 数据保留策略）：https://xiaolong.li/2017/06/09/TSDB-INFLUXDB-Key-Features/

时序数据库分析：http://hbasefly.com/category/%E6%97%B6%E5%BA%8F%E6%95%B0%E6%8D%AE%E5%BA%93/?nateza=pvopj1

***TimeScaleDB

---

TimeScaleDB的功能更完善。TimeScaleDB作为PostgreSQL的扩展，只是在数据存储上利用PostgreSQL的特性做了一些优化，PostgreSQL支持的功能，TimeScaleDB全部支持。而InfluxDB是分析型时序数据库，舍弃了很多交易型数据库必须支持的功能

增删改：InfluxDB不支持对数据的修改，InfluxDB只支持按tag或时间戳删除。TimeScaleDB都支持。

索引：InfluxDB时间戳和tags带索引，不支持自定义索引。TimeScaleDB更加灵活，可自定义索引

约束：InfluxDB不支持，TimeScaleDB支持
聚合函数：常用的聚合函数两种数据库都支持，TimeScaleDB的函数覆盖面更广一些。

缺点：通过测试在全表和多列查询上TimeScaleDB查询速度是InfluxDB的两倍

单列查询时InfluxDB的性能比TimeScaleDB高一倍，但多列查询时InfluxDB的性能下降非常明显。而TimeScaleDB查询的列数几乎不影响结果。InfluxDB的查询性能和查询的列数成反比。

参看文章：

1.InfluxDB vs TimeScaleDB 功能/性能对比 （一）https://blog.csdn.net/suzy1030/article/details/81478514

2.InfluxDB vs TimeScaleDB 功能/性能对比 （二）https://blog.csdn.net/suzy1030/article/details/81486234

Prometheus

---

(K-V形式) —存储的数值类型不支持字符串
–暂不考虑

Influxdb vs Prometheus（引用）

influxdb 集成已有的概念，比如查询语法类似 sql，引擎从 LSM 优化而来，学习成本相对低。
influxdb 支持的类型有 float，integers，strings，booleans，prometheus 目前只支持 float。
influxdb 的时间精度是纳秒，prometheus 的则是毫秒。
influxdb 仅仅是个数据库，而 prometheus 提供的是整套监控解决方案，当然 influxdb 也提供了整套监控解决方案。
influxdb 支持的 math function 比较少，prometheus 相对来说更多，influxdb 就目前使用上已经满足功能。
2015年 prometheus 还在开发阶段，相对来说 influxdb 更加稳定。

influxdb 支持 event log，prometheus 不支持。

更详细的对比请参考：

https://db-engines.com/en/system/Graphite%3BInfluxDB%3BPrometheus

Graphite

---

时序数据收集、监控工具存储，存储端采用Cassandra

Cassandra：是一套开源分布式NoSQL数据库系统

作用是存储和聚合监控数据并绘制图标

Graphite是一个被动接收的时间序列数据库，但提供了数据展示的功能。数据采集agent、警报等其它的功能，需要引入第三方软件来支持。

总结：偏向于一个时序数据展示的工具，不适合做时序库

集群版时序数据库

---

***Kairosdb+Cassandra

k-v数据库 ,从OpenTSDB分支出来的基于Cassandra的时序库，

基本功能删与OpenTSDB类似

支持单机版部署和集群部署

优点：

但存储值上面支持string类型和自定义数字类型

在存储上面采用UID编码方法，解决了rowkey存储数据冗余的问题

更好的压缩数据

在数据查询方面

可以利用组件创建索引，避免了条件查询是的全表扫描，提高了查询性能

缺点：
仅支持简单的auto-rollup（自动汇总）实现，支持定时启动，但可用性和性能较低

存储结构：
…

查询优化：

相比OpenTSDB直接在数据表上进行扫描来过滤row key的方式，KairosDB利用索引表无疑会大大减少扫描的数据量。在metric下tagKey和tagValue组合有限的情况下，会大大的提高查询效率。并且KairosDB还提供了QueryPlugin的方式，能够扩展利用外部组件来对row key进行索引。

参考文章：

开源时序数据库解析：https://zhuanlan.zhihu.com/p/28747552

Cassandra介绍：https://wenku.baidu.com/view/7612fb8805087632311212ee.html

Kairosdb介绍： http://liubin.org/blog/2016/03/12/tsdb-kairosdb/

KairosDB详解：https://zhuanlan.zhihu.com/p/32710206

为什么选择了Cassandra而没有用Hbase：https://www.cppentry.com/bencandy.php?fid=118&id=204683

**Heroic+Cassandra

---

Spotify在决定研发Heroic之前，在OpenTSDB、InfluxDB、KairosDB等TSDB中选用KairosDB来替换他们老的监控系统的底层。但是很快就遇到了KairosDB在查询方面的问题，最主要还是KairosDB对metric和tag没有索引，在metric和tag基数达到一定数量级后，查询会变的很慢。所以Spotify研发Heroic的最大动机就是解决KairosDB的查询问题，采用的解决方案是使用ElasticSearch来作为索引优化查询引擎，而数据的写入和数据表的Schema则完全与KairosDB一致。

简单总结下它的特点：

完整的数据模型，完全遵循metric2.0的规范。

1. 数据存储模型与KairosDB一致，使用ElasticSearch优化查询引擎。（这是除了InfluxDB外，其他TSDB如KairosDB、OpenTSDB、BlueFlood等现存最大的问题，是其核心竞争力之一）

2. 但不支持auto-rollup。

3. 如果你需要TSDB支持完整的数据模型，且希望得到高效的索引查询，那Heroic会是你的选择。

参考文章：开源时序数据库解析（二）：https://www.jeesns.cn/article/detail/4645

CrateDB+Elastic Search

---

Druid（分布式sql数据库）**

官网：https://druid.apache.org/docs/latest/design/index.html

简介：(https://www.wangt.cc/2018/08/%E3%80%90%E5%B9%B2%E8%B4%A7%E3%80%91%E4%B8%80%E6%96%87%E7%90%86%E8%A7%A3druid%E5%8E%9F%E7%90%86%E6%9E%B6%E6%9E%84%EF%BC%88%E6%97%B6%E5%BA%8F%E6%95%B0%E6%8D%AE%E5%BA%93%EF%BC%8C%E4%B8%8D%E6%98%AFali/)

优点：Druid存储的压缩率高，列式存储方便做聚合查询，支持sql 查询

压缩率：

缺点：查询效率低，有冗余数据，且内存的资源的消耗大。

Bitmap索引构建时机

这里实际上会碰到第一个需要权衡的问题：Bitmap索引是应该在数据写入的同时实时构建呢，还是应该在数据从内存persist到硬盘的时候批量构建。很显然，实时构建会对数据写入吞吐量造成一定影响，实际测试下来发现写入性能会下降5%到15%，而且表维度越多，性能下降越明显。而另一方面，如果是批量构建，那么内存中的数据实际上是没有索引的，这部分数据的检索方式必然与已经持久化到硬盘文件数据的检索方式完全不同：内存中的数据检索不走索引直接查数据，文件中的数据检索需要先走索引再查数据，在实际查询实现中需要分别处理。

Druid中Bitmap的构建时机采用的后者，即在数据从内存persist到硬盘的时候批量构建。本人实现倒排索引时采用的是前者，主要考虑的问题是希望无论数据是在内存还是在硬盘，都能够采用统一的检索方式，即都先根据索引查询行号，再根据行号查具体数据。这样将内存检索和硬盘检索统一处理的好处是在代码实现上更加方便，更加简洁。当然，会牺牲一部分写入性能。

数据库架构：

性能测试

本地测试：38,754 行，用时 1.39s

其他测试(参考文章：https://zhuanlan.zhihu.com/p/56102593)：

本次测试采用了2007年8月美国股票市场level1的TAQ数据集。TAQ数据集按日分为23个csv文件，单个文件大小在7.8G到19.1G不等，整个数据集大小约290G，共有6,561,693,704条数据。

测试数据集TAQ在DolphinDB和Druid中各个字段的数据类型如下所示：

在Druid中，DATE字段指定为timestamp列。其它字段均用作dimension字段。

性能指标

MongoDB

---

文档型的NoSQL数据库

　Cube：使用MongoDB来存储时间序列数据;

DolphinDB

---

DolphinDB属于列式数据库，商业数据库—暂不考虑

参考文献：

DolphinDB与InfluxDB对比测试报告：https://blog.csdn.net/qq_41996852/article/details/86674008

DolphinDB与MongoDB在时序数据上的对比测试：https://blog.csdn.net/qq_41996852/article/details/90021133

LinDB

–处于起步开发阶段，官方文档和教程还没完善–暂不考虑

介绍地址：

分布式时序数据库 - LinDB https://zhuanlan.zhihu.com/p/35998778

Kylin，OpenTSDB

（基于Hbase）–暂不考虑

---

总结：

从上面数据库测支持的功能以及底层的查询和存储存储原理来看，

InfluxDB，单机模式下的首选时序库，首先他的部署非常简单，方便，便于实现轻量化部署，同时他自由的TSM存储引擎可以实现很好的存储和读取性能，但由于他集群模式只在商业版支持，同时在高可用方面，开源版本支持的并不友好，所以需要单独的在实现以下高可用，如果不考虑分布式部署，他的设计及优化是首选。

TimeScaleDB，基于关系型数据库Postgre实现的时序数据库，他继承了Postgre的作为关系型数据的的全部优点，对sql语句的支持是他最大的优点，同时相比于InfluxDB可以提供很好的数据高可用保障，但在实际使用过程中发现，在时序数据复杂查询是，性能会有较大的下降。需要做好数据分区和索引的提前规划设置。

Kairosdb ，是从OpenTSDB发展出来的基于Cassandra的时序数据库，由于InfluxDB开源版不支持集群版部署，他成为分布式部署的很好方案，既有OpenTSDB的很多特性，同时支持索引查询，优化了OpenTSDB全表扫描的问题。他不依赖于Hbase，所以不再受habse及相关hadoop组件的影响。相比于hbase ,Cassandrade 的读写效果要好的多，其日志记录及周期性写入保证了写入性能，同时顺序读取和多级缓存保证了其读取效率。同时他的集群是没有主从概念的，各个几点完全相同，所以不存在单点故障导致的集群故障。

Heroic，在写入结构上和Kairosdb 是完全相同的，但他使用ElasticSearch来作为索引优化查询引擎，极大的完善了Kairosdb 在在metric和tag数量级增加导致的查询性能下降的问题

---

还有KairosDB是基于cassandra的，这个存储也可以，但读取的时候不支持sql，聚合查询的话需要调他的http接口,获取数据。还有一个Druid，但底层存储可以存到hdfs或者本地，如果不考虑他的部署环境的话，这个支持sql查询，可以基于kafka流式写入，查询速度也还可以