大白话之时序数据库入门篇

今天简单带大家了解一下时序数据库。聊聊什么是时序数据库，有什么特点，用在什么场景，和传统关系型数据库的区别与联系，以及开源解决方案调研。

什么是时序数据库

时间序列数据（Time Series Data，TSD，以下简称时序）从定义上来说，就是一串按时间维度索引的数据。

用描述性的语言来解释什么是时序数据，简单的说，就是这类数据描述了某个被测量的主体在一个时间范围内的每个时间点上的测量值。

它普遍存在于IT基础设施、运维监控系统和物联网中。

应用场景

1

股市、币圈

如果你是一个股民，某只股票的股价就是一类时序数据，其记录着每个时间点该股票的股价。

2

物联网领域

笔者之前有物联网从业经历，我们是国内最大共享单车平台。

其实你随便骑的一辆单车，无论你骑没骑，时时刻刻都在上报自身数据，比如电池 电量数据，Sim卡相关数据，设备地理位置数据。

这些数据其实都需要时时写入时序数据库，我们需要统计设备的SIM卡有效无效数据，设备地理位置坐标及统计分布数据等。

3

APM监控

如果你是一个运维人员，监控数据是一类时序数据，例如对于机器的CPU的监控数据，就是记录着每个时间点机器上CPU的实际消耗值。

数据模型

1

数据模型

对时序数据进行建模的话，会包含三个重要部分，分别是：主体，时间点和测量值。

时序数据从时间维度上将孤立的观测值连成一条线，从而揭示软硬件系统的状态变化。孤立的观测值不能叫时序数据，但如果把大量的观测值用时间线串起来，我们就可以研究和分析观测值的趋势及规律

时序数据库的特点

1

数据模式

时序数据随时间增长，相同维度重复取值，指标平滑变化：这点从上面的Network表的数据变化可以看出。

2

高吞吐量写入能力

这是针对时序业务持续产生海量数据这么一个特点量身定做的，当前要实现系统高吞吐量写入，必须要满足两个基本技术点要求：系统具有水平扩展性和单机LSM体系结构。

系统具有水平扩展性很容易理解，单机肯定是扛不住的，系统必须是集群式的，而且要容易加节点扩展，说到底，就是扩容的时候对业务无感知，目前Hadoop生态系统基本上都可以做到这一点；

而LSM体系结构是用来保证单台机器的高吞吐量写入，LSM结构下数据写入只需要写入内存以及追加写入日志，这样就不再需要随机将数据写入磁盘，HBase、Kudu以及Druid等对写入性能有要求的系统目前都采用的这种结构。

3

数据分级存储/TTL

这是针对时序数据冷热性质定制的技术特性。数据分级存储要求能够将最近小时级别的数据放到内存中，将最近天级别的数据放到SSD，更久远的数据放到更加廉价的HDD或者直接使用TTL过期淘汰掉。

4

高压缩率

提供高压缩率有两个方面的考虑：

一方面是节省成本，这很容易理解，将1T数据压缩到100G就可以减少900G的硬盘开销，这对业务来说是有很大的诱惑的。

另一个方面是压缩后的数据可以更容易保证存储到内存中，比如最近3小时的数据是1T，我现在只有100G的内存，如果不压缩，就会有900G的数据被迫放到硬盘上，这样的话查询开销会非常之大，而使用压缩会将这1T数据都放入内存，查询性能会非常之好。

5

高效时间窗口查询能力

时序业务的查询需求分为两类：

一是实时数据查询，反映当前监控对象的状态；

二是主要是查询某个时间段的历史数据，历史数据的数据量非常大，这时候需要针对时间窗口大量数据查询进行优化。

6

多维度查询能力

时序数据通常会有多个维度的标签来刻画一条数据，就是上文中提到的维度列。

如何根据随机几个维度进行高效查询就是必须要解决的一个问题，这个问题通常需要考虑位图索引或者倒排索引技术。

7

高效聚合能力

时序业务一个通用的需求是聚合统计报表查询，比如哨兵系统中需要查看最近一天某个接口出现异常的总次数，或者某个接口执行的最大耗时时间。

这样的聚合实际上就是简单的count以及max，问题是如何能高效的在那么大的数据量的基础上将满足条件的原始数据查询出来并聚合，要知道统计的原始值可能因为时间比较久远而不在内存中哈，因此这可能是一个非常耗时的操作。

目前业界比较成熟的方案是使用预聚合，就是在数据写进来的时候就完成基本的聚合操作。

8

通常不需要具备事务的能力

时序数据库与传统关系型数据库不同,传统关系型数据库注重增删改查和事务功能，而时序数据库针对海量数据写入，其读取查询多是一段时间段内的数据。

开源时序数据库选型对比

1

OpenTSDB

- Metric+Tags

-集群方案成熟(HBase)

- 写高效（LSM-Tress）

- 查询函数有限 - 依赖HBase - 运维复杂 - 聚合分析能力较弱

2

InfluxDB

- Metrics+Tags - 部署简单、无依赖 - 实时数据Downsample - 高效存储 - 开源版本没有集群功能 - 存在前后版本兼容问题 - 存储引擎在变化

3

Druid

- 支持嵌套数据的列式存储

- 具有强大的多维聚合分析能力

- 实时高性能数据摄取

- 具有分布式容错框架

- 支持类SQL查询

- 一般不能查询原始数据

- 不适合维度基数特别高的场景

- 时间窗口限制了数据完整性

- 运维较复杂

4

ClickHouse

- 具有强大的多维聚合分析能力

- 实时高性能数据读写

- 支持类SQL查询

- 提供丰富的函数支持

- 具有分布式容错框架

- 支持原始数据查询

- 适用于基数大的维度存储分析

- 比较年轻，扩张不够丰富，社区还不够活跃

- 不支持数据更新和删除

- 集群功能较弱