关于tdengine:TDengine无模式写入行协议的四种方式

2次阅读

共计 4379 个字符,预计需要花费 11 分钟才能阅读完成。

小 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,可移步 https://docs.taosdata.com/ref… 理解更多的后缀及映射类型。
  • 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 边界限度(https://docs.taosdata.com/tao…)。

数据模式映射规定与变更解决

以 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)。

写在最初

受篇幅所限,对于无模式写入的工夫分辨率辨认、写入完整性、错误码等内容请参考 https://docs.taosdata.com/ref…。如有更多问题,欢送退出 TDengine 用户交换群,届时将会有业余的技术人员为你解惑。

欢送增加小 T(VX:TDengine),退出物联网技术探讨群,第一工夫理解 TDengine 官网信息,与关注前沿技术的同学们独特探讨新技术、新玩法。


想理解更多 TDengine Database 的具体细节,欢送大家在 GitHub 上查看相干源代码。

正文完
 0