时序数据库简介- IT系统运维

时序数据的定义

在谈到数据库，大多数IT运维会想到关系型数据库和非关系型数据库二大类。今天跟大家聊聊时序数据库。什么是时间序列数据（Time Series Data，TSD，以下简称时序）从定义上来说，就是一串按时间维度索引的数据。用描述性的语言来解释什么是时序数据，简单的说，就是这类数据描述了某个被测量的主体在一个时间范围内的每个时间点上的测量值。它普遍存在于IT基础设施、运维监控系统和物联网中。

对时序数据进行建模的话，会包含三个重要部分，分别是：主体，时间点和测量值。套用这套模型，你会发现你在日常工作生活中，无时无刻不在接触着这类数据。如果你是一个股民，某只股票的股价就是一类时序数据，其记录着每个时间点该股票的股价。如果你是一个运维人员，监控数据是一类时序数据，例如对于机器的CPU的监控数据，就是记录着每个时间点机器上CPU的实际消耗值。时序数据从时间维度上将孤立的观测值连成一条线，从而揭示软硬件系统的状态变化。孤立的观测值不能叫时序数据，但如果把大量的观测值用时间线串起来，我们就可以研究和分析观测值的趋势及规律。

时序数据的数学模型

上面介绍了时序数据的基本概念，也说明了分析时序数据的意义。那么时序数据该怎样存储呢？数据的存储要考虑其数学模型和特点，时序数据当然也不例外。所以这里先介绍时序数据的数学模型和特点。

下图为一段时序数据，记录了一段时间内的某个集群里各机器上各端口的出入流量，每半小时记录一个观测值。这里以图中的数据为例，介绍下时序数据的数学模型（不同的时序数据库中，基本概念的称谓有可能不同，这里以腾讯CTSDB为准）：

measurement： 度量的数据集，类似于关系型数据库中的 table；

point： 一个数据点，类似于关系型数据库中的 row；

timestamp： 时间戳，表征采集到数据的时间点；

tag： 维度列，代表数据的归属、属性，表明是哪个设备/模块产生的，一般不随着时间变化，供查询使用；

field： 指标列，代表数据的测量值，随时间平滑波动，不需要查询。

如上图所示，这组数据的measurement为Network，每个point由以下部分组成：

timestamp：时间戳

两个tag：host、port，代表每个point归属于哪台机器的哪个端口

两个field：bytes_in、bytes_out，代表piont的测量值，半小时内出入流量的平均值

同一个host、同一个port，每半小时产生一个point，随着时间的增长，field（bytes_in、bytes_out）不断变化。如host：host4，port：51514，timestamp从02:00 到02:30的时间段内，bytes_in 从 37.937上涨到38.089，bytes_out从2897.26上涨到3009.86，说明这一段时间内该端口服务压力升高。

时序数据特点

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

写入： 持续高并发写入，无更新操作：时序数据库面对的往往是百万甚至千万数量级终端设备的实时数据写入（如摩拜单车2017年全国车辆数为千万级），但数据大多表征设备状态，写入后不会更新。

查询： 按不同维度对指标进行统计分析，且存在明显的冷热数据，一般只会频繁查询近期数据。

时序数据的存储

传统关系型数据库存储时序数据的问题

有了时序数据后，该存储在哪里呢？首先我们看下传统的关系型数据库解决方案在存储时序数据时会遇到什么问题。

很多人可能认为在传统关系型数据库上加上时间戳一列就能作为时序数据库。数据量少的时候确实也没问题。但时序数据往往是由百万级甚至千万级终端设备产生的，写入并发量比较高，属于海量数据场景。

MySQL在海量的时序数据场景下存在如下问题：

存储成本大：对于时序数据压缩不佳，需占用大量机器资源；

维护成本高：单机系统，需要在上层人工的分库分表，维护成本高；

写入吞吐低：单机写入吞吐低，很难满足时序数据千万级的写入压力；

查询性能差：适用于交易处理，海量数据的聚合分析性能差。

另外，使用Hadoop生态（Hadoop、Spark等）存储时序数据会有以下问题：

数据延迟高：离线批处理系统，数据从产生到可分析，耗时数小时、甚至天级；

查询性能差：不能很好的利用索引，依赖MapReduce任务，查询耗时一般在分钟级。

可以看到时序数据库需要解决以下几个问题：

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

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

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

时序数据库

时序数据库产品的发明都是为了解决传统关系型数据库在时序数据存储和分析上的不足和缺陷，这类产品被统一归类为时序数据库。***针对时序数据的特点对写入、存储、查询等流程进行了优化，这些优化与时序数据的特点息息相关：

存储成本：

利用时间递增、维度重复、指标平滑变化的特性，合理选择编码压缩算法，提高数据压缩比；

通过预降精度，对历史数据做聚合，节省存储空间。

高并发写入：

批量写入数据，降低网络开销；

数据先写入内存，再周期性的dump为不可变的文件存储。

低查询延时，高查询并发：

优化常见的查询模式，通过索引等技术降低查询延时；

通过缓存、routing等技术提高查询并发。

时序数据的存储原理

传统数据库存储采用的都是 B tree，这是由于其在查询和顺序插入时有利于减少寻道次数的组织形式。我们知道磁盘寻道时间是非常慢的，一般在 10ms 左右。磁盘的随机读写慢就慢在寻道上面。对于随机写入 B tree 会消耗大量的时间在磁盘寻道上，导致速度很慢。我们知道 SSD 具有更快的寻道时间，但并没有从根本上解决这个问题。

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

业界主流都是采用 LSM tree 替换 B tree，比如 Hbase, Cassandra 等 nosql 。这里我们详细介绍一下。

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

LSM tree 操作流程如下：

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

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

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

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

分布式存储

时序数据库面向的是海量数据的写入存储读取，单机是无法解决问题的。所以需要采用多机存储，也就是分布式存储。分布式存储首先要考虑的是如何将数据分布到多台机器上面，也就是分片（sharding）问题。下面我们就时序数据库分片问题展开介绍。分片问题由分片方法的选择和分片的设计组成。

分片方法

时序数据库的分片方法和其他分布式系统是相通的。

哈希分片：这种方法实现简单，均衡性较好，但是集群不易扩展。

一致性哈希：这种方案均衡性好，集群扩展容易，只是实现复杂。代表有 Amazon 的 DynamoDB 和开源的 Cassandra。

范围划分：通常配合全局有序，复杂度在于合并和分裂。代表有 Hbase。

以上内容由北京艾锑无限科技发展有限公司整理