1. 什么是时序列数据库（Time series database）？
   一听到时序列数据库，如果只是稍有耳闻的人，可能立刻会联想到运维和监控系统。

没错，确实是很多运维、监控系统都采用了TSDB作为数据库系统来存储海量的、严格按时间递增的、在一定程度来说结构非常简单的各种指标（英文可能为metric、measurement或者类似的其他单词）数据。

A time series database (TSDB) is a software system that is optimized for handling time series data, arrays of numbers indexed by time (a datetime or a datetime range).

翻译过来就是“时序列数据库用来存储时序列（time-series）数据并以时间（点或区间）建立索引的软件。”

其中，时序列数据可以定义如下：

可以唯一标识的序列名/ID（比如cpu.load.1）及meta-data；
一组数据点{timestamp, value}。timestamp是一个Unix时间戳，一般精度会比较高，比如influxdb里面是nano秒。一般来说这个精度都会在秒以上。
一般时序列数据都具备如下两个特点：

数据结构简单
数据量大
所谓的结构简单，可以理解为某一度量指标在某一时间点只会有一个值，没有复杂的结构（嵌套、层次等）和关系（关联、主外键等）。

数据量大则是另一个重要特点，这是由于时序列数据由所监控的大量数据源来产生、收集和发送，比如主机、IoT设备、终端或App等。

2. TSDB数据库特点
   TSDB作为一种专为时序列数据优化而设计的数据库，在很多方面都和传统的RDBMS和NoSQL数据库不太一样，比如它不关心范式和事务。

其他方面TSDB的特点主要有以下几点，这里简单罗列了一下。

区块删除很容易进行优化，比如可以按区块来分开存储到不同的文件，这样删除一个区块只需要删除一个文件就可以了，成本会比较低。

即使读取操作相对写来说较少，但是读操作的响应时间要求很高，除非你是只做后台报表生成，否则一旦有交互性操作，必须要求快速响应。

为了提高读取的响应时间，有两种策略。

一是以写性能优先，不为读取做存储优化，但是通过分布式和并发读，来提高读取的速度。

二就是在写入的时候就考虑到读的性能问题，将统一指标、时间段的数据写入到同一数据块中，为读取进行写入优化。

同时，它也应该是能扩展和自动失败切换（Fault-tolerant）的。随着数据量的增长，所需服务器的台数也会增加，能动态的增减服务器则是一个基本要求。同时，随着服务器的增多，各种服务器软件或者网络故障发生的概率也会增大，这时候失败切换也显得很重要，不能因为一台机器的失效而导致整个集群不可工作。

3. 如何去选择开源时序列数据库
   虽然每个人的场景不太一样，不过我觉得以下的大部分因素，都值得大家好好考量一下。除了功能上能满足、性能上撑得住，运（售）维（后）等也是我们准备长期使用所必须面临的问题。

我自己总结的评价因素主要有如下几点：

通过前面的说明，我们也知道TSDB 99.9%都是读少写多，因此写入性能必须能跟得上、无延时，并且不能阻塞读操作，且读操作能快速返回最新的数据。

还有一点必须注意的是，现在很多用户的数据都跑在云主机上，那么IOPS则是一个你必须要注意的因素，超了Plan限制的话很难找出问题原因。

还好大部分TSDB都提供了HTTP API，除了简单的文本格式，有很多还支持JSON格式的输入、输出。

Client Library也是一个加分项，有一个好用的、你熟悉的语言的SDK包的话应该会更方便你做开发。

讯享网

可能这看起来比较酷，不过对我来说这只能算是个加分项而已。因为我们只会通过API来读写数据，而且查询模式非常固定、数量不多。

但是很多经常出报表的人，可能更喜欢这一特点了，因为老板、运营可能会定期或者随时找他们出统计数据。

同时，部署的容易程度也几乎等于以后运维的复杂程度。

3.7.1. 生态系统

生态系统主要是指围绕该软件的周边工具、插件的丰富程度，以及相应的社区的活跃程度。

一个软件的生态系统，跟它的开放机制、插件（扩展）机制关系很大，直接决定第三方是否能很方便的对系统进行扩展。

3.7.2. 开发活跃度

这个可以从TSDB项目的提交记录（比如从GitHub上能看到开发状况）、ISSUE的解决情况，Pull Request的merge情况、以及Release的频率来确认。

有一些TSDB项目甚至提供了ROADMAP，我们还可以通过路线图来了解该软件未来发展方向、特性支持。

3.7.3. 社区包活跃度

主要是文档的丰富性等，可以在Google搜索一下，看看相关的Blog是否足够多，也可以在StackOverFlow上看一下相关讨论内容。

最重要的评论观点就是在专业社区（比如在Ops相关讨论组或社区）中该TSDB出现的频次、大家的关注程度等。

3.7.4. 应用案例

是否有大规模、大公司真正的生产环境的部署案例？规模有多大，性能如何，有无问题等，都是重要考察因素。有大公司的信任背书，你在选择上也就多了份安心，少了些纠结。

比如，Druid就在主页列出了很多使用了Druid的公司： http://druid.io/druid-powered.html

ELK这么流行，跟其一揽子方案关系很大。除了强大的功能之外，部署简单、功能齐全是其吸引人的地方。

技术栈为什么也是一个选型时需要考虑的因素呢，这是因为TSDB所采用的技术，会影响你们开发和运维的复杂程度，此外还会受到既有资产的影响。比如你们没有人熟悉HBase，又不熟悉Java语言，那么可能Influxdb就更适合你们了。

如果不删除数据，也可以对数据进行压缩，或者再采样（Resampling），比如对最近1天的数据我们可能需要精确到秒，而查询1年的数据时，我们只需要精确到天，这时候，海量的数据一年只需要365个点来存储，大大节省了存储空间。

好处是其持续性可期，不用担心过两天项目没有人维护了，有了bug也有人会专门解决。

敝处就是你可能上了贼船下来需要成本较高。比如ElasticSearch，搭建起ELK比较简单，但是一涉及到具体的生产环境部署时需要考虑的权限等问题，要么自己去hack，要么就得买他们的产品，这是成本上需要考虑的。

关于安全性最基本的需求就是不要像ELK那样，暴露在公网上如果不设防火墙的话，谁都能使用，这就带来了很大的安全隐患。

所以说，安全上的最小实现就是支持基本的用户密码认证功能，而且是在两个层次支持，一是UI层，即管理界面或者控制面板等，另一方面就是API级别的用户认证。

4. 参考文献
   Time-Series Database Requirements
   Thoughts on Time-series Databases
   DB-Engines Ranking of Time Series DBMS(January 2016)
5. 相关阅读
   这是本系列文章的其他部分：

时序列数据库武斗大会之什么是TSDB
时序列数据库武斗大会之TSDB名录 Part 1
时序列数据库武斗大会之TSDB名录 Part 2
时序列数据库武斗大会之OpenTSDB篇
时序列数据库武斗大会之KairosDB篇