小 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其中：
=,= =,= tag_set 中所有的数据自动转化为 nchar 数据类型，并不需要使用双引号（”)。在无模式写入数据行协议中，field_set 中的每个数据项都需要对自身的数据类型进行描述。具体来说：
"abc"。L"报错信息"。例如如下数据行表示：向名为 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，其他的行会忽略。
此外，在处理行数据时，其他原则如下所示：
注意，无模式所有的处理逻辑仍会遵循 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上查看相关源代码。