时序数据库influxdb Spring Boot中使用时序数据库InfluxDB

很多朋友对于时序数据库influxdb和Spring Boot中使用时序数据库InfluxDB不太懂，今天就由小编来为大家分享，希望可以帮助到大家，下面一起来看看吧！

Spring Boot中使用时序数据库InfluxDB

除了最常用的关系数据库和缓存之外，之前我们已经介绍了在Spring Boot中如何配置和使用 MongoDB、 LDAP这些存储的案例。接下来，我们继续介绍另一种特殊的数据库：时序数据库InfluxDB在Spring Boot中的使用。

什么是时序数据库？全称为时间序列数据库。时间序列数据库主要用于指处理带时间标签（按照时间的顺序变化，即时间序列化）的数据，带时间标签的数据也称为时间序列数据。时间序列数据主要由电力行业、化工行业等各类型实时监测、检查与分析设备所采集、产生的数据，这些工业数据的典型特点是：产生频率快（每一个监测点一秒钟内可产生多条数据）、严重依赖于采集时间（每一条数据均要求对应唯一的时间）、测点多信息量大（常规的实时监测系统均有成千上万的监测点，监测点每秒钟都产生数据，每天产生几十GB的数据量）。虽然关系型数据库也可以存储基于时间序列的数据，但由于存储结构上的劣势，使得这些数据无法高效地实现高频存储和查询统计，因此就诞生了一种专门针对时间序列来做存储和优化的数据库，以满足更高的效率要求。(参考：百度百科：时序数据库https://baike.baidu.com/item/%E6%97%B6%E5%BA%8F%E6%95%B0%E6%8D%AE%E5%BA%93/922671）

InfluxDB就是目前比较流行的开源时序数据库（官网地址：https://www.influxdata.com/），我们比较常见的使用场景就是一些与时间相关的高频的数据记录和统计需要，比如：监控数据的存储和查询。

在进行下面的动手环节之前，先了解一下InfluxDB中的几个重要名词：

其中，一个Point由三个部分组成：

在了解了什么是时序数据库以及InfluxDB一些基础概念之后，下面我们通过一个简单的定时上报监控数据的小案例，进一步理解InfluxDB的基础配置、数据组织和写入操作！

第一步：创建一个基础的Spring Boot项目（如果您还不会，可以参考这篇文章：快速入门（https://blog.didispace.com/spring-boot-learning-21-1-1/）

第二步：在 pom.xml中引入influx的官方SDK

注意：这里因为Spring Boot 2.x版本的parent中有维护InfluxDB的SDK版本，所以不需要手工指明版本信息。如果使用的Spring Boot版本比较老，那么可能会缺少version信息，就需要手工写了。

第三步：配置要连接的influxdb信息

三个属性分别代表：连接地址、用户名、密码。到这一步，基础配置就完成了。

注意：虽然没有spring data的支持，但spring boot 2.x版本中也实现了InfluxDB的自动化配置，所以只需要写好配置信息，就可以使用了。具体配置属性可以查看源码： org.springframework.boot.autoconfigure.influx.InfluxDbProperties。

第四步：创建定时任务，模拟上报数据，并写入InfluxDB

第一步：启动InfluxDB，并通过命令行准备好要使用的数据库，主要涉及的命令如下；

第二步：启动Spring Boot应用，在定时任务的作用下，我们会看到类似下面的日志：

第三步：通过命令，查看一下InfluxDB中是否已经存在这些数据

可以看到，已经存在与日志中一样的数据了。

本文的完整工程可以查看下面仓库中 2.x目录下的 chapter6-3：

再不懂时序就OUT啦!阿里云数据库InfluxDB正式商业化

阿里云数据库 InfluxDB®版已于近日正式启动商业化。云数据库 InfluxDB®是基于当前最流行的开源数据库 InfluxDB提供的在线数据库服务，相比较开源具有免运维，稳定可靠，可弹性伸缩的优势，广泛应用于互联网基础资源监控，容器监控，业务运营监控分析，物联网设备远程实时监控，工业安全生产监控，生产质量评估和故障回溯。提供时序数据自动化采集，压缩存储，类SQL查询，多维聚合计算和数据可视化分析能力。点击关注，InfluxDB商业化活动

时序数据和企业业务密切相关，不可或缺。任何一家企业都需要一套高效的运维系统保证实时发现应用和业务问题，通过监控，故障告警的手段，进行故障定位，保证在线业务的稳定，减少不可用时常。业务运营人员依赖运营系统，保证有充足的数据进行业务分析判断，便于更准确的做出业务决策。物联网企业和工业企业都需要能够实时掌握设备的运行状态，对生产过程进行监控，实时判故障预警，故障定位，故障回溯以及业务。以上业务场景都需要时序数据作为“数据证据”来表示指标“变化”过程，进而达到告警，诊断，修复和预测的业务目的。

时序数据很简单，构成具有三个要素，主体，时间戳，和指标数据。比如： xxx公司（主体）2019年8月26日上午10时，11时， 12时（时间戳）的股价分别是：160 USD，165 USD，180 USD（指标值）。概括来说，区别于关系数据库关心的是“最终结果”。时序数据表示的是资产或者过程是如何随着时间变化的，体现的是“变化”的过程价值。

时序数据主要应用在：运维监控，运营分析，设备监控，BI分析，工业安全生产监控场景。这些场景上，产生的核心数据是时序数据，业务特征表现在写多读少，无事务性要求，数据分析强关联时间维度，且实时性要求高。

时序数据库针对时序数据业务特征进行针对性的数据存储结构设计，以及存储方式的优化，在监控等时序业务场景下数据的写入，读取，分析能力相比较传统的关系型数据库如 MySQL，具有百倍的性能提升。

从数据存储架构上看，关系数据库通常按照行来记录一条时间记录数据，且顺序记录之间无主体关联性，单个主体的记录数据随机分散在多行，如果是分布式数据库甚至分布在多个分分库上，记录之间也没有时间顺序组织数据，连续时间戳的数据，分散在不连续的存储上，这样就造成按照主体和时间维度的数据写入和存储的效率大大降低。

而时序数据库按照主体为维度进行数据存储和索引，完全按照业务使用场景组织数据，相同主体指标数据组织在一起，并且按照时间为度进行分片存储，只需要获取主体信息和时间分片信息就可以顺序进行写入和读取操作。单次IO请求磁盘寻道的时间和获取数据量比关系数据库寻道的效率和获取数据量都要高，查询的时间区间越大，查询主体越多，数据越多，效率差异越大，整体性能比关系数据库要高出十倍甚至百倍。

云InfluxDB®相比较开源InfluxDB优势明显。云InfluxDB提供云服务的方式，有行业顶级的专家支持服务，具有免安装，免运维，稳定性高，数据高可靠的优势。使用云存储的方案，数据多副本存储，数据可靠性达到99.9999%。

自建快速迁移上云

云 InfluxDB提供了快速迁云的工具，只需动动鼠标就可以完成自建InfluxDB到云 InfluxDB的迁移。

类SQL开发友好，快速上手

阿里云 InfluxDB完全兼容开源 InfluxDB，面向开发友好，为了方便传统关系数据库开发者能够快速适应Influx DB开发，提供给了类 SQL的查询语言 InfluxQL，在提供强大的时序分析能力的基础上，最大程度的沿用了SQL的开发模式，使得学习成本大大降低。

集成数据采集，搭建监控更简单

阿里云数据库 InfluxDB继承了 Influx DB良好的开源生态，具有完整的数据采集，存储和数据可视化监控告警体系 TICK Stack支撑。同时相比较开源产品，提供了产品化的数据采集服务，只需在控制台进行几步简单操作，“0”代码完成各类监控源的监控数据自动采集。

云InfluxDB®金融高可用版即将推出

服务的高可靠和数据一致性对金融类企业至关重要，开源的InfluxDB没有提供高可靠的HA版本，阿里云InfluxDB针对金融，保险，银行，涉及数据和服务高可靠的研发了 HA高可用版本，目前正在商业化上线的过程中，不久就可上线提供服务。

云InfluxDB®商业化限时优惠

几个时序数据库

================================

可用作时序的数据库:

================================

[时序]TimescaleDB,基于 PostgreSQL,支持 SQL.

[时序]KairosDB,基于 Cassandra,不支持 SQL.

[通用]CrateDB,基于 Elastic Search,但支持ANSI SQL

[时序]InfluxDB,是 db-engines上排名第一的时序数据库,最新版中集群功能不开源了,商业版支持,另外并发查询性能较差.

[通用]Kudu,列式存储(类parquet),支持 java API更新数据,比较赞的是支持 upsert.可以通过 impala或 spark来支持SQL查询.

简单点评(基于底层技术做的点评,未做个实际测试)

TimescaleDB基于PostgreSQL,可能适合数据量不太大的情形,但提供丰富的SQL功能

KairosDB,基于 Cassandra,运维应该比较简单,扩展性也应该不错,写入性能估计要比 CrateDB差一些,另外不支持SQL.

CrateDB基于 Elastic Search,写入性能应该很好,扩展性也应该不错,估计 SQL支持度和读取性能会差一些,支持全文检索.

db-engines网站的对比:

https://db-engines.com/en/system/CrateDB%3BKairosDB%3BTimescaleDB

Crate官方的比较:

http://go.cratedb.com/rs/832-QEZ-801/images/CrateDB-Cassandra-MongoDB-Comparison.pdf

================================

支持SQL的流处理框架

================================

多数流处理方案中,数据一般都会暂存在 kafka中,格式推荐使用 Json/Avro, schema推荐使用 Oracle Goldgate(OGG)数据格式.

支持SQL的流处理框架有:

1. Spark Streaming:可以写很复杂的SQL,比如和其他数据库DB做 join.

2. Kafka的 KSQL:和Kafka公用集群,不需要额外计算集群.

3. PipelineDB:基于 PostgreSQL的扩展, cluster版需要付费.流数据既可以直接写到 pipelinedb(以pipelinedb的FOREIGN TABLE形式暂存流数据),然后通过 pipelinedb SQL来处理;流数据也可以先打到kafka中,然后再通过 pipelinedb extension来处理.

几个时序数据库

标签：streaming格式新版mongod运维spark流处理处理cassandra

好了，文章到此结束，希望可以帮助到大家。