寫入問題

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

付出的代價：

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

這樣設(shè)計的最終目的是為了將相同Tag組合的數(shù)據(jù)放到一起，但是系統(tǒng)設(shè)計時完全可以自己內(nèi)部針對這個Tag組合記錄一個唯一id或者唯一字符串來作為內(nèi)部隱藏的表名，來替換讓用戶自己起表名的操作，對用戶只需要呈現(xiàn)一個超級表STable即可，減輕用戶負(fù)擔(dān)。

其實可以看到上述其實是將系統(tǒng)內(nèi)部判斷唯一的負(fù)擔(dān)轉(zhuǎn)交給用戶，麻煩了用戶。假如系統(tǒng)內(nèi)部自動判斷Tag組合是否唯一，則在數(shù)據(jù)寫入過程中一直需要判斷當(dāng)前Tag組合是否存在以及查找對應(yīng)的底層唯一id或者唯一字符串，而讓用戶起表名則省去了上述代價，因為用戶起的表名就是一個唯一的字符串，所以寫入性能自然好一些

Tag支撐與管理

• 最多支持6個Tag，如果想要支持更多就要重新源碼編譯
• 超級表STable對Tag組合的索引是全內(nèi)存的，終將會遇到瓶頸的，InfluxDB已經(jīng)走過這條路了，從之前的全內(nèi)存到后面的tsi
• 超級表STable對Tag組合的索引僅僅是對第一個Tag作為key來構(gòu)建一個skiplist,也就是說當(dāng)你的查詢用到第一個tag時可以利用下上述索引，當(dāng)你的查詢沒用到第一個tag時，那就是暴力全掃，所以這種在Tag組合數(shù)過多的時候過濾查詢能力還是很有限的。而像其他時序數(shù)據(jù)庫InfluxDB、Druid都在寫入過程中針對Tag組合構(gòu)建了倒排索引來應(yīng)對任意維度的過濾，寫入性能比TDengine自然就會差一些
• 對于不再使用的Tag組合的過期目前也是個麻煩的事情

不支持亂序?qū)懭?/h3>

每張表會記錄該表目前寫入的最大時間，一旦后續(xù)的寫入時間小于該時間則不允許寫入。假如你不小心向某張表寫入2021-07-24 00:00:00時間的數(shù)據(jù)，那么該時間之前的數(shù)據(jù)都無法寫入了

這樣做帶來的好處，簡化了寫入過程，寫入過程永遠(yuǎn)是append操作。舉個簡單例子，比如用數(shù)組來存放內(nèi)存數(shù)據(jù)，數(shù)組中的數(shù)據(jù)是按時間排序的，如果后來的數(shù)據(jù)的時間不是遞增，那么就需要將數(shù)據(jù)插入到數(shù)組中間的某個位置，并且需要將該位置之后的數(shù)據(jù)全部后移。假如后來的數(shù)據(jù)的時間都是遞增的，那么直接往數(shù)組的最后面放即可，所以不支持亂序?qū)懭爰匆誀奚脩羰褂脼榇鷥r來簡化寫入過程提高寫入性能

不支持亂序?qū)懭脒€省去的一個麻煩就是：LSM中常見的compact。如果允許亂序?qū)懭?，那么就會存?個文件中時間范圍是有重疊的，那么就需要像RocksDB那樣來進(jìn)行compact來消滅重疊，進(jìn)而減少查詢時要查詢的文件個數(shù)，所以你就會發(fā)現(xiàn)HBase、RocksDB、InfluxDB等等辛辛苦苦設(shè)計的compact在TDengine中基本不存在

總結(jié)一下就是：不支持亂序?qū)懭胧且誀奚脩舻氖褂脼榇鷥r來提高寫入性能以及簡化設(shè)計

查詢問題

求topN的group

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

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

downsampling和aggregation

downsampling:將同一根時間線上1s粒度的數(shù)據(jù)聚合成10s粒度的數(shù)據(jù)

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

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

假如使用標(biāo)準(zhǔn)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

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

由于這類需求在時序查詢中太常見了，使用上述SQL書寫非常麻煩，有些系統(tǒng)就通過函數(shù)嵌套的方式來簡化這類查詢的書寫

目前TDengine的聚合函數(shù)要么只能是downsampling要么只能是aggregation，也不支持子查詢，那么是無法滿足上述需求的

查詢聚合架構(gòu)

查詢分2階段：第一階段請求管理節(jié)點，獲取符合tag過濾的所有表的meta信息(包含每個表在哪個數(shù)據(jù)節(jié)點上)，假如滿足條件的表有上百萬個，這這個階段的查詢基本也吃不消，第二階段向數(shù)據(jù)節(jié)點查詢聚合每個表的數(shù)據(jù)，返回給客戶端，客戶端再做最終的聚合。

這種查詢方案終究還是會面臨客戶端聚合瓶頸的，還是要上多機協(xié)調(diào)的分布式查詢方案比如類似Presto、Impala等等

以上就是時序數(shù)據(jù)庫TDengine寫入問題分析的詳細(xì)內(nèi)容，更多關(guān)于時序數(shù)據(jù)庫TDengine寫入的資料請關(guān)注本站其它相關(guān)文章！

國外穩(wěn)定服務(wù)器

版權(quán)聲明：本站文章來源標(biāo)注為YINGSOO的內(nèi)容版權(quán)均為本站所有，歡迎引用、轉(zhuǎn)載，請保持原文完整并注明來源及原文鏈接。禁止復(fù)制或仿造本網(wǎng)站，禁止在非www.sddonglingsh.com所屬的服務(wù)器上建立鏡像，否則將依法追究法律責(zé)任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學(xué)習(xí)參考，不代表本站立場，如有內(nèi)容涉嫌侵權(quán)，請聯(lián)系alex-e#qq.com處理。