小 T 導讀：在 58 同城的駕考業務上，需要存儲分析駕校教練車傳感器產生的數據，這是典型的時序數據場景，開發人員對原有的 TiDB 性能并不是很滿意，因此 DBA 團隊開始調研更具針對性的時序數據庫。基于自身的業務需求，他們在 6 款時序數據庫中選擇了 TDengine Database，在經過(guo)深(shen)入的調研測試之后，開始部署實踐(jian)，最終業務痛點問題(ti)得(de)到(dao)了解決。

企業簡介

作為中國領先的(de)生活(huo)服務(wu)(wu)(wu)平(ping)(ping)臺，58 同(tong)城業務(wu)(wu)(wu)覆蓋招(zhao)聘、房產(chan)、汽(qi)車、二(er)手、本(ben)地(di)生活(huo)服務(wu)(wu)(wu)及金融等各(ge)個領域。在(zai)用戶服務(wu)(wu)(wu)層面，58 同(tong)城不(bu)僅是(shi)一個信息交互的(de)平(ping)(ping)臺，更是(shi)一站式的(de)生活(huo)服務(wu)(wu)(wu)平(ping)(ping)臺，同(tong)時也逐步為商家建立(li)起全方位的(de)市(shi)場營銷解決方案。目前(qian)，58 同(tong)城已(yi)經成(cheng)為中國全面服務(wu)(wu)(wu)本(ben)地(di)商戶與用戶的(de)線(xian)上(shang)商業服務(wu)(wu)(wu)平(ping)(ping)臺。

項目介紹

58 同城業務(wu)覆蓋了(le)眾(zhong)多不同的(de)領域，比如(ru) 58 同城主站、安(an)居客、趕集網、數(shu)(shu)科公司、中華英才(cai)網、駕校一點通等，基于此(ci)，DBA 團隊也引入(ru)了(le)不同類型的(de)數(shu)(shu)據庫來支持上層業務(wu)，其中包括 MySQL、Redis、MongoDB、ELK、TiDB、StarRocks、NebulaGraph，在服務(wu)規(gui)模上能達到每日請求(qiu)幾萬億次。在以上數(shu)(shu)據庫服務(wu)矩陣中，可(ke)以發現缺少了(le)處理時(shi)序數(shu)(shu)據相關(guan)的(de)數(shu)(shu)據庫。

在我們的駕考業務上，需要存儲分析駕校教練車傳感器產生的數據，是典型的時序數據。該場景會涉及高并發插入，數據處理特點為寫多讀少，有特定時間段的聚合分析。我們此前使用的是 TiDB 存儲，但開發人員對 TiDB 的性能不是很滿意，業務具體需求是：日增千萬數據，毫秒級插入，并在1秒鐘以內返回3萬條符合時間分析條件的數據。

但這(zhe)(zhe)也不(bu)能怪(guai) TiDB，目前(qian)在數(shu)據(ju)庫(ku)(ku)(ku)選型(xing)上其實(shi)就是不(bu)匹配的(de)(de)，這(zhe)(zhe)個業務場(chang)(chang)景(jing)是典型(xing)的(de)(de)車(che)聯網(wang)設備傳感器數(shu)據(ju)，而 TiDB 和(he)時序類型(xing)數(shu)據(ju)庫(ku)(ku)(ku)（Time-Series Database）是兩種(zhong)完(wan)全不(bu)同的(de)(de)數(shu)據(ju)庫(ku)(ku)(ku)服(fu)務，在功能側重上也有較大區別。事實(shi)上，當前(qian)沒有一(yi)種(zhong)數(shu)據(ju)庫(ku)(ku)(ku)可以滿足所有需(xu)求場(chang)(chang)景(jing)，“All In xxDB” 這(zhe)(zhe)種(zhong)脫離了場(chang)(chang)景(jing)談數(shu)據(ju)庫(ku)(ku)(ku)選型(xing)都是沒意(yi)義(yi)的(de)(de)。為了給上層(ceng)業務提供更貼(tie)合的(de)(de)數(shu)據(ju)庫(ku)(ku)(ku)服(fu)務，我們的(de)(de) DBA 團隊開始(shi)調研時序數(shu)據(ju)庫(ku)(ku)(ku)。

一、從需求看數據庫選型

根據(ju)上述需求，DBA 團隊調研了如下六款時序數據(ju)庫(ku)，調研結果如下：

• InfluxDB：最流行的時序數據庫，單機開源，高可用集群收費
• OpenTSDB：集群方案成熟，依賴 HBase，運維復雜，聚合分析能力弱
• Prometheus：維護簡單，集成監控和報警功能，但沒有集群解決方案，聚合分析能力較弱
• DolphinDB：運行快，開發快，部署快。閉源，免費版本限制 CPU 和內存大小
• ES：集群化，易于使用，維護成本低，但內存耗用高，歷史數據計算時性能下降明顯
• TDengine：性能強悍，國產自主研發，集群版免費，也有附加功能的收費版，還在持續迭代開發

基于以(yi)上所考慮的問題點，在經過(guo)初步分析(xi)后，我們最終選定(ding)了對 TDengine Database 進(jin)行(xing)深(shen)入調(diao)研(yan)測試。

1. 測試環境

集(ji)群架構：3 副(fu)本 + 負(fu)載均衡

容錯：先寫數據庫日(ri)志(zhi)文件，成功后再寫數據文件

測(ce)試工(gong)具：官方 taosdemo

2. 機器配置

3. 寫入并發 50：

字段數	綁定參數	設備數	數據量	寫入	平均響應時間
3	是	10000	1億	12120036.84 records/second	2.49ms
3	否	10000	1億	5932514.09 records/second	6.86ms
20	是	10000	1億	5883183.51 records/second	5.09ms
20	否	10000	1億	2078181.61 records/second	19.20ms
20	是	100000	10億	2673966.95 records/second	174.34ms
20	否	100000	10億	2621617.26 records/second	57.08ms
50	否	100000	10億	1216557.03 records/second	57.19ms

4. 服務器最大負載：

	CPU LOAD	內存	磁盤IO	網絡
ALL	<10	<7G	<10%	<280M

從以(yi)(yi)上(shang)測試結果(guo)可以(yi)(yi)看(kan)出(chu)，TDengine Database 在響應時間、插入性能、服務器負載及(ji)運(yun)維(wei)便宜成都上(shang)都可以(yi)(yi)滿足上(shang)述(shu)業務需求。部署和運(yun)維(wei)細節這(zhe)里就不(bu)展開了。

二、生產環境部署架構與效果展示

在實際生產環境部署上，我們沒有采用官方推薦的單機單實例部署，而是單機多實例部署，為三節點+三副本架構，監控上使用的是 TDinsight + Grafana。

在實際應用上，基于業務情況我們調低了步長和子表數，希望可以達成更高的并發能力。針對之前應用 TiDB 時的痛點問題，業務方反饋在代碼未調整的情況下TDengine可以在1秒內返回所需數據，業務代碼調整過后在300毫秒內即可返回所需數據。此(ci)外(wai)借助 TDengine 的(de)已有函數，很輕(qing)松(song)就打(da)通(tong)了向量分析的(de)邏輯，避免再去(qu)編寫業(ye)務代碼，省(sheng)時省(sheng)力。

當(dang)然，在應用過程中，我(wo)們也遇到了一(yi)些(xie)問(wen)題(ti)，在此也匯總一(yi)下，作為給 TDengine 研發團(tuan)隊(dui)的一(yi)些(xie)改進(jin)建議：

• 我們使用的單機多實例部署方式，在目前已發布版本中還沒有很好的命令支持，日志輸出的位置也需要顯式指定。業務的發展會有不確定的變化，從資源成本角度來看，應該初期可預估、后期可調整，希望未來 TDengine 也能有更靈活多變的部署方式。

• TDinsight 可以很直觀地監控 TDengine 的性能，但一個視圖模式下只對一套集群，如果有幾十套、幾百套集群，集成的 TDinsight 組件目前還無法添加，只能手動一個個修改 Grafana 視圖變量，這個比較麻煩，建議官方優化集成的 TDinsight 組件。
• 在進行 taosdump 導入時，更換庫名后無法利用原庫名的備份文件進行導入，建議官方修改支持。

三、寫在最后

基于(yu) 58 集團(tuan)眾多的業務(wu)場景，TDengine Database 已經成為(wei) DBA 團(tuan)隊為(wei)上(shang)層業務(wu)提供數據庫服務(wu)矩陣的可(ke)選(xuan)方(fang)案之一，讓(rang)時(shi)序數據也(ye)有了(le)專業的處理方(fang)案，后續監(jian)控(kong)服務(wu)的數據也(ye)會陸續轉移到 TDengine 進行存儲。未來我(wo)們(men)將會與 TDengine 一起(qi)探索更(geng)多維度的生態合(he)作(zuo)，為(wei)集團(tuan)提供更(geng)好的底層數據服務(wu)支持。

作者簡介

張廣元，58 集(ji)團 DBA，十年(nian)數據庫(ku)運維管(guan)理(li)老兵一枚。