influxdb

ElonMuscle
1,313 阅读8分钟

数据库创建、数据CRUD操作基本上和常规SQL类似

插入数据操作与SQL不一样

对比传统数据库概念

InfluxDB 传统数据库中的概念
database 数据库
measurement 数据库中的表
points 表里面的一行数据

常用的名词

需要对时序数据库的一些新的概念进行理解：

  • tag set
    数据点上tag key和tag value的集合。

  • tag
    InfluxDB数据结构中的键值对，tags在InfluxDB的数据中是可选的，但是它们可用于存储常用的metadata; tags会被索引，因此tag上的查询是很高效的。

  • tag key
    组成tag的键值对中的键部分，tag key是字符串，存在metadata中。

  • tag value
    组成tag的键值对中的值部分，tag value是字符串，存在metadata中。

  • field set
    数据点上field key和field value的集合。

  • field
    InfluxDB数据中记录metadata和真实数据的键值对。fields在InfluxDB的数据结构中是必须的且不会被索引。如果要用field做查询条件的话，那就必须遍历所选时间范围里面的所有数据点，这种方式对比与tag效率会差很多。

  • field key
    组成field的键值对里面的键的部分。field key是字符串且保存在metadata中。

  • field value
    组成field的键值对里面的值的部分。field value才是真正的数据，可以是字符串，浮点数，整数，布尔型数据。一个field value总是和一个timestamp相关联。 field value不会被索引，如果要对field value做过滤话，那就必须遍历所选时间范围里面的所有数据点，这种方式对比与tag效率会差很多。

  • measurement
    InfluxDB数据结果中的一部分，描述了存在关联field中的数据的意义，measurement是字符串。

  • replication factor
    retention policy的一个参数，决定在集群模式下数据的副本的个数。InfluxDB在N个数据节点上复制数据，其中N就是replication factor。 replication factor在单节点的实例上不起作用

  • retention policy(RP)
    数据保留策略, InfluxDB数据结构的一部分，描述了InfluxDB保存数据的长短(duration)，数据存在集群里面的副本数(replication factor)，以及shard group的时间范围(shard group duration)。RPs在每个database里面是唯一的，连同measurement和tag set定义一个series。 当你创建一个database的时候，InfluxDB会自动创建一个叫做autogen的retention policy，其duration为永远，replication factor为1，shard group的duration设为的七天。

  • series
    InfluxDB数据结构的集合，一个特定的series由measurement，tag set和retention policy组成。

注意：field set不是series的一部分

  • point
    InfluxDB数据结构的一部分由series中的的一堆field组成。 每个点由其series和timestamp唯一标识。 你不能在同一series中存储多个具有相同timestamp的点。 相反，当你使用与该series中现有点相同的timestamp记将新point写入同一series时，该field set将成为旧field set和新field set的并集。

  • tsm(Time Structured Merge tree)
    InfluxDB的专用数据存储格式。 TSM可以比现有的B+或LSM树实现更大的压缩和更高的写入和读取吞吐量。

  • shard
    shard包含实际的编码和压缩数据，并由磁盘上的TSM文件表示。 每个shard都属于唯一的一个shard group。多个shard可能存在于单个shard group中。每个shard包含一组特定的series。给定shard group中的给定series上的所有点将存储在磁盘上的相同shard（TSM文件）中。

  • shard duration
    shard duration决定了每个shard group跨越多少时间。具体间隔由retention policy中的SHARD DURATION决定。 例如，如果retention policy的SHARD DURATION设置为1w，则每个shard group将跨越一周，并包含时间戳在该周内的所有点。

  • shard group
    shard group是shard的逻辑组合。shard group由时间和retention policy组织。包含数据的每个retention policy至少包含一个关联的shard group。给定的shard group包含shard group覆盖的间隔的数据的所有shard。每个shard group跨越的间隔是shard的持续时间。

InfluxQL基本语法

  1. 数据库操作
  • 创建 CREATE DATABASE <DB>;
  • 删除 DROP DATABASE <DB>;
  • 使用 USE <DB>;
  1. 数据表(measurements) 和数据操作

  • 显示所有表 show measurements;

  • 新建表（写数据）

    insert <measurement>[,<tag-key>=<tag-value>...] <field-key>=<field-value>[,<field2-key>=<field2-value>...] [unix-nano-timestamp]
    示例如下:

    INSERT temperature,machine=unit42,type=assembly external=25,internal=37 1434067467000000000

  • 删除表
    DROP MEASUREMENT <measurement_name>

  • 读数据 与SQL相同

  • 用Drop删除series
    DROP SERIES FROM <measurement_name[,measurement_name]> WHERE <tag_key>='<tag_value>
    示例如下:

    # 从单个measurement删除所有series：
DROP SERIES FROM "h2o_feet"
# 从单个measurement删除指定tag的series：
DROP SERIES FROM "h2o_feet" WHERE "location" = 'santa_monica'
# 从数据库删除有指定tag的所有measurement中的所有数据：
DROP SERIES WHERE "location" = 'santa_monica'

  • 用DELETE删除series
    DELETE删除数据库中的measurement中的所有点。与DROP SERIES不同，它不会从索引中删除series，并且它支持WHERE子句中的时间间隔。 该查询采用以下格式，必须包含FROM子句或WHERE子句，或两者都有：

    DDELETE FROM <measurement_name> WHERE [<tag_key>='<tag_value>'] | [<time interval>]
    示例如下:

    # 删除measurementh2o_feet的所有相关数据：
 DELETE FROM "h2o_feet"
删除measurementh2o_quality并且tagrandtag等于3的所有数据：
# DELETE FROM "h2o_quality" WHERE "randtag" = '3'
删除数据库中2016年一月一号之前的所有数据：
#  DELETE WHERE time < '2016-01-01'

  • 删除shard
    DORP SHARD删除一个shard，也会从metastore中删除shard。格式如下：
    DROP SHARD <shard_id_number>

influxdb时间序列数据库设计见解和权衡

InfluxDB是一个时间序列数据库。针对这种用例进行优化需要进行一些权衡，主要是以牺牲功能为代价来提高性能。以下列出了一些权衡过的设计见解：

  1. 对于时间序列用例，我们假设如果相同的数据被多次发送，那么认为客户端几次都是同一笔数据。 优势：通过简化的冲突解决增加了写入性能 劣势：不能存储重复数据;可能会在极少数情况下覆盖数据

  2. 删除是罕见的事情。当它们发生时，肯定是针对大量的旧数据，这些数据对于写入来说是冷数据。 优势：限制删除操作，从而增加查询和写入性能 劣势：删除功能受到很大限制

  3. 对现有数据的更新是罕见的事件，持续地更新永远不会发生。时间序列数据主要是永远不更新的新数据。 优势：限制更新操作，从而增加查询和写入性能 劣势：更新功能受到很大限制

  4. 绝大多数写入都是接近当前时间戳的数据，并且数据是按时间递增的顺序添加。 优势：按时间递增的顺序添加数据明显更高效些 劣势：随机时间或时间不按升序写入点的性能要低得多

  5. 规模至关重要。数据库必须能够处理大量的读取和写入。 优势：数据库可以处理大量的读取和写入 劣势：InfluxDB开发团队被迫做出权衡来提高性能

  6. 能够写入和查询数据比具有强一致性更重要。 优势：多个客户端可以在高负载的情况下完成查询和写入数据库操作 劣势：如果数据库负载较重，查询返回结果可能不包括最近的点
    理解：infloxdb不是事务数据库，不强调传统关系型数据库的事务特征ACID
    注: 数据库事务特征，即 ACID：
    A Atomicity 原子性 事务是一个原子性质的操作单元，事务里面的对数据库的操作要么都执行，要么都不执行，

    C Consistent 一致性 在事务开始之前和完成之后，数据都必须保持一致状态，必须保证数据库的完整性。也就是说，数据必须符合数据库的规则。

    I Isolation 隔离性 数据库允许多个并发事务同事对数据进行操作，隔离性保证各个事务相互独立，事务处理时的中间状态对其它事务是不可见的，以此防止出现数据不一致状态。可通过事务隔离级别设置：包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）

    D Durable 持久性 一个事务处理结束后，其对数据库的修改就是永久性的，即使系统故障也不会丢失

  7. 许多时间序列都是短暂的。经常是时间序列，只出现了几个小时，然后消失，例如一个新的主机，开机并监控数据被写入一段时间，然后被关闭。 优势：InfluxDB善于管理不连续数据 劣势：无模式设计意味着不支持某些数据库功能，例如没有交叉表连接 8.没有数据点太重要了。 优势：InfluxDB具有非常强大的工具来处理聚合数据和大数据集 劣势：数据点没有传统意义上的ID，它们被时间戳和series区分开来

    理解：数据点point主键标识是由（timestamp+series组成）

数据源采集

influxdb全家桶之采集数据的代理程序：Telegraf
采集输入插件见:
docs.influxdata.com/telegraf/v1…

数据可视化

influxdb全家桶之可视化套件：Chronograf
或
使用通用数据可视化条件grafana
grafana支持的数据源：InfluxDB、Graphite、Elasticsearch、CloudWatch、OpenTSDB、Prometheus、MySQL、Postgres、Microsoft SQL Server (MSSQL)。

参考

  1. jasper-zhang1 - InfluxDB中文文档
  2. Frank- 玩转时序数据库 InfluxDB（一）初体验
  3. 程序猿knight-脏读、幻读与不可重复读
  4. Magic_Duck-Telegraf+Influxdb+Grafana构建监控平台
avatar
文章
阅读
粉丝