时序数据库

时序数据库简介

        从时序数据库的名称可以看出时序数据库存储的是时序数据。

        时序数据指的是按照时间顺序存储的一连串随时间推移测量相同事物的数据点。如监控数据、程序时间流等。

时序数据具有以下特点：

• 抵达的数据几乎总是作为新条目被记录

• 数据通常按照时间顺序抵达

• 时间是一个主坐标轴（既可以是规则的时间间隔，也可以是不规则的）

为什么需要时序数据库

        为什么已经有传统关系型数据库的基础上，我们还要使用时序数据库？一般都是因为传统关系型数据库的性能无法满足我们的需求。并且时序数据库中存储的时序数据具有按照时间顺序排序的默认特性，针对该特性可以针对性进行存储和查询方面的优化。

        时序数据一般都是一秒内会产生上千万的数据，并且对这上千万的数据进行聚合计算等，时序数据库需要解决的问题：

• 时序数据的写入：如何支持每秒钟上千万上亿数据点的写入。

• 时序数据的读取：又如何支持在秒级对上亿数据的分组聚合运算。

• 成本敏感：由海量数据存储带来的是成本问题。如何更低成本的存储这些数据，将成为时序数据库需要解决的重中之重。

简单说下时序数据库跟传统数据库的存储方式的不同：

        传统数据库采用的都是B树，这是由于其在查询和顺序插入时有利于减少寻道次数的组织形式。我们知道磁盘寻道时间是非常慢的，一般在10ms左右。磁盘的随机读写慢就慢在寻道上面。对于随机写入B tree会消耗大量的时间在磁盘寻道上，导致速度很慢。

        对于90%以上场景都是写入的时序数据库，B tree很明显是不合适的。

        业界主流都是通过LSM树替换的B树，比如HBase、Cassendra等。

        LSM tree包括内存里的数据结构和磁盘上的文件两部分。分别对应Hbase里的MemStore和HLog;对应Cassandra里的MemTable和sstable。

LSM树操作流程简述：

• 数据写入和更新时首先写入位于内存里的数据结构。为了避免数据丢失也会先写到WAL文件中。

• 内存里的数据结构会定时或者达到固定大小会刷到磁盘。这些磁盘上的文件不会被修改。

• 随着磁盘上积累的文件越来越多，会定时的进行合并操作，消除冗余数据，减少文件数量。

        可以看到LSM tree核心思想就是通过内存写和后续磁盘的顺序写入获得更高的写入性能，避免了随机写入。但同时也牺牲了读取性能，因为同一个key的值可能存在于多个HFile中。为了获取更好的读取性能，可以通过bloom filter和compaction得到。

开源时序数据库

Timescale

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

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

基础功能：

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

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

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

• 可靠的数据存储。

扩展功能：

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

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

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

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

劣势：

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

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

Kairosdb

        底层使用Cassandra作为分布式存储引擎，如上面提到单机上采用的是LSM tree。

        Cassandra有两级索引：partition key和clustering key。其中partition key是其分片ID，使用的是一致性哈希;而clustering key在一个partition key中保证有序。

        Kairosdb利用Cassandra的特性，将 ++<数据类型>+作为partition key，数据点时间在timestamp上的偏移作为clustering key，其有序性方便做基于时间范围的查询。

        partition key中的timestamp是3周对齐的，也就是说21天的时序数据会在一个clustering key下。3周的毫秒数是18亿正好小于Cassandra每行列数20亿的限制。

Influxdb

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

特点：

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

• 无额外存储依赖。

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

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

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

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

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

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

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

OpenTSDB

        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 查询

Druid

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

特性：

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

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

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

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

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

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

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

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

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

ElasticSearch

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

        Elasticsearch 以 ELK stack 被人所熟知。许多公司基于 ELK 搭建日志分析系统和实时搜索系统。Elasticsearch 新版本开始发布 Metrics 组件和 APM 组件，并大量的推广其全文检索外，对时间序列的存储能力。

        Elasticsearch 的时序优化可以参考一下这篇文章:《elasticsearch-as-a-time-series-data-store》

        也可以去了解一下 Elasticsearch 的 Metric 组件Elastic Metrics

Beringei

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

        2015 年 Facebook 发表了一篇论文《Gorilla: A Fast, Scalable, In-Memory Time Series Database 》，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

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