關(guān)于作者

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

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

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

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

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

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

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

• 兩級(jí)存儲(chǔ)結(jié)構(gòu)，數(shù)據(jù)插入性能高，資源利用率高；
• 對(duì)時(shí)序數(shù)據(jù)壓縮率極高；
• 針對(duì)采集點(diǎn)單獨(dú)建表，匹配業(yè)務(wù)場(chǎng)景；
• 支持大批量數(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容器化部署的最佳實(shí)踐》這篇博客。

2.2 使用成本

3.TDengine個(gè)人總結(jié)

優(yōu)點(diǎn)：

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

待改善的地方：

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

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