InfluxDB时序数据库的安装使用教程1（基本介绍）

InfluxDB时序数据库的安装使⽤教程1（基本介绍）
⼀、基本介绍
1，时序数据介绍
（1）时间序列数据（Time Series Data，TSD，以下简称时序）从定义上来说，就是⼀串按时间维度索引的数据。

（2）简单的说，就是这类数据描述了某个被测量的主体在⼀个时间范围内的每个时间点上的测量值。

它普遍存在于 IT 基础设施、运维监控系统和物联⽹中。

2，时序数据库介绍
（1）时序数据库产品的发明都是为了解决传统关系型数据库在时序数据存储和分析上的不⾜和缺陷，这类产品被统⼀归类为时序数据库（TSDB）
（1）在传统关系型数据库上加上时间戳⼀列并不能真正作为时序数据库。

因为时序数据往往是由百万级甚⾄千万级终端设备产⽣的，写⼊并发量⽐较⾼，属于海量数据场景。

此时传统关系型数据库就会出现问题。

（2）MySQL 在海量的时序数据场景下存在如下问题：
存储成本⼤：对于时序数据压缩不佳，需占⽤⼤量机器资源；
维护成本⾼：单机系统，需要在上层⼈⼯的分库分表，维护成本⾼；
写⼊吞吐低：单机写⼊吞吐低，很难满⾜时序数据千万级的写⼊压⼒；
查询性能差：适⽤于交易处理，海量数据的聚合分析性能差。

（3）另外，使⽤ Hadoop ⽣态（Hadoop、Spark 等）存储时序数据会有以下问题：
数据延迟⾼：离线批处理系统，数据从产⽣到可分析，耗时数⼩时、甚⾄天级；
查询性能差：不能很好的利⽤索引，依赖 MapReduce 任务，查询耗时⼀般在分钟级。

（2）时序数据库时序数据的特点对写⼊、存储、查询等流程进⾏了优化，具体特点如下：
数据压缩存储：利⽤时间递增、维度重复、指标平滑变化的特性，合理选择编码压缩算法，提⾼数据压缩⽐；通过预降精度，对历史数据做聚合，节省存储空间。

⾼并发写⼊：批量写⼊数据，降低⽹络开销；数据先写⼊内存，再周期性的 dump 为不可变的⽂件存储。

低查询延时，⾼查询并发：优化常见的查询模式，通过索引等技术降低查询延时；通过缓存、routing 等技术提⾼查询并发。

（3）⽬前⾏业内⽐较流⾏的开源时序数据库产品有 InfluxDB、OpenTSDB、Prometheus、Graphite 等，其产品特性对⽐如下图所⽰：3，InfluxDB 介绍
（1）InfluxDB 是⼀个开源分布式时序、时间和指标数据库，使⽤ Go 语⾔编写，⽆需外部依赖。

其设计⽬标是实现分布式和⽔平伸缩扩展，是 InfluxData 的核⼼产品。

注意：InfluxDB 不是⼀个完整的 CRUD 数据库，它更像是⼀个 CR-ud 数据库。

它优先考虑的是增加和读取数据⽽不是更新和删除数据的性能，⽽且它阻⽌了某些更新和删除⾏为使得创建和读取数据更加⾼效。

（2）InfluxDB ⾃带的各种特殊函数如求标准差，随机取样数据，统计数据变化⽐等，使数据统计和实时分析变得⼗分⽅便。

此外它还有如下特性：
内置 HTTP 接⼝，使⽤⽅便
数据可以打标记，这样查询可以很灵活
类 SQL 的查询语句
安装管理很简单，并且读写数据很⾼效
能够实时查询，数据在写⼊时被索引后就能够被⽴即查出
（3）InfluxDB 常⽤于性能监控，应⽤程序指标，物联⽹传感器数据和实时分析等的后端存储。

4，InfluxDB 基本概念
（1）database
database类似传统数据库中的数据库概念。

⼀个数据库可以有多个measurement，retention policy，continuous queries 以及 user。

（2）measurement
measurement类似传统数据库中的表概念。

measurement是fields，tags以及time列的容器，measurement的名字⽤于描述存储在其中的字段数据，类似 mysql 的表名。

（3）point
point 类似传统数据库中表中的⼀⾏数据
point 的数据结构由时间戳（time）、标签（tags）、数据（fields）三部分组成
（4）timestamp
既然是时间序列数据库，influxdb的数据都有⼀列名为time的列，⾥⾯存储UTC时间戳。

（5）field key、field value、field set
field为字段，在 influxdb中，字段必须存在（即数量必须 >=1）。

注意，字段是没有索引的。

如果使⽤字段作为查询条件，会扫描符合查询条件的所有字段值，性能不及tag。

其中field key为字段名，field value为字段值，field value可以为 string，float，integer或 boolean类型
field key和field value对组成的集合称之为field set
（6）tag key、tag value、tag set
tag为标签，在 InfluxDB中可以没有 tag（即数量 >=0）。

不同于field，tag是有索引的。

其中tag key为标签名，tag value为标签值，tag value只能是 string 类型
tag key 和 tag value 对组成的集合称之为 tag set
（7）retention policy
retention policy 指数据保留策略（更详细介绍可以看本⽂下⽅附录部分）。

measurement 默认会有⼀个autogen的保留策略，autogen中的数据永不删除且备份数replication为 1（只有⼀份数据，在集群中起作⽤）。

（8）series
series 相当于是 InfluxDB 中⼀些数据的集合，在同⼀个database中，retention policy、measurement、tag sets完全相同的数据同属于⼀个 series
同⼀个series 的数据在物理上会按照时间顺序排列存储在⼀起。

附：InfluxDB 保留策略（retention policy）
（1）每个数据库刚开始会⾃动创建⼀个默认的存储策略 autogen，数据保留时间为永久，在集群中的副本个数为 1。

（2）插⼊和查询数据时如果不指定存储策略，则使⽤默认存储策略，且默认存储策略可以修改。

（3）⽤户可以⾃⼰设置保留策略（查看、新建、修改、删除），例如保留最近 2 ⼩时的数据。

InfluxDB 会定期清除过期的数据。

（4）建议在数据库建⽴的时候设置存储策略，不建议设置过多且随意切换
create database testdb2 with duration 30d
（5）每个数据库可以有多个过期策略，使⽤如下语句查看：
show retention policies on "db_name"
（6）Shard在influxdb中是⼀个⽐较重要的概念，它和retention policy相关联：
每⼀个存储策略下会存在许多shard，每⼀个 shard 存储⼀个指定时间段内的数据，并且不重复，例如7点 - 8点的数据落
⼊shard0中，8点 - 9点的数据则落⼊ shard1中。

每⼀个shard 都对应⼀个底层的tsm存储引擎，有独⽴的cache、wal、tsm file。

这样做的⽬的就是为了可以通过时间来快速定位到要查询数据的相关资源，加速查询的过程，并且也让之后的批量删除数据的操作变得⾮常简单且⾼效。