時序資料庫TDengine寫入查詢的問題分析

2022-03-24 19:01:16

寫入問題

必須為每個Tag組合起一個表名

付出的代價：

使用者必須要保證每個Tag組合起的表名唯一，並且一旦Tag組合數過多使用者很難記住每個Tag組合對應的表名，在查詢時基本都是靠超級表STable來查詢。所以對使用者來說這個表名幾乎沒用到卻讓使用者來花代價來起名

這樣設計的最終目的是為了將相同Tag組合的資料放到一起，但是系統設計時完全可以自己內部針對這個Tag組合記錄一個唯一id或者唯一字串來作為內部隱藏的表名，來替換讓使用者自己起表名的操作，對使用者只需要呈現一個超級表STable即可，減輕使用者負擔。

其實可以看到上述其實是將系統內部判斷唯一的負擔轉交給使用者，麻煩了使用者。假如系統內部自動判斷Tag組合是否唯一，則在資料寫入過程中一直需要判斷當前Tag組合是否存在以及查詢對應的底層唯一id或者唯一字串，而讓使用者起表名則省去了上述代價，因為使用者起的表名就是一個唯一的字串，所以寫入效能自然好一些

Tag支撐與管理

最多支援6個Tag，如果想要支援更多就要重新原始碼編譯
超級表STable對Tag組合的索引是全記憶體的，終將會遇到瓶頸的，InfluxDB已經走過這條路了，從之前的全記憶體到後面的tsi
超級表STable對Tag組合的索引僅僅是對第一個Tag作為key來構建一個skiplist,也就是說當你的查詢用到第一個tag時可以利用下上述索引，當你的查詢沒用到第一個tag時，那就是暴力全掃，所以這種在Tag組合數過多的時候過濾查詢能力還是很有限的。而像其他時序資料庫InfluxDB、Druid都在寫入過程中針對Tag組合構建了倒排索引來應對任意維度的過濾，寫入效能比TDengine自然就會差一些
對於不再使用的Tag組合的過期目前也是個麻煩的事情

不支援亂序寫入

每張表會記錄該表目前寫入的最大時間，一旦後續的寫入時間小於該時間則不允許寫入。假如你不小心向某張表寫入2021-07-24 00:00:00時間的資料，那麼該時間之前的資料都無法寫入了

這樣做帶來的好處，簡化了寫入過程，寫入過程永遠是append操作。舉個簡單例子，比如用陣列來存放記憶體資料，陣列中的資料是按時間排序的，如果後來的資料的時間不是遞增，那麼就需要將資料插入到陣列中間的某個位置，並且需要將該位置之後的資料全部後移。假如後來的資料的時間都是遞增的，那麼直接往陣列的最後面放即可，所以不支援亂序寫入即以犧牲使用者使用為代價來簡化寫入過程提高寫入效能

不支援亂序寫入還省去的一個麻煩就是：LSM中常見的compact。如果允許亂序寫入，那麼就會存在2個檔案中時間範圍是有重疊的，那麼就需要像RocksDB那樣來進行compact來消滅重疊，進而減少查詢時要查詢的檔案個數，所以你就會發現HBase、RocksDB、InfluxDB等等辛辛苦苦設計的compact在TDengine中基本不存在

總結一下就是：不支援亂序寫入是以犧牲使用者的使用為代價來提高寫入效能以及簡化設計

查詢問題

求topN的group

order by只能對時間、以及tag進行排序。top或者bottom只能對某個field求topN

時序領域非常常見的topN的group，比如求CPU利用率最大的3臺機器，目前也無法滿足

downsampling和aggregation

downsampling:將同一根時間線上1s粒度的資料聚合成10s粒度的資料

aggregation:將同一時刻多根時間線聚合成1根時間線

比如每個appId有多臺機器，每臺機器每秒都會記錄該機器的連線數，目前想畫出每個appId的總連線數的曲線

假如使用標準SQL則可能表示如下：

select sum(avg_host_conn),appid,new_time from (
		select avg(connection) as avg_host_conn,
				appid,host,time/10 as new_time 
		from t1 group by appid,host,time/10
) as t2 group by appid, new_time

內部的子查詢會先將每個appid的host 10s內的connection求平均值，即downsampling，外部的查詢將每個appid下的host的上述平均值求和，即aggregation

由於這類需求在時序查詢中太常見了，使用上述SQL書寫非常麻煩，有些系統就通過函數巢狀的方式來簡化這類查詢的書寫

目前TDengine的聚合函數要麼只能是downsampling要麼只能是aggregation，也不支援子查詢，那麼是無法滿足上述需求的