關(guān)于作者

鄭赫揚，理想汽車數(shù)據(jù)庫高級開發(fā)工程師。目前負責(zé)公司分布式數(shù)據(jù)庫的業(yè)務(wù)落地和運維平臺產(chǎn)品開發(fā)。

隨著業(yè)務(wù)數(shù)據(jù)量級的上升，理想汽車的物聯(lián)網(wǎng)場景業(yè)務(wù)對數(shù)據(jù)存儲性能的要求不斷提高。我們內(nèi)部團隊也在積極探索不同的數(shù)據(jù)庫與不同場景的最佳實踐匹配，本文將分享TDengine Database在我們的物聯(lián)網(wǎng)場景的落地經(jīng)驗。 首先我們來了解一下業(yè)務(wù)場景。

1. 業(yè)務(wù)場景介紹

我們有信號上報業(yè)務(wù)，需要將標記時間戳和采集點的信息，通過云端寫入到后端數(shù)據(jù)庫中，有一定的聚合查詢需求。這是典型的高并發(fā)插入場景，寫多讀少。目前的壓力為7萬的寫入QPS，預(yù)計未來3年將達到20萬以上。 我們之前的系統(tǒng)用的是MongoDB。業(yè)務(wù)存儲放在MongoDB，后來因為MongoDB的局限性，我們將業(yè)務(wù)遷移到了TiDB，方便進行擴縮容。 遷移到TiDB之后，在目前使用百度云SSD虛擬機的情況下，TiDB集群純寫入性能并不能達到我們的業(yè)務(wù)期望預(yù)期（HTAP場景數(shù)據(jù)庫對純高并發(fā)寫入支持不好，與該業(yè)務(wù)場景的適配性不高），需要不斷的資源擴容。

整體來看，TiDB適合TP或者輕AP場景，而且TiDB對硬件配置要求很高。對于時序數(shù)據(jù)，寫入用TiDB的話性價比很低。另外對業(yè)務(wù)有入侵性，底層庫表要按照月份來建表，還要針對每個采集點打上標簽。一次性大批量寫入場景也不太適配。 總的來說，當(dāng)前架構(gòu)主要存在如下痛點和新需求：

• 持續(xù)高并發(fā)寫入，帶有tag，時間戳有時會亂序；
• 業(yè)務(wù)數(shù)量級膨脹極快，需求無感知scale-out；
• 對基于時間戳范圍的聚合查詢有一定的需求；
• 因為數(shù)據(jù)量非常大，所以需要支持數(shù)據(jù)壓縮，降本增效；
• 希望可以不用針對月份數(shù)據(jù)進行分庫分表，需求TTL機制；
• 希望可以針對采集點單獨建表；
• 希望支持批量數(shù)據(jù)寫入，且業(yè)務(wù)期望寫入延時較低。

基于這些需求，我們決定嘗試一下時序數(shù)據(jù)庫TDengine。通過跟官方的深入業(yè)務(wù)封閉式測試，該數(shù)據(jù)庫產(chǎn)品的功能超出預(yù)期。在此也特別感謝肖波、陳偉燦和楊麗娜三位老師的大力支持。 TDengine的以下特點能夠很好地滿足我們的場景：

• 兩級存儲結(jié)構(gòu)，數(shù)據(jù)插入性能高，資源利用率高；
• 對時序數(shù)據(jù)壓縮率極高；
• 針對采集點單獨建表，匹配業(yè)務(wù)場景；
• 支持大批量數(shù)據(jù)寫入；
• 無感知的scale-out和scale-in；
• 支持TTL。

TDengine Database極其優(yōu)秀的高并發(fā)寫入和數(shù)據(jù)壓縮能力，極大降低了業(yè)務(wù)成本和業(yè)務(wù)壓力，因此我們決定從TiDB遷移至TDengine。

2.業(yè)務(wù)遷移過程與使用成本

2.1 遷移過程

遷移方案：

1. 先切寫流量到TDengine，歷史讀流量在TiDB的方案
2. 逐步將歷史數(shù)據(jù)格式化導(dǎo)入到TDengine
3. 部署方案: 采用域名—>LB—>firstEP+SecondEP的方式，具體可以參考《TDengine容器化部署的最佳實踐》這篇博客。

2.2 使用成本

3.TDengine個人總結(jié)

優(yōu)點：

• 非常優(yōu)秀的時序數(shù)據(jù)庫，性能比InfluxDB要強出許多，兩級存儲架構(gòu)設(shè)計(行存與列存)很棒；
• 適配物聯(lián)網(wǎng)的大數(shù)據(jù)存儲場景(TDengine從超級表概念的引入到架構(gòu)設(shè)計，決定了其適配的場景)；
• 非常低廉的機器使用成本；
• 方便的彈性擴縮容，引入了firstEP機制；
• 對聚合類查詢的速度支持也很快；
• 有TTL和標簽機制，對業(yè)務(wù)透明。

待改善的地方：

• 監(jiān)控指標的完整性有待提高，只有基礎(chǔ)的監(jiān)控指標，性能排查還要看日志，寫入延時要通過業(yè)務(wù)監(jiān)控去看；
• 周邊生態(tài)工具支持待完善，對于運維管理人員不是很方便；
• 應(yīng)用端和客戶端要求強一致，如果升級版本，則客戶端也要一起升級，重新打包進K8s node，滾動批次更新多個客戶端，這點不是很友好；
• 各類報錯信息還需要進一步完善，對用戶更友好一些，方便排查問題；
• Go的SDK不支持prepare statement（新版本已經(jīng)支持——編者注）；
• 賬號隔離支持有待完善，為了避免互相影響，只能從業(yè)務(wù)上約束，或者一套業(yè)務(wù)一個集群。

最終，無論是MySQL、MongoDB、TiDB還是TDengine，都是優(yōu)秀的數(shù)據(jù)庫產(chǎn)品，但是沒有一種數(shù)據(jù)庫產(chǎn)品是銀彈，還是業(yè)務(wù)場景為王，適配業(yè)務(wù)的才是好產(chǎn)品。