内容简介:InfluxDB是一个由InfluxData开发的开源时序型数据库。它由Go写成,着力于高性能地查询与存储时序型数据。InfluxDB被广泛应用于存储系统的监控数据,它还是没有额外依赖的开源时序数据库,用于记录 metrics、events,进行数据分析。 何谓时间序列数据库?什么是时间序列数据库,最简单的定义就是数据格式里包含Timestamp字段的数据,比如某一时间环境的温度,CPU的使用率等。 但是,有什么数据不包含Timestamp呢?几乎所有的数据其实都可以打上一个Timestamp字段。时间序列
InfluxDB是一个由InfluxData开发的开源时序型数据库。它由 Go 写成,着力于高性能地查询与存储时序型数据。InfluxDB被广泛应用于存储系统的监控数据,
它还是没有额外依赖的开源时序数据库,用于记录 metrics、events,进行数据分析。 何谓时间序列数据库?
什么是时间序列数据库,最简单的定义就是数据格式里包含Timestamp字段的数据,比如某一时间环境的温度,CPU的使用率等。 但是,有什么数据不包含Timestamp呢?几乎所有的数据其实都可以打上一个Timestamp字段。时间序列数据的更重要的一个属性是如何去查询它,包括数据的过滤,计算等等。 一般时间序列数据都具备如下两个特点:
数据结构简单 数据量大 所谓的结构简单,可以理解为某一度量指标在某一时间点只会有一个值,没有复杂的结构(嵌套、层次等)和关系(关联、主外键等)。
数据量大则是另一个重要特点,这是由于时间序列数据由所监控的大量数据源来产生、收集和发送,比如主机、物联网设备、终端或App等。
一、InfluxDB 简介
InfluxDB主要特色功能 1.基于时间序列,支持与时间有关的相关函数(如最大,最小,求和等)
2.可度量性:你可以实时对大量数据进行计算
3.基于事件:它支持任意的事件数据
InfluxDB的主要特点 1.无结构(无模式):可以是任意数量的列
2.可拓展的
3.支持min, max, sum, count, mean, median 等一系列函数,方便统计
4.原生的HTTP支持,内置HTTP API
5.强大的类 SQL 语法
6.自带管理界面,方便使用
官网文档: docs.influxdata.com/influxdb/v1…
二、InfluxDB安装
本文以操作系统RedHat & CentOS为例,介绍下InfluxDB最新版本的安装。RedHat和CentOS用户可以直接用yum包管理来安装最新版本的InfluxDB。
cat <<EOF | sudo tee /etc/yum.repos.d/influxdb.repo [influxdb] name = InfluxDB Repository - RHEL \$releasever baseurl = https://repos.influxdata.com/rhel/\$releasever/\$basearch/stable enabled = 1 gpgcheck = 1 gpgkey = https://repos.influxdata.com/influxdb.key EOF 复制代码
一旦加到了yum源里面,就可以运行下面的命令来安装和启动InfluxDB服务:
sudo yum install influxdb
目前最新版本为1.7.3-1
三、InfluxDB启动
1.服务端启动 如果是通过包安装的,可以使用如下语句启动:
sudo service influxdb start 这样就启动了服务端
2.客户端 在usr/bin里使用influx即可登入Influx服务器。也可以将路径加入环境变量中,这样既可在任意地方使用influx。
命令启动客户端,如下图:
早期版本的InfluxDB自带web管理界面,在浏览器中输入 http://服务器IP:8083 即可进入web管理页面。
不过从版本1.3开始,Web管理界面在InfluxDB中不再可用。而官方给出使用Chronograf用于查询数据,写入数据和数据库管理的改进 工具 取代了Web管理界面。
后面我们详细介绍一下Chronograf
四、InfluxDB相关操作
1.开启认证
创建管理员
修改配置文件,开启认证
重启InfluxDB:
systemctl restart influxdb
再次登录
客户端工具连接数据库:
注:这里的-precision参数指定了时间戳的格式为rfc3339,也可以不使用该参数。
2.相关概念 influxDB相关名词
database:数据库。
measurement:数据库中的表。它就是tag,field,time的容器;对于influxDB的measurement来说,field是必须的,并且不能根据field来排序;
Tag是可选的,tag可以用来做索引,tag是以字符串的形式存放的。
points:表里面的一行数据。
influxDB中独有的概念
(1)Point由时间戳(time)、数据(field)和标签(tags)组成。
time:每条数据记录的时间,也是数据库自动生成的主索引;
fields:各种记录的值;
tags:各种有索引的属性。
InfluxDB不需要做schema定义,这意味着你可以随意的添加measurements, tags, and fields at any time。
(2)series
所有在数据库中的数据,都需要通过图表来展示,而这个series表示这个表里面的数据,可以在图表上画成几条线:通过tags排列组合算出来。
其实一个series就是一个测点,或者说一条曲线,那么retention policy, measurement, tagset就共同组成了一个定位测点序列的唯一标识。
point,就是某个series的同一个时刻的多个field的value,就组成了一个point;其实就是一条曲线上的一个点。
influxDB与传统数据库中的名词做比较
(3)retention policy
保留策略,用于决定要保留多久的数据,保存几个备份,以及集群的策略等。
3.相关操作
查看数据库:
创建数据库:
使用数据库:
插入数据:
influxDB存储数据采用的是Line Protocol格式。
Line Protocol格式:写入数据库的Point的固定格式。格式如下:
<measurement>[,<tag-key>=<tag-value>...] <field-key>=<field-value>[,<field2-key>=<field2-value>...] [unix-nano-timestamp] 复制代码
比如:
> INSERT cpu,host=serverA,region=us_west value=0.64 复制代码
其中:
cpu是表名
host=serverA,region=us_west 是tag
value=0.64是field
查询数据:
influxDB是支持类sql语句的,具体的查询语法都差不多。
比如:select * from cpu
注:InfluxDB集群功能已经不再开源。要想使用集群服务需要购买企业版。
开源版和企业版的主要区别就是企业版的InfluxDB支持集群,而开源版不支持,此外企业版提供了先进的备份/恢复功能,而开源版本没有。
但InfluxDB单机版性能也足够支撑中小公司的业务了。
4.数据保存策略
InfluxDB每秒可以处理成千上万条数据,要将这些数据全部保存下来会占用大量的存储空间,有时我们可能并不需要将所有历史数据进行存储。
因此,InfluxDB推出了数据保留策略(Retention Policies),用来让我们自定义数据的保留时间。InfluxDB的数据保留策略用来定义数据在InfluxDB中存放的时间,或者定义保存某个期间的数据。
一个数据库可以有多个保留策略,但每个策略必须是独一无二的。
查询策略
可以通过如下语句查看数据库的现有策略:
数据库telegraf只有一个策略,各字段的含义如下:
name:名称,此示例名称为 autogen。当你创建一个数据库的时候,InfluxDB会自动为数据库创建一个名叫 autogen 的策略,这个策略会永久保存数据。你可以重命名这个策略,并且在InfluxDB的配置文件中禁止掉自动创建策略。
duration:数据保存时间,0代表无限制 shardGroupDuration:shardGroup的存储时间,shardGroup是InfluxDB的一个基本储存结构。 replicaN:全称是REPLICATION,副本个数 default:是否是默认策略。 这里有两个概念:
shard:
shard 在 InfluxDB 中是一个比较重要的概念,它和 retention policy(数据保留策略) 相关联。每一个存储策略下会存在许多 shard,每一个 shard 存储一个指定时间段内的数据,
并且不重复,例如 7点-8点 的数据落入 shard0 中,8点-9点的数据则落入 shard1 中。每一个 shard 都对应一个底层的 TSM 存储引擎,有独立的 cache、wal、tsm file。
创建数据库时会自动创建一个默认存储策略,永久保存数据,对应的在此存储策略下的 shard 所保存的数据的时间段为 7 天,也就是上面查询时看到的168h。
如果创建一个新的 retention policy 设置数据的保留时间为 1 天,则单个 shard 所存储数据的时间间隔为 1 小时,超过1个小时的数据会被存放到下一个 shard 中。
shard group:
shard group是shards的逻辑容器。
创建策略
语法:
CREATE RETENTION POLICY <retention_policy_name> ON <database_name> DURATION <duration> REPLICATION <n> [SHARD DURATION <duration>] [DEFAULT] 复制代码
:SHARD DURATION子句决定了每个shard group存储的时间间隔,在永久存储的策略里这个子句是无效的。这个子句是可选的。shard group duration默认由策略的 duration 决定。
示例1:为数据库telegraf创建一个策略
CREATE RETENTION POLICY "one_day_only" ON "telegraf" DURATION 1d REPLICATION 1 复制代码
示例2:为数据库telegraf创建一个默认策略
CREATE RETENTION POLICY "one_day_only" ON "telegraf" DURATION 24h REPLICATION 1 DEFAULT 复制代码
修改策略
语法:
ALTER RETENTION POLICY <retention_policy_name> ON <database_name> DURATION <duration> REPLICATION <n> SHARD DURATION <duration> DEFAULT 复制代码
删除策略
语法:
DROP RETENTION POLICY <retention_policy_name> ON <database_name> 复制代码
注:当一个表使用的策略不是默认策略时,在进行操作时一定要显式的指定策略名称,否则会出现错误。
InfluxDB命令集合:
SHOW MEASUREMENTS --查询当前数据库中含有的表
SHOW FIELD KEYS --查看当前数据库所有表的字段
SHOW series from pay --查看key数据
SHOW TAG KEYS FROM "pay" --查看key中tag key值
SHOW TAG VALUES FROM "pay" WITH KEY = "merId" --查看key中tag 指定key值对应的值
SHOW TAG VALUES FROM cpu WITH KEY IN ("region", "host") WHERE service = 'redis'
DROP SERIES FROM <measurement_name[,measurement_name]> WHERE <tag_key>='<tag_value>' --删除key
SHOW CONTINUOUS QUERIES --查看连续执行命令
SHOW QUERIES --查看最后执行命令
KILL QUERY --结束命令
SHOW RETENTION POLICIES ON mydb --查看保留数据
查询数据
SELECT * FROM /.*/ LIMIT 1 --查询当前数据库下所有表的第一行记录
select * from pay order by time desc limit 2
select * from db_name."POLICIES name".measurement_name --指定查询数据库下数据保留中的表数据 POLICIES name数据保留
删除数据
delete from "query" --删除表所有数据,则表就不存在了
drop MEASUREMENT "query" --删除表(注意会把数据保留删除使用delete不会)
DELETE FROM cpu
DELETE FROM cpu WHERE time < '2000-01-01T00:00:00Z'
DELETE WHERE time < '2000-01-01T00:00:00Z'
DROP DATABASE “testDB” --删除数据库
DROP RETENTION POLICY "dbbak" ON mydb --删除保留数据为dbbak数据
DROP SERIES from pay where tag_key='' --删除key中的tag
SHOW SHARDS --查看数据存储文件
DROP SHARD 1
SHOW SHARD GROUPS
SHOW SUBSCRIPTIONS
5.Chronograf
Influxdb在1.3以后版本已经关闭了内置的8086的web管理功能,需要单独的工具来管理。而这个工具就是Chronograf。
其实Chronograf是TICK技术栈的一个组成部分。TICK是InfluxdDB公司推出的监控套件,承包指标采集、分析、画图等时序数据库上下游的工作,有点模仿日志分析系统ELK套件的意思。TICK包含:
Telegraf:数据采集
InfluxDB:数据接收和存储
Chronograf:数据汇总展示,报警等
Kapacitor:数据处理,比如监控策略等
下载Chronograf
下载地址 : portal.influxdata.com/downloads
安装Chronograf
启动Chronograf
systemctl start chronograf
访问Chronograf
浏览器输入 http://IP:8888
查询:
丰富的界面操作,易于查询、查看、统计分析等,使用起来非常方便。
五、数据备份与恢复
备份数据的命令格式
influxd backup -database [name] [path-to-backup] 复制代码
远程备份:
influxd backup -database myinfo -host 0.0.0.0:8088 /home/gooagoo/influxDB/backup 复制代码
0.0.0.0替换为ip地址
恢复数据的命令格式
influxd restore [ -metadir | -datadir ] <path-to-meta-or-data-directory> <path-to-backup> 复制代码
六、综合案例:Telegraf + InfluxDB + Grafana
1.Telegraf
Telegraf 是用Go写的代理程序,可以用于收集系统和服务的统计数据,是TICK技术栈的一部分。它具备输入插件,可以直接从系统获取指标数据,从第三方API获取指标数据, 甚至可以通过Kafka获取指标数据。它还具备输出插件,可以将采集的指标发送到各种数据存储,服务和消息队列。比如InfluxDB,Graphite,OpenTSDB,Datadog,Librato,Kafka,MQTT等等。
下载安装Telegraf
wget https://dl.influxdata.com/telegraf/releases/telegraf-1.9.3-1.x86_64.rpm 复制代码
sudo yum install telegraf-1.9.3-1.x86_64.rpm telegraf -version 复制代码
如果你的telegraf是安装的,其配置文件位置为:
/etc/telegraf/telegraf.conf
编辑配置文件,将我们配置好的Influxdb数据库指定为期望的输出源:
[[outputs.influxdb]]
urls=[" http://localhost:8086 "]
启动服务、添加开机启动:
sudo systemctl start telegraf.service sudo service telegraf status sudo systemctl enable telegraf.service 复制代码
在InfluxDB上检查默认配置下Telegraf采集了哪些数据:
> show databases > use telegraf > show measurements > SHOW FIELD KEYS 复制代码
如何进行配置:
# Read metrics about cpu usage # 读取有关CPU使用情况的指标 [[inputs.cpu]] ## Whether to report per-cpu stats or not percpu = true ## Whether to report total system cpu stats or not totalcpu = true ## If true, collect raw CPU time metrics. collect_cpu_time = false ## If true, compute and report the sum of all non-idle CPU states. report_active = false # Read metrics about disk usage by mount point # 通过mount point读取有关磁盘使用情况的指标 [[inputs.disk]] ## Ignore mount points by filesystem type. ignore_fs = ["tmpfs", "devtmpfs", "devfs", "overlay", "aufs", "squashfs"] # Read metrics about disk IO by device # 通过device读取有关磁盘IO的指标 [[inputs.diskio]] # Get kernel statistics from /proc/stat # 通过/proc/stat获取内核统计信息 [[inputs.kernel]] # no configuration # Read metrics about memory usage # 读取有关内存使用量的指标 [[inputs.mem]] # no configuration # Get the number of processes and group them by status # 获取进程的数量并按状态分组 [[inputs.processes]] # no configuration # Read metrics about swap memory usage # 读取有关交换内存使用量的指标 [[inputs.swap]] # no configuration # Read metrics about system load & uptime # 读取有关系统负载和运行时间的指标 [[inputs.system]] # no configuration 复制代码
如何查找指标及其采集数据
telegraf主要分为输入插件和输入插件,其源码目录分别对应plugins/inputs和plugins/outputs,你只要参考telegraf官档找到你所需要的插件然后去到源码对应的目录找到相应的.md文件,按照提示获取相关信息进行配置即可。
启用telegraf服务后,你会发现在InfluxDB中多了一个telegraf的库,其中有多个measurement,这说明我们的数据采集已经成功了。有了数据以后,我们需要关心的是如何把数据聚合然后进行展示。
2.Grafana展示
下载安装基本配置请参考wiki:大数据图表监控分析工具Grafana
这里简单讲解一下如何使用Grafana展示Telegraf收集的相关数据。
启动服务后访问http://ip:3000,默认端口为3000,可在配置文件修改。登录后按照提示配置数据源,我们选择InfluxDB作为数据源:
根据配置信息填写相关的InfluxDB的配置项
接着创建一个dashboard:
我们先选择导入模板的方式来预览效果,再来了解grafana/dashboard的相关配置,这里选择官方提供的一套Telegraf: system dashboard,地址。 请你根据它的提示配置你的telegraf。然后在dashboards中选择import->Upload.jsonFile,将下载的模板导入:
查看结果:
Grafana的功能非常丰富,在这里不能详细叙述,请您参考官档了解更多: docs.grafana.org/
七、InfluxDB硬件规模指南
单节点还是集群? InfluxDB单节点实例是完全开源的。InfluxDB集群需要我们的闭源商业产品。单节点实例不提供冗余。如果服务器不可用,则写入和查询将立即失败。
群集提供高可用性和冗余。多个数据副本分布在多个服务器上,任何一个服务器的丢失都不会对集群产生重大影响。如果您的性能要求属于中等或低负载范围,
那么您可能会使用InfluxDB的单个节点实例。如果您的性能要求中至少有一个属于可能不可行的类别,那么您可能需要使用群集在多个服务器之间分配负载。
1、单节点
注:查询对系统的影响差异很大。
简单查询:
几乎没有函数也没有正则表达式
是时间限制在几分钟,几小时或一天
通常在几毫秒到几十毫秒内执行
中等查询:
有多个函数和一个或两个正则表达式
也可能有复杂的GROUP BY条款或抽样多个星期的时间范围
通常在几百或几千毫秒内执行
复杂查询:
具有多个聚合或转换函数或多个正则表达式
可以抽样几个月或几年的非常大的时间范围
通常需要多秒才能执行
低负荷建议:
CPU:2-4核心
RAM:2-4 GB
IOPS:500
适度的负载建议:
CPU:4-6核
RAM:8-32 GB
IOPS:500-1000
高负荷建议:
CPU:8+核心
RAM:32+ GB
IOPS:1000+
2、集群
元节点
群集必须至少具有三个独立的元节点才能在丢失服务器后继续存在。具有2n + 1元节点的集群可以容忍元节点的丢失n。群集应该具有奇数个元节点。没有理由拥有偶数个元节点,并且它可能导致某些配置出现问题。
元节点不需要很大的计算能力。无论群集负载如何,我们建议对元节点使用以下内容:
普遍推荐
CPU:1-2核心
RAM:512 MB - 1 GB
IOPS:50
数据节点
只有一个数据节点的集群有效,但没有数据冗余。冗余由写入数据的保留策略上的复制因子设置。群集可能会丢失 n - 1数据节点并仍然返回完整的查询结果,其中n是复制因子。
为了在群集内进行最佳数据分发,InfluxData建议使用偶数个数据节点。群集数据节点的硬件建议类似于独立实例建议。数据节点应始终至少有2个CPU内核,因为它们必须处理常规的读写流量以及集群内读写流量。
由于群集通信开销,群集中的数据节点处理的吞吐量低于同一硬件上的独立实例。
注:查询对系统的影响差异很大。
简单查询:
几乎没有函数也没有正则表达式
是时间限制在几分钟,几小时或一天
通常在几毫秒到几十毫秒内执行
中等查询:
有多个函数和一个或两个正则表达式
也可能有复杂的GROUP BY条款或抽样多个星期的时间范围
通常在几百或几千毫秒内执行
复杂查询:
具有多个聚合或转换函数或多个正则表达式
可以抽样几个月或几年的非常大的时间范围
通常需要多秒才能执行
低负荷建议
CPU:2个核心
RAM:2-4 GB
IOPS:1000
适度的负载建议
CPU:4-6
内存:8-32GB
IOPS:1000+
高负荷建议
CPU:8+
RAM:32+ GB
IOPS:1000+
企业Web节点
Enterprise Web服务器主要是具有类似负载要求的HTTP服务器。对于大多数应用程序,它不需要非常强大。群集只能使用一个Web服务器,但为了实现冗余,可以将多个Web服务器连接到单个后端Postgres数据库。
注:生产集群不应使用 SQLite 数据库,因为它不允许冗余Web服务器,也不能像Postgres一样优雅地处理高负载。
普遍推荐
CPU:1-4核心
RAM:1-2 GB
IOPS:50
八、InfluxDB单机性能测试
官方给出的硬件参考配置是:
两块SSD。一块存储influxdb/wal,一块存储influxdb/data 最少8G内存
虚拟机InfluxDB性能测试,这里记录下结果,方便以后查阅。
操作系统: CentOS Linux release 7.5.1804
InfluxDB版本 : V1.7.4
CPU : Intel(R) Xeon(R) CPU E5-2403 0 @ 1.80GHz,4个4核CPU
内存 :16G
硬盘:机械硬盘
批量写入官方指导:
可以使用对写端点的单个HTTP请求将一批点提交到数据库。这通过大幅减少HTTP开销,使HTTP API的写入更加高效。
InfluxData建议批量大小为5,000-10,000点,但不同的用例可以通过明显更小或更大的批次来提供更好的服务。
优化前的结果(写入):单线程写入数据超过1200W左右写入失败,内存不够用
多次优化后的结果(写入):
全表扫描性能
条件查询性能
时间维度查询
聚合查询性能
同一个measurement,批量写入大量数据,然后多线程读取,随着数据量的增大,读取速度放慢。
如果是不同的measurement,读写分别不同的measurement,则读和写之间不受相互影响。
服务器应具有内存配置限制,以最大程度地降低内部进程触发OOM的风险。
目前的行为:
系统中有几个地方可以进行大量分配,这可能是发生OOM的风险存在。
一般来说,这些都发生在:
查询 - 通常使用过宽的过滤条件导致一次加载太多系列,比如select * 操作(确认存在)
内存索引 - 高基数(series)系列导致索引增长和OOM进程(确认存在)
写入 - 许多正在进行的大批量和慢速磁盘写入会导致在等待磁盘写入/同步时构建大量内部缓冲区。(确认存在)
压缩 - 在某些情况下,可以加载大型系列,以便更优化地对点进行重复数据删除和分块。(尚未发现)
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- InfluxDB 1.8.3 发布,开源时序数据库
- InfluxDB 1.7.11 发布,开源时序数据库
- InfluxDB 1.8.5 发布,开源时序数据库
- InfluxDB 1.8.6 发布,开源时序数据库
- InfluxDB 2.0.7 发布,开源时序数据库
- 饿了么:分布式时序数据库 - LinDB
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
计算机网络(第4版)
[美] James F. Kurose、[美] Keith W. Ross / 陈鸣 / 机械工业出版社 / 2009-11 / 66.00元
本书采用了独创的自顶向下方法,即从应用层开始沿协议栈向下讲解计算机网络的基本原理,强调应用层范例和应用编程接口,内容深入浅出,注重教学方法,理论与实践相结合。第3版的内容相应更新并反映了网络领域的最新进展,如增加了无线和移动网络一章,扩充了对等网络、BGP、MPLS、网络安全、广播选路和因特网编址及转发方面的材料;还增加了一套实用的实验,并修订了习题。本书适合作为计算机、电子、通信工程相关专业的本......一起来看看 《计算机网络(第4版)》 这本书的介绍吧!