监控系统如何选择合适的时序数据库？_时序数据采集系统

1.可以按照以下需求自行选择合适的存储：

• 小而精，性能高，数据量较小(亿级): InfluxDB

• 简单，数据量不大（千万级），有联合查询、关系型数据库基础：timescales

• 数据量较大，大数据服务基础，分布式集群需求： opentsdb、KairosDB

• 分布式集群需求，olap实时在线分析，资源较充足：druid

• 性能极致追求，数据冷热差异大：Beringei

• 兼顾检索加载，分布式聚合计算： elsaticsearch

• 如果你兼具索引和时间序列的需求。那么Druid和Elasticsearch是最好的选择。其性能都不差，同时满足检索和时间序列的特性，并且都是高可用容错架构。

2.时序数据具有以下特点：

• 周期性采集设备的时序数据，对插入性能和稳定性要求高，可能发生乱序或者丢失数据的情况；更新和删除频次低；

• 时序数据量大，对存储压缩比敏感，希望冷热数据分级存储；

• 为了节省存储，通常会对高频时序数据降采样；

• 设备属性信息重复度高，修改频次低；

• 指标数据量大而变化小；

• 查询需求多样，如单设备最新值、单设备明细、单设备过滤聚集、多设备查询、多维查询、降采样、滑动窗口查询、设备状态演变图、特定模式识别、趋势预测、根因分析、阈值修正等。

3.时序数据库种类

3.1Timescale

这个数据库其实就是一个基于传统关系型数据库postgresql改造的时间序列数据库。了解postgresql的同学都知道，postgresql是一个强大的，开源的，可扩展性特别强的一个数据库系统。

于是timescale.inc开发了Timescale，一款兼容sql的时序数据库， 底层存储架构在postgresql上。 作为一个postgresql的扩展提供服务。其特点如下：

基础：

• PostgreSQL原生支持的所有SQL,包含完整SQL接口（包括辅助索引，非时间聚合，子查询，JOIN，窗口函数）

• 用PostgreSQL的客户端或工具，可以直接应用到该数据库，不需要更改。

• 时间为导向的特性，API功能和相应的优化。

• 可靠的数据存储。

扩展：

• 透明时间/空间分区，用于放大（单个节点）和扩展

• 高数据写入速率（包括批量提交，内存中索引，事务支持，数据备份支持)

• 单个节点上的大小合适的块（二维数据分区），以确保即使在大数据量时即可快速读取。

• 块之间和服务器之间的并行操作

劣势：

• 因为TimescaleDB没有使用列存技术，它对时序数据的压缩效果不太好，压缩比最高在4X左右

• 目前暂时不完全支持分布式的扩展（正在开发相关功能），所以会对服务器单机性能要求较高

其实大家都可以去深入了解一下这个数据库。对RDBMS我们都很熟悉，了解这个可以让我们对RDBMS有更深入的了解，了解其实现机制，存储机制。在对时间序列的特殊化处理之中，我们又可以学到时间序列数据的特点，并学习到如何针对时间序列模型去优化RDBMS。

之后我们也可以写一篇文章来深入的了解一下这个数据库的特点和实现。

3.2Influxdb

Influxdb是业界比较流行的一个时间序列数据库，特别是在IOT和监控领域十分常见。其使用go语言开发，突出特点是性能。

特性：

• 高效的时间序列数据写入性能。自定义TSM引擎，快速数据写入和高效数据压缩。

• 无额外存储依赖。

• 简单，高性能的HTTP查询和写入API。

• 以插件方式支持许多不同协议的数据摄入，如：graphite，collectd，和openTSDB

• SQL-like查询语言，简化查询和聚合操作。

• 索引Tags，支持快速有效的查询时间序列。

• 保留策略有效去除过期数据。

• 连续查询自动计算聚合数据，使频繁查询更有效。

Influxdb已经将分布式版本转为闭源。所以在分布式集群这块是一个弱点，需要自己实现。

⼯业监控系统的数据采集量⾮常⼤，使⽤mysql数据库进⾏数据存储和查询时很慢，⽹上有⼈做过mysql和时序数据库influxDB对⽐，存储1000万条数据mysql要7分多钟，influxDB只需2分多钟，从1000万条数据读10000条所需数据mysql要6秒多，influxDB只需0.22秒多

3.3OpenTSDB

The Scalable Time Series Database. 打开OpenTSDB官网，第一眼看到的就是这句话。其将Scalable作为其重要的特点。OpenTSDB运行在Hadoop和HBase上，其充分利用HBase的特性。通过独立的Time Series Demon(TSD)提供服务，所以它可以通过增减服务节点来轻松扩缩容。

• Opentsdb是一个基于Hbase的时间序列数据库（新版也支持Cassandra）。

  其基于Hbase的分布式列存储特性实现了数据高可用，高性能写的特性。受限于Hbase，存储空间较大，压缩不足。依赖整套HBase, ZooKeeper

• 采用无模式的tagset数据结构(sys.cpu.user 1436333416 23 host=web01 user=10001)

  结构简单，多value查询不友好

• HTTP-DSL查询

OpenTSDB在HBase上针对TSDB的表设计和RowKey设计是值得我们深入学习的一个特点。有兴趣的同学可以找一些详细的资料学习学习。

3.4Druid

Druid是一个实时在线分析系统(LOAP)。其架构融合了实时在线数据分析，全文检索系统和时间序列系统的特点，使其可以满足不同使用场景的数据存储需求。

• 采用列式存储：支持高效扫描和聚合，易于压缩数据。

• 可伸缩的分布式系统：Druid自身实现可伸缩，可容错的分布式集群架构。部署简单。

• 强大的并行能力：Druid各集群节点可以并行地提供查询服务。

• 实时和批量数据摄入：Druid可以实时摄入数据，如通过Kafka。也可以批量摄入数据，如通过Hadoop导入数据。

• 自恢复，自平衡，易于运维：Druid自身架构即实现了容错和高可用。不同的服务节点可以根据响应需求添加或减少节点。

• 容错架构，保证数据不丢失：Druid数据可以保留多副本。另外可以采用HDFS作为深度存储，来保证数据不丢失。

• 索引：Druid对String列实现反向编码和Bitmap索引，所以支持高效的filter和groupby。

• 基于时间分区：Druid对原始数据基于时间做分区存储，所以Druid对基于时间的范围查询将更高效。

• 自动预聚合：Druid支持在数据摄入期就对数据进行预聚合处理。

Druid架构蛮复杂的。其按功能将整个系统细分为多种服务，query、data、master不同职责的系统独立部署，对外提供统一的存储和查询服务。其以分布式集群服务的方式提供了一个底层数据存储的服务。

Druid在架构上的设计很值得我们学习。如果你不仅仅对时间序列存储感兴趣，对分布式集群架构也有兴趣，不妨看看Druid的架构。另外Druid在segment(Druid的数据存储结构)的设计也是一大亮点，既实现了列式存储，又实现了反向索引。

3.5Elasticsearch

Elasticsearch 是一个分布式的开源搜索和分析引擎，适用于所有类型的数据，包括文本、数字、地理空间、结构化和非结构化数据。Elasticsearch 在 Apache Lucene 的基础上开发而成，由 Elasticsearch N.V.（即现在的 Elastic）于 2010 年首次发布。Elasticsearch 以其简单的 REST 风格 API、分布式特性、速度和可扩展性而闻名。

Elasticsearch以ELK stack被人所熟知。许多公司基于ELK搭建日志分析系统和实时搜索系统。之前我们在ELK的基础上开始开发metric监控系统。即想到了使用Elasticsearch来存储时间序列数据库。对Elasticserach的mapping做相应的优化，使其更适合存储时间序列数据模型，收获了不错的效果，完全满足了业务的需求。后期发现Elasticsearch新版本竟然也开始发布Metrics组件和APM组件，并大量的推广其全文检索外，对时间序列的存储能力。真是和我们当时的想法不谋而合。

3.6Beringei

Beringei是Facebook在2017年最新开源的一个高性能内存时序数据存储引擎。其具有快速读写和高压缩比等特性。

2015年Facebook发表了一篇论文，Beringei正是基于此想法实现的一个时间序列数据库。

Beringei使用Delta-of-Delta算法存储数据，使用XOR编码压缩数值。使其可以用很少的内存即可存储下大量的数据。

如何选择一个适合自己的时间序列数据库

• Data model

  时间序列数据模型一般有两种，一种无schema，具有多tag的模型，还有一种name、timestamp、value型。前者适合多值模式，对复杂业务模型更适合。后者更适合单维数据模型。

• Query language

  目前大部分TSDB都支持基于HTTP的SQL-like查询。

• Reliability

  可用性主要体现在系统的稳定高可用上，以及数据的高可用存储上。一个优秀的系统，应该有一个优雅而高可用的架构设计。简约而稳定。

• Performance

  性能是我们必须考虑的因素。当我们开始考虑更细分领域的数据存储时，除了数据模型的需求之外，很大的原因都是通用的数据库系统在性能上无法满足我们的需求。大部分时间序列库倾向写多读少场景，用户需要平衡自身的需求。下面会有一份各库的性能对比，大家可以做一个参考。

• Ecosystem

  我一直认为生态是我们选择一个开源组件必须认真考虑的问题。一个生态优秀的系统，使用的人多了，未被发现的坑也将少了。另外在使用中遇到问题，求助于社区，往往可以得到一些比较好的解决方案。另外好的生态，其周边边界系统将十分成熟，这让我们在对接其他系统时会有更多成熟的方案。

• Operational management

  易于运维，易于操作。

• Company and support

  一个系统其背后的支持公司也是比较重要的。背后有一个强大的公司或组织，这在项目可用性保证和后期维护更新上都会有较大的体验。

4.时序数据库与关系数据库

时序数据库是为处理时序数据而设计的数据库，目的是实现时序数据的高效采集、存储、计算和应用。时序数据库的基本设计目标是高效插入、存储和查询（见图3）

图3 时序数据库的基本设计目标

但一个企业级时序数据库产品远远不止这些，比如InfluxDB的下一代产品iox提出了13条设计目标（见图4），从中可以窥见一斑。

正因时序数据库这些特性，它被广泛应用于物联网、车联网、工业互联网和智慧城市等场景，实现各类设备数据的采集、存储、计算和应用。

时序数据库和关系型数据库

当对时序数据库有一定了解后，你可能会疑惑，虽然时序数据是非常好的结构化数据，但是关系型数据库自20世纪80年代开始就支持时间戳数据类型。为什么不使用关系型数据库处理时序数据，而要开发专门的时序数据库？

这要从关系型数据库的存储引擎说起。传统关系型数据库使用行存储引擎存储数据，通过B+树来提升查询的性能。B+树是一种为读而优化的数据结构，数据写入时会引起B+树分页，而分页会造成“随机磁盘IO”，大幅降低数据写入的性能。此外，B+树的压缩比也较低。

正因为关系型数据库的这些特性，使得它不适合做时序数据库。时序数据库中绝大多数操作是写入操作，且数据量大。因此，优化数据写入，并能够达到较好的压缩比，这都是传统关系型数据库所不具备的条件。

时序数据库大多不使用B+树，而是使用LSM（Log Structured Merge）树或其变种。LSM树是为写而优化的数据结构，写性能出色，故而很多时序数据库选择LSM，或者LSM的变种作为其核心存储引擎，比如InfluxDB、OpenTSDB（OpenTSDB基于HBase，而HBase基于LSM树）等。

那么，LSM树就能满足时序数据库所有的特性需求吗？也不尽然。LSM树虽然写性能优异，但是不能很好地支持读操作。为此，时序数据库引入不同的机制来提升查询性能，譬如InfluxDB使用B树索引、倒排索引和Bloomfilter等技术提升查询性能，这样一方面提升了读操作的查询性能，另一方面写数据时需要维护这些不同类型的索引，也增加了写操作的开销。可见时序数据库需要取得读操作和写操作之间的平衡，而不是单纯地追求其中之一。

近年来，有些产品开始质疑关系型数据库不适合处理时序数据的假设，并基于行存和B+树开发出性能出色的关系型时序数据库，具有代表性的产品是TimescaleDB。

TimescaleDB基于时序数据天然具有时间戳属性的特点，把时序数据表按照时间分区，当前分区使用行存和B+树，老分区使用基于行存的类列式存储引擎（把1000行合并成一行，达到类似列存的效果）。那么，TimescaleDB的写性能如何呢？网上一些评测发现，其写性能优于专用时序数据库InfluxDB，这是为什么呢？B+树不是为读而优化，写性能不如LSM树吗？

B+树理论上确实会造成磁盘随机IO，但是数据库工程实现时都会使用“WAL日志+缓冲区”的方式来尽可能避免随机IO。WAL总是顺序读写，B+树的页面发生修改时不会直接写入磁盘，而是先写WAL日志，然后更新内存缓冲区，只有内存缓冲区满之后才会刷新磁盘，这样就很大程度上把随机磁盘IO优化为顺序磁盘IO了。而LSM树为了提升写性能引入了各种各样的索引，在一定程度上增加了写开销。

时序数据多为指标数据，通常是一系列数字串。为了让这些数字串变成有价值的信息，通常需要引入时序数据的上下文信息，这些信息大多是关系数据。所以，时序场景通常需要关系型数据库和时序数据库配合以赋予数据意义，发挥数据的价值。关系型时序数据库在关系型数据库内实现对时序数据的支持，一个数据库代替关系型数据库与时序数据库联合才能解决问题。可以大幅简化技术栈，提升开发运维效率。

5.存储实时采集数据的数据库如何选择和设计？数据采集24小时连续不断，更新或插入数据库操作的频率大概在每秒1000+。

1. 采集数据主要是看应用场景，如果是采集数据按周期整存整取，批量读取分析的话，用分布式文件系统，数据量够大，写入非常快，直接上Hadoop hdfs

2. 但是若数据采集到，不仅要做离线分析，还需要实时的回放查找，那么对于这种情况最好的方法就是使用时序数据库，例如opentsdb，它是基于HBASE，因此底层还是依赖Hadoop hdfs。influxdb也不错，自己实现原生数据库，只不过你要为集群模式付费，其实它们都是通过lsm-tree的nosql，对最近存储的数据，查找性能很强，但是对于历史数据的查找速度就差点。当然你也可以考虑国产清华造的IoTDB，现在也是Apache顶级开源项目了，而且也是需要通过Hadoop hdfs来保证数据可靠性！

3. 再加一条，若应用场景不仅仅是高速写入，还可能涉及到大量的范围查找，那么就要从MongoDB这样的分布式数据库的选择基础之上进行优化，因其采用B-tree索引，范围查询的综合效果肯定是要好于基于lsm-tree的nosql(近期数据查找快)，例如时序数据库基本上都是lsm-tree。但Mongo的写入一定要根据实际数据结构优化，因为你的业务基本上是1毫秒级的写入，这对于Mongo是一个不小的挑战，所以MongoDB的批量顺序写，以及加大内存资源等设置就很重要。

参考：http://ty2y.com/study/sjxlsjktsdbcsyxzinfluxdbopentsdbdruidelasticsearchdb.html#

https://www.modb.pro/db/50050

https://mp.weixin.qq.com/s/E1L9aYdj0JGObtgGPGKMOg