> 小 T 導讀：此前有人在某問答網站上釋出了這樣一個問題：既然部分時序資料庫如 InfluxDB、TimescaleDB 是基於關係型、非時序資料庫 PostgreSQL 開發而來，那在時序資料場景下，能否用 MySQL/MongoDB 這類資料庫去代替時序資料庫（Time-Series Database）使用？對於此問題，濤思資料資深研發工程師試圖從原理和實踐出發為同樣有此疑問的朋友作出解答。

從資料庫的定義來看，資料庫就是一個資料管理系統，是用來存放資料檔案的一個軟體，它能夠支援使用者的新增、修改、刪除、查詢等操作。因此從定義上講，時序資料庫和關係/非關係型資料庫是一樣的，都是用來存放資料的。但因為儲存的資料特點不同，這兩類資料庫的應用場景也不盡相同：

- 關係型資料庫：主要用來儲存結構化資料，使用實物保證資料一致性，使用 SQL 語言來進行查詢操作。這類資料庫的典型代表主要包括 MySQL、Oracle、SQL Server 等。
- 非關係型資料庫：主要用來儲存非結構化資料，資料可以不透過驗證進行儲存，使用 JSON 資料物件進行查詢操作。其典型代表主要有 MongoDB、Redis 等。

而時序資料庫主要用於儲存實時資料，最明顯的特點就是每條資料都會帶有時間戳屬性，在電力、石化、冶金、智慧汽車、監控等領域應用較為廣泛。這類 Database 的典型代表主要包括 TDengine、InfluxDB、TimescaleDB 等。下面直切主題，我們來討論一下關係/非關係型資料庫是否能替代時序資料庫。

**能否用關係/非關係型資料庫代替時序資料庫 ？**

事實上，如果資料採集頻率少，資料量不大的話，使用關係/非關係型資料庫代替時序資料庫是完全沒有問題的。但如果從長遠角度來看，這種做法卻存在著很大的風險，具體原因還要從時序資料庫的特點講起。

時序資料具備採集頻率高、資料量大、寫操作為主讀操作為輔、很少有更新或刪除操作、卻有統計聚合等實時計算操作等特點，關係/非關係型資料庫很難滿足這樣高的效能需求。在大資料場景下，如果效能達不到要求，資料沒有辦法被有效儲存的話，那麼這樣的資料庫是無法代替時序資料庫的。

舉一個簡單的例子，在相同的測試環境（16 核 64G 記憶體）下，以傳統的關係型資料庫 MySQL 和時序資料庫 TDengine 為例，做一下 benchmark 的對比測試 ：

分別使用 MySQL 自帶的 benchmark 工具 mysqlslap 和 TDengine 自帶的 benchmark 工具taosbenchmark，設定 16 個執行緒，寫入單表 10 萬條記錄，表結構為 1 個 timestamp 型別，2 個 int 型別，2 個字串型別，測試結果如下：

**MySQL——**
```asp
mysqlslap -uroot -p1234 --concurrency=16 --number-of-queries=100000 --create-sc 
hema=tests --query="INSERT INTO meters(c0, c1, c2, c3) VALUES (RAND() * 100, RAND() * 100, uuid(), uuid())" 
```
![](http://img.blog.itpub.net/blog/2022/06/17/38afb8316c041c1d.jpeg?x-oss-process=style/bb)

**TDengine——**
```asp
taosBenchmark -b int,int,binary\(128\),binary\(128\) -n 100000 -t 1 -T 16 
```
![](http://img.blog.itpub.net/blog/2022/06/17/5188ead32bd117dd.jpeg?x-oss-process=style/bb)

從以上對比測試結果可以看出在同樣寫入 10 萬條記錄的情況下，MySQL 使用自帶的 mysqlslap 工具需要 75 秒完成，而 TDengine 使用自帶的 taosBenchmark 只需要不到 1 秒。在差距如此巨大的結果中，我們可以得出一個結論——使用 MySQL 代替時序資料庫處理時序資料是比較困難的。當然由於測試工具不同，這裡只是做一個示例，測試本身算不上嚴謹。下面我會從一些具體的企業案例出發，再為大家做下分析。

**從具體的案例看大資料的儲存問題**

其實，想要回答這個問題，具體的企業案例實踐才是最好、最真實的答案。業內人應該都知道，時序資料庫是近幾年隨著物聯網等技術的發展才逐漸流行起來的，在此之前，各行各業的企業可選的資料庫方案都十分有限，以車聯網企業為例，行業中最普遍的選擇就是 MongoDB、HBase 一類的傳統大資料解決方案。

但隨著業務的發展，資料量的不斷攀升，這些企業或多或少都遭遇了資料架構危機，甚至阻礙了業務的發展，不得不考慮進行資料架構的迭代和遷移。下面我從 MySQL、MongoDB、HBase 三個 database 維度列舉企業案例，進行說明。

**MySQL**
在柳工的工業車聯網應用 LiuGong iLink 中，由於應用層不合理的複雜查詢和歷史資料的高頻寫入，導致 MySQL 處理速度緩慢，甚至容易當機，嚴重影響使用者體驗。在分析原因後，他們得出了一個結論：關係型資料庫並不適用於儲存海量的時序資料，在海量資料聚合計算、抽稀等業務中效率很低。從這個結論出發，他們開始針對時序資料庫進行選型。

由於其業務場景與 TDengine 的“一個裝置採集點一張表”的理念十分吻合，且 TDengine 可以支援對大資料進行聚合和降取樣查詢等操作，能夠經有效改善 MySQL 的資料痛點問題，又經過嚴謹的調研和測試，最終他們決定遷移至 TDengine。

以一個真實場景看一下遷移效果：在替換 TDengine 之前，該專案每天都有一些業務報表需要展示，每一小時需統計一次下一個時區內所有裝置的資料，這個流程在 MySQL 中經常需要耗時1小時以上，無法正常執行後續業務。而換到TDengine後，整個出表流程只需要 10 秒左右。

查詢對比如下圖所示：
![](http://img.blog.itpub.net/blog/2022/06/17/5171fcaa170e4e60.jpeg?x-oss-process=style/bb)

參考資料：https://www.taosdata.com/blog/2022/05/17/8473.html

**MongoDB & HBase**
對於這兩大資料庫的應用坑點，零跑汽車可以說是相當有發言權了。作為一家典型的新能源車企，零跑汽車在資料儲存選擇上一直都是 MongoDB 和 HBase，隨著業務的加速擴張，出現了寫入速度太慢、支撐成本過高等問題。

用 MongoDB 儲存資料會將資料全部儲存在記憶體中，過高的儲存成本導致只能儲存一段時間內的資料，且儲存的資料格式需要經過業務組織處理，不僅業務變更不靈活，可以做的業務也非常有限，而 HBase 本身就是一個很重的資料庫，搭建 HBase 需要整套 HDFS 做支撐，使用、運維、人力等成本都很高。

在應用 TDengine 進行架構升級後，壓縮效能直接提升了 10 到 20 倍，降低儲存壓力的同時解決了資料儲存成本高的問題，也解決了以前 HBase 入庫不及時的問題，可以用更少的伺服器資源入庫更多的資料，節省更多成本。同時業務靈活性也有了極大提升，不用再像 MongoDB 一樣，在查詢前還需要根據業務加工出需求資料，TDengine 的列式儲存，直接以 SQL 計算即可。

**寫在最後**

從上面的諸多論證中我們可以得出最終結論，如果你面對的也是時序大資料場景，時序資料庫才是最正確、最合理的選擇，如果因為資料量尚小就選擇通用資料庫，那後面各種棘手問題也會接踵而至，包括開發效率慢、執行效率低、運維成本高、應用推出慢、小資料量場景下私有化部署太重等諸多問題。在資料庫的選型上，“對症下藥”才是有利於業務發展的良策。

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

想了解更多 TDengine Database的具體細節，歡迎大家在[GitHub]( https://github.com/taosdata/grafanaplugin"GitHub")上檢視相關原始碼。
[![](http://img.blog.itpub.net/blog/2022/05/11/0fd59db1207fc97f.jpeg?x-oss-process=style/bb)](https://www.taosdata.com/?zh "![](http://img.blog.itpub.net/blog/2022/05/11/0fd59db1207fc97f.jpeg?x-oss-process=style/bb)")

為什麼不建議你用 MongoDB 這類產品替代時序資料庫？

相關文章