时间序列数据库(TSDB)初识与选择

时间序列数据库(TSDB)初识与选择

本文做者由 MageByte 团队的 「借来方向」编写，关注公众号 给你更多硬核技术

背景

这两年互联网行业掀着一股新风，老是听着各类高大上的新名词。大数据、人工智能、物联网、机器学习、商业智能、智能预警啊等等。

之前的系统，作数据可视化，信息管理，流程控制。如今业务已经不只仅知足于这种简单的管理和控制了。数据可视化分析，大数据信息挖掘，统计预测，建模仿真，智能控制成了各类业务的追求。

“全部一切如泪水般消失在时间之中，时间正在死去“，之前咱们利用互联网解决现实的问题。如今咱们已经不知足于现实，数据将链接成时间序列，往前能够观其历史，揭示其规律性，日后能够把握其趋势性，预测其走势。

咱们开始存储大量的数据，并总结出这些数据的结构特色和常见使用场景，不断改进和优化，创造了一种新型的数据库分类——时间序列数据库(time series database).

时间序列模型

时间序列数据库主要用于处理带时间标签（按照时间的顺序变化，即时间序列化）的数据，带时间标签的数据也称为时间序列数据。

每一个时序点结构以下：

• timestamp: 数据点的时间，表示数据发生的时间。
• metric: 指标名，当前数据的标识，有些系统中也称为 name。
• value: 值，数据的数值，通常为 double 类型，如 cpu 使用率，访问量等数值，有些系统一个数据点只能有一个 value，多个 value 就是多条时间序列。有些系统能够有多个 value 值，用不一样的 key 表示
• tag: 附属属性。

tsdb

实现

假如我想记录一系列传感器的时间序列数据。数据结构以下：

* 标识符：device_id，时间戳
* 元数据：location_id，dev_type，firmware_version，customer_id
* 设备指标：cpu_1m_avg，free_mem，used_mem，net_rssi，net_loss，电池
* 传感器指标：温度，湿度，压力，CO，NO2，PM10

若是使用传统 RDBMS 存储，建一张以下结构的表便可： 如此即是一个最简单的时间序列库了。但这只是知足了时间序列数据模型的须要。咱们还须要在性能，高效存储，高可用，分布式和易用性上作更多的事情。

你们能够思考思考，若是让咱们本身来实现一个时间序列数据库，你会怎么设计，你会考虑哪些性能上的优化，又如何作到高可用，怎样作到简单易用。

Timescale

这个数据库其实就是一个基于传统关系型数据库 postgresql 改造的时间序列数据库。了解 postgresql 的同窗都知道，postgresql 是一个强大的，开源的，可扩展性特别强的一个数据库系统。

因而 timescale.inc 在 postgresql 架构上开发了 Timescale，一款兼容 sql 的时序数据库。 做为一个 postgresql 的扩展提供服务。其特色以下：

基础：

• 支持全部 PostgreSQL 原生 SQL，包含完整 SQL 接口（包括辅助索引，非时间聚合，子查询，JOIN，窗口函数）。
• 用 PostgreSQL 的客户端或工具，能够直接应用到该数据库，不须要更改。
• 时间为导向的特性，API 功能和相应的优化。
• 可靠的数据存储。

扩展：

• 透明时间/空间分区，用于放大（单个节点）和扩展。
• 高数据写入速率（包括批量提交，内存中索引，事务支持，数据备份支持)。
• 单个节点上的大小合适的块（二维数据分区），以确保即便在大数据量时也可快速读取。
• 块之间和服务器之间的并行操做。

劣势：

• 由于 TimescaleDB 没有使用列存技术，它对时序数据的压缩效果不太好，压缩比最高在 4X 左右
• 目前暂时不彻底支持分布式的扩展（正在开发相关功能），因此会对服务器单机性能要求较高

其实你们均可以去深刻了解一下这个数据库。对 RDBMS 咱们都很熟悉，了解这个可让咱们对 RDBMS 有更深刻的看法，了解其实现机制，存储机制。在对时间序列的特殊化处理之中，咱们又能够学到时间序列数据的特色，并学习到如何针对时间序列模型去优化 RDBMS。

以后咱们也能够写一篇文章来深刻的了解一下这个数据库的特色。

Influxdb

Influxdb 是业界比较流行的一个时间序列数据库，特别是在 IOT 和监控领域十分常见。其使用 go 语言开发，突出特色是性能。 特性：

• 高效的时间序列数据写入性能。自定义 TSM 引擎，快速数据写入和高效数据压缩。
• 无额外存储依赖。
• 简单，高性能的 HTTP 查询和写入 API。
• 以插件方式支持许多不一样协议的数据摄入，如：graphite，collectd，和 openTSDB
• SQL-like 查询语言，简化查询和聚合操做。
• 索引 Tags，支持快速有效的查询时间序列。
• 保留策略有效去除过时数据。
• 连续查询自动计算聚合数据，使频繁查询更有效。

Influxdb 已经将分布式版本转为闭源。因此在分布式集群这块是一个弱点，须要本身实现。

OpenTSDB

The Scalable Time Series Database. 打开 OpenTSDB 官网，第一眼看到的就是这句话。可见其将 Scalable 做为本身重要的”卖点“。OpenTSDB 运行在 Hadoop 和 HBase 上，其充分利用 HBase 的特性。经过独立的 Time Series Demon(TSD)提供服务，因此它能够经过增减服务节点来轻松扩缩容。

tsdb-architecture

• Opentsdb 是一个基于 Hbase 的时间序列数据库（新版也支持 Cassandra）。

  其基于 Hbase 的分布式列存储特性实现了数据高可用，高性能写的特性。受限于 Hbase，存储空间较大，压缩不足。依赖整套 HBase, ZooKeeper

• 采用无模式的 tagset 数据结构(sys.cpu.user 1436333416 23 host=web01 user=10001)

  结构简单，多 value 查询不友好

• HTTP-DSL 查询

OpenTSDB 在 HBase 上针对 TSDB 的表设计和 RowKey 设计值得咱们深刻学习的一个特色。有兴趣的同窗能够找一些详细的资料学习学习。

Druid

Druid 是一个实时在线分析系统(LOAP)。其架构融合了实时在线数据分析，全文检索系统和时间序列系统的特色，使其能够知足不一样使用场景的数据存储。

• 采用列式存储：支持高效扫描和聚合，易于压缩数据。
• 可伸缩的分布式系统：Druid 自身实现可伸缩，可容错的分布式集群架构。部署简单。
• 强大的并行能力：Druid 各集群节点能够并行地提供查询服务。
• 实时和批量数据摄入：Druid 能够实时摄入数据，如经过 Kafka。也能够批量摄入数据，如经过 Hadoop 导入数据。
• 自恢复，自平衡，易于运维：Druid 自身架构即实现了容错和高可用。不一样的服务节点能够根据负载需求添加或减小节点。
• 容错架构，保证数据不丢失：Druid 数据能够保留多副本。另外能够采用 HDFS 做为深度存储，来保证数据不丢失。
• 索引：Druid 对 String 列实现反向编码和 Bitmap 索引，因此支持高效的 filter 和 groupby。
• 基于时间分区：Druid 对原始数据基于时间作分区存储，因此 Druid 对基于时间的范围查询将更高效。
• 自动预聚合：Druid 支持在数据摄入期就对数据进行预聚合处理。

Druid 架构蛮复杂的。其按功能将整个系统细分为多种服务，query、data、master 不一样职责的系统独立部署，对外提供统一的存储和查询服务。其以分布式集群服务的方式提供了一个底层数据存储的服务。

druid-architecture

Druid 在架构上的设计很值得咱们学习。若是你不只仅对时间序列存储感兴趣，对分布式集群架构也有兴趣，不妨看看 Druid 的架构。另外 Druid 在 segment(Druid 的数据存储结构)的设计上也是一大亮点，即实现了列式存储，又实现了反向索引。

Elasticsearch

Elasticsearch 是一个分布式的开源搜索和分析引擎，适用于全部类型的数据，包括文本、数字、地理空间、结构化和非结构化数据。Elasticsearch 在 Apache Lucene 的基础上开发而成，由 Elasticsearch N.V.（即如今的 Elastic）于 2010 年首次发布。Elasticsearch 以其简单的 REST 风格 API、分布式特性、速度和可扩展性而闻名。

Elasticsearch 以 ELK stack 被人所熟知。许多公司基于 ELK 搭建日志分析系统和实时搜索系统。以前我所在团队在 ELK 的基础上开始开发 metric 监控系统。即想到了使用 Elasticsearch 来存储时间序列数据库。对 Elasticserach 的 mapping 作相应的优化，使其更适合存储时间序列数据模型，收获了不错的效果，彻底知足了业务的需求。后期发现 Elasticsearch 新版本居然也开始发布 Metrics 组件和 APM 组件，并大量的推广其全文检索外，对时间序列的存储能力。真是和咱们当时的想法不谋而合。

Elasticsearch 的时序优化能够参考一下这篇文章:《elasticsearch-as-a-time-series-data-store》

也能够去了解一下 Elasticsearch 的 Metric 组件Elastic Metrics

Beringei

Beringei 是 Facebook 在 2017 年最新开源的一个高性能内存时序数据存储引擎。其具备快速读写和高压缩比等特性。

2015 年 Facebook 发表了一篇论文《Gorilla: A Fast, Scalable, In-Memory Time Series Database 》，Beringei 正是基于此想法实现的一个时间序列数据库。

Beringei 使用 Delta-of-Delta 算法存储数据，使用 XOR 编码压缩数值。使其能够用不多的内存便可存储下大量的数据。

如何选择一个适合本身的时间序列数据库

• Data model

  时间序列数据模型通常有两种，一种无 schema，具备多 tag 的模型，还有一种 name、timestamp、value 型。前者适合多值模式，对复杂业务模型更适合。后者更适合单维数据模型。

• Query language

  目前大部分 TSDB 都支持基于 HTTP 的 SQL-like 查询。

• Reliability

  可用性主要体如今系统的稳定高可用上，以及数据的高可用存储上。一个优秀的系统，应该有一个优雅而高可用的架构设计。简约而稳定。

• Performance

  性能是咱们必须考虑的因素。当咱们开始考虑更细分领域的数据存储时，除了数据模型的需求以外，很大的缘由都是通用的数据库系统在性能上没法知足咱们的需求。大部分时间序列库倾向写多读少场景，用户须要平衡自身的需求。下面会有一份各库的性能对比，你们能够作一个参考。

• Ecosystem

  我一直认为生态是咱们选择一个开源组件必须认真考虑的一个问题。一个生态优秀的系统，使用的人多了，未被发现的坑也将少了。另外在使用中遇到问题，求助于社区，每每能够获得一些比较好的解决方案。另外好的生态，其周边边界系统将十分红熟，这让咱们在对接其余系统时会有更多成熟的方案。

• Operational management

  易于运维，易于操做。

• Company and support

  一个系统其背后的支持公司也是比较重要的。背后有一个强大的公司或组织，这在项目可用性保证和后期维护更新上都会有较大的体验。

性能对比

	Timescale	InfluxDB	OpenTSDB	Druid	Elasticsearch	Beringei
write(single node)	15K/sec	470k/sec	32k/sec	25k/sec	30k/sec	10m/sec
write(5 node)			128k/sec	100k/sec	120k/sec

总结

最后总结一下：

• 若是你想要一个极限性能的系统能够考虑 Beringei 和 InfluxDB，在数据高可用方面，能够采用客户端双写模式来对数据作一个副本，保证数据的可用性。
• 若是你数据量不大，性能要求也不是特别高，却又点查询，删除和关联查询等需求，不妨考虑一下 Timescale。
• 若是你间距索引和时间序列的需求。那么 Druid 和 Elasticsearch 是最好的选择。其性能都不差，而且都是高可用容错架构。

最后

以后咱们能够来深刻了解一两个 TSDB，好比 Influxdb，Druid，Elasticsearch 等。并能够学习一下行存储与列存储的不一样，LSM 的实现原理，数值数据的压缩，MMap 提高读写性能的知识等。

关注公众号，掌握更多硬核技术