influxdb时序型数据库基础

什么是InfluxDB

InfluxDB是一个开源的、高性能的时序型数据库，在时序型数据库DB-Engines Ranking上排名第一。

在介绍InfluxDB之前，先来介绍下时序数据。按照时间顺序记录系统、设备状态变化的数据被称为时序数据（Time Series Data），如CPU利用率、某一时间的环境温度等。

时序数据以时间作为主要的查询纬度，通常会将连续的多个时序数据绘制成线，制作基于时间的多纬度报表，用于揭示数据背后的趋势、规律、异常，进行实时在线预测和预警，时序数据普遍存在于IT基础设施、运维监控系统和物联网中。随着物联网时代的到来，时序数据的数据量呈井喷式爆发，针对于这一数据细分的优化存储显得越来越重要。

对于传统关系型数据库，增删改查应该是必备且常用的功能，而influxdb常用的只有insert和select，没有提供update语法，虽然有delete可以删除数据（delete语法和mysql相似），但是需求不大。

因为存储的数据都是跟时间有关的测量数值，多用于图表展示，不太需要人为的去删除，而有时统计的数据是秒级，甚至毫秒级、纳秒级的，势必造成数据量巨大。如果一直长久存储会占用机器大量资源，而且有些数据越旧越失去它的时效性，越没有参考价值，所以保留策略retention policy就是可以让数据存储一段时间后自动清除。

时序数据特点

时序数据有这几个属性：

度量的数据集（measurement），类似于关系型数据库中的 table；

一个数据点（point），类似于关系型数据库中的 row；

时间戳（timestamp），表征采集到数据的时间点；

维度列（tag），代表数据的归属、属性，表明是哪个设备/模块产生的，一般不随着时间变化，供查询使用；

指标列（field），代表数据的测量值，随时间平滑波动。

常见应该场景

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

举例：

监控软件系统： 虚拟机、容器、服务、应用

监控物理系统： 水文监控、制造业工厂中的设备监控、国家安全相关的数据监控、通讯监控、传感器数据、血糖仪、血压变化、心率等

资产跟踪应用： 汽车、卡车、物理容器、运货托盘

金融交易系统： 传统证券、新兴的加密数字货币

事件应用程序： 跟踪用户、客户的交互数据

商业智能工具： 跟踪关键指标和业务的总体健康情况

在互联网行业中，也有着非常多的时序数据，例如用户访问网站的行为轨迹，应用程序产生的日志数据等等

时序数据库解决什么问题

传统数据库通常记录数据的当前值，时序型数据库则记录所有的历史数据，在处理当前时序数据时又要不断接收新的时序数据，同时时序数据的查询也总是以时间为基础查询条件，并专注于解决以下海量数据场景的问题：

• 专为时序存储和高性能读写而设计：计算机虚拟世界的各种系统和应用，以及物理世界的IoT设备等都在创建海量的时序数据，每秒千万级的数据吞吐量是很常见的，而且这些数据还需要可以以非阻塞方式接收并且可压缩以节省有限的存储资源。如何支持千万级/秒数据的写入。如何支持千万级/秒数据的聚合和查询。
• 专为实时操作而设计：预测能力和实时决策能力，需要收到数据后，就能实时输出最新的数据分析结果，执行预定义的操作。
• 专为高可用性而设计：现代软件系统需要全天候可用，除了基本的集群能力，还需要根据需求自动扩容和缩容，支持柔性可用等。
• 成本敏感：海量数据存储带来的是成本问题，如何更低成本存储这些数据是时序型数据库需要解决的关键问题。

InfluxDB的优势

InfluxData选择从头开始构建InfluxDB以支持下一代时序中台的需求，InfluxDB通过实现高度可扩展的数据接收和存储引擎，可以高效地实时收集、存储、查询、可视化显示和执行预定义操作。

它通过连续查询提升查询效率和缩短延迟，通过数据保留策略，及时高效地删除过期冷数据，提升存储效率。

为什么通用数据库在时序场景上不是最优的选择呢？许多通用数据库正在为时序数据添加一些支持，虽然可能很容易使用，但它们基本上都不是针对海量时序数据的吞吐量和实时操作而设计的。

与InfluxDB相比，通用数据库，如Cassandra、MongoDB、HBase等，需要开发人员投入大量的时间进行代码编写，以开发与InfluxDB类似的功能。具体来说，开发人员需要做如下工作：

编写代码实现跨集群数据分片功能、聚合运算和采样功能、数据生命周期管理功能等。
实现丰富的API接口。
编写用于数据采集的工具。
实现实时处理模块并编写用于监控和警报的代码。
编写可视化引擎以向用户显示时序数据。

InfluxDB常用命令

# ==================数据库操作==================
create database db_name
show databases
drop database db_name
use db_name
show  measurements

# ==================数据库策略操作==================
show retention policies on device_ea
# ===创建===
CREATE RETENTION POLICY <retention_policy_name> ON <database_name> 
DURATION <duration> REPLICATION <n> [SHARD DURATION <duration>] [DEFAULT]
# 为monitor库创建一个数据保留时长30天的rp，同时设置shard duration为1d，副本为1，并设置为默认rp
create retention policy rp_30_days on monitor duration 30d replication 1 shard duration 1d default
# 为monitor库创建一个数据保留时长一个星期的rp，副本为1
create retention policy rp_one_week on monitor duration 1w  replication 1
# ===修改===
# 修改rp_1_week 保留数据时长为15days 
alter retention policy rp_1_week on monitor duration 15d replication 1 default 
# 设置rp_30_days为默认rp
alter retention policy rp_30_days on monitor default 
# ===删除===
# 删除名为rp_1_week的rp
drop retention policy rp_1_week on monitor

# ==================插入操作==================
# 在没有use 哪个db的时候需要指定db,选择monitor数据库，指定rp为rp_3_days写入数据到service_qps
insert into monitor.rp_3_days service_qps,svrName=TaskSvr,hostName=dev4 qps=12.9
# 切换选择monitor
use monitor
# 并指定rp为rp_3_days写入数据到service_qps
insert into rp_3_days service_qps,svrName=TaskSvr,hostName=dev4 qps=12.9
# 【完全错误的写法】
insert rp_3_days.service_qps,svrName=TaskSvr,hostName=dev4 qps=12.9


# ==================查询操作==================
# 默认指定默认RP
select  *  from  service_qps
# 指定RP查询
select  *  from  rp_3_days.service_qps

参考：

https://www.freesion.com/article/53171426136/#retention_policy_40

https://blog.csdn.net/qq355972697/article/details/129775503