以下内容来自 尚硅谷,写这一系列的文章,主要是为了方便后续自己的查看,不用带着个PDF找来找去的,太麻烦!
第 1 章 认识InfluxDB
1.1 InfluxDB的使用场景
-
InfluxDB是一种时序数据库,时序数据库通常被用在监控场景,比如运维和 IOT(物联网)领域。这类数据库旨在存储时序数据并实时处理它们。
-
比如,我们可以写一个程序将服务器上CPU的使用情况每隔 10 秒钟向InfluxDB中写入一条数据。接着,我们写一个查询语句,查询过去 30 秒CPU的平均使用情况,然后让这个查询语句也每隔 10 秒钟执行一次。最终,我们配置一条报警规则,如果查询语句的执行结果>xxx,就立刻触发报警。
-
上述就是一个指标监控的场景,在IOT领域中,也有大量的指标需要我们监控。比如,机械设备的轴承震动频率,农田的湿度温度等等。
1.2 为什么不用关系型数据库
1.2.1 写入性能
-
关系型数据库也是支持时间戳的,也能够基于时间戳进行查询。但是,从我们的使用场景出发,需要注意数据库的写入性能。通常,关系型数据库会采用B+树数据结构,在数据写入时,有可能会触发叶裂变,从而产生了对磁盘的随机读写,降低写入速度。
-
当前市面上的时序数据库通常都是采用LSM Tree的变种,顺序写磁盘来增强数据的写入能力。网上有不少关于性能测试的文章,大家可以自己去参考学习,通常时序数据库都会保证在单点每秒数十万的写入能力。
1.2.2 数据价值
- 我们之前说,时序数据库一般用于指标监控场景。这个场景的数据有一个非常明显的特点就是冷热差别明显。通常,指标监控只会使用近期一段时间的数据,比如我只查询某个设备最近 10 分钟的记录, 10 分钟前的数据我就不再用了。那么这 10 分钟前的数据,对 我们来说就是冷数据,应该被压缩放到磁盘里去来节省空间。而热数据因为经常要用,数据库就应该让它留在内存里,等待查询。而市面上的时序数据库大都有类似的设计。
1.2.3 时间不可倒流,数据只写不改
-
时序数据是描述一个实体在不同时间所处的不同状态。
-
就像是我们打开任务管理器,查看CPU的使用情况。我发现CPU占用率太高了,于是杀死了一个进程,但 10 秒前的数据不会因为我关闭进程再发生改变了。
-
这是时序数据的一大特点。与之相应,时序数据库基本上是插入操作较多,而且还没有什么更新需求。
1.3 1.X版本的TICK技术栈与 2 .X版本的进一步融合
-
根据上文的介绍,我们首先可以知道时序数据一般用在监控场景。大体上,数据的应用可以分为 4 步走。
- ( 1 )数据采集
- ( 2 )存储
- ( 3 )查询(包括聚合操作)
- ( 4 )报警
-
这样一看,只给一个数据库其实只能完成数据的存储和查询功能,上游的采集和下游的报警都需要自己来实现。因此InfluxData在InfluxDB1.X的时候推出了TICK生态来推出start全套的解决方案。
-
TICK 4 个字母分别对应 4 个组件。
⚫ T : Telegraf - 数据采集组件,收集&发送数据到InfluxDB。
⚫ I : InfluxDB - 存储数据&发送数据到Chronograf。
⚫ C : Chronograf - 总的用户界面,起到总的管理功能。
⚫ K : Kapacitor - 后台处理报警信息。 -
到了 2 .x,TICK进一步融合,ICK的功能全部融入了InfluxDB,仅需安装InfluxDB就能得到一个管理页面,而且附带了定时任务和报警功能。
1.4 influxDB版本比较与选型
1.4.1 版本特性比较
-
2020 年InfluxDB推出了 2 .0的正式版。 2 .x同 1 .x相比,底层引擎原理相差不大,但会涉及一些概念的转变(例如db/rp换成了org/bucket)。另外,对于TICK生态来说, 1 .x需要自己配置各个组件。2.x则是更加方便集成,有很棒的管理页面。
-
另外,在查询语言方面,1.x是使用InfluxQL进行查询,它的风格近似SQL。2.x推出了FLUX查询语言,可以使用函数与管道符,是一种更符合时序数据特性的更具表现力的查询语言。
1.4.2 选型(本文档使用InfluxDB 2. 4)
-
市场现状:目前企业里面用 InfluxDB 1.X 和 InfluxDB 2.X 都有人在用,数量上InfluxDB1.X 占多一些。
-
易用性:在开发中,InfluxDB 1.X集成生态会比较麻烦,InfluxDB 2.X相对来说更加便利。
-
性能:InfluxDB 1.X和 2 .X的内核原理基本一致,性能上差距不大。
-
集群:InfluxDB从 0 .11版本开始,就闭源了集群功能的代码。也就是说,你只能免费试用InfluxDB的单节点版(开源),想要集群等功能就需要购买企业版。不过就InfluxDB 1.8来说,有开源项目根据 0. 11 的代码思路提供了InfluxDB开源的集群方案。也
有开源项目给InfluxDB 2. 3 增加了反向代理功能,让我们可以横向拓展InfluxDB的服务能
力。项目参考地址:
项目 | 地址 |
---|---|
InfluxDB Cluster | 对应 1.8.10:https://github.com/chengshiwen/influxdb-cluster |
InfluxDB Proxy | 对应 1.2 - 1.8:https://github.com/chengshiwen/influx-proxy |
InfluxDB Proxy | 对应 2.3:https://github.com/chengshiwen/influx-proxy/tree/influxdb-v |
-
FLUX语言支持:自InfluxDB 1.7 和 InfluxDB 2.0以来,InfluxDB推出了一门独立的新的查询语言FLUX,而且作为一个独立的项目来运作。InfluxData公司希望FLUX语言能够成为一个像SQL一样的通用标准,而不仅仅是查询InfluxDB的特定语言。而且不管是你是选择InfluxDB 1.X 还是 2.X 最终都会接触到FLUX。不过2.X 对FLUX的支持性要更好一些。
-
InfluxDB产品概况:
- InfluxDB 1.8 在小版本上还在更新,主要是修复一些BUG,不再添加新特性
- InfluxDB 2. 4 这是InfluxDB较新的版本,仍然在增加新的特性。
- InfluxDB 企业版 1.9 需要购买,相比开源版,它有集群功能。
- InfluxDB Cloud,免部署,跑在InfluxData公司的云服务器上,你可以使用客户端来操作。功能上对应开源版的 2. 4
-
2 .x 与 1.x的主要区别:两个版本的内核原理基本一致,性能上的差别不大。差别主要是在,权限管理方式不同, 2 .x TICK的集成性比 1 .x好, 1 .x中的database到了 2 .x中变成了bucket等。
-
最终,本文选择 Influx 2. 4 来进行写作,学会使用 InfluxDB 2. 4 后应当也能知道 InfluxDB 1.7及以上版本的开发。写作过程遇到与InfluxDB1.8不同的地方,会做一些提醒。