> 小 T 導讀：在對多款時序資料庫進行了選型測試後，同程旅行自研的“夜鷹監控”搭載 TDengine 代替了現有儲存裝置，減少運維成本。本文分享了他們對建表模型的方案選擇思路，接入 TDengine 後所遇到問題的解決經驗以及落地效果展示。

同程旅行有一套自研的基礎監控系統“夜鷹監控”。目前夜鷹監控使用情況為百萬級別 endpoint、億級 metric、每秒 200 萬併發寫入以及 2 萬併發查詢。其儲存元件基於 RRD 儲存，RRD 儲存雖然擁有很好的效能，卻也存在著一些問題——基於記憶體快取定期寫入 RRD，在機器重啟後會丟失部分資料。

出現這一問題的原因是 RRD 寫入為單點寫入，當機器故障後無法實現自動切換，這一儲存特性也導致無法展示更長時間的原始資料。 針對此問題，夜鷹監控做了很多高可用設計，但還是很難滿足業務的需求，之後又進行了如下改造：
- 引入了 ES 儲存，為夜鷹監控提供 7 天內原始資料的查詢，目前部署的 2 套儲存。
- RRD 提供給 API 呼叫，呼叫量在幾萬級 TPS。
- ES 提供給夜鷹皮膚使用，儲存 7 天原始資料，呼叫量在幾百 QPS。

但隨著基礎監控系統接入指標的增長，目前 2 套儲存系統在資源消耗方面一直在增長，同時業務對監控也提出了更多的聚合計算功能要求。基於此，我們需要尋找一個新的時序資料庫來代替現有的儲存系統，以減少運維成本。

在進行時序資料庫選型時，實際需求主要有以下三點：
- 效能強，可以支援千萬級別併發寫入、10 萬級的併發讀取
- 高可用，可以橫向擴充套件，不存在單點故障
- 功能強，提供四則運算、最大、最小、平均、最新等聚合計算功能

透過對比 InfluxDB、TDengine、Prometheus、Druid、ClickHouse 等多款市面流行的時序資料庫產品後，最終 TDengine 從中脫穎而出，能滿足我們所有的選型要求。

**一、基於 TDengine 的建表模型**

夜鷹監控系統不僅存在系統指標資料，同時也會存在業務指標資料。前者諸如 CPU、記憶體、磁碟、網路一類，這類資訊是可以預測的指標，其指標名是固定的，總數約為 2000 萬個。後者則會透過夜鷹監控的 API 上傳業務自身定義的指標，指標名是無法預測的，其特點是併發量不大卻存在長尾效應，隨著時間累積，一年可以達到一億級。

而 TDengine 在建立表之前需要先規劃表的結構，從上面的資料儲存背景來看，如果要將海量的指標數量直接一次性扁平化全部建立，則會造成效能的下降。透過和 TDengine 技術支援人員溝通，他們給出了兩個建表方案：

其一，將系統類基礎指標聚合到一個超級表，一張表存放一個節點，多個指標一次性寫入。這個方式的好處是表的數量可以降低到千萬級別，但因為夜鷹監控的資料是單條上傳的，很難做到一個表裡面全部指標集齊再寫入。並且不同的指標上傳頻率不同，如果再根據頻率建不同的超級表，運維管理成本會非常高。

其二，將不同的指標建成一個一個的子表，5 千萬個左右的指標匯聚成一個叢集，分多個叢集接入。這種方式的好處是表結構簡單，但運維管理多個叢集會很麻煩。不過我們也瞭解到濤思資料明年會發布 TDengine 3.0 版本，能支援超過上億張表，那麼這一方案就可以很好的進行資料遷移了。

最終，我們選擇了第二個方案。同時為了減少搭建叢集的數量，準備寫個程式定期清理掉過期的子表。目前夜鷹監控的超級表結構如下。
![](http://img.blog.itpub.net/blog/2022/03/30/7edbf6c63361be08.png?x-oss-process=style/bb)
夜鷹監控接入 TDengine 後，架構圖如下。
![](http://img.blog.itpub.net/blog/2022/03/30/4d0c6511635c4d39.png?x-oss-process=style/bb)

**二、接入 TDengine 之後的效果展示**

在進行資料遷移時，我們先是將夜鷹監控資料轉移到 Kafka 中，之後透過消費轉換程式將 Kafka 的資料格式轉為了 TDengine SQL 格式。 這個過程還遇到了如下三個小問題，解決思路放在這裡給大家參考：

- **連線方式問題。**剛開始我們使用的是 go-connector sdk 的方式接入 TDengine，跑起來後發現，go-connector 依賴於 taos client 包以及 taos.cfg 配置檔案裡面的連結配置，同時因為 FQDN 的設定難以使用 VIP 負載均衡的配置方式。我們考慮到後面消費程式會部署到容器中，不宜產生過多的依賴，因此還是放棄了 go-connector 的連線方式，改為了 HTTP RESTful 的連線方式。 
- **Kafka 消費數量問題。**由於夜鷹監控上傳到 Kafka 裡面的資料是一條一個指標，再加上 200 萬左右的併發，連線數很快就耗光了。透過和 TDengine 技術支援人員溝通，瞭解到可以改造成批次 SQL 的方式寫入，最佳的實踐效果是 400-600K 單個 SQL 的長度。經過計算，我們上傳的指標條數大概為 5000 條左右，大小為 500K 。
- **讀取速度問題。**因為每次要等到消費 5000 條資料，才會觸發一次寫入，這種情況也導致讀取速度較慢。TDengine 技術支援人員再次給出瞭解決方案——使用 Taos 自己實現的 Queue，程式碼地址為:github.com/taosdata/go-demo-kafka/pkg/queue ，有需要的同學可以自行獲取。

聚焦到實際效果上，TDengine 資料寫入效能很強。**原本我們的單套儲存系統需要 10 多臺高配機器，IO 平均 30% 最高 100% 的情況下才能寫完資料；現在只需要 7 臺機器，並且 CPU 消耗在 10% 左右、磁碟 IO 消耗在 1% 左右，這點非常的棒!**
![](http://img.blog.itpub.net/blog/2022/03/30/17de634605eeabb6.png?x-oss-process=style/bb)

![](http://img.blog.itpub.net/blog/2022/03/30/a855c0fc34b126c2.png?x-oss-process=style/bb)

同時，其資料讀取接入過程也很順利。使用 RESTful 介面後，結合 TDengine 自帶的強大聚合函式功能，很容易就能計算出想要的結果。

**三、寫在最後**

在我們的專案中，TDengine 展現出了超強的效能和多元化的功能，不僅具備高效的寫入效能、壓縮率，其聚合函式功能也非常齊全，支援 Sum/Max/Min/Avg/Top/Last/First/Diff/Percentile 等多種函式，在架構上也設計的很合理，可以實現很好地橫向擴充套件。同時，其自身監控也做的很不錯，打造了基於 Grafana 的 TDengine 零依賴監控解決方案 TDinsight，在監控系統自身狀態上展現出了很好的效果。

未來，我們也希望與 TDengine 展開更深層次的合作，在此也為其提出一些小小的建議，助力 TDengine 往更好的方向發展：
- 官方文件還不夠完善，新版的功能在文件中沒有體現，很多用法缺少程式碼示例，個人理解起來比較晦澀難懂
- 社群使用者經驗傳遞不是很多， 遇到一些問題時，Google 比較難以找到社群的解決案例

在接入的過程中，非常感謝 TDengine 的技術支援人員的全力支援。雖然目前 TDengine 還處於發展初期，也存在一些問題需要最佳化，不過其優異的效能還是給了我們一個大大的驚喜！總而言之，TDengine 是個非常不錯的儲存系統，相信在陶老師的帶領下會發展的越來越好！

------------

想了解更多 TDengine 的具體細節，歡迎大家在[GitHub](https://github.com/taosdata/TDengine "GitHub")上檢視相關原始碼。
[![](http://img.blog.itpub.net/blog/2022/03/28/36f3ecc653e3892c.jpeg?x-oss-process=style/bb)](https://www.taosdata.com?utm_source=itpub&utm_medium=tdengine&utm_campaign=techarti&utm_term=20220330)

機器使用成本下降 50%，TDengine 在同程旅行基礎監控中的實踐

相關文章