输入格式与输出格式

目录

1. Line Protocol
   1. 添加多个字段
   2. 类型说明
   3. 类型冲突
   4. 添加标签
   5. 添加时间戳
   6. 时间戳精度说明
   7. 覆盖数据点
2. 带注释的 CSV
   1. 原始 CSV 与带注释的 CSV
   2. 标题行
   3. 记录行
   4. 记录与数据点
   5. 注释行
3. 从序列到磁盘上的表
   1. 添加字段
   2. 添加标签
4. 真实世界数据
   1. 使用 Flux 探索真实世界数据 Schema
   2. 真实世界数据练习
5. 延伸阅读

InfluxDB 的输入格式是 Line Protocol。InfluxDB 的输出格式是带注释的 CSV。InfluxDB 用户有时最初会感到困惑，因为使用 Line Protocol 类似于写入单个表，但是当他们查询相同的数据时，查询会以 CSV 格式返回多个表。这是因为以 Line Protocol 格式化的数据被 InfluxDB 摄取后，会被分成多个序列。理解摄取格式和时间序列之间的这种微妙关系对于良好的 Schema 设计和优化使用 InfluxDB 非常重要。

Line Protocol

Line Protocol 允许的最小行包括测量值、单个字段和该字段的值。测量值是桶内数据的最高分组。字段是测量值的一部分，并定义单个数据点。字段通过空格与测量值分隔。因此，最小的可读行如下所示：

measurement1 field1=1i

添加多个字段

您需要至少提供一个字段，但您可以在一行中提供任意数量的字段，用逗号分隔。

measurement1 field1=1i,field2=1,field3="a"

Line Protocol 非常紧凑，但是每个字段在存储到数据库中时都会位于自己的序列中。更多相关信息请参阅从序列到磁盘上的表。

类型说明

字段值的类型可以是整数、浮点数或字符串。默认情况下，数字将被解释为浮点数。在 my_field 的每个数字后添加“i”告诉 InfluxDB 我希望它们是整数。使用引号可确保 InfluxDB 知道我想要字符串类型。

类型冲突

创建序列后，您无法更改序列的字段类型。在写入此行后，InfluxDB 将拒绝以下写入：

measurement1 field1=1,field2="1",field3="a"

注意 field2 字段值已从字符串更改为浮点数。

measurement1 field1=1i,field2=1,field3="a"

添加标签

标签是您可以添加到 Line Protocol 行中的另一种数据。标签很有用，因为它们会被 InfluxDB 自动索引。使用和查询标签可以显着提高查询性能。此外，标签对于对查询进行分类也很有用。

请记住，序列由测量值、标签集和字段键定义。标签在测量值名称之后定义，并用逗号与之分隔。我可以将标签添加到之前的 Line Protocol 行中，如下所示：

measurement1,tag1=tagvalue1 field1=1i,field2=1,field3="a" 1626118680000000000
measurement1,tag1=tagvalue2 field1=2i,field2=2,field3="b" 1626118740000000000

引入标签键“tag1”，带有 2 个不同的标签值“tagvalue1”和“tagvalue2”，会生成 6 个序列 - 2 个标签值中的每个值的 3 个不同字段产生 3 个序列。

添加时间戳

如果 Line Protocol 中省略了时间戳，InfluxDB 将根据写入时的当前服务器时间添加时间戳。

让 InfluxDB 自动提供时间戳非常方便，但对于您的应用程序来说可能不够精确，因此您通常还需要提供时间戳。InfluxDB 期望时间戳是 Unix 时间戳。InfluxDB 还期望时间戳具有纳秒分辨率，但写入 API 允许您根据需要定义较低分辨率的精度。

时间戳位于 Line Protocol 行的末尾，并用空格与最后一个字段值分隔。向上述 Line Protocol 行提供时间戳如下所示：

measurement1 field1=1i,field2=1,field3="a" 1626118680000000000
measurement1 field1=2i,field2=2,field3="b" 1626118740000000000

时间戳精度说明

InfluxDB 中时间戳的原生分辨率是纳秒。在 InfluxDB 中，分辨率单位（例如纳秒、微秒、毫秒）称为时间戳的“精度”。例如：

• 1 微秒中有 1,000 纳秒
• 1 毫秒中有 1,000,000 纳秒
• 1 秒中有 1,000,000,000 纳秒

在构建应用程序时务必牢记这一点，因为许多系统无法处理纳秒分辨率，因此需要在它们之间进行转换。

请注意，InfluxDB 工具确实允许您定义时间戳的精度，因此在写入时，您可以让 InfluxDB 为您处理转换。这将在第三部分中介绍。

覆盖数据点

当您使用相同的序列和相同的时间戳写入数据时，您可以覆盖 InfluxDB 中的数据点。例如，如果您将以下 Line Protocol 行写入 InfluxDB：

measurement1 field1=2i,field2=2,field3="b" 1626118740000000000

然后，您可以通过接下来写入以下行来覆盖这 3 个数据点。

measurement1 field1=10i,field2=10,field3="overwritten" 1626118740000000000
<more examples that include partial overwrites, subsets of tags>

带注释的 CSV

带注释的 CSV 是 InfluxDB 的输出格式。**在使用简单查询或不对数据应用其他转换时**，带注释的 CSV 输出与 InfluxDB 持久化格式匹配。带注释的 CSV 结果是 Flux 返回的表流，其中每个表代表**仅针对简单查询的**一个序列。例如，如果您将此 Line Protocol 行写入 InfluxDB：

measurement1,tag1=tagvalue1 field1=1i

当查询测量值中的所有字段和标签（此处没有）时，您将返回以下完整的带注释的 CSV 输出：

#group,false,false,true,true,false,false,true,true,true
#datatype,string,long,dateTime:RFC3339,dateTime:RFC3339,dateTime:RFC3339,long,string,string,string
#default,_result,,,,,,,,
,result,table,_start,_stop,_time,_value,_field,_measurement,tag1
,,0,rfc3339time1,rfc3339time2,2021-08-17T21:23:39.000000000Z,1,field1,Measurement1,tagvalue1

请记住，该 Line Protocol 行产生 1 个序列，这就是带注释的 CSV 输出中包含一个表的原因。

原始 CSV 与带注释的 CSV

关于带注释的 CSV 输出格式，首先要注意的是它类似于您熟悉的 CSV 格式。为了便于区分两者，我们将 CSV 称为原始 CSV。与原始 CSV 不同，带注释的 CSV 包含以下行：

• 标题行
• 记录行
• 注释行

标题行

标题行类似于 CSV 中的任何标题行。它描述了时间序列数据的列名。标题行位于 3 个注释行下方。我们的标题行是：

,result,table,_start,_stop,_time,_value,_field,_measurement,tag1

其中一些标题是从 Line Protocol 直观转换而来的，而其他标题则不是。标题包括：

• result。此列包含查询指定的 result 名称。如果未提供名称，则为空。
• table。此列包含带注释的 CSV 输出结果中每个表的唯一 ID。在上面的示例中，我们只写入和查询 1 个序列，因此该表中该列的值设置为 0。
• _start。此列包含查询数据的时间范围的开始时间。指定范围对于任何 Flux 查询都是必需的。
• _stop。此列包含查询数据的时间范围的结束时间。指定范围对于任何 Flux 查询都是必需的。
• _time。此列是时间序列的时间戳。此列的值要么在写入时添加，要么在 Line Protocol 中显式包含。
• _value。此列包含 _field 列下同一行中相应字段键的字段值。
• _field。此列包含字段键。
• _measurement。此列包含测量值的名称。
• tag1。此列包含我们的 tag1 标签键的标签值。

在本节的其余部分，您可以忽略 _start、_stop 和 result 列的值。这些值是由用户在查询执行期间分配的。现在，只需专注于理解 Line Protocol 输入格式和生成的带注释 CSV 之间的相似之处。

记录行

记录行位于标题行的正下方。这些行包含我们的时间序列数据。每一行包含一条记录。一条记录是一个命名值的元组。每个表至少包含一条记录。当查询时间序列数据时，如果不添加任何 Flux 转换，一个表

记录 vs 数据点

记住，数据点是指特定时间戳下系列中的一个数据点。一条记录可以是一个数据点，但并非总是如此。例如，您可以使用 Flux 删除所有标签、字段和测量列。此时，注释 CSV 中的记录将不反映数据点，而是反映时间序列数据。

注释行

注释行位于完整注释 CSV 输出的前三行。注释包含关于注释 CSV 的元数据。使用 API 查询 InfluxDB 时，您可以指定要在注释 CSV 输出中包含哪些标题。当您通过 InfluxDB UI 导出查询结果时，默认情况下会包含所有 3 个标题。

这 3 个注释是

1. ​​#group：一个布尔值，指示该列是否属于分组键。分组键是一个列的列表，表中的每一行都具有相同的值。如果一列的​​#group 注释设置为​​true，则该列属于分组键。

   重要提示：table 列是一个例外。table 的分组键设置为 false，因为用户无法直接更改表编号。即使分组键设置为 false，表记录在所有行中也将始终相同。

2. #datatype：描述数据的类型或列所代表的行协议元素。
3. #default：用于空值行的值。

如果您对注释感到困惑，请不要担心。注释的重要性将在本书的后续章节中变得显而易见，尤其是在理解 Flux 方面。此外，值得一提的是，​​#group 注释是成功使用 Flux 最重要的注释。现在，请注意，InfluxDB 会将默认分组键应用于您的数据，以便注释 CSV 输出中的每个表都代表简单查询中的单个系列。这种默认应用分组键的方式是系列在磁盘上存储方式的结果，这将在下一节中进行描述。

从系列到磁盘上的表

每个系列都作为表存储在磁盘上。数据写入 InfluxDB 的存储桶中。将数据写入存储桶时，会将其添加到相应的表中，如果需要，还会创建新表。每个表都只有一个测量值、一个字段和一组唯一的标签值。在写入时创建或修改索引，以便在查询时能够快速找到这些表。此外，所有表中的所有行都按时间索引。

有些人认为 InfluxDB 是“无模式”数据库。然而，这并不准确。更准确地说，InfluxDB 是“写入时模式”。也就是说，InfluxDB 不需要预先定义模式，也不强制写入时遵循模式。相反，Influxdb 会根据您进行的写入隐式构建模式。

虽然写入时模式对开发人员来说确实很方便，但您应该了解在写入数据时隐式创建的模式。设计不良的模式会对查询的简易性、性能和基数等方面产生负面影响。

在本节中，我们将学习行协议如何生成系列，以及这些系列如何作为表存储在磁盘上。

添加字段

在本节中，我们将分解行协议如何转换为系列，以及如何作为表写入 InfluxDB。让我们回顾一下上面的行协议示例

measurement1 field1=1i,field2=1,field3="a"
measurement1 field1=1i,field2=2,field3="b"

假设每行写入间隔一分钟，写入时将形成 3 个不同的时间序列，每个序列包含 2 个数据点。然后，数据将保存在三个单独的表中

此示例提供了对输入格式和持久化/输出格式之间差异的初步了解。InfluxDB 中的每个系列都只持久化一个字段，尽管行协议允许多个字段写入。这是一个非常重要的概念，需要理解，因此值得重复。InfluxDB 输入格式与 InfluxDB 持久化和输出格式不同。

这些表代表系列中可能存在的最小数据角色。一个系列必须至少包含

• 测量名称
• 字段键
• 字段值
• 时间

这些在数据库中用前导“_”表示。前导下划线表示这些是存储引擎强制执行的系列中的“槽”，并有助于避免与潜在标签名称发生命名冲突。

在不添加任何其他 Flux 转换的情况下简单查询此数据时，带注释的 CSV 输出如下所示

#group,false,false,true,true,false,false,true,true
#datatype,string,long,dateTime:RFC3339,dateTime:RFC3339,dateTime:RFC3339,long,string,string
#default,_result,,,,,,,
,result,table,_start,_stop,_time,_value,_field,_measurement
,,0,rfc3339time1,rfc3339time2,2021-07-12T19:39:00.000000000Z,1,field1,measurement1
,,0,rfc3339time1,rfc3339time2,2021-07-12T19:38:00.00000000Z,1,field1,measurement1

#group,false,false,true,true,false,false,true,true
#datatype,string,long,dateTime:RFC3339,dateTime:RFC3339,dateTime:RFC3339,string,string,string
#default,_result,,,,,,,
,result,table,_start,_stop,_time,_value,_field,_measurement
,,1,rfc3339time1,rfc3339time2,2021-07-12T19:39:00.000000000Z,a,field3,measurement1
,,1,rfc3339time1,rfc3339time2,2021-07-12T19:38:00.00000000Z,b,field3,measurement1

#group,false,false,true,true,false,false,true,true
#datatype,string,long,dateTime:RFC3339,dateTime:RFC3339,dateTime:RFC3339,double,string,string
#default,_result,,,,,,,
,result,table,_start,_stop,_time,_value,_field,_measurement
,,2,rfc3339time1,rfc3339time2,2021-07-12T19:39:00.000000000Z,1,field2,measurement1
,,2,rfc3339time1,rfc3339time2,2021-07-12T19:38:00.000000000Z,2,field2,measurement1

请注意，生成的带注释 CSV 输出中包含 3 个表。这可以通过行分隔以及表最后一个流中table列的值（等于 2，记住带注释的 CSV 从 0 开始计数表结果）来证明。已将分组键添加到数据中以生成这些表，以便默认情况下每个表代表一个系列。记住，如果单个表中该列的所有值都相同，则该列属于分组键。例如，time 和 value 列的 #group 注释被指定为​​false。将 #group 注释设置为​​false允许将单个系列中不同时间戳和字段值的数据点包含在同一个表中。

添加标签

让我们回顾一下上面添加了标签的行协议示例

measurement1,tag1="tagvalue1" field1=1i,field2=1,field3="a" 1626118680000000000
measurement1,tag1="tagvalue2" field1=2i,field2=2,field3="b" 1626118740000000000

引入 tag1 会生成以下 6 个系列

请确保您花时间研究并理解行协议与生成的表之间的关系，因为存储引擎在磁盘上表示这些表。这种关系对于实现最有效的模式和应用程序查询至关重要。

在不添加任何其他 Flux 转换的情况下简单查询此数据时，带注释的 CSV 输出如下所示

#group,false,false,true,true,false,false,true,true,true
#datatype,string,long,dateTime:RFC3339,dateTime:RFC3339,dateTime:RFC3339,string,string,string,string
#default,_result,,,,,,,,
,result,table,_start,_stop,_time,_value,_field,_measurement,tag1
,,0,rfc3339time1,rfc3339time2,2021-07-12T19:39:000000000Z,b,field3,measurement1,tagvalue2

#group,false,false,true,true,false,false,true,true,true
#datatype,string,long,dateTime:RFC3339,dateTime:RFC3339,dateTime:RFC3339,double,string,string,string
#default,_result,,,,,,,,
,result,table,_start,_stop,_time,_value,_field,_measurement,tag1
,,1,rfc3339time1,rfc3339time2,2021-07-12T19:38:000000000Z,1,field2,measurement1,tagvalue1

#group,false,false,true,true,false,false,true,true,true
#datatype,string,long,dateTime:RFC3339,dateTime:RFC3339,dateTime:RFC3339,long,string,string,string
#default,_result,,,,,,,,
,result,table,_start,_stop,_time,_value,_field,_measurement,tag1
,,2,2021-01-18T20:59:37Z,2021-08-17T19:59:37.097Z,2021-07-12T19:38:000000000Z,1,field1,measurement1,tagvalue1

#group,false,false,true,true,false,false,true,true,true
#datatype,string,long,dateTime:RFC3339,dateTime:RFC3339,dateTime:RFC3339,string,string,string,string
#default,_result,,,,,,,,
,result,table,_start,_stop,_time,_value,_field,_measurement,tag1
,,3,rfc3339time1,rfc3339time2,2021-07-12T19:38:000000000Z,a,field3,measurement1,tagvalue1

#group,false,false,true,true,false,false,true,true,true
#datatype,string,long,dateTime:RFC3339,dateTime:RFC3339,dateTime:RFC3339,long,string,string,string
#default,_result,,,,,,,,
,result,table,_start,_stop,_time,_value,_field,_measurement,tag1
,,4,rfc3339time1,rfc3339time2,2021-07-12T19:39:000000000Z,2,field1,measurement1,tagvalue2

#group,false,false,true,true,false,false,true,true,true
#datatype,string,long,dateTime:RFC3339,dateTime:RFC3339,dateTime:RFC3339,double,string,string,string
#default,_result,,,,,,,,
,result,table,_start,_stop,_time,_value,_field,_measurement,tag1
,,5,rfc3339time1,rfc3339time2,2021-07-12T19:39:000000000Z,2,field2,measurement1,tagvalue2

请注意，生成的带注释 CSV 输出中包含 6 个表。这可以通过行分隔以及表最后一个流中table列的值（等于 5，记住带注释的 CSV 从 0 开始计数表结果）来证明。已将分组键添加到数据中以生成这些表，以便默认情况下每个表代表一个系列。记住，如果单个表中该列的所有值都相同，则该列属于分组键。例如，time 列的 #group 注释被指定为​​false。将 #group 注释设置为​​false允许将单个系列中不同时间戳的数据点包含在同一个表中。相反，_measurement 列的 #group 注释被指定为​​true。将 #group 注释设置为​​true强制该表中的所有记录都具有相同的测量值。记住，一个系列由测量值、标签集和字段的唯一组合来标识。如果一个表要表示一个系列，则该表必须在所有行中包含具有相同测量值、标签集和字段的记录。

重要提示：您可以使用 Flux 来操作分组键和输出带注释 CSV 表流中生成的表数量。我们将在后面的章节中学习如何做到这一点。

现在，让我们专注于理解行协议如何生成不同的系列。我们可以通过添加其他标签来扩展示例，但在这种情况下，请注意 tag2只有一个标签值

measurement1,tag1="tagvalue1",tag2="tagvalue3" field1=1i,field2=1,field3="a" 1626118680000000000
measurement1,tag1="tagvalue2",tag2="tagvalue3" field1=2i,field2=2,field3="b" 1626118740000000000

同样，每个系列都由其唯一的标签键、标签值和字段键组合来标识。由于系列部分由一组唯一的标签*值*定义，因此在本例中，引入 tag2 不会更改底层数据模型中的表计数。当引入标签不会更改底层数据模型中的表计数时，该标签称为依赖标签

为了演示标签值组合对时间序列创建的影响，以下是三行行协议，但只有一个字段

measurement1,tag1="tagvalue1",tag2="tagvalue4" field1=1i 1626118620000000000
measurement1,tag1="tagvalue2",tag2="tagvalue5" field1=2i 1626118680000000000
measurement1,tag1="tagvalue3",tag2="tagvalue6" field1=3i 1626118740000000000

在这 3 行中，标签值和单个字段有 3 个唯一组合，因此，尽管共有 6 个标签值，但只创建了 3 个系列

在此示例中，只有 2 个唯一的标签值组合

measurement1,tag1="tagvalue1",tag2="tagvalue4" field1=1i 1626118620000000000
measurement1,tag1="tagvalue1",tag2="tagvalue4" field1=2i 1626118680000000000
measurement1,tag1="tagvalue2",tag2="tagvalue4" field1=3i 1626118740000000000

因此，第一个系列包含两个数据点，因为这两个数据点具有相同的字段名称和标签值组合，而第三个数据点具有一组不同的标签值。

真实世界数据

InfluxData 维护着一个优秀的半实时行协议数据存储库。这通常用作示例数据，以帮助您开始探索 InfluxDB。目前，那里有 4 个数据集保持最新

1. 空气传感器数据：此数据集包含一个标签，该标签是报告 3 个字段（温度、湿度和一氧化碳水平）的特定空气质量传感器的 ID。
2. 鸟类迁徙数据：这是一个地理空间数据集，表示鸟类的迁徙运动。它被标记以辅助地理空间查询。
3. NOAA 国家浮标中心数据：此数据集提供了来自 NOAA NDBC 浮标网络的最新观测结果。它包含大量标签和字段。
4. USGS 地震数据。美国地质调查局 (USGS) 地震数据集包含地震活动数据。这是一个非常大的数据集，包含更多的标签和字段。

您可以简单地将任何真实世界样本数据集中的 Flux 复制到数据资源管理器中的脚本编辑器中并可视化数据。我建议创建一个桶，并使用 to() 函数将数据写入该桶，如第 1 部分写入和查询示例数据中所述。将数据写入 InfluxDB 中的桶允许您使用 Flux 来探索数据集的模式。

重要提示：如果您将较大的数据集写入 InfluxDB，则可能会达到免费套餐帐户的序列基数限制。如果您使用的是免费套餐帐户，我建议只写入空气传感器数据。

重要提示：本节建议您使用 InfluxDB UI 将数据写入 InfluxDB，因为尚未介绍使用其他工具写入数据。我们建议使用 CLI 或 VS Code 写入数据。如果您更喜欢使用这些工具进行开发，请查看

使用 Flux 探索真实世界数据模式

让我们将注意力转向 2 个真实世界数据集：空气传感器数据和NOAA 国家浮标中心数据。我们将使用 Flux 来了解我们的模式。然后，我们将进行一些练习，以确保我们理解行协议输入格式与存储引擎在磁盘上持久化的 InfluxDB 数据模型之间的关系。

我们将首先关注空气传感器数据集，因为它是最简单的数据集。空气传感器数据集包含

• 1 个测量值：airSensors
• 3 个字段
  • co
  • humidity
  • temperature
• 1 个标签：sensor_id
  • 8 个 sensor_id 标签值

如您所见，字段是实际数据，在本例中均为浮点型，而标签是元数据，定义了哪个传感器生成了数据。

使用Flux 探索您的数据模式，通过使用 schema 包获取数据中测量值、标签键、标签值和字段键的数量。

要从空气传感器样本数据集中获取 airSensors 测量值中的字段数量，请在您的首选工具（CLI、VS Code、InfluxDB UI）中运行以下 Flux 查询

import "influxdata/influxdb/schema"

schema.measurementFieldKeys(
  bucket: "Air sensor sample dataset",
  measurement: "airSensors"
)
|> count()

要从空气传感器样本数据集中获取 airSensors 测量值中的标签键数量，请在您的首选工具（CLI、VS Code、InfluxDB UI）中运行以下 Flux 查询

import "influxdata/influxdb/schema"

schema.measurementTagKeys(
  bucket: "Air sensor sample dataset",
  measurement: "airSensors"
)
|> count()

要从空气传感器样本数据集中获取 airSensors 测量值中 sensor_id 标签键的标签值数量，请使用以下 Flux 查询（CLI、VS Code、InfluxDB UI）

import "influxdata/influxdb/schema"

schema.measurementTagValues(
  bucket: "Air sensor sample dataset",
  tag: "sensor_id",
  measurement: "example-measurement"
)
|> count()

我们可以对NOAA 国家浮标中心数据重复相同的方法。我们发现NOAA 国家浮标中心数据具有以下模式

• 1 个测量值：ndbc
• 21 个字段
  • air_temp_degc
  • avg_wave_period_sec
  • dewpoint_temp_degc
  • dominate_wave_period_sec
  • gust_speed_mps
  • lat
  • lon
  • pressure_temdancy_hpa
  • sea_level_pressure_hpa
  • sea_surface_temp_degc
  • significant_Wave_height_m
  • station_currents
  • station_dart
  • station_elev
  • station_met
  • station_visibility_mei
  • station_waterquality
  • water_level_ft
  • wave_dir_degt
  • wind_dir_degt
  • wind_spead_mps
• 5 个标签键
  • station_id
    • 113 个 station_id 标签值
  • station_name
    • 828
  • station_owner
    • 57 个 station_owner 标签值
  • station_pgm
    • 6 个 station_pgm 标签值
  • station_type
    • 4 个 station_type 标签值

同样，请注意，21 个字段是气象站可能收集的所有不同种类的数据，而 5 个标签包含有关哪些气象站收集数据的元数据。

真实世界数据练习

现在我们了解了 2 个真实世界数据集的模式，空气传感器数据和NOAA 国家浮标中心数据，尝试回答以下问题以测试您对模式设计、行协议和

问题 1：根据上述模式，空气传感器数据将创建多少个序列？

答案 1：(1 个 sensor_id 标签 x 8 个唯一标签值) x (3 个字段) = 4 x 3 = 24

问题 2：根据上述模式，NOAA 国家浮标中心数据将创建多少个序列（假设没有依赖标签）？

答案 2：(1 station_id 标签 x 113 个唯一标签值) x (1 station_name 标签 x 828 个唯一标签值) x (1 station_owner 标签 x 57 个唯一标签值) x (1 station_pgm 标签 x 6 个唯一标签值) x (1 station_type 标签 x 47 个唯一标签值) x (21 个字段) = 113 x 828 x 57 x 6 x 47 x 21 = 31,028,816,448

问题 3：以下来自空气传感器样本数据集的行协议将如何在磁盘上的表中组织？每个序列中有多少个点？

airSensors,sensor_id=TLM0100 temperature=71.17615703642676,humidity=35.12940716174776,co=0.5024058630839136 1626537623000000000
airSensors,sensor_id=TLM0101 temperature=71.80350992863588,humidity=34.864121891949736,co=0.4925449578765155 1626537623000000000
airSensors,sensor_id=TLM0102 temperature=72.02673296407973,humidity=34.91147650009415,co=0.4941631223400505 1626537623000000000
airSensors,sensor_id=TLM0103 temperature=71.34822444566278,humidity=35.19576623496297,co=0.4046734235304059 1626537623000000000
airSensors,sensor_id=TLM0200 temperature=73.57230556533555,humidity=35.77102288427073,co=0.5317633226995193 1626537623000000000
airSensors,sensor_id=TLM0201 temperature=72.57230556533555,humidity=35.17327249047271,co=0.5000439017037601 1626537623000000000
airSensors,sensor_id=TLM0202 temperature=75.28582430811852,humidity=35.668729783597556,co=0.48071553398947864 1626537623000000000
airSensors,sensor_id=TLM0203 temperature=74.75927935923579,humidity=35.89268792033798,co=0.4089308476612381 1626537623000000000
airSensors,sensor_id=TLM0100 temperature=71.2194835668512,humidity=35.12891266051405,co=0.4958773037139102 1626537633000000000
airSensors,sensor_id=TLM0101 temperature=71.78232293801005,humidity=34.88621453634278,co=0.5074032895942003 1626537633000000000
airSensors,sensor_id=TLM0102 temperature=72.07101160147653,humidity=34.938529830668536,co=0.5102716855442547 1626537633000000000
airSensors,sensor_id=TLM0103 temperature=71.32889101333731,humidity=35.21581883021604,co=0.4245915521103036 1626537633000000000
airSensors,sensor_id=TLM0200 temperature=73.55081075397399,humidity=35.74330537831752,co=0.5435288991742965 1626537633000000000
airSensors,sensor_id=TLM0201 temperature=74.06284877512215,humidity=35.17611147751894,co=0.4813785832360323 1626537633000000000
airSensors,sensor_id=TLM0202 temperature=75.29425020175684,humidity=35.64366062740866,co=0.4911462705616819 1626537633000000000
airSensors,sensor_id=TLM0203 temperature=74.77142594525142,humidity=35.941017361190255,co=0.42797647488504065 1626537633000000000

答案 3

行协议将生成以下序列和磁盘上的表。每个序列包含来自上述行协议的两个点。

下一节

进一步阅读

1. TL;DR InfluxDB 技术提示 - 如何解释带注释的 CSV
2. Line Protocol