influxdb 基础理论知识（一）

一.influxdb是什么

1.1 概述

ime series database (TSDB) 时序数据库

influxdb是一个分布式的时序数据库，它使用Go语言编写的一个开源分布式时序、事件和指标数据库，无需外部依赖。类似的数据库有Elasticsearch、Graphite等。

1.时序数据库是一种随着时代演化，数据量大量增加的情况出现的数据库，时序数据库更像是之前的关系型数据库和非关系型数据库的结合体，时序数据库不需要严格的数据结构，时序数据库的一种 —

influxDB使用的是类似于SQL 语句的操纵方式，且时序数据库与非关系型数据库都有很强的高并发能力。 

2.时序数据库是基于时间进行存储的一种数据库，每一条数据中都有一个时间戳，因而这种数据库特别适合存储那些随着时间变化的数据，通过一些工具处理后，能够分析出数据随时间变化的趋势。

3.时序数据库相较关系型数据库的变化，底层的存储结构不同，关系型数据库使用的是B+ 树存储结构，而时序数据库使用的是LSM存储结构，能够带来很多好处，一大好处就是支持比关系型数据库甚至比NoSQL大得多的并发量。

influxdb各个字段的组成含义：其中tag字段相当于索引，加快检索，field没有索引，查询时，全盘扫描，效率低

1.2 功能特点

1.基于时间序列，支持与时间有关的相关函数（如最大，最小，求和等）

2.可度量性：你可以实时对大量数据进行计算

3.基于事件：它支持任意的事件数据

4.支持min, max, sum, count, mean, median 等一系列函数，方便统计

5.无结构（无模式）：可以是任意数量的列

6.可拓展的

7.原生的HTTP支持，内置HTTP API

8.强大的类SQL语法

9.自带管理界面，方便使用

1.3 时序数据库应用场景

1.时序数据库最开始应用的地方 – 工业制造，为了高效存储传感器传来的测量数据，监测各项环境变量

2.IoT – 物联网，也就是每个设备都会有一个传感器，搭配上IPv6，每个设备都能传输数据到数据库

3.自动驾驶，与5G搭配，将自动驾驶的海量数据存储到时序数据库

4.监控，运维中对计算机基础设施的监控数据非常多，从网络，数据中心，集群，主机，虚拟机，存储等

5.金融，华尔街还专门开发时序数据库(DolphinDB)存储金融数据，为量化金融的分析统计助力

1.4 常见时序数据库

二 influxdb数据库的概念

2.1 和传统数据库比较

将butterflies、honeybees两个字段设置为tag，而location、scientist设置为field，butterflies honeybees是tag，属于索引，查询大规模数据的时候效率就会提升，字段键(field key) 是没有索引的，在大规模数据查询的时候会扫描全表数据，此时效率就会很低

2.2.series

1.所有在数据库中的数据，都需要通过图表来展示，而这个series表示这个表里面的数据，可以在图表上画成几条线：通过tags排列组合算出来。

2.需要注意的是，influxdb不需要像传统数据库一样创建各种表，其表的创建主要是通过第一次数据插入时自动创建，如下：
insert mytest, server=serverA count=1,name=5 //自动创建表
“mytest”，“server” 是 tags，“count”、“name” 是 fields
fields 中的 value 基本不用于索引

2.3.保留策略

1.每个数据库刚开始会自动创建一个默认的存储策略 autogen，数据保留时间为永久，在集群中的副本个数为1，之后用户可以自己设置（查看、新建、修改、删除），例如保留最近2小时的数据。

2.插入和查询数据时如果不指定存储策略，则使用默认存储策略，且默认存储策略可以修改。InfluxDB 会定期清除过期的数据。

3.每个数据库可以有多个过期策略：show retention policies on "db_name"

4.Shard 在 influxdb中是一个比较重要的概念，它和 retention policy 相关联。每一个存储策略下会存在许多 shard，每一个 shard 存储一个指定时间段内的数据，并且不重复，例如 7点-8点 的数据落入 shard0 中，8点-9点的数据则落入 shard1 中。每一个 shard 都对应一个底层的 tsm 存储引擎，有独立的 cache、wal、tsm file。
这样做的目的就是为了可以通过时间来快速定位到要查询数据的相关资源，加速查询的过程，并且也让之后的批量删除数据的操作变得非常简单且高效。

5.建议在数据库建立的时候设置存储策略，不建议设置过多且随意切换：create database testdb2 with duration 30d

2.4.存储引擎

TSM是在LSM的基础上优化改善的，引入了serieskey的概念，对数据实现了很好的分类组织。
TSM主要由四个部分组成： cache、wal、tsm file、compactor：

cache：插入数据时，先往 cache 中写入再写入wal中，可以认为 cache 是 wal 文件中的数据在内存中的缓存，cache 中的数据并不是无限增长的，有一个 maxSize 参数用于控制当 cache 中的数据占用多少内存后就会将数据写入 tsm 文件。如果不配置的话，默认上限为 25MB

wal：预写日志，对比MySQL的 binlog，其内容与内存中的 cache 相同，作用就是为了持久化数据，当系统崩溃后可以通过 wal 文件恢复还没有写入到 tsm 文件中的数据，当 InfluxDB 启动时，会遍历所有的 wal 文件，重新构造 cache。

tsm file：每个 tsm 文件的大小上限是 2GB。当达到 cache-snapshot-memory-size,cache-max-memory-size 的限制时会触发将 cache 写入 tsm 文件。

compactor：主要进行两种操作，一种是 cache 数据达到阀值后，进行快照，生成一个新的 tsm 文件。另外一种就是合并当前的 tsm 文件，将多个小的 tsm 文件合并成一个，减少文件的数量，并且进行一些数据删除操作。 这些操作都在后台自动完成，一般每隔 1 秒会检查一次是否有需要压缩合并的数据。

2.5 数据目录

influxdb的数据存储有三个目录，分别是meta、wal、data：

meta 用于存储数据库的一些元数据，meta 目录下有一个 meta.db 文件；
wal 目录存放预写日志文件，以 .wal 结尾；
data 目录存放实际存储的数据文件，以 .tsm 结尾。