时序列数据库武斗大会之什么是 TSDB ？

本文选自 OneAPM Cloud Insight 高级工程师刘斌博客 。

• 刘斌，一个才思敏捷的程序员，《第一本 Docker 书》、《GitHub 入门与实践》等书籍译者，Docker入门与实践课程主讲人。

• 时间序列数据库，Cloud Insight 实现对性能指标进行聚合、分组、过滤所采起的解决方案。

因为工做上的关系，最近看了一些关于时序列数据库的东西，固然，我所看的也都是以开源方案为主。趁着这股热劲还没退，但愿能整理一些资料出来。若是正好你也有这方面的需求，那么但愿这一系列的介绍可以帮助到你。

1. 什么是时序列数据库（Time series database）？

一听到时序列数据库，若是只是稍有耳闻的人，可能马上会联想到运维和监控系统。

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

1.1 给TSDB一个定义

这是维基百科上的解释：

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 的特色主要有如下几点，这里简单罗列了一下。

2.1 数据写入

TSDB 在数据写入方面，具备以下特色：

• 写多于读：95%-99%的操做都是写操做

• 顺序写：因为是时间序列数据，所以数据多为追加式写入，并且几乎都是实时写入，不多会写入几天前的数据。

• 不多更新：数据写入以后，不会更新

• 区块（bulk）删除：基本没有随机删除，多数是从一个时间点开始到某一时间点结束的整段数据删除。好比删除上个月，或者7天前的数据。不多出现删除单独某个指标的数据，或者跳跃时间段的数据。

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

2.2 数据读取（查询）

相对于写入操做，TSDB 的读取操做特色以下：

• 顺序读：基本都是按照时间顺序读取一段时间内的数据。

• 基数大：基本数据大，超过内存大小，要选取的只是其一小部分，且没有规律，缓存几乎不起任何做用。

即便读取操做相对写来讲较少，可是读操做的响应时间要求很高，除非你是只作后台报表生成，不然一旦有交互性操做，必需要求快速响应。

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

• 一是以写性能优先，不为读取作存储优化，可是经过分布式和并发读，来提升读取的速度。

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

2.3 分布式（集群）

TSDB 应该天生就要考虑到分布式和分区等特性，将存储和查询分发到不一样的服务器，以支撑大规模的数据采集和查询请求。

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

2.4 基本数据分析支持

TSDB 的数据是用来分析的，因此 TSDB 还会提供作数据分析所必须的各类运算、变换函数。好比能够方便的对时序列数据进行求和、求平均值等操做，就像传统的 RDBMS 同样。

3. 如何去选择开源时序列数据库

虽然每一个人的场景不太同样，不过我以为如下的大部分因素，都值得你们好好考量一下。除了功能上能知足、性能上撑得住，运（售）维（后）等也是咱们准备长期使用所必须面临的问题。

我本身总结的评价因素主要有以下几点：

3.1 性能

主要就是读和写的性能，在前面 TSDB 的特色中咱们已经讲过了。

经过前面的说明，咱们也知道 TSDB 99.9% 都是读少写多，所以写入性能必须能跟得上、无延时，而且不能阻塞读操做，且读操做能快速返回最新的数据。

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

3.2 存储方案（或引擎）

存储方案主要会影响到读写性能、集群扩展容易程度、以及运维的复杂度。典型的存储方案有 HDFS、HBase、Cassandra、LevelDB等。

3.3 集群功能

通常来讲，集群主要集中为存储和查询的集群功能，也表明其可扩展性，由于时序列数据库的数据量极可能很大，而且增加趋势不可预测，尤为是随着大数据和物联网的兴起，GB 已经算入门，TB 也是刚起步。

3.4 API（HTTP API 和 Client Library）

若是你须要定制，或者只是使用 TSDB 作存储，本身写入数据并经过查询接口进行数据展现，那么 API 的完善程度将是一个很重要的评判因素。

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

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

3.5 SQL-like Query Language

若是能经过相似传统 SQL 的 来查询 metric 的话，是否是刚接触到 TSDB 的人更容易上手和理解呢？

select mean(value) from metric where role='user' and time >= xxx and time <= yyy group by dc

可能这看起来比较酷，不过对我来讲这只能算是个加分项而已。由于咱们只会经过 API 来读写数据，并且查询模式很是固定、数量很少。

可是不少常常出报表的人，可能更喜欢这一特色了，由于老板、运营可能会按期或者随时找他们出统计数据。

3.6 部署体验

便是否容易部署，特别是做为产品的话，不少企业级产品在安装部署或者升级所耗费的时间绝对是占了大头的。因此是否容易部署就成了一个重要的指标，好比是否能一键部署、单机部署？是否有额外依赖组件等。

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

3.7 成熟度

成熟度包括软件自己的成熟度和生态系统的成熟度。

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

3.8 可视化和报警功能

说到 TSDB，容易联想到的两个功能就是可视化和报警。若是 TSDB 自带了功能强大的可视化组件和报警支持，则可能会省去不少开发的成本，更容易吸引用户。即便开发，也能方便开发过程当中进行调试和验证。

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

3.9 所采用技术栈

主要是该方案采用了什么编程语言，有哪些第三方模块。好比有的用 Java 编写，有的用 Golang；有的用 HBase，有的用本身的存储方案；有的自带丰富的 UI，有的则只提供了简单的调试界面。

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

3.10 保留策略（Retention Policies，或自动删除、压缩）

自动删除就是为数据设置 TTL，过了指定的 TTL 则自动删除相关数据，以节省存储空间同时提升查询性能。

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

3.11 背后主导公司

有商业公司专职开发，多是个双刃剑。

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

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

3.12 License

这多是影响最弱的一个因素了，可是若是你想拿来商业化的话，则又是一个很是重要甚至致命的因素。

3.13 多租户支持

这部分需求可能会比较少，可是若是想基于 TSDB 为用户提供服务，好比 SaaS 类应用，能从物理上隔离固然是最理想的了，不过很遗憾目前好像尚未这方面的方案。要想支持多租户，只能从应用自身来设计，相似传统 RDBMS 那样，为每一个实体加入 user_id=xxx 相似的属性。

3.14 安全性

好比：权限管理、访问控制等。

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

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

4. 参考文献

• Time-Series Database Requirements

• Thoughts on Time-series Databases

• DB-Engines Ranking of Time Series DBMS(January 2016)

请期待本系列文章的其余部分：

• 时序列数据库武斗大会之TSDB名录 Part 1

• 时序列数据库武斗大会之TSDB名录 Part 2

• 时序列数据库武斗大会之 OpenTSDB 篇

Cloud Insight 集监控、管理、计算、协做、可视化于一身，帮助全部 IT 公司，减小在系统监控上的人力和时间成本投入，让运维工做更加高效、简单。
本文转自 OneAPM 官方博客