小 T 導讀：為了在數(shù)據(jù)采集項頻繁變動的情況下保證用戶仍然能夠順利地完成數(shù)據(jù)記錄工作，TDengine 提供了三種無模式寫入?yún)f(xié)議，分別是 InfluxDB Line 協(xié)議、OpenTSDB Telnet 協(xié)議和 OpenTSDB JSON 格式協(xié)議。本文將對無模式寫入方式的主要處理邏輯、映射規(guī)則與變更處理等進行分析，便于用戶理解與使用。

通常來說，物聯(lián)網(wǎng)應用常會采集比較多的數(shù)據(jù)項，用于實現(xiàn)智能控制、業(yè)務分析、設備監(jiān)控等功能。但在此過程中，由于應用邏輯的版本升級，或者設備自身的硬件調(diào)整等原因，數(shù)據(jù)采集項可能較為頻繁地出現(xiàn)變動。這也是時序數(shù)據(jù)庫（Time Series Database，TSDB）需要應對的一個挑戰(zhàn)。

為了在這種情況下順利完成數(shù)據(jù)記錄工作，TDengine 時序數(shù)據(jù)庫 提供了 Schemaless 寫入方式，讓用戶可以省略掉預先創(chuàng)建超級表/子表的步驟，憑借數(shù)據(jù)寫入接口能夠自動創(chuàng)建與數(shù)據(jù)對應的存儲結構。在必要時，Schemaless 將自動增加必要的數(shù)據(jù)列，保證用戶寫入的數(shù)據(jù)能夠被正確存儲。

值得一提的是，通過無模式寫入方式建立的超級表及其對應的子表，與通過 SQL 直接建立的超級表和子表完全沒有區(qū)別，你也可以通過 SQL 語句直接向其中寫入數(shù)據(jù)。但需要注意，通過無模式寫入方式建立的表，其表名是基于標簽值按照固定的映射規(guī)則生成的，所以無法明確地進行表意，缺乏可讀性。

無模式寫入行協(xié)議

TDengine 的無模式寫入行協(xié)議兼容 InfluxDB 的行協(xié)議（Line Protocol）、OpenTSDB 的 telnet 行協(xié)議、OpenTSDB 的 JSON 格式協(xié)議。但是使用這三種協(xié)議的時候，需要在 API 中指定輸入內(nèi)容使用解析協(xié)議的標準。

對于 InfluxDB、OpenTSDB 的標準寫入?yún)f(xié)議請參考《在 TDengine 中如何高效寫入？四種寫入方式提效大全》。下面首先以 InfluxDB 的行協(xié)議為基礎，介紹 TDengine 擴展的協(xié)議內(nèi)容，允許用戶采用更加精細的方式控制（超級表）模式。

Schemaless 采用一個字符串來表達一個數(shù)據(jù)行（可以向?qū)懭?API 中一次傳入多行字符串來實現(xiàn)多個數(shù)據(jù)行的批量寫入），其格式約定如下：

measurement,tag_set field_set timestamp

其中：

• measurement 將作為數(shù)據(jù)表名。它與 tag_set 之間使用一個英文逗號來分隔。
• tag_set 將作為標簽數(shù)據(jù)，其格式形如 <tag_key>=<tag_value>,<tag_key>=<tag_value>，也即可以使用英文逗號來分隔多個標簽數(shù)據(jù)。它與 field_set 之間使用一個半角空格來分隔。
• field_set 將作為普通列數(shù)據(jù)，其格式形如 <field_key>=<field_value>,<field_key>=<field_value>，同樣是使用英文逗號來分隔多個普通列的數(shù)據(jù)。它與 timestamp 之間使用一個半角空格來分隔。
• timestamp 即本行數(shù)據(jù)對應的主鍵時間戳。

tag_set 中所有的數(shù)據(jù)自動轉(zhuǎn)化為 nchar 數(shù)據(jù)類型，并不需要使用雙引號（”)。在無模式寫入數(shù)據(jù)行協(xié)議中，field_set 中的每個數(shù)據(jù)項都需要對自身的數(shù)據(jù)類型進行描述。具體來說：

• 如果兩邊有英文雙引號，表示 BINARY(32) 類型。例如 "abc"。
• 如果兩邊有英文雙引號而且?guī)в?L 前綴，表示 NCHAR(32) 類型。例如 L"報錯信息"。
• 對空格、等號（=）、逗號（,）、雙引號（”），前面需要使用反斜杠（\）進行轉(zhuǎn)義（都指的是英文半角符號）。
• 數(shù)值類型將通過后綴來區(qū)分數(shù)據(jù)類型，如后綴為無或 f64，映射的數(shù)據(jù)類型為 double；后綴為 f32，映射為 float，可移步 https://docs.taosdata.com/reference/schemaless/ 了解更多的后綴及映射類型。
• t, T, true, True, TRUE, f, F, false, False 將直接作為 BOOL 型來處理。

例如如下數(shù)據(jù)行表示：向名為 st 的超級表下的 t1 標簽為 “3”（NCHAR）、t2 標簽為 “4”（NCHAR）、t3 標簽為 “t3″（NCHAR）的數(shù)據(jù)子表，寫入 c1 列為 3（BIGINT）、c2 列為 false（BOOL）、c3 列為 “passit”（BINARY）、c4 列為 4（DOUBLE）、主鍵時間戳為 1626006833639000000 的一行數(shù)據(jù)。

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

需要注意的是，如果描述數(shù)據(jù)類型后綴時使用了錯誤的大小寫，或者為數(shù)據(jù)指定的數(shù)據(jù)類型有誤，均可能引發(fā)報錯提示而導致數(shù)據(jù)寫入失敗。

無模式寫入的主要處理邏輯

無模式寫入使用如下規(guī)則來生成子表名：首先將 measurement 的名稱和標簽的 key 和 value 組合成為如下的字符串——

"measurement,tag_key1=tag_value1,tag_key2=tag_value2"

需要注意的是，這里的 tagkey1，tag_key2 并不是用戶輸入的標簽的原始順序，而是使用了標簽名稱按照字符串升序排列后的結果，所以，tag_key1 并不是在行協(xié)議中輸入的第一個標簽。 排列完成以后計算該字符串的 MD5 散列值為 “md5_val”，我們將計算的結果與字符串組合生成表名：“t_md5_val”，其中的 “t” 是固定的前綴，每個通過該映射關系自動生成的表都具有該前綴。

用戶可以通過在 taos.cfg 里配置 smlChildTableName 參數(shù)來指定生成的表名。 舉例如下：配置 smlChildTableName=tname 插入數(shù)據(jù)為 st,tname=cpu1,t1=4 c1=3 1626006833639000000，則創(chuàng)建的表名為 cpu1，注意如果多行數(shù)據(jù) tname 相同，但是后面的 tag_set 不同，則使用第一行自動建表時指定的 tag_set，其他的行會忽略。

此外，在處理行數(shù)據(jù)時，其他原則如下所示：

1. 如果解析行協(xié)議獲得的超級表不存在，則會自動創(chuàng)建這個超級表（不建議手動創(chuàng)建超級表，不然插入數(shù)據(jù)可能異常）。
2. 如果解析行協(xié)議獲得子表不存在，則 Schemaless 會按照步驟 1 或 2 確定的子表名來創(chuàng)建子表。
3. 如果數(shù)據(jù)行中指定的標簽列或普通列不存在，則在超級表中增加對應的標簽列或普通列（只增不減）。
4. 如果超級表中存在一些標簽列或普通列未在一個數(shù)據(jù)行中被指定取值，那么這些列的值在這一行中會被置為 NULL。
5. 對 BINARY 或 NCHAR 列，如果數(shù)據(jù)行中所提供值的長度超出了列類型的限制，自動增加該列允許存儲的字符長度上限（只增不減），以保證數(shù)據(jù)的完整保存。
6. 整個處理過程中遇到的錯誤會中斷寫入過程，并返回錯誤代碼。
7. 為了提高寫入的效率，默認假設同一個超級表中 field_set 的順序是一樣的（第一條數(shù)據(jù)包含所有的 field，后面的數(shù)據(jù)按照這個順序），如果順序不一樣，需要配置參數(shù) smlDataFormat 為 false，否則，數(shù)據(jù)寫入按照相同順序?qū)懭?，庫中?shù)據(jù)會異常。

注意，無模式所有的處理邏輯仍會遵循 TDengine 對數(shù)據(jù)結構的底層限制，例如每行數(shù)據(jù)的總長度不能超過 16KB。這方面的具體限制約束請參見 TDengine SQL 邊界限制（https://docs.taosdata.com/taos-sql/limit/）。

數(shù)據(jù)模式映射規(guī)則與變更處理

以 InfluxDB 行協(xié)議為例，其數(shù)據(jù)如何映射成為具有模式的數(shù)據(jù)？從上文中我們了解到，每個行協(xié)議中數(shù)據(jù) measurement 映射為超級表名稱，tag_set 中的標簽名稱為數(shù)據(jù)模式中的標簽名，field_set 中的名稱為列名稱。以如下數(shù)據(jù)為例，說明映射規(guī)則：

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

該行數(shù)據(jù)映射生成一個超級表：st， 其包含了 3 個類型為 nchar 的標簽，分別是：t1, t2, t3；五個數(shù)據(jù)列，分別是 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))

在數(shù)據(jù)模式變更處理中，不同行數(shù)據(jù)寫入情況下，對于數(shù)據(jù)模式的影響也不同。在使用行協(xié)議寫入一個明確標識的字段類型時，后續(xù)再更改該字段的類型定義，會出現(xiàn)明確的數(shù)據(jù)模式錯誤，即會觸發(fā)寫入 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

第一行的數(shù)據(jù)類型映射將 c4 列定義為 Double， 但是第二行的數(shù)據(jù)又通過數(shù)值后綴方式聲明該列為 BigInt， 由此會觸發(fā)無模式寫入的解析錯誤。如果列前面的行協(xié)議將數(shù)據(jù)列聲明為了 binary， 后續(xù)的要求長度更長的 binary 長度，此時會觸發(fā)超級表模式的變更。

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

第一行中行協(xié)議解析會聲明 c5 列是一個 binary(4)的字段，第二次行數(shù)據(jù)寫入會提取列 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

第二行數(shù)據(jù)相對于第一行來說增加了一個列 c6，類型為 binary(6)。那么此時會自動增加一個列 c6， 類型為 binary(6)。

寫在最后

受篇幅所限，關于無模式寫入的時間分辨率識別、寫入完整性、錯誤碼等內(nèi)容請參考 https://docs.taosdata.com/reference/schemaless/ 。如有更多問題，歡迎加入 TDengine 用戶交流群，屆時將會有專業(yè)的技術人員為你解惑。