database - InfluxDB数据结构和数据库模型

Question

您能告诉我，哪个数据结构具有InfluxDB，而哪个数据模型具有InfluxDB？是这个键值模型。我阅读了完整的文档，但没有听懂。

先感谢您!

Answer 1

1.数据模型和术语

InfluxDB数据库存储点。点由四个部分组成:度量，标签集，字段集和时间戳。

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

点的序列化格式由[线路协议(protocol)]定义(如果您想了解更多详细信息，还可以包括其他示例和说明)。规范中的一个示例点有助于解释该术语:

”温度，机器= unit42，类型=组件内部= 32，外部= 100 1434055562000000035

测量是温度。

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

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

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

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

我们还需要开始使用另外一个术语:系列。系列只是说保留策略+度量+标签集的捷径。具有相同保留策略，度量和标签集的所有点都是同一系列的成员。

您可以引用[文档术语表]中的这些术语或本博客系列文章中可能使用的其他术语。

2.从客户那里获得积分

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

当数据库接收到新的点时，它必须(1)使这些点具有持久性，以便在数据库或服务器崩溃的情况下可以将其恢复；以及(2)使这些点可查询。这篇文章集中在上半年，使观点持久。

3.持久存储点

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

虽然WAL格式有效地使传入数据具有持久性，但它对于读取来说是一种非常糟糕的格式-使其不适合支持查询。为了允许立即查询新数据，输入点也被写入内存缓存中。缓存是一种内存中数据结构，针对查询和插入性能进行了优化。高速缓存数据结构是序列到按时间排序的字段列表的映射。

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

WAL和高速缓存的组合对于传入数据非常有效，但对于长期存储而言则不足。由于必须在启动时重播WAL，因此将其限制为合理的大小非常重要。缓存被限制为RAM的大小，这在许多时间序列的用例中也是不希望的。因此，需要对数据进行组织并将其写入磁盘上的长期存储块，这些存储块具有高效的大小(以便数据库可以存储很多点)并且对于查询有效。

时间序列查询通常是时间上的汇总-对有界时间范围内的点进行扫描，然后通过诸如平均值，最大值或移动窗口之类的汇总函数来减少这些查询。列式数据库存储技术非常适合这种查询模式，在该技术中，数据是按列而不是按行组织在磁盘上的。此外，柱状系统可以很好地压缩数据，从而满足有效存储数据的需求。关于列存储的文献很多。 [面向列的数据库系统]就是这样的概述。

时间序列应用程序通常会在一段时间后从存储中删除数据。例如，许多监视应用程序将在线存储最后一两个月的数据，以支持监视查询。如果已配置的生存时间到期，则从数据库中删除数据的效率必须很高。从列存储中删除点很昂贵，因此InfluxDB还将其列格式组织为有时间限制的块。当生存时间到期时，可以将有时间限制的文件从文件系统中删除，而无需对持久性数据进行大的更新。

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

使用InfluxDB保留策略配置可选的生存时间，生存时间范围内的时间间隔的粒度以及副本数:

建立持续时间复制的保留政策[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/