摘要：2017年时序数据库忽然火了起来。开年2月Facebook开源了beringei时序数据库；到了4月基于PostgreSQL打造的时序数据库TimeScaleDB也开源了，而早在2016年7月，百度云在其天工物联网平台上释出了国内首个多租户的分散式时序数据库产品TSDB，成为支援其发展制造，交通，能源，智慧城市等产业领域的核心产品，同时...
2017年时序数据库忽然火了起来。开年2月Facebook开源了beringei时序数据库；到了4月基于PostgreSQL打造的时序数据库TimeScaleDB也开源了，而早在2016年7月，百度云在其天工物联网平台上释出了国内首个多租户的分散式时序数据库产品TSDB，成为支援其发展制造，交通，能源，智慧城市等产业领域的核心产品，同时也成为百度战略发展产业物联网的标志性事件。时序数据库作为物联网方向一个非常重要的服务，业界的频频发声，正说明各家企业已经迫不及待的拥抱物联网时代的到来。
本文会从时序数据库的基本概念、使用场景、解决的问题一一展开，最后会从如何解决时序资料储存这一技术问题入手进行深入分析。
1. 背景
百度无人车在执行时需要监控各种状态，包括座标，速度，方向，温度，湿度等等，并且需要把每时每刻监控的资料记录下来，用来做大资料分析。每辆车每天就会采集将近8T的资料。如果只是储存下来不查询也还好（虽然已经是不小的成本），但如果需要快速查询“今天下午两点在后厂村路，速度超过60km/h的无人车有哪些”这样的多纬度分组聚合查询，那么时序数据库会是一个很好的选择。
2. 什么是时序数据库
先来介绍什么是时序资料。时序资料是基于时间的一系列的资料。在有时间的座标中将这些资料点连成线，往过去看可以做成多纬度报表，揭示其趋势性、规律性、异常性；往未来看可以做大资料分析，机器学习，实现预测和预警。
时序数据库就是存放时序资料的数据库，并且需要支援时序资料的快速写入、持久化、多纬度的聚合查询等基本功能。
对比传统数据库仅仅记录了资料的当前值，时序数据库则记录了所有的历史资料。同时时序资料的查询也总是会带上时间作为过滤条件。
时序资料示例
p1-北上广三地2015年气温变化图
p2-北上广三地当前温度实时展现
下面介绍下时序数据库的一些基本概念（不同的时序数据库称呼略有不同）。
metric: 度量，相当于关系型数据库中的table。
data point: 资料点，相当于关系型数据库中的row。
timestamp：时间戳，代表资料点产生的时间。
field: 度量下的不同字段。比如位置这个度量具有经度和纬度两个field。一般情况下存放的是会随着时间戳的变化而变化的资料。
tag: 标签，或者附加资讯。一般存放的是并不随着时间戳变化的属性资讯。timestamp加上所有的tags可以认为是table的primary key。
如下图，度量为Wind，每一个数据点都具有一个timestamp，两个field：direction和speed，两个tag：sensor、city。它的第一行和第三行，存放的都是sensor号码为95D8-7913的装置，属性城市是上海。随着时间的变化，风向和风速都发生了改变，风向从23.4变成23.2；而风速从3.4变成了3.3。
p3-时序数据库基本概念图
3. 时序数据库的场景
所有有时序资料产生，并且需要展现其历史趋势、周期规律、异常性的，进一步对未来做出预测分析的，都是时序数据库适合的场景。
在工业物联网环境监控方向，百度天工的客户就遇到了这么一个难题，由于工业上面的要求，需要将工况资料储存起来。客户每个厂区具有20000个监测点，500毫秒一个采集周期，一共20个厂区。这样算起来一年将产生惊人的26万亿个资料点。假设每个点50Byte，资料总量将达1P（如果每台服务器10T的硬盘，那么总共需要100多台服务器）。这些资料不只是要实时生成，写入储存；还要支援快速查询，做视觉化的展示，帮助管理者分析决策；并且也能够用来做大资料分析，发现深层次的问题，帮助企业节能减排，增加效益。最终客户采用了百度天工的时序数据库方案，帮助他解决了难题。
在互联网场景中，也有大量的时序资料产生。百度内部有大量服务使用天工物联网平台的时序数据库。举个例子，百度内部服务为了保障使用者的使用体验，将使用者的每次网络卡顿、网络延迟都会记录到百度天工的时序数据库。由时序数据库直接生成报表以供技术产品做分析，尽早的发现、解决问题，保证使用者的使用体验。
4. 时序数据库遇到的挑战
很多人可能认为在传统关系型数据库上加上时间戳一列就能作为时序数据库。资料量少的时候确实也没问题，但少量资料是展现的纬度有限，细节少，可置信低，更加不能用来做大资料分析。很明显时序数据库是为了解决海量资料场景而设计的。
可以看到时序数据库需要解决以下几个问题
l 时序资料的写入：如何支援每秒钟上千万上亿资料点的写入。
l 时序资料的读取：又如何支援在秒级对上亿资料的分组聚合运算。
l 成本敏感：由海量资料储存带来的是成本问题。如何更低成本的储存这些资料，将成为时序数据库需要解决的重中之重。
这些问题不是用一篇文章就能含盖的，同时每个问题都可以从多个角度去优化解决。在这里只从资料储存这个角度来尝试回答如何解决大资料量的写入和读取。
5. 资料的储存
资料的储存可以分为两个问题，单机上储存和分散式储存。
单机储存
如果只是储存起来，直接写成日志就行。但因为后续还要快速的查询，所以需要考虑储存的结构。
传统数据库储存采用的都是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操作流程如下：
1. 资料写入和更新时首先写入位于内存里的资料结构。为了避免资料丢失也会先写到WAL档案中。
2. 内存里的资料结构会定时或者达到固定大小会刷到磁盘。这些磁盘上的档案不会被修改。
3. 随着磁盘上积累的档案越来越多，会定时的进行合并操作，消除冗余资料，减少档案数量。
p4-Hbase LSM tree结构介绍（注1）
可以看到LSM tree核心思想就是通过内存写和后续磁盘的顺序写入获得更高的写入效能，避免了随机写入。但同时也牺牲了读取效能，因为同一个key的值可能存在于多个HFile中。为了获取更好的读取效能，可以通过bloom filter和compaction得到，这里限于篇幅就不详细展开。
分散式储存
时序数据库面向的是海量资料的写入储存读取，单机是无法解决问题的。所以需要采用多机储存，也就是分散式储存。
分散式储存首先要考虑的是如何将资料分布到多台机器上面，也就是 分片（sharding）问题。下面我们就时序数据库分片问题展开介绍。分片问题由分片方法的选择和分片的设计组成。
分片方法
时序数据库的分片方法和其他分散式系统是相通的。
杂凑分片：这种方法实现简单，均衡性较好，但是丛集不易扩充套件。
一致性杂凑：这种方案均衡性好，丛集扩充套件容易，只是实现复杂。代表有Amazon的DynamoDB和开源的Cassandra。
范围划分：通常配合全域性有序，复杂度在于合并和。代表有Hbase。
分片设计
分片设计简单来说就是以什么做分片，这是非常有技巧的，会直接影响写入读取的效能。
结合时序数据库的特点，根据metric+tags分片是比较好的一种方式，因为往往会按照一个时间范围查询，这样相同metric和tags的资料会分配到一台机器上连续存放，顺序的磁盘读取是很快的。再结合上面讲到的单机储存内容，可以做到快速查询。
进一步我们考虑时序资料时间范围很长的情况，需要根据时间范围再将分成几段，分别储存到不同的机器上，这样对于大范围时序资料就可以支援并发查询，优化查询速度。
如下图，第一行和第三行都是同样的tag（sensor=95D8-7913;city=上海），所以分配到同样的分片，而第五行虽然也是同样的tag，但是根据时间范围再分段，被分到了不同的分片。第二、四、六行属于同样的tag（sensor=F3CC-20F3;city=北京）也是一样的道理。
p5-时序资料分片说明
6. 真实案例
下面我以一批开源时序数据库作为说明。
InfluxDB:
非常优秀的时序数据库，但只有单机版是免费开源的，丛集版本是要收费的。从单机版本中可以一窥其储存方案：在单机上InfluxDB采取类似于LSM tree的储存结构TSM；而分片的方案InfluxDB先通过+（事实上还要加上retentionPolicy）确定ShardGroup，再通过+的hash code确定到具体的Shard。
这里timestamp预设情况下是7天对齐，也就是说7天的时序资料会在一个Shard中。
p6-Influxdb TSM结构图（注2）
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亿的限制。
OpenTsdb:
底层使用Hbase作为其分散式储存引擎，采用的也是LSM tree。
Hbase采用范围划分的分片方式。使用row key做分片，保证其全域性有序。每个row key下可以有多个column family。每个column family下可以有多个column。
上图是OpenTsdb的row key组织方式。不同于别的时序数据库，由于Hbase的row key全域性有序，所以增加了可选的salt以达到更好的资料分布，避免热点产生。再由与timestamp间的偏移和资料型别组成column qualifier。
他的timestamp是小时对齐的，也就是说一个row key下最多储存一个小时的资料。并且需要将构成row key的metric和tags都转成对应的uid来减少储存空间，避免Hfile索引太大。下图是真实的row key示例。
p7-open tsdb的row key示例（注3）
7. 结束语
可以看到各分散式时序数据库虽然储存方案都略有不同，但本质上是一致的，由于时序资料写多读少的场景，在单机上采用更加适合大吞吐量写入的单机储存结构，而在分散式方案上根据时序资料的特点来精心设计，目标就是设计的分片方案能方便时序资料的写入和读取，同时使资料分布更加均匀，尽量避免热点的产生。
资料储存是时序数据库设计中很小的一块内容，但也能管中窥豹，看到时序数据库从设计之初就要考虑时序资料的特点。后续我们会从其他的角度进行讨论。
如果您喜欢本文章，可以点选关注，每天将有更多精彩文章与您分享！
