Influxdb - 简单介绍
1. 时序数据库TSDB
1.1. 时序数据
- 通常按时间顺序到达(可以按规则或不规则的时间间隔到达)
- 数据量大
- 具有时效性，越新的数据越有价值
image.png
1.2. 时序数据库
-
发展史
发展史
-
DB-Engine-Rank
image.png
image.png
2. Influxdb介绍
2.1. 优势
- 易用性：类SQL语句
- 功能齐全
- TICK生态
- 数据压缩率高
- 读写性能高
2.2. 哪些公司在使用
image.png
2.3. Evolution and Thinks
Evolution
- 版本0.9.0之前，基于LevelDB的LSMTree方案
- 版本0.9.0～0.9.4，基于BoltDB的B+tree方案
- 版本0.9.5～1.2，基于自研的WAL + TSMFile方案
- 版本1.3～至今，基于自研的WAL + TSMFile + TSIFile方案
Some Thinks
- 时序数据在降采样后会存在大批量的数据删除，LevelDB的LSMTree删除代价过高
- 单机环境存放大量数据时不能占用过多文件句柄，LevelDB会随着时间增长产生大量小文件
- 数据存储需要热备份，LevelDB只能冷备
- 大数据场景下写吞吐量要跟得上，BoltDB的B+tree写操作吞吐量成瓶颈
- 存储需具备良好的压缩性能，BoltDB不支持压缩
2.4. Goal：高效写入，高压缩比
- 采用无模式设计，便于管理不连续数据。也意味着不支持某些数据库功能，例如没有交叉表连接
- 不能存储重复数据，可能会在极少数情况下覆盖数据
- 限制数据删除和更新，从而增加查询和写入性能
删除功能，不能只根据tag删除，须携带timestamp筛选删除
更新功能，不支持update，可以通过insert相同timestamp的数据点
- 存储压缩比例高达10%
2.5. Terms
image.png
- database: 数据库，measurement集合
- measurement：指标对象，也即一个数据源对象。每个measurement可以拥有一个或多个指标值
- tag：概念等同于大多数时序数据库中的tags, 通常通过tags可以唯一标示数据源。每个tag的key和value必须都是字符串
- field：数据源记录的具体指标值。每一种指标被称作一个“field”，指标值就是 “field”对应的“value”
- timestamp：数据的时间戳。在InfluxDB中，理论上时间戳可以精确到 纳秒（ns）级别
- series：retention policy、measurement和tag set的集合
image.png
2.6. Functions
image.png
2.7. Continuous Queries and Retention Policies
- Continuous Query (CQ)，是在数据库内部自动周期性运行的一个查询
- Retention Policy (RP)，是InfluxDB数据架构的一部分，它描述了InfluxDB保存数据的时间。单个数据库中可以有多个RPs，但是每个Measurement的RPs是唯一的
2.8. Test Case
数据
以10秒的间隔，来追踪餐厅通过电话和网站订购食品的订单数量。我们会把这些数据存在food_data数据库里，其measurement为orders，fields分别为phone和website，如图所示。
image.png
问题
假定在长时间的运行中，我们只关心每三十分钟通过手机和网站订购的平均数量，我们希望用RPs和CQs实现下面的需求：
- 自动将十秒间隔数据聚合到30分钟的间隔数据
- 自动删除两个小时以上的原始10秒间隔数据
- 自动删除超过52周的30分钟间隔数据
Answer
- 准备数据库，以及Retention Policy
CREATE DATABASE "food_data"
CREATE RETENTION POLICY "two_hours" ON "food_data" DURATION 2h REPLICATION 1 DEFAULT
CREATE RETENTION POLICY "a_year" ON "food_data" DURATION 52w REPLICATION 1
- 创建Continuous Query
CREATE CONTINUOUS QUERY "cq_30m" ON "food_data" BEGIN
SELECT mean("website") AS "mean_website",mean("phone") AS "mean_phone"
INTO "a_year"."downsampled_orders"
FROM "orders"
GROUP BY time(30m)
END
- 写入数据
INSERT orders phone=10,website=30 ...
- 结果数据
在orders里面是10秒钟间隔的裸数据，保存时间为2小时
在downsampled_orders里面是30分钟的聚合数据，保存时间为52周
2.9. Hardware sizing guidelines
- Low load recommendations，CPU: 2-4 cores，RAM: 2-4 GB，IOPS: 500
- Moderate load recommendations，CPU: 4-6 cores，RAM: 8-32 GB，IOPS: 500-1000
- High load recommendations，CPU: 8+ cores，RAM: 32+ GB，IOPS: 1000+
image.png
3. The eco-system for InfluxDB
- Telegraf, Time-Series Data Collector
- InfluxDB, Time-Series Data Storage
- Chronograf, Time-Series Data Visualization
- Kapacitor, Time-Series Data Processing
TICK
3.1. Telegraf
Telegraf is the open source server agent to help you collect metrics from your stacks, sensors and systems.
- monitoring the host filesystem
- monitoring docker containers
- supporting 200+ inputs, such as mysql, redis, mongodb, nginx, kubernetes.
3.2. StatsD
A network daemon that runs on the Node.js platform and listens for statistics, like counters and timers, sent over UDP or TCP and sends aggregates to one or more pluggable backend services (e.g., Graphite).
- 计数器counter，例如user.logins:10|c // user.logins+10
- 计时器timer，例如foo:100|ms // foo 100ms
- 标量gauge，例如age:+1|g // age+1
- 集合set，例如user:1|s user:2|s user:1|s // 2个user
3.3. Chronograf
Chronograf is the user interface and administrative component of the InfluxDB 1.x platform.
image.png
image.png
3.4. Grafana
The open platform for beautiful analytics and monitoring.
4. Refers
- InfluxDB官方文档：https://docs.influxdata.com/platform/introduction
- InfluxDB中文文档：https://jasper-zhang1.gitbooks.io/influxdb/content/
- 时序数据库技术体系解析：http://hbasefly.com/category/%e6%97%b6%e5%ba%8f%e6%95%b0%e6%8d%ae%e5%ba%93/
- 如何写一个时序数据库：https://fabxc.org/tsdb/
