小T導讀：廣東領益(yi)智造(zao)股(gu)份有(you)限公(gong)司是全(quan)球領先(xian)的智能(neng)制(zhi)造(zao)平臺企業(ye)，致力(li)于(yu)以技術先(xian)進(jin)、質量可靠為(wei)核心競爭力(li)，為(wei)客戶(hu)提供“一(yi)站式”精(jing)密智造(zao)解(jie)決方案，實現精(jing)密、美觀、高品(pin)質、低成本于(yu)一(yi)體的終端產(chan)品(pin)。業(ye)務涵蓋消費電子(zi)、醫療器械(xie)、汽車零(ling)部件等多個行業(ye)，憑(ping)借先(xian)進(jin)的研發(fa)與(yu)制(zhi)造(zao)能(neng)力(li)，領益(yi)智造(zao)與(yu)世界知(zhi)名企業(ye)建立了穩固的戰略合作關系(xi)，綜合實力(li)位居(ju)全(quan)球同行業(ye)前三強。
在(zai)對生產設備的(de)(de)(de) AOI 全(quan)檢數(shu)(shu)據進行(xing)質量分析時，我們(men)對關(guan)系(xi)型數(shu)(shu)據庫(ku)(ku)做(zuo)了很多(duo)預處(chu)理運算，但(dan)是在(zai)計算正(zheng)態分布、盒須圖、尺寸分析及原(yuan)始數(shu)(shu)據查(cha)詢(xun)上遇到(dao)了致(zhi)命的(de)(de)(de)性能問題。此前(qian)我們(men)選擇的(de)(de)(de)數(shu)(shu)據庫(ku)(ku)服(fu)務(wu)器已(yi)達到(dao)較高的(de)(de)(de)硬件配置(zhi)（1.5T 的(de)(de)(de)內存、96 邏輯核的(de)(de)(de) CPU、全(quan)閃盤(pan)的(de)(de)(de)專業(ye)存儲），再想要通過提高服(fu)務(wu)器配置(zhi)來實現響(xiang)應速度的(de)(de)(de)提升是非常(chang)困(kun)難的(de)(de)(de)。即使數(shu)(shu)據庫(ku)(ku)對查(cha)詢(xun)做(zuo)了相應的(de)(de)(de)索引，選擇一周的(de)(de)(de)數(shu)(shu)據進行(xing)查(cha)詢(xun)時，系(xi)統的(de)(de)(de)響(xiang)應時間仍然在(zai) 20 秒以上。
為了解決當下(xia)的問題，我們(men)找(zhao)了很多方(fang)(fang)案(an)進行測試。首先(xian)使用(yong) Hadoop 生成 10 億的數據量進行查(cha)詢的模(mo)擬測試，發(fa)現(xian)實時查(cha)詢時的查(cha)詢效率還沒有關系型數據庫好，因此排除了 Hadoop 替代方(fang)(fang)案(an)。接著對(dui)(dui)杉巖的對(dui)(dui)像(xiang)存(cun)儲(chu)方(fang)(fang)案(an)進行測試，因其(qi)對(dui)(dui)象存(cun)儲(chu)的緣故，采用(yong)此方(fang)(fang)案(an)的話(hua)才購買(mai)不(bu)久的服務器資源(yuan)就無(wu)法使用(yong)了，同時還需要再投(tou)入軟硬件(jian)費(fei)用(yong)，成本(ben)較(jiao)高。
正當我們準備驗證 ClickHouse 方案時，卻在(zai)查(cha)詢資(zi)料時無意中發(fa)現了 TDengine Database，查(cha)看官方的性(xing)能報告后，我們決(jue)定(ding)對(dui)其進(jin)行測試。我們下載(zai)了 2020 年的 TDengine 社區(qu)版進(jin)行測試，發(fa)現在(zai)寫(xie)入、查(cha)詢時的效率很(hen)驚艷，隨即開始展開其與(yu)業(ye)務匹配度(du)(du)的評估，確認了在(zai)計算正態分(fen)布、盒(he)須圖、尺寸分(fen)析時的匹配度(du)(du)均很(hen)高，而這些問題(ti)恰好又是我們現在(zai)所急(ji)需(xu)解決(jue)的。
最終我們決定使用關系型數據庫和時序數據庫同時保存兩(liang)份(fen)數據，以此來滿足不同的業(ye)務場景。
一、經驗分享
結合數據特點和使用場景，我們開始構建超級表，以其中一張表為例，數據(ju)模型創建(jian)如(ru)下：
create table t_qualityproductdetail (ftime TIMESTAMP,fqualityproductid BINARY(32),fpromachineid BIGINT,fjobnumber BINARY(50),fsn BINARY(250),value FLOAT,standard FLOAT,max FLOAT,min FLOAT,createon TIMESTAMP,fisok INT) TAGS (fproductid BIGINT,fprocessesid BIGINT,faiid BIGINT,fmachineid BIGINT,fresult INT,fcount INT)
在引入 TDengine 時首先面臨的就是時間戳的問題。因為我們每一個產品在同一個時間點會有多個數據產生，且這些數據是在同一臺機器上產生的，按照官方文檔，在一個超級表中一(yi)臺(tai)機器(qi)一(yi)個(ge)子表的方式(shi)會造成(cheng)“只(zhi)能存儲最后一(yi)條(tiao)數據”的問題，經分析后最終我們(men)決(jue)定把表拆到(dao)每個(ge)檢測點的粒度，以此方式(shi)解決(jue)了此問題。
但(dan)由此(ci)也帶來(lai)了一(yi)個(ge)新的問題，那就是表數量(liang)超(chao)限。在 2.2 以前(qian)的版本(ben)上，官(guan)方建議超(chao)級表的數量(liang)不應超(chao)過 4 萬個(ge)，而我(wo)們的產(chan)品、生(sheng)產(chan)機臺號(hao)、檢(jian)測(ce)機臺號(hao)外加檢(jian)測(ce)點的集合(he)，按計算會(hui)遠(yuan)大(da)于 4 萬個(ge)，我(wo)們也很擔心(xin)在上線后會(hui)對性能造成較大(da)影響，但(dan)所幸(xing)新的 2.2 版本(ben)沒有這(zhe)一(yi)限制了。
通過(guo)與官方的溝通，我們(men)在(zai)(zai)使用過(guo)程(cheng)中接觸到了更(geng)多 TDengine 的特性，將(jiang)其應(ying)(ying)用到業務(wu)中支持更(geng)多的時序(xu)(xu)數據場(chang)景，目前(qian) TDengine 已經被應(ying)(ying)用在(zai)(zai)中間表預處理、良(liang)(liang)率計(ji)算(suan)、通過(guo)序(xu)(xu)列號查詢產品實例的測點明細等業務(wu)中，其中在(zai)(zai)良(liang)(liang)率計(ji)算(suan)上(shang)還用到了一(yi)些小技巧(qiao)，在(zai)(zai)此給大(da)家做一(yi)下經驗分享。
在良(liang)(liang)率計算邏輯調(diao)整(zheng)上，關系型數據庫(ku)中是(shi)通過子查詢的關聯(lian)來進行(xing)每(mei)臺(tai)機器的良(liang)(liang)率計算，判(pan)斷(duan)良(liang)(liang)品(pin)是(shi)通過一個 Fresult 進行(xing)判(pan)斷(duan)，結果(guo)為1（良(liang)(liang)品(pin)）、2（不良(liang)(liang)品(pin)）、3（重測），計算時采(cai)用以下方式：
select FProcessesID,FConmpyID,FMachineID,FProductID,FProMachineID,cast(FTime as date) FTime,FCount,count(0) FTotalCount,sum(case FRESULT when 1 then 1 else 0 end) FOKCount from [T_QualityProduct] t0 WITH (nolock) where FTime >=@currdate and FTime <@currenddate group by FProcessesID,FConmpyID,FMachineID,FProductID,FProMachineID,cast(FTime as date),FCount而 TDengine 不支持 case when 的運算，在處理時需(xu)要計(ji)算兩次，先(xian)是通(tong)過以(yi)下方式來計(ji)算總數：
select FProMachineID,FCount,count(*) FTotalCount from [T_QualityProduct] where FTime >=@currdate and FTime <@currenddate group by FProcessesID,FConmpyID,FMachineID,FProductID,FProMachineID,FCount interval(1d)然(ran)后再通過以下方式計(ji)算良品數量：
select FProMachineID,FCount,count(*) FOKCount from [T_QualityProduct] where FTime >=@currdate and FTime <@currenddate and FRESULT =1 group by FProcessesID,FConmpyID,FMachineID,FProductID,FProMachineID,FCount interval(1d)算出結果后(hou)通過(guo)程序(xu)代碼把上述多條件分(fen)組匯(hui)總的數據合并到一(yi)起。
以(yi)上(shang)這種計算方(fang)式有(you)兩個(ge)缺(que)點，一是(shi)(shi)需(xu)要查詢(xun)兩次，效率不高；二是(shi)(shi)程序代碼(ma)中需(xu)要做多條件(jian)的(de)(de)匹配匯總(zong)，代碼(ma)改(gai)造工作量(liang)較大，效率低。經(jing)(jing)反(fan)復(fu)溝通后，最終我們決定增加一個(ge) fisok 的(de)(de) Int 類型的(de)(de)字段，良品用(yong) 1，其余用(yong) 0 來(lai)展示(shi)，經(jing)(jing)此改(gai)造后，代碼(ma)和執(zhi)行效率有(you)了質的(de)(de)提(ti)升。可(ke)以(yi)直接使用(yong)以(yi)下的(de)(de)代碼(ma)來(lai)實現查詢(xun)：
select FCount, count(*) FTotalCount,sum(fisok) FOKCount，sum(fisok)/count(*) yeild from [T_QualityProduct] where FTime >=@currdate and FTime <@currenddate group by FProcessesID,FConmpyID,FMachineID,FProductID,FProMachineID,FCount interval(1d)
最(zui)終(zhong)我們使(shi)用此方(fang)式成功計算出(chu)了(le)良率，且性能遠(yuan)高(gao)于關系型數據(ju)庫，程序代碼也不(bu)用改動。
二、效果展示
在(zai) TDengine 成功(gong)上線(xian)接入后，我們將每日良率、線(xian)別機臺良率、尺(chi)寸(cun)良率分(fen)析(xi)、正態分(fen)布、361 分(fen)析(xi)、盒(he)須圖(tu)、原始數(shu)據查看(kan)等業務(wu)都移到了 TDengine 中(zhong)，而 TDengine 在(zai)實際業務(wu)中(zhong)也展現(xian)(xian)出了如(ru)測試時所(suo)表現(xian)(xian)的高(gao)效性(xing)能。
存儲容量對比
1、某(mou)關(guan)系型數據(ju)庫的數據(ju)空間和(he)(he)索引(yin)空間大小(xiao)，QualityProductDetail 和(he)(he) QualityProduct 兩張表(biao)分別求和(he)(he)。
2、TDengine 通過在 CentOS 執(zhi)行 du -sh /var/lib/taos 查(cha)看文件夾大小。
查詢效率對比
- 通過正態分布語句進行查詢對比
1）5天查詢條件：FTime between ‘2021-06-21 00:00:00.000000’ and ‘2021-06-25 23:59:59.999999’ and FAIID=1693 and FProcessesID=1 and value<999 and FCount=1
2）3月(yue)查(cha)詢條件(jian)：FTime between ‘2021-06-01 20:00:00.000000’ and ‘2021-09-01 19:59:59.999999’ and FAIID=1693 and FProcessesID=1 and value<999 and FCount=1
- 查詢效率對比詳細測試數據
1）5天數(shu)據(ju) 某關系(xi)型數(shu)據(ju)庫——查(cha)詢結果量414,995條(tiao)，平均耗時328.13秒(miao)(miao) TDengine——查(cha)詢結果量413,180條(tiao)，平均耗時4.61秒(miao)(miao)
2）3個(ge)月數(shu)據(ju) 某關系型(xing)數(shu)據(ju)庫——查(cha)詢(xun)結果(guo)量1,949,501條，平均耗時340.29秒(miao) TDengine——查(cha)詢(xun)結果(guo)量1,848,385條，平均耗時20.80秒(miao)
通過以上的對比測試，我們發現在同等條件下，查詢最近 5 天的數據，某關系型數據庫平均耗時 328.13 秒，而用 TDengine 則平均耗時 4.61 秒，用時為原來的 70 分之一，查詢效率提升了 70 倍，把數據拉長到3個月，效率也有15倍的提升。在我們正常的業務場景下，80% 的情況會查詢最近 7 天的數據，70 倍的查詢效率提升也如實映射為正常業務環境下的表現。
我們使用原來的關系型數據庫時，會建立大量的索引來提升查詢速度，但發現進行原始數據查詢計算時效率還是太低，響應時間以十秒為單位，故而采用了預處理的方案，把每日的良率提前按產品、機臺進行混部，這樣在查詢時就可以有較快的查詢速度，但同時也犧牲了空間和實時性。通過以上對比可以看出，在建好索引和中間表的情況下，同樣的數據量級，某關系型數據庫的空間使用是 TDengine 的 40 倍。
三、寫在最后
伴隨物聯網技術終端和應用的跨越式發展，其背后巨大的市場空間和經濟效益日益顯現，作為一個大的技術趨勢被科技企業廣泛關注。在此背景下，TDengine 作為一款專為物聯網大數據場景而生的時序數據庫，它所展(zhan)現(xian)出的高效(xiao)性能(neng)和成本管控能(neng)力(li)(li)都(dou)非常驚艷，成為科技企業抓住物(wu)聯(lian)網機遇的一個有力(li)(li)抓手。
目前我們已著手把(ba)稼(jia)動率的項目遷移到 TDengine 上，同時(shi)集(ji)團在 2021 年底把(ba)物聯部門提升(sheng)為一(yi)級部門，后續將(jiang)會有更多的設備聯機數(shu)據需要存(cun)儲和分析。
