时间序列数据库简称时序数据库(Time Series Database)，用于处理带时间标签(按照时间的顺序变化，即时间序列化)的数据，带时间标签的数据也称为时间序列数据。

时序数据的几个特点

  • 基本上都是插入，没有更新的需求。
  • 写多于读：95%-99%的操作都是写操作
  • 顺序写：由于是时间序列数据，因此数据多为追加式写入，而且几乎都是实时写入，很少会写入几天前的数据。
  • 很少更新：数据写入之后，不会更新
  • 区块（bulk）删除：基本没有随机删除，多数是从一个时间点开始到某一时间点结束的整段数据删除。比如删除上个月，或者7天前的数据。很少出现删除单独某个指标的数据，或者跳跃时间段的数据。
  • 数据读取（查询）
  • 顺序读：基本都是按照时间顺序读取一段时间内的数据。
  • 基数大：基本数据大，超过内存大小，要选取的只是其一小部分，且没有规律，缓存几乎不起任何作用。
  • 即使读取操作相对写来说较少，但是读操作的响应时间要求很高，除非你是只做后台报表生成，否则一旦有交互性操作，必须要求快速响应。为了提高读取的响应时间，有两种策略：
  • 一是以写性能优先，不为读取做存储优化，但是通过分布式和并发读，来提高读取的速度。
  • 二就是在写入的时候就考虑到读的性能问题，将统一指标、时间段的数据写入到同一数据块中，为读取进行写入优化。
  • 分布式（集群）
  • TSDB 应该天生就要考虑到分布式和分区等特性，将存储和查询分发到不同的服务器，以支撑大规模的数据采集和查询请求。
  • 同时，它也应该是能扩展和自动失败切换（Fault-tolerant）的。随着数据量的增长，所需服务器的台数也会增加，能动态的增减服务器则是一个基本要求。同时，随着服务器的增多，各种服务器软件或者网络故障发生的概率也会增大，这时候失败切换也显得很重要，不能因为一台机器的失效而导致整个集群不可工作。
  • 数据基本上都有时间属性，随着时间的推移不断产生新的数据。
  • 数据量大，每秒钟需要写入千万、上亿条数据
  • 保留策略（Retention Policies，或自动删除、压缩）
  • 自动删除就是为数据设置 TTL，过了指定的 TTL 则自动删除相关数据，以节省存储空间同时提高查询性能。如果不删除数据，也可以对数据进行压缩，或者再采样（Resampling），比如对最近 1 天的数据我们可能需要精确到秒，而查询 1 年的数据时，我们只需要精确到天，这时候，海量的数据一年只需要 365 个点来存储，大大节省了存储空间。

业务方常见需求

  • 获取最新状态，查询最近的数据(例如传感器最新的状态)
  • 展示区间统计，指定时间范围，查询统计信息，例如平均值，最大值，最小值，计数等。。。
  • 获取异常数据，根据指定条件，筛选异常数据

常见业务场景

  • 监控软件系统： 虚拟机、容器、服务、应用
  • 监控物理系统： 水文监控、制造业工厂中的设备监控、国家安全相关的数据监控、通讯监控、传感器数据、血糖仪、血压变化、心率等
  • 资产跟踪应用： 汽车、卡车、物理容器、运货托盘
  • 金融交易系统： 传统证券、新兴的加密数字货币
  • 事件应用程序： 跟踪用户、客户的交互数据
  • 商业智能工具： 跟踪关键指标和业务的总体健康情况
  • 在互联网行业中，也有着非常多的时序数据，例如用户访问网站的行为轨迹，应用程序产生的日志数据等等。
  • 一些基本概念(不同的时序数据库称呼略有不同)
  • Metric: 度量，相当于关系型数据库中的 table。
  • Data point: 数据点，相当于关系型数据库中的 row。
  • Timestamp：时间戳，代表数据点产生的时间。
  • Field: 度量下的不同字段。比如位置这个度量具有经度和纬度两个 field。一般情况下存放的是随时间戳而变化的数据。
  • Tag: 标签。一般存放的是不随时间戳变化的信息。timestamp 加上所有的 tags 可以视为 table 的 primary key。
  • 例如采集有关风的数据，度量为 Wind，每条数据都有时间戳timestamp，两个字段 field：direction(风向)、speed(风速)，两个tag：sensor(传感器编号)、city(城市)。第一行和第三行，存放的都是 sensor 编号为86F-2RT8的设备，城市是深圳。随着时间的变化，风向和风速发生了改变，风向从56.4变为45.6，风速从2.9变为3.6。

需要解决的几个问题

  • 时序数据的写入：如何支持每秒钟成千上亿条数据的写入。
  • 时序数据的读取：如何支持在秒级对上亿条数据的分组聚合运算。
  • 成本敏感：海量数据存储带来的成本问题。如何以更低成本存储数据，将成为时序数据库需要解决的重中之重。

常见时序数据库

时序数据库出现的时间较晚，目前较成熟的时序数据库都仅有2、3年的历史。 InfluxDB(单机版免费，集群版收费)最成熟，Kairosdb(底层使用Cassandra)，OpenTsdb(底层使用HBase)，beringei(Facebook开源)，TimeScaleDB(底层基于PostgreSQL)，TSDB(百度开源)，HiTSDB(阿里开源，底层是PostgreSQL)，MatrixDB（国产，据说写入性能比InfluxDB快几十倍：https://zhuanlan.zhihu.com/p/374151291 ）