时序数据库

【引言】

时序数据库，又名时间序列数据库。时序数据库会成为新趋势。

时序数据库（Time Series Database）是用于存储和管理时间序列数据的专业化数据库，为时间序列数据提供高性能读写和强计算能力的分布式云端数据库服务。时序数据库特别适用于物联网设备监控和互联网业务监控场景。

【简介】

时序数据库全称为时间序列数据库。存储时间序列数据的高性能数据库。时间序列数据库主要用于指处理带时间标签（按照时间的顺序变化，即时间序列化）的数据，带时间标签的数据也称为时间序列数据。

时间序列数据主要由电力行业、化工行业、运维技术、大数据采集等各类型实时监测、检查与分析设备所采集、产生的数据，这些工业数据的典型特点是：产生频率快（每一个监测点一秒钟内可产生多条数据）、严重依赖于采集时间（每一条数据均要求对应唯一的时间）、测点多信息量大（常规的实时监测系统均有成千上万的监测点，监测点每秒钟都产生数据，每天产生几十GB的数据量）。

特点

基于时间序列数据的特点，关系型数据库无法满足对时间序列数据的有效存储与处理，因此迫切需要一种专门针对时间序列数据来做优化的数据库系统，即时间序列数据库。

目前对于时序大数据的存储和处理往往采用关系型数据库的方式进行处理，但由于关系型数据库天生的劣势导致其无法进行高效的存储和数据的查询。时序大数据解决方案通过使用特殊的存储方式，使得时序大数据可以高效存储和快速处理海量时序大数据，是解决海量数据处理的一项重要技术。该技术采用特殊数据存储方式，极大提高了时间相关数据的处理能力，相对于关系型数据库它的存储空间减半，查询速度极大的提高。时间序列函数优越的查询性能远超过关系型数据库，Informix TimeSeries非常适合在物联网分析应用。

·有效处理庞大数据

扫描二维码关注公众号，回复： 11324168 查看本文章

·对重复的部分，Informix TimeSeries只保持一份数据

·节省空间50%，有效降低I/O

·主键索引更有效

·时间序列表头分离的特性不浪费空间;

================================
支持SQL的流处理框架
================================
多数流处理方案中, 数据一般都会暂存在 kafka中, 格式推荐使用 Json/Avro, schema 推荐使用 Oracle Goldgate(OGG)数据格式.

支持SQL的流处理框架有:
1. Spark Streaming: 可以写很复杂的SQL, 比如和其他数据库DB做 join.
2. Kafka 的 KSQL: 和Kafka公用集群, 不需要额外计算集群.
3. PipelineDB : 基于 PostgreSQL 的扩展, cluster版需要付费. 流数据既可以直接写到 pipelinedb(以pipelinedb的FOREIGN TABLE形式暂存流数据), 然后通过 pipelinedb SQL来处理; 流数据也可以先打到kafka中, 然后再通过 pipelinedb extension来处理.

================================
可用作时序的数据库:
================================
[时序]TimescaleDB, 基于 PostgreSQL, 支持 SQL.
[时序]KairosDB, 基于 Cassandra, 不支持 SQL.
[通用]CrateDB, 基于 Elastic Search, 但支持ANSI SQL
[时序]InfluxDB, 是 db-engines 上排名第一的时序数据库, 最新版中集群功能不开源了, 商业版支持, 另外并发查询性能较差.
[通用]Kudu, 列式存储(类parquet), 支持 java API 更新数据, 比较赞的是支持 upsert. 可以通过 impala 或 spark 来支持SQL 查询.

在寻找可评估的TSDB。找了一圈，发现了：

#. Hummer TimeSeries DB（蜂鸟）
#. HBase/Cassandra
#. Druid
#. Geras
#. InfluxDB
#. KairosDB
#. KDB+
#. OpenTSDB
#. SiteWhere
#. TempoDB
#. TreasureData
#. Riak TSDB
#. Druid
#. Baidu TSDB PaaS

希望用过的人提供一下经验。虽然TSDB面对的往往都是大体量的数据，支持分布式集群，但是评估阶段，最好能够支持单机的测试。呵呵，可能有些强人所难。

简单点评(基于底层技术做的点评, 未做个实际测试)
TimescaleDB 基于PostgreSQL, 可能适合数据量不太大的情形, 但提供丰富的SQL功能
KairosDB, 基于 Cassandra, 运维应该比较简单, 扩展性也应该不错, 写入性能估计要比 CrateDB 差一些, 另外不支持SQL.
CrateDB 基于 Elastic Search, 写入性能应该很好, 扩展性也应该不错, 估计 SQL 支持度和读取性能会差一些, 支持全文检索.

db-engines 网站的对比:
https://db-engines.com/en/system/CrateDB%3BKairosDB%3BTimescaleDB

Crate 官方的比较:
http://go.cratedb.com/rs/832-QEZ-801/images/CrateDB-Cassandra-MongoDB-Comparison.pdf

为什么要为时间序列来建立专门的数据库?明明我们就有很多方法来处理时序数据，例如在SQL数据库中通过时间列的排序来解决或者是选择Cassandra这样的分布式数据库。但是，这些方法虽然能够解决时序数据的问题，但是却需要进行大量的工作，十分耗时。那么怎么才能更好的解决时序数据呢?

首先，我们先来看一下时序数据的种类：常规和不规则。

开发人员比较常见和熟悉的是常规时间序列，它只在规定的时间间隔内进行测量，如每10秒钟一次，通常会发生在传感器中，定期读取数据。常规时间序列代表了一些基本的原始事件流或分发。

不规则时间序列则对应离散事件，主要是针对API，例如股票交易。如果要以1分钟间隔计算API的平均响应时间，可以聚合各个请求以生成常规时间序列。

现代TSDB需要能够处理常规和不规则的事件和度量，它们要有通用的元数据来描述用户可能要查询的东西。例如主机名，应用程序，区域，传感器ID，建筑物，股票名称，投资组合名称或者是其它任何维度的数据。时间序列添加元数据要允许客户切片，并创建摘要。

时间序列应用与规模

时序数据库与其他数据库用例和工作负载的区别。

时间序列数据专注于快速摄取。也就是说，时序数据库需要经常插入新数据。使用传感器数据用例时，我们常常会发现滞后的数据收集，这时也要将数据附加进行。

高精度数据保存时间较短，中等或更低精度的摘要数据保留时间较长。这也意味着用户必须不断从数据库中删除数据。这是一个非常不同于正常数据库设计来处理的工作量。

代理或数据库本身必须连续计算来自高精度数据的摘要以进行长期存储。这些计算既包括一些简单的聚合，同时也有一些复杂计算。

时间序列的查询模式可能与其他数据库工作负载有很大的不同。在大多数情况下，查询是在所请求的时间范围内提取一段数据。但对于即时计算聚合和缩减样本的数据库，常常会流失很多数据，所以快速迭代数据来计算聚合对于时间序列用例至关重要。

使用SQL数据库时间序列的问题

许多用户在使用时间序列之前，是将其数据存储在常见的SQL RDBMS(如PostgreSQL或MySQL)中。一般来说，短期内还是可以满足需求的，但随着数据规模的增加，事情就开始失控了。

结论：关系型数据库不是为了解决具体的时间序列问题而设计的，所以试图让他们解决问题是不现实的。

基于分布式数据库

与SQL变体一样，在类似Cassandra的分布式数据库之上构建时间序列解决方案需要相当多的应用级代码。

首先，需要决定如何构建数据。Cassandra中的行被存储在一个复制组，这意味着需要考虑如何构造行键，以确保集群得到正确利用。之后还需要编写应用程序逻辑来对时间序列用例进行其他查询处理。然后，编写采样逻辑来处理创建可用于长期可视化的较低精度样本。最后，在查询不同维度的许多时间序列和计算聚合时，需要确保查询性能。

结论：编写所有这些应用程序代码通常需要有能力的后端工程师进行几个月的时间。

为什么要建立一个时间序列数据平台?

减轻开发者的工作

我们经常会看到开发者不断编写代码来解决相同的问题，如果我们将其引入到平台或者是数据库中，开发者的代码量就会减少，解决问题的时间就会被优化。

时间是特殊的

除了可用性目标之外，我们还可以围绕时间序列的特性进行一些数据库的优化，例如，在插入时聚合和缩小样本，在用户想要释放空间时自动排除高精度数据。甚至还可以构建针对时间序列数据进行优化的压缩。

超越数据库，使开发更容易

专为时序数据构建数据库的一个优点就是它可以超越数据库。我们发现大多数用户遇到了一系列需要解决的问题，如何收集数据，如何存储数据，如何处理和监视数据，以及如何可视化。

使用通用API可以使社区更容易的构建解决方案。用 line protocol来表示时间序列数据，用于写入和查询的HTTP API，以及用于处理的Kapacitor……随着时间的推移，我们可以对常见的用例来预先构建组件。

主流的时间序列数据库

前文对于时间序列数据库解释了那么多，最后我们就来看看主流的时间序列数据库有哪些?根据DB-Engines排行榜，在300多个数据库中，时间序列数据库共有17个，但可惜的是目前市场份额还是有点低。

背景

　　目前对于时序大数据的存储和处理往往采用关系型数据库的方式进行处理，但由于关系型数据库天生的劣势导致其无法进行高效的存储和数据的查询。时序大数据解决方案通过使用特殊的存储方式，使得时序大数据可以高效存储和快速处理海量时序大数据，是解决海量数据处理的一项重要技术。该技术采用特殊数据存储方式，极大提高了时间相关数据的处理能力，相对于关系型数据库它的存储空间减半，查询速度极大的提高。时间序列函数优越的查询性能远超过关系型数据库，Informix TimeSeries非常适合在物联网分析应用。

定义

　　时间序列数据库主要用于指处理带时间标签（按照时间的顺序变化，即时间序列化）的数据，带时间标签的数据也称为时间序列数据。

最新时序数据库排名：

特点& 分类：

专门优化用于处理时间序列数据

该类数据以时间排序
由于该类数据通常量级大（因此Sharding和Scale非常重要）或逻辑复杂（大量聚合，上取，下钻），关系数据库通常难以处理

时间序列数据按特性分为两类

高频率低保留期（数据采集，实时展示）
低频率高保留期（数据展现、分析）

按频度

规则间隔（数据采集）
不规则间隔（事件驱动）

时间序列数据的几个前提

单条数据并不重要
数据几乎不被更新，或者删除（只有删除过期数据时），新增数据是按时间来说最近的数据
同样的数据出现多次，则认为是同一条数据

如图：

时间序列数据库关键比对

InfluxDB	ElasticSearch
流行（TSDB排行第一）	流行（搜索引擎排行第一）
高可用需要收费	集群高可用容易实现，免费
单点写入性能高	单点写入性能低
查询语法简单，功能强	查询语法简单，功能强（弱于Influxdb）
后端时序数据库设计，写入快	设计并不是时序数据库，后端存储采用文档结构，写入慢

由此可见：高频度低保留期用Influxdb，低频度高保留期用ES。

其他时序数据库介绍：

如何使用

数据的查询与写入：

Influxdb与ES都是REST API风格接口
通过HTTP Post写入数据，通过HTTP Get获取数据，ES还有HTTP Put和Delete等
写入数据可以是JSON格式，Influxdb支持Line Protocol
JSON格式徒增解析成本，录入数据格式越简单越好
通常ES搭配Logstash使用，Influxdb搭配telegraf使用

以Influxdb为例，看一些如何插入和查询数据：

Influxdb的HTTP API

创建DB

[root@host31 ~]# curl -i -XPOST http://192.168.32.31:8086/query --data-urlencode "q=CREATE DATABASE mydb"
HTTP/1.1 200 OK
Connection: close
Content-Type: application/json
Request-Id: 42a1f30c-5900-11e6-8003-000000000000
X-Influxdb-Version: 0.13.0
Date: Tue, 02 Aug 2016 22:27:13 GMT
Content-Length: 16

{"results":[{}]}[root@host31 ~]#

写入数据

[root@host31 ~]# curl -i -XPOST http://192.168.32.31:8086/query --data-urlencode "q=CREATE DATABASE mydb"
HTTP/1.1 200 OK
Connection: close
Content-Type: application/json
Request-Id: 42a1f30c-5900-11e6-8003-000000000000
X-Influxdb-Version: 0.13.0
Date: Tue, 02 Aug 2016 22:27:13 GMT
Content-Length: 16

{"results":[{}]}[root@host31 ~]#

查询写入的数据

[root@host31 ~]# curl -GET 'http://192.168.32.31:8086/query?pretty=true' --data-urlencode "db=mydb" --data-urlencode "q=SELECT \"value\" FROM \"cpu_load_short\" WHERE \"region\"='us-west'"
{
    "results": [
        {
            "series": [
                {
                    "name": "cpu_load_short",
                    "columns": [
                        "time",
                        "value"
                    ],
                    "values": [
                        [
                            "2015-06-11T20:46:02Z",
                            0.64
                        ]
                    ]
                }
            ]
        }
    ]
}[root@host31 ~]#

介绍Telegraf&Logstash:

都是数据收集和中转的工具，架构都是插件式配置
Telegraf相比Logstash更加轻量
都支持大量源，包括关系数据库、NOSQL、直接收集操作系统信息（Linux、Win）、APP、服务（Docker）
执行模式分为两种
主动：根据配置一次性读取被收集的数据，收集完成后关闭进程
被动：作为进程驻留内存，监听特定端口，等待消息发送

介绍两种时序数据库使用的架构:

1.日志采集，然后存入influxdb，最后在grafana 中进行可视化查询。

2.数据库监控，主要通过采集关系型数据库的性能指标分析数据库的运行状态便于监控和管理，如下图所示

数据可视化展示

　　数据的可视化展示有很多种选择，比如ELK中推荐使用kibana，配合es更方便，而搭配influxdb可以使用grafana。

目前grafana支持数据源

– ES

– Influxdb

– Prometheus

– Graphite

– OpenTSDB

– CloudWatch

安装Grafana

Grafana的安装很简单，以Debian安装为例：

执行命令：

$ wget https://grafanarel.s3.amazonaws.com/builds/grafana_2.6.0_amd64.deb

$ sudo apt-get install -y adduser libfontconfig

$ sudo dpkg -i grafana_2.6.0_amd64.deb

启动服务器：

$ sudo service grafana-server start

然后即可进行配置使用数据可视化了。这里就不展开讲了。下面会有独立文章介绍grafana和kibana。

总结　　

　　本篇简要概述了时序数据库的内容，介绍了特点并以influxdb为实例对比了与传统数据库的区别，以及如何使用Influxdb。最后讲解了使用时序数据库的架构，日志和监控等，通过grafana进行可视化的数据查询分析监控等。

【参考文章】

时序数据库的选择？ - 知乎 https://www.zhihu.com/question/50194483

背景

定义