请告诉我，哪个数据结构有InfluxDB和InfluxDB使用哪种数据模型？这是键值模型吗？我阅读了完整的文档，但我没有理解。
提前谢谢！
答案 0 :(得分：3)
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/
答案 1 :(得分：1)
它本质上是键值，键是时间，其中值可以是一个或多个字段/列。值也可以选择是索引列，在Influxdb中称为标记，它们被优化用于搜索以及始终需要的时间。至少需要一个非索引值。
请参阅schema design documentation for more details。
事实上，就像Cassandra一样，虽然在开发人员为Cassandra编写模式时，涌入本质上是写入模式的。
存储引擎再次非常类似于Cassandra，using a variation of SSTables as used in Cassandra，针对时间序列数据进行了优化。
答案 2 :(得分：0)
我不确定在寻找答案时是否存在以下流入文档：
https://docs.influxdata.com/influxdb/v1.5/concepts/key_concepts/
但这确实帮助我了解了influxdb的数据结构。