> 小 T 導讀：為了在資料採集項頻繁變動的情況下保證使用者仍然能夠順利地完成資料記錄工作，[TDengine]( ****"TDengine") 提供了三種無模式寫入協議，分別是 InfluxDB Line 協議、[OpenTSDB]( https://www.taosdata.com/opentsdb"OpenTSDB") Telnet 協議和 OpenTSDB JSON 格式協議。本文將對無模式寫入方式的主要處理邏輯、對映規則與變更處理等進行分析，便於使用者理解與使用。

通常來說，物聯網應用常會採集比較多的資料項，用於實現智慧控制、業務分析、裝置監控等功能。但在此過程中，由於應用邏輯的版本升級，或者裝置自身的硬體調整等原因，資料採集項可能較為頻繁地出現變動。這也是[時序資料庫]( https://www.taosdata.com/"時序資料庫")（Time Series Database，TSDB）需要應對的一個挑戰。

為了在這種情況下順利完成資料記錄工作，TDengine 提供了 Schemaless 寫入方式，讓使用者可以省略掉預先建立超級表/子表的步驟，憑藉資料寫入介面能夠自動建立與資料對應的儲存結構。在必要時，Schemaless 將自動增加必要的資料列，保證使用者寫入的資料能夠被正確儲存。

值得一提的是，透過無模式寫入方式建立的超級表及其對應的子表，與透過 SQL 直接建立的超級表和子表完全沒有區別，你也可以透過 SQL 語句直接向其中寫入資料。但需要注意，透過無模式寫入方式建立的表，其表名是基於標籤值按照固定的對映規則生成的，所以無法明確地進行表意，缺乏可讀性。

**無模式寫入行協議**

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

對於 InfluxDB、OpenTSDB 的標準寫入協議請參考[《在 TDengine 中如何高效寫入？四種寫入方式提效大全》]( https://www.taosdata.com/engineering/14129.html"《在 TDengine 中如何高效寫入？四種寫入方式提效大全》")。下面首先以 InfluxDB 的行協議為基礎，介紹 TDengine 擴充套件的協議內容，允許使用者採用更加精細的方式控制（超級表）模式。

Schemaless 採用一個字串來表達一個資料行（可以向寫入 API 中一次傳入多行字串來實現多個資料行的批次寫入），其格式約定如下：
```cpp
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/reference/schemaless/ 瞭解更多的字尾及對映型別。
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 的一行資料。

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

需要注意的是，如果描述資料型別字尾時使用了錯誤的大小寫，或者為資料指定的資料型別有誤，均可能引發報錯提示而導致資料寫入失敗。

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

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

```cpp
"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/taos-sql/limit/）。

**資料模式對映規則與變更處理**

以 InfluxDB 行協議為例，其資料如何對映成為具有模式的資料？從上文中我們瞭解到，每個行協議中資料 measurement 對映為超級表名稱，tag_set 中的標籤名稱為資料模式中的標籤名，field_set 中的名稱為列名稱。以如下資料為例，說明對映規則：

```cpp
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 語句：

```cpp
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 報告錯誤。如下所示：

```cpp
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 長度，此時會觸發超級表模式的變更。

```cpp
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 的寬度增加到能夠容納新字串的寬度。

```cpp
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/reference/schemaless/ 。如有更多問題，歡迎加入 TDengine 使用者交流群，屆時將會有專業的技術人員為你解惑。

> 歡迎新增小T（VX：TDengine），加入物聯網技術討論群，第一時間瞭解TDengine 官方資訊，與關注前沿技術的同學們共同探討新技術、新玩法。

------------

想了解更多 [TDengine Database]( https://www.taosdata.com/?zh"TDengine Database")的具體細節，歡迎大家在[GitHub]( https://github.com/taosdata/TDengine"GitHub")上檢視相關原始碼。
[![](http://img.blog.itpub.net/blog/2022/05/11/0fd59db1207fc97f.jpeg?x-oss-process=style/bb)](https://www.taosdata.com/?zh "![](http://img.blog.itpub.net/blog/2022/05/11/0fd59db1207fc97f.jpeg?x-oss-process=style/bb)")</field_value></field_key></field_value></field_key></tag_value></tag_key></tag_value></tag_key>

TDengine：無模式寫入行協議的四種方式

相關文章