關于作者
鄭赫揚，理(li)想汽車數(shu)據庫高級開發工程師。目(mu)前負責公司(si)分布式數(shu)據庫的業務落地和運維平臺產品(pin)開發。
隨著業務數據(ju)量(liang)級(ji)的(de)(de)(de)上(shang)升，理(li)想汽車的(de)(de)(de)物聯網場景(jing)(jing)業務對數據(ju)存(cun)儲性能的(de)(de)(de)要求不(bu)斷提高。我們內(nei)部團隊也在積極探索不(bu)同(tong)的(de)(de)(de)數據(ju)庫與(yu)不(bu)同(tong)場景(jing)(jing)的(de)(de)(de)最佳實踐匹配(pei)，本文將分(fen)享TDengine Database在我們的(de)(de)(de)物聯網場景(jing)(jing)的(de)(de)(de)落地經驗。 首先我們來了解一下業務場景(jing)(jing)。
1. 業務場景介紹
我們(men)有信號上報業(ye)(ye)務(wu)，需(xu)要將標記時間戳和采(cai)集點的(de)信息，通過(guo)云(yun)端寫入(ru)到(dao)后端數據(ju)庫(ku)中，有一定的(de)聚合查(cha)詢需(xu)求。這是典(dian)型的(de)高并(bing)(bing)發插入(ru)場(chang)(chang)(chang)景(jing)，寫多讀少(shao)。目(mu)前(qian)的(de)壓力為(wei)7萬(wan)的(de)寫入(ru)QPS，預(yu)(yu)計(ji)未來3年將達到(dao)20萬(wan)以上。 我們(men)之(zhi)前(qian)的(de)系統用的(de)是MongoDB。業(ye)(ye)務(wu)存(cun)儲(chu)放在(zai)(zai)MongoDB，后來因(yin)為(wei)MongoDB的(de)局限性，我們(men)將業(ye)(ye)務(wu)遷移到(dao)了TiDB，方便(bian)進行(xing)擴(kuo)(kuo)縮(suo)容(rong)。 遷移到(dao)TiDB之(zhi)后，在(zai)(zai)目(mu)前(qian)使用百度云(yun)SSD虛(xu)擬機的(de)情況(kuang)下，TiDB集群純(chun)寫入(ru)性能并(bing)(bing)不(bu)能達到(dao)我們(men)的(de)業(ye)(ye)務(wu)期望預(yu)(yu)期（HTAP場(chang)(chang)(chang)景(jing)數據(ju)庫(ku)對(dui)純(chun)高并(bing)(bing)發寫入(ru)支持(chi)不(bu)好，與該業(ye)(ye)務(wu)場(chang)(chang)(chang)景(jing)的(de)適配性不(bu)高），需(xu)要不(bu)斷的(de)資源擴(kuo)(kuo)容(rong)。
整(zheng)體來(lai)看，TiDB適(shi)合TP或(huo)者輕AP場景，而且(qie)TiDB對(dui)(dui)硬件配置要(yao)(yao)(yao)求(qiu)很高。對(dui)(dui)于時序數據，寫入用TiDB的話(hua)性價比很低(di)。另外對(dui)(dui)業務有(you)入侵性，底(di)層庫(ku)表要(yao)(yao)(yao)按照月份來(lai)建表，還要(yao)(yao)(yao)針對(dui)(dui)每個采集點(dian)打(da)上(shang)標簽(qian)。一次性大(da)批量寫入場景也不太適(shi)配。 總的來(lai)說，當前架構(gou)主要(yao)(yao)(yao)存在(zai)如(ru)下痛點(dian)和新(xin)需求(qiu)：
- 持續高并發寫入，帶有tag，時間戳有時會亂序；
- 業務數量級膨脹極快，需求無感知scale-out；
- 對基于時間戳范圍的聚合查詢有一定的需求；
- 因為數據量非常大，所以需要支持數據壓縮，降本增效；
- 希望可以不用針對月份數據進行分庫分表，需求TTL機制；
- 希望可以針對采集點單獨建表；
- 希望支持批量數據寫入，且業務期望寫入延時較低。
基于這些需求，我們決定嘗試一下時序數據庫TDengine。通過跟(gen)官方的(de)(de)深(shen)入業(ye)務封(feng)閉式測試，該數據(ju)庫產品的(de)(de)功能(neng)超出(chu)預期。在此(ci)也特別感謝肖波(bo)、陳(chen)偉燦和楊(yang)麗(li)娜三(san)位老師的(de)(de)大(da)力支持(chi)。 TDengine的(de)(de)以下特點能(neng)夠很好地滿足(zu)我們的(de)(de)場景：
- 兩級存儲結構，數據插入性能高，資源利用率高；
- 對時序數據壓縮率極高；
- 針對采集點單獨建表，匹配業務場景；
- 支持大批量數據寫入；
- 無感知的scale-out和scale-in；
- 支持TTL。
TDengine Database極其優秀的高并發寫入(ru)和(he)(he)數(shu)據壓縮(suo)能(neng)力，極大(da)降(jiang)低了業務成本和(he)(he)業務壓力，因此(ci)我們決(jue)定從TiDB遷移至TDengine。
2.業務遷移過程與使用成本
2.1 遷移過程
遷移方案：
- 先切寫流量到TDengine，歷史讀流量在TiDB的方案
- 逐步將歷史數據格式化導入到TDengine
- 部署方案: 采用域名—>LB—>firstEP+SecondEP的方式，具體可以參考《TDengine容器化部署的最佳實踐》這篇博客。
2.2 使用成本
3.TDengine個人總結
優點：
- 非常優秀的時序數據庫，性能比InfluxDB要強出許多，兩級存儲架構設計(行存與列存)很棒；
- 適配物聯網的大數據存儲場景(TDengine從超級表概念的引入到架構設計，決定了其適配的場景)；
- 非常低廉的機器使用成本；
- 方便的彈性擴縮容，引入了firstEP機制；
- 對聚合類查詢的速度支持也很快；
- 有TTL和標簽機制，對業務透明。
待改善的地方：
- 監控指標的完整性有待提高，只有基礎的監控指標，性能排查還要看日志，寫入延時要通過業務監控去看；
- 周邊生態工具支持待完善，對于運維管理人員不是很方便；
- 應用端和客戶端要求強一致，如果升級版本，則客戶端也要一起升級，重新打包進K8s node，滾動批次更新多個客戶端，這點不是很友好；
- 各類報錯信息還需要進一步完善，對用戶更友好一些，方便排查問題；
- Go的SDK不支持prepare statement（新版本已經支持——編者注）；
- 賬號隔離支持有待完善，為了避免互相影響，只能從業務上約束，或者一套業務一個集群。
最(zui)終，無論是(shi)MySQL、MongoDB、TiDB還(huan)是(shi)TDengine，都(dou)是(shi)優秀(xiu)的(de)數據(ju)(ju)庫產(chan)品(pin)，但(dan)是(shi)沒有一種數據(ju)(ju)庫產(chan)品(pin)是(shi)銀彈，還(huan)是(shi)業務場(chang)景為王，適配業務的(de)才是(shi)好產(chan)品(pin)。
