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

企業(yè)簡介

作為中國領先的生活服務平臺，58 同城業(yè)務覆蓋招聘、房產(chǎn)、汽車、二手、本地生活服務及金融等各個領域。在用戶服務層面，58 同城不僅是一個信息交互的平臺，更是一站式的生活服務平臺，同時也逐步為商家建立起全方位的市場營銷解決方案。目前，58 同城已經(jīng)成為中國全面服務本地商戶與用戶的線上商業(yè)服務平臺。

項目介紹

58 同城業(yè)務覆蓋了眾多不同的領域，比如 58 同城主站、安居客、趕集網(wǎng)、數(shù)科公司、中華英才網(wǎng)、駕校一點通等，基于此，DBA 團隊也引入了不同類型的數(shù)據(jù)庫來支持上層業(yè)務，其中包括 MySQL、Redis、MongoDB、ELK、TiDB、StarRocks、NebulaGraph，在服務規(guī)模上能達到每日請求幾萬億次。在以上數(shù)據(jù)庫服務矩陣中，可以發(fā)現(xiàn)缺少了處理時序數(shù)據(jù)相關的數(shù)據(jù)庫。

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

但這也不能怪 TiDB，目前在數(shù)據(jù)庫選型上其實就是不匹配的，這個業(yè)務場景是典型的車聯(lián)網(wǎng)設備傳感器數(shù)據(jù)，而 TiDB 和時序類型數(shù)據(jù)庫（Time-Series Database）是兩種完全不同的數(shù)據(jù)庫服務，在功能側重上也有較大區(qū)別。事實上，當前沒有一種數(shù)據(jù)庫可以滿足所有需求場景，“All In xxDB” 這種脫離了場景談數(shù)據(jù)庫選型都是沒意義的。為了給上層業(yè)務提供更貼合的數(shù)據(jù)庫服務，我們的 DBA 團隊開始調(diào)研時序數(shù)據(jù)庫。

一、從需求看數(shù)據(jù)庫選型

根據(jù)上述需求，DBA 團隊調(diào)研了如下六款時序數(shù)據(jù)庫，調(diào)研結果如下：

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

基于以上所考慮的問題點，在經(jīng)過初步分析后，我們最終選定了對 TDengine Database 進行深入調(diào)研測試。

1. 測試環(huán)境

集群架構：3 副本 + 負載均衡

容錯：先寫數(shù)據(jù)庫日志文件，成功后再寫數(shù)據(jù)文件

測試工具：官方 taosdemo

2. 機器配置

3. 寫入并發(fā) 50：

字段數(shù)	綁定參數(shù)	設備數(shù)	數(shù)據(jù)量	寫入	平均響應時間
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	內(nèi)存	磁盤IO	網(wǎng)絡
ALL	<10	<7G	<10%	<280M

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

二、生產(chǎn)環(huán)境部署架構與效果展示

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

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

當然，在應用過程中，我們也遇到了一些問題，在此也匯總一下，作為給 TDengine 研發(fā)團隊的一些改進建議：

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

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

三、寫在最后

基于 58 集團眾多的業(yè)務場景，TDengine Database 已經(jīng)成為 DBA 團隊為上層業(yè)務提供數(shù)據(jù)庫服務矩陣的可選方案之一，讓時序數(shù)據(jù)也有了專業(yè)的處理方案，后續(xù)監(jiān)控服務的數(shù)據(jù)也會陸續(xù)轉移到 TDengine 進行存儲。未來我們將會與 TDengine 一起探索更多維度的生態(tài)合作，為集團提供更好的底層數(shù)據(jù)服務支持。

作者簡介

張廣元，58 集團 DBA，十年數(shù)據(jù)庫運維管理老兵一枚。