InfluxDB 数据结构和数据库模型

Posted 2023-02-14

技术标签:

【中文标题】InfluxDB 数据结构和数据库模型【英文标题】：InfluxDB data structure & database model 【发布时间】：2017-12-11 19:19:15 【问题描述】：

你能告诉我，哪个数据结构有一个 InfluxDB 和哪个数据模型 InfluxDB 使用？这就是键值模型。我阅读了完整的文档，但没有听懂。

提前谢谢你！

【问题讨论】：

【参考方案1】：

1.数据模型和术语

InfluxDB 数据库存储点。一个点有四个组成部分：一个测量值、一个标签集、一个字段集和一个时间戳。

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

点的序列化格式由 [line protocol] 定义（如果您想阅读更多详细信息，还包括其他示例和说明）。规范中的一个示例点有助于解释术语：

” 温度,machine=unit42,type=assembly internal=32,external=100 1434055562000000035

测量的是温度。

标签集是 machine=unit42,type=assembly。标签集中的键、机器和类型称为标签键。 tagset 中的值 unit42 和 assembly 称为标签值。

字段集内部=32，外部=100。字段集中的内部和外部键称为字段键。字段集中的值 32 和 100 称为字段值。

每个点都存储在一个数据库中的一个数据库中。数据库是用户、保留策略和积分的容器。保留策略配置 InfluxDB 保留点的时间（持续时间），在集群中存储这些点的多少副本（复制因子），以及分片组覆盖的时间范围（分片组持续时间）。保留策略使用户（并且对数据库有效）可以轻松删除不再需要的旧数据。这是时间序列应用程序中的常见模式。

稍后我们将在描述 InfluxDB 中写入路径的工作原理时解释复制因子、分片组和分片。

我们还需要一个额外的术语来开始：系列。系列只是说保留策略+测量+标签集的捷径。具有相同保留策略、度量和标记集的所有点都是同一系列的成员。

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

2。从客户那里获得积分

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

当数据库接收到新点时，它必须 (1) 使这些点持久，以便在数据库或服务器崩溃的情况下可以恢复它们，并且 (2) 使这些点可查询。这篇文章主要关注上半场，让积分更持久。

3.持久化存储点

为了使点持久，每个批次都被写入并同步到预写日志 (WAL)。 WAL 是仅在数据库恢复期间读取的仅附加文件。为了空间和磁盘 IO 效率，WAL 中的每个批次在写入磁盘之前都使用 [快速压缩] 进行压缩。

虽然 WAL 格式有效地使传入的数据具有持久性，但它是一种极差的读取格式，因此不适合支持查询。为了允许立即查询新数据，传入点也被写入内存缓存。缓存是一种内存数据结构，针对查询和插入性能进行了优化。缓存数据结构是一系列到按时间排序的字段列表的映射。

WAL 使新点持久。缓存使新点可查询。如果系统在缓存写入 TSM 文件之前崩溃或关闭，则在数据库启动时通过读取和重放 WAL 中存储的批处理来重建它。

WAL 和缓存的组合对于传入的数据效果很好，但不足以长期存储。由于 WAL 必须在启动时重放，因此将其限制在合理的大小非常重要。缓存仅限于 RAM 的大小，这对于许多时间序列用例来说也是不可取的。因此，需要组织数据并将其写入磁盘上的长期存储块，这些存储块具有大小效率（以便数据库可以存储大量点）和高效查询。

时间序列查询通常是随时间推移的聚合——对有限时间范围内的点进行扫描，然后通过平均值、最大值或移动窗口等汇总函数进行缩减。列式数据库存储技术，其中数据在磁盘上按列而不是按行组织，非常适合这种查询模式。此外，列式系统对数据的压缩效果非常好，满足了高效存储数据的需求。有很多关于专栏商店的文献。 [面向列的数据库系统]就是这样一种概述。

时间序列应用程序通常会在一段时间后从存储中清除数据。例如，许多监控应用程序会在线存储最近一两个月的数据，以支持监控查询。如果配置的生存时间到期，则需要高效地从数据库中删除数据。从列式存储中删除点的成本很高，因此 InfluxDB 额外将其列式格式组织成有时间限制的块。当生存时间到期时，可以简单地从文件系统中删除有时间限制的文件，而不需要对持久数据进行大量更新。

最后，当 InfluxDB 作为集群系统运行时，它会在多台服务器之间复制数据，以确保在发生故障时的可用性和持久性。

使用 InfluxDB 保留策略配置可选的生存时间、生存时间段内的时间块粒度和副本数：

在 DURATION REPLICATION [SHARD DURATION ] [DEFAULT] 上创建保留策略

持续时间是可选的生存时间（如果数据不应过期，请将持续时间设置为 INF）。 SHARD DURATION 是数据在有效期内的粒度。例如，持续时间为 24 小时的一小时分片持续时间将数据库配置为存储 24 个一小时分片。每小时，最旧的分片都会从数据库中过期（删除）。设置 REPLICATION 以配置复制因子——一个分片的副本数应该存在于一个集群中。

具体来说，数据库在磁盘上创建了这种数据的物理组织：

'' 数据库主管 /db '' 保留策略目录 /db/rp '' 分片组（有时间限制）。（逻辑） '' 分片目录 (db/rp/Id#) '' TSM0001.tsm（数据文件） '' TSM0002.tsm（数据文件） ''…… 内存中的高速缓存以 TSM 格式刷新到磁盘。当刷新完成时，刷新的点会从缓存中移除，相应的 WAL 会被截断。（WAL 和缓存也是按分片维护的。）TSM 数据文件存储按列组织的点。一旦写入，TSM 文件就是不可变的。 [InfluxDB 文档] 中提供了 TSM 文件布局的详细说明。

4.压缩持久点

缓存是相对少量的数据。当 TSM 列格式可以在单个块中存储一个系列的长运行值时，它的效果最好。更长的运行会产生更好的压缩并减少扫描字段以进行查询的寻求。 TSM 格式主要基于日志结构的合并树。新的（一级）TSM 文件由高速缓存刷新生成。这些文件稍后被组合（压缩）成二级文件。二级文件进一步合并为三级文件。随着文件变大并最终变冷（它们覆盖的时间范围不再适合写入），会出现额外的压缩级别。上面的文档参考提供了压缩的详细描述。

TSM 压缩代码中有很多逻辑和复杂性。但是，高级目标非常简单：将一系列值组织在一起进行长期运行，以最好地优化压缩和扫描查询。

参考：https://www.influxdata.com/blog/influxdb-internals-101-part-one/

【讨论】：

这看起来是一个很好的答案（我还没有全部阅读），但它是一堵文字墙。也许考虑正确格式化它。【参考方案2】：

本质上是key-value，key是时间，value可以是一个或多个字段/列。值也可以选择是索引列，在 influxdb 中称为标签，它们针对搜索以及始终需要的时间进行了优化。至少需要一个非索引值。

见schema design documentation for more details。

事实上，很像 Cassandra，尽管 influx 本质上是 schema-on-write，而开发人员为 Cassandra 编写模式。

存储引擎再次与 Cassandra 非常相似，using a variation of SSTables as used in Cassandra，针对时间序列数据进行了优化。

【讨论】：

【参考方案3】：

我不确定您在寻找答案时是否有以下流入文档：

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