本文选自 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 是否足够多，也可以在 * 上看一下相关讨论内容。
最重要的评论观点就是在专业社区（比如在 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)
请期待本系列文章的其他部分：
Cloud Insight 集监控、管理、计算、协作、可视化于一身，帮助所有 IT 公司，减少在系统监控上的人力和时间成本投入，让运维工作更加高效、简单。
本文转自 OneAPM 官方博客