Mar*_*Fel 5 database datamodel influxdb
您能告诉我，哪个数据结构具有InfluxDB，而InfluxDB使用哪种数据模型？是这个键值模型。我阅读了完整的文档，但没有听懂。
先感谢您！
小智 5
1.数据模型和术语
InfluxDB数据库存储点。点由四个部分组成：度量，标签集，字段集和时间戳。
测量提供了一种关联可能具有不同标签集或字段集的相关点的方法。标签集是键值对的字典，用于存储带点的元数据。字段集是一组类型化的标量值-该点记录的数据。
点的序列化格式由[线路协议]定义（如果您想了解更多详细信息，它还包括其他示例和说明）。规范中的一个示例点有助于解释该术语：
”温度，机器= unit42，类型=组件内部= 32，外部= 100 1434055562000000035
测量是温度。
标签集是machine = unit42，type = assembly。标签集中的键，机器和类型称为标签键。标签集中的值unit42和assembly被称为标签值。
该字段集是internal = 32，external = 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，因此将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/
它本质上是键值对，键是时间，值可以是一个或多个字段/列。值也可以选择是索引列，在 influxdb 中称为标签，它们针对始终需要的时间搜索进行了优化。至少需要一个非索引值。
有关更多详细信息，请参阅架构设计文档。
事实上，很像 Cassandra，尽管 influx 本质上是写入时模式，而开发人员为 Cassandra 编写模式。
存储引擎方面再次与 Cassandra 非常相似，使用 Cassandra 中使用的 SSTable 变体，针对时间序列数据进行了优化。