比Spark更适合工业互联网的数据库——热门时序数据库介绍与核心文档汇总【施工中，欢迎留言加入】

比Spark更适合工业互联网的数据库——热门时序数据库介绍与核心文档汇总【施工中，欢迎留言加入】

最近开始接触到一些IoT相关的内容，国内也有不少公司与学校在关注相关内容，在目前平台互联网发展已经成熟的阶段，工业互联网则是一片蓝海，那么我们就需要一个更加适合工业互联网的数据库

1、什么是时序数据库2、为什么需要时序数据库

2.1、时序数据库的特点

2.1.1、数据写入的特点：2.1.2、数据查询的特点2.1.3、数据储存的特点2.1.4、总结 2.2、关系型数据库面临的挑战 3、热门的时序数据库介绍

3.1、Apache系

3.1.1、Apache Druid3.1.2、Apache IoTDB 3.2、非Apache系

3.2.1、InfluxDB3.2.2、Kdb+

1、什么是时序数据库

什么是时序数据（Time Series Data，TSD，以下简称时序），从定义上来说，是以时间标签为索引的数据。用更加贴近实际的语言来说，就是这类数据描述了某个被测量的单位在一个时间范围内的每个时间点上的测量值。它普遍存在于IT基础设施、运维监控系统和物联网中。

时序数据从时间维度上将孤立的观测值连成一条线，从而揭示软硬件系统的状态变化。孤立的观测值不能叫时序数据，但如果把大量的观测值用时间线串起来，我们就可以研究和分析观测值的趋势及规律。这也是我们在工业互联网中为什么要使用时序数据库的原因。

以国家级气象观测站为例，全国有近6万个气象观测站，每个气象观测站有70种气象物理量需要采集。某市地铁每列列车拥有3200个指标需要测量，全市列车数达300列。服务器运维监控中，一台服务器需要同时监测IOPS、CPU、网络等十余项指标。这些例子中展现出两个概念：设备与度量指标。所谓度量指标（又被称为工况、测点）是指用户关心的能反映目标的某种状况的数据项，例如CPU利用率、温度、湿度等等。设备是指一个拥有一系列度量指标的实体，例如一台服务器、一个进程、一列车、一个气象观测站等等。一个设备的一个度量指标形成了一条时序数据的唯一标识。

随着时间推移，这条时序数据会产生一系列（时间戳，值）的二元组数据点，构成了时间序列数据集。因此，我们定义一条时间序列是由一个时间序列标识（设备和度量指标），一系列时间戳和数据值对组成的无限集。一个时间序列数据库将管理百万甚至千万条这样的时间序列。

参考：

Apache IoTDB 系列教程-1：数据模型时序数据库介绍

2、为什么需要时序数据库 2.1、时序数据库的特点 2.1.1、数据写入的特点：

数据量大：相比于传统的互联网企业，例如滴滴、阿里等，时序数据的来源多为设备，包括车辆、服务器、生产设备等，这类设备与传统的商业活动访问量通常存在波峰波谷不同，其在整个运行周期的各个时间点几乎是均匀等量地产出大量的数据；
时序数据是由每个个体独立生成，所以当个体数量众多时，通常写入的并发和吞吐量都是比较高的，特别是在物联网场景下。写入并发和吞吐量，可以简单的通过个体数量和数据生成频率来计算，例如若你有1000个个体以10秒的频率产生数据，则你平均每秒产生的并发和写入量就是100；
例如车辆行驶过程中，可能需要以秒为单位采集车辆运行过程中的各个设备数据情况，再例如生产车间中需要实时记录设备的运行情况、生产环境的温度、湿度等信息，并且采集频率越高，数据量也就越大；写多读少：时序数据上95%-99%的 *** 作都是写 *** 作，是典型的写多读少的数据。这与其数据特性相关，例如监控数据，你的监控项可能很多，但是你真正去读的可能比较少，通常只会关心几个特定的关键指标或者在特定的场景下才会去读数据。实时写入最近生成的数据，无更新：时序数据的写入是实时的，且每次写入都是最近生成的数据，这与其数据生成的特点相关，因为其数据生成是随着时间推进的，而新生成的数据会实时的进行写入。数据写入无更新，在时间这个维度上，随着时间的推进，每次数据都是新数据，不会存在旧数据的更新，不过不排除人为的对数据做订正。

2.1.2、数据查询的特点

按时间范围读取：通常来说，你不会去关心某个特定点的数据，而是一段时间的数据。所以时序数据的读取，基本都是按时间范围的读取。最近的数据被读取的概率高：最近的数据越有可能被读取，以监控数据为例，你通常只会关心最近几个小时或最近几天的监控数据，而极少关心一个月或一年前的数据。多精度查询：按数据点的不同密集度来区分不同的精度，例如若相邻数据点的间隔周期是10秒，则该时序数据的精度就是10秒，若相邻数据点的时间间隔周期是30秒，则该时序数据的精度就是30秒。时间间隔越短，精度越高。精度越高的数据，能够还原的历史状态更细致更准确，但其保存的数据点会越多。这个就好比相机的像素，像素越高，照片越清晰但是相片大小越大。时序数据的查询，不需要都是高精度的，这是实际的需求，也是一种取舍，同样也是成本的考虑。还是拿监控数据举例，通常监控数据会以曲线图的方式展现，由人的肉眼去识别。在这种情况下，单位长度下若展示的数据点过于密集，反而不利于观察，这是实际的需求。而另外一种取舍是，若你查询一个比较长的时间范围，比如是一个月，若查询10秒精度的数据需要返回259200个点，而若查询60秒精度的数据则只要返回43200个点，这是查询效率上的一种取舍。而成本方面的考虑，主要在存储的数据量上，存储高精度的数据需要的成本越高，通常对于历史数据，可以不需要存储很高精度的数据。总的来说，在查询和处理方面，会根据不同长度的时间范围，来获取不同精度的数据，而在存储方面，对于历史的数据，会选择降精度的数据存储。多维分析：时序数据产生自不同的个体，这些个体拥有不同的属性，可能是同一维度的，也可能是不同维度的。还是举个监控的例子，我有个对某个集群上每台机器的网络流量的监控，此时可以查询这个集群下某台机器的网络流量，这是一个维度的查询，而同时还需要查询这个集群总的网络流量，这是另外一个维度的查询。数据挖掘：随着大数据和人工智能技术的发展，在存储、计算能力以及云计算发展的今天，数据的高附加值的挖掘已经不再有一个很高门槛。而时序数据蕴含着很高的价值，非常值得挖掘。表表关联较少：相比于传统的关系型数据库在使用中往往需要各种表间的join *** 作，时序数据的使用往往不需要各种表之间的关联，因为往往设备之间的关系较少

2.1.3、数据储存的特点

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

2.1.4、总结

时序数据有如下几个特点：

基本上是插入 *** 作较多且无更新的需求数据带有时间属性，且数据量随着时间递增插入数据多，每秒钟插入需要可到达千万甚至是上亿的数据量查询、聚合等 *** 作主要针对近期插入的数据时序数据能够还原数据的变化状态可以通过分析过去时序数据的变化、检测现在的变化，以达到预测未来如何变化的目的

时序数据使用需求：

能够按照指标筛选数据能够按照区间、时间范围、统计信息聚合展示数据

时序数据储存需求：

TB级别、PB级别的数据存储需求新数据使用频率高，旧频率使用频率低多精度储存

2.2、关系型数据库面临的挑战

关于为什么我们需要时序数据库，这就必须要从现有的数据库在工业互联网场景下的使用瓶颈说起。从2.1小节总结的时序数据库的特点来看，目前的关系型数据库对于时序数据的使用瓶颈主要集中在海量数据的IO *** 作上。

对于MySQL型的关系型数据库，其在时序场景下有以下问题：

存储成本大：对于时序数据压缩不佳，需占用大量机器资源；维护成本高：单机系统，需要在上层人工的分库分表，维护成本高；写入吞吐低：单机写入吞吐低，很难满足时序数据千万级的写入压力；查询性能差：适用于交易处理，海量数据的聚合分析性能差。

而Hadoop、Spark等大数据软件在应对时序数据时，往往会面临：

数据延迟高：离线批处理系统，数据从产生到可分析，耗时数小时、甚至天级；查询性能差：不能很好的利用索引，依赖MapReduce任务，查询耗时一般在分钟级。

因此，一个好的时序数据库应该解决以下问题：、

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

更多地关于时序数据库的底层原理或架构的信息可以参考文章：时序数据库介绍和使用，本文不再多做重复性的介绍工作。

3、热门的时序数据库介绍 3.1、Apache系

关于为什么要分一个Apache系，主要是目前对开源比较感兴趣，就专门开了一个，欢迎大家多多关注开源的中国项目，也顺便为自己引个流：盘点2021年Apache年报中出现的国产项目

3.1.1、Apache Druid

Watch: 621
Fork: 3.1k
Star: 11.5k
GitHub链接：Apache IoTDB

Druid is a high performance real-time analytics database. Druid’s main value add is to reduce time to insight and action.

Druid is designed for workflows where fast queries and ingest really matter. Druid excels at powering UIs, running operational (ad-hoc) queries, or handling high concurrency. Consider Druid as an open source alternative to data warehouses for a variety of use cases. The design documentation explains the key concepts.

Druid是一个数据库连接池。Druid是目前最好的数据库连接池，在功能、性能、扩展性方面，都超过其他数据库连接池，包括DBCP、C3P0、BoneCP、Proxool、JBoss DataSource。Druid已经在阿里巴巴部署了超过600个应用，经过一年多生产环境大规模部署的严苛考验。Druid是阿里巴巴开发的号称为监控而生的数据库连接池！

有关于Druid，在GitHub上还有一个阿里的仓库，有兴趣可以点击Alibaba/Druid

关于Druid的内容，有兴趣可以点击：
Alibaba/Druid中文文档
Druid是什么和Druid的介绍

3.1.2、Apache IoTDB

Watch: 86
Fork: 531
Star: 1.7k
GitHub链接：Apache IoTDB
IoTDB (Internet of Things Database) 是一款时序数据库管理系统，可以为用户提供数据收集、存储和分析等服务。IoTDB由于其轻量级架构、高性能和高可用的特性，以及与 Hadoop 和 Spark 生态的无缝集成，满足了工业 IoT 领域中海量数据存储、高吞吐量数据写入和复杂数据查询分析的需求。

有意思的是，Apache IoTDB是国内清华大学软件学院自己孵化出来的国内的第一个高校开源项目，在CSDN上搜索时序数据库时搜索到了这样一篇文章：博士五年，我在清华做时序数据库，有兴趣的朋友可以看一看还是挺有意思的，希望我们国内的开源软件与底层软件可以做得越来越好

IoTDB的主要特点如下:

灵活的部署策略。IoTDB为用户提供了一个在云平台或终端设备上的一键安装工具，以及一个连接云平台和终端上的数据的数据同步工具。硬件成本低。IoTDB可以达到很高的磁盘存储压缩比。高效的目录结构。IoTDB支持智能网络设备对复杂时间序列数据结构的高效组织，同类设备对时间序列数据的组织，海量复杂时间序列数据目录的模糊搜索策略。高吞吐量读写。IoTDB支持数以百万计的低功耗设备的强连接数据访问、高速数据读写，适用于上述智能网络设备和混合设备。
-丰富的查询语义。IoTDB支持跨设备和测量的时间序列数据的时间对齐、时间序列字段的计算(频域转换)和时间维度的丰富聚合函数支持。学习成本非常低。IoTDB支持类似sql的语言、JDBC标准API和易于使用的导入/导出工具。与先进的开放源码生态系统的无缝集成。IoTDB支持分析生态系统，如Hadoop、Spark和可视化工具(如Grafana)。

有关IoTDB的最新信息，请访问IoTDB官方网站。如果您在使用IoTDB时遇到任何问题或发现任何bug，请在[jira]中提交(https://issues.apache.org/jira/projects/IOTDB/issues)。

关于Apache IoTDB的更多内容可以参考

Apache IoTDB中文官方文档Apache IoTDB深度用户主页：分享了很多Apache IoTDB的使用教程，好用！开源工业物联网数据库 Apache IoTDB 毕业成为 Apache 顶级项目！

3.2、非Apache系 3.2.1、InfluxDB

Watch: 750
Fork: 3.1k
Star: 22.7k
GitHub链接：InfluxDB
InfluxDB是目前为止时序数据库中最热门的产品，是一个开源分布式时序、事件和指标数据库。使用 Go 语言编写，无需外部依赖。其设计目标是实现分布式和水平伸缩扩展。

官方介绍文档如下： InfluxDB is an open source time series platform. This includes APIs for storing and querying data, processing it in the background for ETL or monitoring and alerting purposes, user dashboards, and visualizing and exploring the data and more. The master branch on this repo now represents the latest InfluxDB, which now includes functionality for Kapacitor (background processing) and Chronograf (the UI) all in a single binary.

主要特性：

内置HTTP接口，使用方便数据可以打标记，查让查询可以很灵活类SQL的查询语句安装管理很简单，并且读写数据很高效能够实时查询，数据在写入时被索引后就能够被立即查出

关于Influx的特性，可以参考以下Blog或链接
InfluxDB官方文档
InfluxDB中文使用文档
CSDN社区优秀的学习使用笔记

3.2.2、Kdb+

非开源系统
发布时间长
kdb+/q号称是世界上最快的内存数据库，它使用统一的数据库处理实时数据和历史数据，同时具备CEP(复杂事件处理)引擎、内存数据库、磁盘数据库等功能。与一般数据库或大数据平台相比，kdb+/q具有更快的速度和更低的总拥有成本，非常适合海量数据处理，主要被用于海量数据分析、高频交易、人工智能、物联网等领域。