MISC:时序数据库和它的使用场景

MISC:时序数据库和它的使用场景

1. TSDB时序数据库

时序数据库全称为时间序列数据库.时间序列数据库主要用于指处理带时间标签(按照时间的顺序变化,即时间序列化)的数据,带时间标签的数据也称为时间序列数据.

时间序列数据主要由电力行业、化工行业等各类型实时监测、检查与分析设备所采集、产生的数据,这些工业数据的典型特点是:产生频率快(每一个监测点一秒钟内可产生多条数据)、严重依赖于采集时间(每一条数据均要求对应唯一的时间)、测点多信息量大(常规的实时监测系统均有成千上万的监测点,监测点每秒钟都产生数据,每天产生几十GB的数据量).

1.1 什么是时序数据(Time series data)?

有人认为“时间序列数据”是一系列数据点,它们按时间顺序测量相同的事物,并按时间顺序存储.是的,但这只是表象.

其他人可能会想到一系列数字值,每个数字值都与一个时间戳配对,这些时间戳由名称和一组标注的尺寸(或“标签”)定义. 这也许是对时序数据建模的一种方法,但不是对数据本身的定义. 这是一个基本的例子.想象一下,传感器从三种设置中收集数据:城市,农场工厂.在此示例中,这些来源中的每一个都会定期发送新的读数,从而创建一系列随时间收集的测量值.

还有许多其他类型的时间序列数据.仅举几例:DevOps监视数据,移动/ Web应用程序事件,工业机器数据,科学测量. 这些数据集主要有3个共同点:

  • 接收的数据几乎总是记录为新条目
  • 数据通常按时间顺序
  • 时间是主轴(时间间隔可以是规则的也可以是不规则的)

您可能会问:这与在数据集中保存一个Time字段有什么不同?好吧,这取决于:您的数据集如何跟踪变化?通过更新当前条目还是插入新条目?

当您收集传感器x的新读数时,您是覆盖先前的读数还是在单独的行中创建全新的读数? 虽然这两种方法都可以为您提供系统的当前状态,但是只有通过在单独的行中写入新的读数,您才能跟踪一段时间内系统的所有状态.

简而言之:时间序列数据集以INSERT(而不是UPDATE)跟踪整个系统的变化.

这种将每次更改记录为新的不同行的做法使时间序列数据变得如此强大.它使我们能够衡量变化:

  • 分析过去发生的变化
  • 监视现在发生的变化
  • 预测将来可能发生的变化

简而言之,这就是我喜欢定义时间序列数据的方式:这些数据共同表示系统/流程/行为随时间的变化.

1.2 大量时序数据带来的问题

存储时序数据会带来一个明显的问题:您最终会在非常短的时间获得大量数据,时间序列数据很快会堆积阻塞. 记录和查询大量时序数据时,会产生一系列的问题,这就是为什么人们现在转向时间序列数据库的原因.

2. 为什么需要一个时间序列数据库TSDB?

您可能会问:为什么我不仅使用“常用”数据库(即非时间序列,ie: MySQL)?

事实是,您可以做到,有些人可以做到.但是,为什么TSDB是当今增长最快的数据库?两个原因:规模和可用性

2.1 TSDB 扩展性:

时间序列数据积累非常迅速.(例如,一辆联网汽车每天将收集4,000 GB的数据.)而且普通数据库并非设计来处理这种规模的数据. 关系数据库的数据集非常庞大,表现不佳;NoSQL数据库在规模上表现更好,但仍可以通过针对时间序列数据进行优化的数据库胜过. 相反,时间序列数据库(可以基于关系数据库或NoSQL数据库)通过时间视为头等公民才解决规模效率性能问题. 这些效率提高了性能,包括更高的数据接收效率,更快的大规模查询(尽管某些数据库比其他支持更多查询)以及更好的数据压缩.

2.2 TSDB 可用性:

TSDB通常还包括时间序列数据分析的通用功能和操作,例如数据保留策略,连续查询,灵活的时间聚合等. 即使当前不考虑扩展性(例如,如果您只是开始收集数据),这些功能仍然可以提供更好的用户体验,并使您的生活更轻松.

这就是为什么开发人员越来越多地采用时间序列数据库并将其用于各种用例的原因:

  • 监视软件系统:虚拟机,容器,服务,应用程序
  • 监视物理系统:设备,机械,连接的设备,环境,我们的房屋,我们的身体
  • 资产跟踪应用:车辆,卡车,有形集装箱,托盘
  • 金融交易系统:经典证券,更新的加密货币
  • 事件处理应用程序:跟踪用户/客户交互数据
  • 商业智能工具:跟踪关键指标和业务的整体运行状况

即使这样,您仍需要选择最适合您的数据模型和写入/读取模式的时间序列数据库.

3.时序数据库TSDB的特点

  • 数据写入: 时序数据会按照指定的时间粒度持续写入,支持实时、高并发写入,无须更新或删除操作.
  • 数据读取: 写多读少,多时间粒度、指定维度读取,实时聚合.
  • 数据存储: 按列存储,通过查询特征发现时序数据更适合将一个指标放在一起存储,任何列都能作为存储,读取数据时只会读取所需要的维度所在的列;以不同时间粒度存储,将最近时间以一个比较细的粒度存储,可以将历史数据聚合成一个比较粗的粒度.

4. 为什么不用一个’常规’的数据库?

事实上,你完全可以可以使用非时序序列的数据库,并且也确实有人是这样做的.

5. 时序数据库的对比

时序数据库 优点 缺点
OpenTSDB - Metric+Tags - 集群方案成熟(HBase) - 写高效(LSM-Tress) - 查询函数有限 - 依赖HBase - 运维复杂 - 聚合分析能力较弱
Graphite - 提供丰富的函数支持 - 支持自动Downsample - 对Grafana的支持最好 - 维护简单 - Whisper存储 引擎IOPS高 - Carbon组件CPU使用率高 - 聚合分析能力较弱
InfluxDB - Metrics+Tags - 部署简单、无依赖 - 实时数据Downsample - 高效存储 - 开源版本没有集群功能 - 存在前后版本兼容问题 - 存储引擎在变化
Prometheus - Metric + Tags - 适用于容器监控 - 具有丰富的查询语言 - 维护简单 - 集成监控和报警功能 - 没有集群解决方案 - 聚合分析能力较弱
Druid - 支持嵌套数据的列式存储 - 具有强大的多维聚合分析能力 - 实时高性能数据摄取 - 具有分布式容错框架 - 支持类SQL查询 - 一般不能查询原始数据 - 不适合维度基数特别高的场景 - 时间窗口限制了数据完整性 - 运维较复杂
ElasticSearch - 支持嵌套数据的列式存储 - 支持全文检索 - 支持查询原始数据 - 灵活性高 - 社区活跃 - 扩展丰富 - 不支持分析字段的列式存储 - 对硬件资源要求高 - 集群维护较复杂
ClickHouse - 具有强大的多维聚合分析能力 - 实时高性能数据读写 - 支持类SQL查询 - 提供丰富的函数支持 - 具有分布式容错框架 - 支持原始数据查询 - 适用于基数大的维度存储分析 - 比较年轻,扩张不够丰富,社区还不够活跃 - 不支持数据更新和删除 - 集群功能较弱
目录