InfluxDB数据结构和数据库模型

Question

InfluxDB数据结构和数据库模型

databaseinfluxdbdatamodel

11

请问，哪种数据结构被使用在InfluxDB中？InfluxDB采用哪种数据模型？它是键值模型吗？我已经阅读了完整的文档，但我并没有理解清楚。

提前感谢你的回答！

- Mary Fel

3个回答

3

它本质上是键值对，其中键是时间，值可以是一个或多个字段/列。值也可以选择性地作为索引列，称为influxdb中的标签，这些标签与始终需要的时间一起进行了优化搜索。至少需要一个非索引值。

有关更多详细信息，请参见模式设计文档。

实际上很像Cassandra，尽管influx基本上是在写入时进行架构，而开发人员则为Cassandra编写架构。

存储引擎方面，与Cassandra非常相似，使用SSTable的变体，就像Cassandra一样，针对时间序列数据进行了优化。

- danny

0

我不确定以下Influx文档在你寻找答案的时候是否存在：

https://docs.influxdata.com/influxdb/v1.5/concepts/key_concepts/

但它确实帮助我理解了influxdb的数据结构。

- Savaratkar

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- thach.nv92 · Accepted Answer

1. 数据模型与术语

InfluxDB数据库存储点。一个点由四个组成部分构成：测量值（measurement）、标签集（tagset）、字段集（fieldset）和时间戳（timestamp）。

测量值提供了一种将可能具有不同标签集或字段集的相关点关联起来的方式。标签集是一个键值对字典，用于在点上存储元数据。字段集是一组类型化标量值——记录点的数据。

点的序列化格式由[行协议]定义（如果您想阅读更多细节，其中包括其他示例和说明）。规范中的一个示例点有助于解释这些术语：

temperature,machine=unit42,type=assembly internal=32,external=100 1434055562000000035

该测量值为温度。

标签集为machine=unit42,type=assembly。标签集中的键machine和type称为标签键（tag keys）。标签集中的值unit42和assembly称为标签值（tag values）。

字段集为internal=32,external=100。字段集中的键internal和external称为字段键（field keys）。字段集中的值32和100称为字段值（field values）。

每个点都存储在一个数据库和保留策略中。数据库是用户、保留策略和点的容器。保留策略配置了InfluxDB保留点的时间（持续时间）、集群中存储这些点的副本数（复制因子）以及分片组所覆盖的时间范围（分片组持续时间）。保留策略使得用户轻松地删除不再需要的旧数据（对于数据库而言也更加高效）。这是时间序列应用程序中的常见模式。

当我们描述InfluxDB的写入路径时，我们将解释复制因子、分片组和分片。

还有一个需要介绍的术语：series。系列是指保留策略+测量值+标签集的简写。所有具有相同保留策略、测量值和标签集的点都是同一系列的成员。

您可以参考[文档词汇表]查找本系列博客中使用的这些或其他术语。

2. 从客户端接收点

客户端通过POST请求将点（以行协议格式）发送到InfluxDB的HTTP /write端点。点可以单独发送；然而，为了提高效率，大多数应用程序会批量发送点。典型的批量大小在数百到数千个点之间。POST指定了一个数据库和一个可选的保留策略，通过查询参数来传递。如果未指定保留策略，则使用默认的保留策略。正文中的所有点都将被写入该数据库和保留策略中。POST正文中的点可以来自任意数量的系列；批次中的点不必来自同一测量值或标签集。

当数据库接收到新的点时，它必须（1）使这些点持久化，以便在数据库或服务器崩溃的情况下可以恢复它们，并（2）使这些点可查询。本文重点介绍第一部分：使点持久。

3. 将点持久化到存储器

虽然WAL格式有效地使得传入数据具有耐久性，但它非常不适合用于查询，因此无法支持查询。为了立即查询新数据，传入的数据点也会被写入内存缓存。缓存是一种经过优化的内存数据结构，用于查询和插入性能。缓存数据结构是一系列按时间排序的字段列表映射到系列的映射。
WAL使得新的数据点具有耐久性，而缓存使得新的数据点可查询。如果系统在cache被写入TSM文件之前崩溃或关闭，则在数据库启动时通过读取和重放存储在WAL中的批次来重建cache。
WAL和cache的组合对于传入数据很有效，但对于长期存储则不足够。由于必须在启动时重新播放WAL，因此将其限制在合理的大小范围内非常重要。缓存的大小限制为RAM的大小，这对于许多时间序列用例也是不理想的。因此，数据需要组织并写入磁盘上的长期存储块，这些块在大小和查询效率方面都很高效（以便数据库可以存储大量点）。
时间序列查询通常是基于时间的聚合——在有限时间范围内扫描点，并通过汇总函数（如平均值、最大值或移动窗口）进行减少。基于列的数据库存储技术，其中数据按列而不是按行组织在磁盘上，非常适合这种查询模式。此外，列式系统能够优秀地压缩数据，满足了高效存储数据的需求。有关列存储的文献非常多，《面向列的数据库系统》就是一个概述。
时间序列应用程序经常会在一段时间后从存储中清除数据。例如，许多监控应用程序将在线存储最近一个月或两个月的数据以支持监视查询。如果配置的生存时间过期，则从数据库中删除数据需要使用昂贵的列存储操作，因此InfluxDB还将其列式格式组织成基于时间段的块。当生存时间到期时，时间绑定文件可以直接从文件系统中删除，而无需对持久化数据进行大规模更新。
最后，当InfluxDB作为群集系统运行时，它会在多个服务器之间复制数据，以提高可用性和耐久性，以防发生故障。
可以使用InfluxDB保留策略来配置可选的生存时间、生存期内时间块的粒度以及副本数：
CREATE RETENTION POLICY ON DURATION REPLICATION [SHARD DURATION ] [DEFAULT]
duration是可选的生存时间（如果数据不应过期，则将持续时间设置为INF）。SHARD DURATION是到期期间内数据的粒度。例如，具有24小时持续时间的一小时片段持续时间会配置数据库存储24个一小时片段。每个小时，最旧的分片将从数据库中删除。设置副本以
'' Database director /db '' Retention Policy directory /db/rp '' Shard Group (time bounded). (Logical) '' Shard directory (db/rp/Id#) '' TSM0001.tsm (data file) '' TSM0002.tsm (data file) '' …
内存缓存以TSM格式刷新到磁盘上。刷新完成后，刷新的点将从缓存中删除，并且相应的WAL将被截断。（WAL和缓存也是按分片维护的。）TSM数据文件存储列式组织的点。一旦写入，TSM文件就不可变了。有关TSM文件布局的详细描述在[InfluxDB文档]中可用。
4.压缩持久化点
缓存是相对较少的数据量。当TSM列式格式可以存储系列的长时间运行值时，它效果最佳。更长的运行产生更好的压缩并减少了扫描字段进行查询的寻址。 TSM格式在很大程度上基于日志结构合并树。缓存刷新生成新的（一级）TSM文件。稍后将这些文件合并（压缩）成二级文件。二级文件进一步合并为三级文件。随着文件越来越大并且最终变得冷却（它们覆盖的时间范围不再适用于写入），还会发生其他级别的压缩。上面的文档参考提供了压缩的详细描述。
TSM压缩代码中有很多逻辑和复杂性。但是，高层目标非常简单：将系列的值组织在一起，形成长时间运行，以最佳化压缩和扫描查询。
参考：https://www.influxdata.com/blog/influxdb-internals-101-part-one/