时序数据库

时序数据库是什么

时间序列数据库 Time Series Database (TSDB)

时序数据是随时间不断产生的一系列数据，简单来说，就是带时间戳的数据。

虽然其他数据库也可以在数据规模较小时一定程度上处理时间序列数据，但 TSDB可以更有效地处理随时间推移的数据摄取、压缩和聚合。以车联网场景为例，20000辆车，每个车60个指标，假设每秒采集一次，那么每秒将上报20000 * 60 = 1200000指标值，即120W数据指标值每秒，每个指标值为16字节（假设仅包括8字节时间戳和8字节的浮点数），则每小时将产生64G左右的数据。而实际上每个指标值还会附带标签等额外数据，实际需要存储空间会更大。

时序数据库相关概念

时序数据库是专门处理时序数据的数据库，因此其相关概念是和时序数据紧密联系的，下面是时序数据库的一些基本概念。

* 度量 Metric：Metric 类似关系型数据库里的表（Table），代表一系列同类时序数据的集合，例如为空气质量传感器建立一个 Table，存储所有传感器的监测数据。

* 标签 Tag：Tag 描述数据源的特征，通常不随时间变化，例如传感器设备，包含设备 DeviceId、设备所在的 Region 等 Tag 信息，数据库内部会自动为 Tag 建立索引，支持根据 Tag 来进行多维检索查询；Tag 由 Tag Key、Tag Value 组成，两者均为 String 类型。

* 时间戳 Timestamp：Timestamp代表数据产生的时间点，可以写入时指定，也可由系统自动生成；

* 量测值 Field：Field描述数据源的量测指标，通常随着时间不断变化，例如传感器设备包含温度、湿度等Field；

* 数据点Data Point: 数据源在某个时间产生的某个量测指标值（Field Value）称为一个数据点，数据库查询、写入时按数据点数来作为统计指标；

* 时间线 Time Series ：数据源的某一个指标随时间变化，形成时间线，Metric + Tags + Field 组合确定一条时间线；针对时序数据的计算包括降采样、聚合（sum、count、max、min等）、插值等都基于时间线维度进行；

时序数据库应用场景

时序数据库的应用场景在物联网和互联网APM等场景应用比较多，下面是列举了一些时序数据库的应用场景，但不是全部：

* 公共安全：上网记录、通话记录、个体追踪、区间筛选；

* 电力行业：智能电表、电网、发电设备的集中监测；

* 互联网：服务器/应用监测、用户访问日志、广告点击日志；

* 物联网：电梯、锅炉、机械、水表等各种联网设备；

* 交通行业：实时路况、路口流量监测、卡口数据；

* 金融行业：交易记录、存取记录、ATM、POS机监测；

说不定除了这个空调，下次的电梯项目也是时序数据库

时序数据库特点

具有不变性、唯一性、时间排序性

• 时序数据是基于时间的一系列的数据。在有时间的坐标中将这些数据点连成线，往过去看可以做成多纬度报表，揭示其趋势性、规律性、异常性；往未来看可以做大数据分析，机器学习，实现预测和预警。

• 想时序数据库就是存放时序数据的数据库，并且需要支持时序数据的快速写入、持久化、多纬度的聚合查询等基本功能。

数据写入的特点

• 写入平稳、持续、高并发高吞吐：时序数据的写入是比较平稳的，这点与应用数据不同，应用数据通常与应用的访问量成正比，而应用的访问量通常存在波峰波谷。时序数据的产生通常是以一个固定的时间频率产生，不会受其他因素的制约，其数据生成的速度是相对比较平稳的。
• 写多读少：时序数据上95%-99%的操作都是写操作，是典型的写多读少的数据。这与其数据特性相关，例如监控数据，你的监控项可能很多，但是你真正去读的可能比较少，通常只会关心几个特定的关键指标或者在特定的场景下才会去读数据。
• 实时写入最近生成的数据，无更新：时序数据的写入是实时的，且每次写入都是最近生成的数据，这与其数据生成的特点相关，因为其数据生成是随着时间推进的，而新生成的数据会实时的进行写入。数据写入无更新，在时间这个维度上，随着时间的推进，每次数据都是新数据，不会存在旧数据的更新，不过不排除人为的对数据做订正。

数据存储的特点

• 数据量大：拿监控数据来举例，如果我们采集的监控数据的时间间隔是1s，那一个监控项每天会产生86400个数据点，若有10000个监控项，则一天就会产生864000000个数据点。在物联网场景下，这个数字会更大。整个数据的规模，是TB甚至是PB级的。
• 冷热分明：时序数据有非常典型的冷热特征，越是历史的数据，被查询和分析的概率越低。
• 具有时效性：时序数据具有时效性，数据通常会有一个保存周期，超过这个保存周期的数据可以认为是失效的，可以被回收。一方面是因为越是历史的数据，可利用的价值越低；另一方面是为了节省存储成本，低价值的数据可以被清理。
• 多精度数据存储：在查询的特点里提到时序数据出于存储成本和查询效率的考虑，会需要一个多精度的查询，同样也需要一个多精度数据的存储。

数据模型

时间序列数据可以分成两部分

• 序列 ：就是标识符（维度），主要的目的是方便进行搜索和筛选
• 数据点：时间戳和数值构成的数组
  • 行存：一个数组包含多个点，如 [{t: 2017-09-03-21:24:44, v: 0.1002}, {t: 2017-09-03-21:24:45, v: 0.1012}]
  • 列存：两个数组，一个存时间戳，一个存数值，如[ 2017-09-03-21:24:44, 2017-09-03-21:24:45], [0.1002, 0.1012]
    一般情况下：列存能有更好的压缩率和查询性能

对比和选择

可以按照以下需求自行选择合适的存储：

• 小而精，性能高，数据量较小(亿级): InfluxDB

• 简单，数据量不大（千万级），有联合查询、关系型数据库基础：timescales

• 数据量较大，大数据服务基础，分布式集群需求： opentsdb、KairosDB

• 分布式集群需求，olap实时在线分析，资源较充足：druid

• 性能极致追求，数据冷热差异大：Beringei

• 兼顾检索加载，分布式聚合计算： elsaticsearch

• 适配工业物联网场景，端边云协同配置，高频数据接入，存储压缩比要求较高：Apache IoTDB
  
  

• 如果你兼具索引和时间序列的需求。那么Druid和Elasticsearch是最好的选择。其性能都不差，同时满足检索和时间序列的特性，并且都是高可用容错架构。

• 如果你的使用场景为工业物联网的设备与传感器管理，或者需要厂侧、中心侧的协同部署，那么 Apache IoTDB 会更加合适，其写入性能、压缩比、查询延时都很好，并且为工业物联网自研的树形数据架构也能够更方便的对应数据层级与实际业务层级（厂、设备、零件、传感器等）。

TDengine与InfluxDB对比测试

TDengine与InfluxDB对比测试 - TDengine | 涛思数据 (taosdata.com)

Apache IoTDB 与 InfluxDB、OpenTSDB、KairosDB、TimecaleDB 对比测试

TSDB - 时间序列数据库比较