TDengine：无模式写入行协议的四种方式

小 T 导读：为了在数据采集项频繁变动的情况下保证用户仍然能够顺利地完成数据记录工作，TDengine 提供了三种无模式写入协议，分别是 InfluxDB Line 协议、OpenTSDB Telnet 协议和 OpenTSDB JSON 格式协议。本文将对无模式写入方式的主要处理逻辑、映射规则与变更处理等进行分析，便于用户理解与使用。

通常来说，物联网应用常会采集比较多的数据项，用于实现智能控制、业务分析、设备监控等功能。但在此过程中，由于应用逻辑的版本升级，或者设备自身的硬件调整等原因，数据采集项可能较为频繁地出现变动。这也是时序数据库（Time Series Database，TSDB）需要应对的一个挑战。

为了在这种情况下顺利完成数据记录工作，TDengine 提供了 Schemaless 写入方式，让用户可以省略掉预先创建超级表/子表的步骤，凭借数据写入接口能够自动创建与数据对应的存储结构。在必要时，Schemaless 将自动增加必要的数据列，保证用户写入的数据能够被正确存储。

值得一提的是，通过无模式写入方式建立的超级表及其对应的子表，与通过 SQL 直接建立的超级表和子表完全没有区别，你也可以通过 SQL 语句直接向其中写入数据。但需要注意，通过无模式写入方式建立的表，其表名是基于标签值按照固定的映射规则生成的，所以无法明确地进行表意，缺乏可读性。

无模式写入行协议

TDengine 的无模式写入行协议兼容 InfluxDB 的行协议（Line Protocol）、OpenTSDB 的 telnet 行协议、OpenTSDB 的 JSON 格式协议。但是使用这三种协议的时候，需要在 API 中指定输入内容使用解析协议的标准。

对于 InfluxDB、OpenTSDB 的标准写入协议请参考《在 TDengine 中如何高效写入？四种写入方式提效大全》。下面首先以 InfluxDB 的行协议为基础，介绍 TDengine 扩展的协议内容，允许用户采用更加精细的方式控制（超级表）模式。

Schemaless 采用一个字符串来表达一个数据行（可以向写入 API 中一次传入多行字符串来实现多个数据行的批量写入），其格式约定如下：

measurement,tag_set field_set timestamp

其中：

measurement 将作为数据表名。它与 tag_set 之间使用一个英文逗号来分隔。
tag_set 将作为标签数据，其格式形如 <tag_key>=<tag_value>,<tag_key>=<tag_value>，也即可以使用英文逗号来分隔多个标签数据。它与 field_set 之间使用一个半角空格来分隔。
field_set 将作为普通列数据，其格式形如 <field_key>=<field_value>,<field_key>=<field_value>，同样是使用英文逗号来分隔多个普通列的数据。它与 timestamp 之间使用一个半角空格来分隔。
timestamp 即本行数据对应的主键时间戳。

tag_set 中所有的数据自动转化为 nchar 数据类型，并不需要使用双引号（”)。在无模式写入数据行协议中，field_set 中的每个数据项都需要对自身的数据类型进行描述。具体来说：

如果两边有英文双引号，表示 BINARY(32) 类型。例如 "abc"。
如果两边有英文双引号而且带有 L 前缀，表示 NCHAR(32) 类型。例如 L"报错信息"。
对空格、等号（=）、逗号（,）、双引号（”），前面需要使用反斜杠（\）进行转义（都指的是英文半角符号）。
数值类型将通过后缀来区分数据类型，如后缀为无或 f64，映射的数据类型为 double；后缀为 f32，映射为 float，可移步 Schemaless 写入 | TDengine 文档 | 涛思数据了解更多的后缀及映射类型。
t, T, true, True, TRUE, f, F, false, False 将直接作为 BOOL 型来处理。

例如如下数据行表示：向名为 st 的超级表下的 t1 标签为 “3”（NCHAR）、t2 标签为 “4”（NCHAR）、t3 标签为 “t3″（NCHAR）的数据子表，写入 c1 列为 3（BIGINT）、c2 列为 false（BOOL）、c3 列为 “passit”（BINARY）、c4 列为 4（DOUBLE）、主键时间戳为 1626006833639000000 的一行数据。

st,t1=3,t2=4,t3=t3 c1=3i64,c3="passit",c2=false,c4=4f64 1626006833639000000

需要注意的是，如果描述数据类型后缀时使用了错误的大小写，或者为数据指定的数据类型有误，均可能引发报错提示而导致数据写入失败。

无模式写入的主要处理逻辑

无模式写入使用如下规则来生成子表名：首先将 measurement 的名称和标签的 key 和 value 组合成为如下的字符串——

"measurement,tag_key1=tag_value1,tag_key2=tag_value2"

需要注意的是，这里的 tagkey1，tag_key2 并不是用户输入的标签的原始顺序，而是使用了标签名称按照字符串升序排列后的结果，所以，tag_key1 并不是在行协议中输入的第一个标签。排列完成以后计算该字符串的 MD5 散列值为 “md5_val”，我们将计算的结果与字符串组合生成表名：“t_md5_val”，其中的 “t” 是固定的前缀，每个通过该映射关系自动生成的表都具有该前缀。

用户可以通过在 taos.cfg 里配置 smlChildTableName 参数来指定生成的表名。举例如下：配置 smlChildTableName=tname 插入数据为 st,tname=cpu1,t1=4 c1=3 1626006833639000000，则创建的表名为 cpu1，注意如果多行数据 tname 相同，但是后面的 tag_set 不同，则使用第一行自动建表时指定的 tag_set，其他的行会忽略。

此外，在处理行数据时，其他原则如下所示：

如果解析行协议获得的超级表不存在，则会自动创建这个超级表（不建议手动创建超级表，不然插入数据可能异常）。
如果解析行协议获得子表不存在，则 Schemaless 会按照步骤 1 或 2 确定的子表名来创建子表。
如果数据行中指定的标签列或普通列不存在，则在超级表中增加对应的标签列或普通列（只增不减）。
如果超级表中存在一些标签列或普通列未在一个数据行中被指定取值，那么这些列的值在这一行中会被置为 NULL。
对 BINARY 或 NCHAR 列，如果数据行中所提供值的长度超出了列类型的限制，自动增加该列允许存储的字符长度上限（只增不减），以保证数据的完整保存。
整个处理过程中遇到的错误会中断写入过程，并返回错误代码。
为了提高写入的效率，默认假设同一个超级表中 field_set 的顺序是一样的（第一条数据包含所有的 field，后面的数据按照这个顺序），如果顺序不一样，需要配置参数 smlDataFormat 为 false，否则，数据写入按照相同顺序写入，库中数据会异常。

注意，无模式所有的处理逻辑仍会遵循 TDengine 对数据结构的底层限制，例如每行数据的总长度不能超过 16KB。这方面的具体限制约束请参见 TDengine SQL 边界限制（命名与边界 | TDengine 文档 | 涛思数据）。

数据模式映射规则与变更处理

以 InfluxDB 行协议为例，其数据如何映射成为具有模式的数据？从上文中我们了解到，每个行协议中数据 measurement 映射为超级表名称，tag_set 中的标签名称为数据模式中的标签名，field_set 中的名称为列名称。以如下数据为例，说明映射规则：

st,t1=3,t2=4,t3=t3 c1=3i64,c3="passit",c2=false,c4=4f64 1626006833639000000

该行数据映射生成一个超级表：st，其包含了 3 个类型为 nchar 的标签，分别是：t1, t2, t3；五个数据列，分别是 ts（timestamp），c1 (bigint），c3(binary)，c2 (bool), c4 (bigint）。映射成为如下 SQL 语句：

create stable st (_ts timestamp, c1 bigint, c2 bool, c3 binary(6), c4 bigint) tags(t1 nchar(1), t2 nchar(1), t3 nchar(2))

在数据模式变更处理中，不同行数据写入情况下，对于数据模式的影响也不同。在使用行协议写入一个明确标识的字段类型时，后续再更改该字段的类型定义，会出现明确的数据模式错误，即会触发写入 API 报告错误。如下所示：

st,t1=3,t2=4,t3=t3 c1=3i64,c3="passit",c2=false,c4=4    1626006833639000000
st,t1=3,t2=4,t3=t3 c1=3i64,c3="passit",c2=false,c4=4i   1626006833640000000

第一行的数据类型映射将 c4 列定义为 Double，但是第二行的数据又通过数值后缀方式声明该列为 BigInt，由此会触发无模式写入的解析错误。如果列前面的行协议将数据列声明为了 binary，后续的要求长度更长的 binary 长度，此时会触发超级表模式的变更。

st,t1=3,t2=4,t3=t3 c1=3i64,c5="pass"     1626006833639000000
st,t1=3,t2=4,t3=t3 c1=3i64,c5="passit"   1626006833640000000

第一行中行协议解析会声明 c5 列是一个 binary(4)的字段，第二次行数据写入会提取列 c5 仍然是 binary 列，但是其宽度为 6，此时需要将 binary 的宽度增加到能够容纳新字符串的宽度。

st,t1=3,t2=4,t3=t3 c1=3i64               1626006833639000000
st,t1=3,t2=4,t3=t3 c1=3i64,c6="passit"   1626006833640000000

第二行数据相对于第一行来说增加了一个列 c6，类型为 binary(6)。那么此时会自动增加一个列 c6，类型为 binary(6)。

写在最后

受篇幅所限，关于无模式写入的时间分辨率识别、写入完整性、错误码等内容请参考 Schemaless 写入 | TDengine 文档 | 涛思数据。如有更多问题，欢迎加入 TDengine 用户交流群，届时将会有专业的技术人员为你解惑。

欢迎添加小T（VX：TDengine），加入物联网技术讨论群，第一时间了解TDengine 官方信息，与关注前沿技术的同学们共同探讨新技术、新玩法。

想了解更多 TDengine Database的具体细节，欢迎大家在GitHub上查看相关源代码。