时序数据库之InfluxDB

2022-02-11 00:00:00 数据 数据库 时序 指标 保存

近公司业务重度依赖时序数据库, 公司上个版本选择了OpenTSDB, 在1-2年前，他的确很流行。但是在做软件重构时, 业务层反馈的一些问题, OpenTSDB暂时无法解决,成为了一个痛点, 让我需要考虑其他方案, 由于之前使用过InfluxDB, 也一直在关注, 它给了我惊艳的感觉,所以记忆犹新.

1背景

之前做运维时,重度使用过zabbix, 关系型数据库的优化,根本无法解决高IO, 后面又使用过Graphite, 这个安装像迷一样的工具, 它后端在RRD上面设计出了一个简单的时序数据库, 但是配置繁杂,容量完全靠规划。直到使用了InfluxDB, 部署简单,使用方便,高压缩, 对它印象很不错, 但是0.12过后不支持集群。

之前InfluxDB切换了2次存储引擎(它的存储是插件式的), 也没去了解过它切换的原因, 直到看到InfoQ上七牛的演讲从InfluxDB看时序数据的处, 他道出了了原因:

  1. LevelDB不支持热备份, influxDB设计的shard会消耗大量文件描述符，将系统资源耗尽。
  2. BoltDB解决了热备, 解决了消耗大量文件描述符的问题, 但是引入了一个更致命的问题:容量达到数GB级别时,会产生大量随机写, 造成高IOPS。
  3. 放弃了他们, 在他们的经验上开始自己实现一个存储引擎: TSM(Time-Structured Merge Tree), 它截取了OpenTSDB的一些设计经验,根据LSM Tree针对时间序列数据进行优化

我认为像这样的针对特殊场景进行优化的数据库会是今后数据库领域发展的主流, 另一个证明就是EleasticSearch一个针对文本解索而设计的数据库, 虽然OpenTSDB也针对时序数据做了优化,但是由于存储系统依然依赖HBase, 所以力度上面感觉没InfluxDB给力。

社区一路走来之艰辛,但是却激情洋溢,他们是先行者. 我对它集群的闭源并不反感, 这群激情洋溢的人需要有商业支持。

2时序数据库热度排名

这是DB Engine的时序数据库新的排行榜

上图可以看出InfluxDB超级火热, 稳居，对于一个设计精良，部署简单，使用方便，而且还高性能的时序数据库而言, 想不热都难。

3简介


基于Go语言开发，社区非常活跃，项目更新速度很快，日新月异，关注度高, 1.0发布过后, 稳定性也非常高。官方是这样介绍InfluxDB的：

influxdb是一个从底层一步一步成长为能处理高写入,高查询的时序数据库, 它专门针对时序数据做了优化,让其更高性能, 他可以用来存储任何时序数据, 包括DevOps的监控、应用指标、物联网传感器的数据, 并实时分析


这是它github上给出的特性说明:

  • 内建HTTP API, 无需自己实现
  • 数据高压缩, 支持非常灵活的查询访问
  • 支持类SQL查询, 学习成本低, 方便使用
  • 安装和管理都十分简单, 数据写入和读取的速度快
  • 为实时查询而生, 对每一个点位都建立索引, 及时查询响应速度小于100ms

4业务问题


我们需要一个时序数据库, 他需要能解决我们以下这些问题:

  1. 一个测试指标多值

一个指标往往有多个维度来描述其变化状态,并不仅仅是值, 比如对于CPU的而言, 应该有中断，负载, 使用率等。

2.多Tag支持

tag是对一个指标的描述,是一个标签, 在业务上Tag对于分组过滤非常有意义, 用于标示一个指标在业务上的意义, 比如对于IOT来说, 传感器的指标往往是一个无意义的id, 因此需求给它打上name标签, 标示他的特殊意义, 打上设备ID, 标示它属于哪个设备, 打上位置标签, 标示该指标来源于哪个地方。

3.在指标的值上能做一些基本的比较运算

作为一个数据库,在功能层面需要解决一些基本的运算, 比如求和，求小，求大, 但这还不够, 需要支持条件过滤, 支持Tag的条件过滤, 支持值的条件过滤, 支持值的条件过滤是关键, 不然会产生巨大的数据复制, 比如我们需要过滤出 CPU > 90的机器, 如果数据库不支持, 那么我需要将这些数据从数据库中查出来,复制给我的程序处理。

这带来了巨大的问题:

  • 数据库要吐出如此大量的数据, 负载升高, 出口流量暴增
  • 程序拿到如此大量的数据, 给处理方带来了巨大的计算压力, 如果前段采用Angular或者React来写, 一个运行在pc上的小小的浏览器,根本处理不了。
  • 处理效率低，数据的处理本该在数据存储的地方进行, 比如Hadoop, 完全没必要复制。

4.指标计算的中间结果需要存会指标


这是一个比较常见的场景, 使用RDD时更是常用,比如数据是按照30秒存储的，但是我需要 这样一个聚合维度 5m, 15m, 1h, 3h, 12h, 然后我平时只使用这些维度的数据, 不用每次临时计算。

5概念介绍


influxDB的核心概念包含: Line Protocol, Retention Policy, Series, Point, Continuous Query.

5.1 Line Protocol

Line Protocol用于描述存入数据库的数据格式, 也可以说是数据协议, 相比于JSON格式，Line Protocol无需序列化，更加高效, 官方对它做了全面的介绍Line Protocol, 下面摘取语法部分做简要说明：Line Protocol里面的一行就是InfluxDB里面的一个点位, 他将一个点分割成measurement, tag_set, field_set, timestamp4个部分, 例如:

语法格式: measurement[,tag_key1=tag_value1...] field_key=field_value[,field_key2=field_value2] [timestamp]
栗子:
weather,location=us-midwest temperature=82 1465839830100400200
  |    -------------------- --------------  |
  |             |             |             |
  |             |             |             |
+-----------+--------+-+---------+-+---------+
|measurement|,tag_set| |field_set| |timestamp|
+-----------+--------+-+---------+-+---------+

相关文章