小 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——
hema=tests --query="INSERT INTO meters(c0, c1, c2, c3) VALUES (RAND() * 100, RAND() * 100, uuid(), uuid())"
TDengine——
taosBenchmark -b int,int,binary\(128\),binary\(128\) -n 100000 -t 1 -T 16
從以上對比測試結果可以看出在同樣寫入 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 秒左右。
查詢對比如下圖所示：
參考資料：https://www.taosdata.com/blog/2022/05/17/8473.html
MongoDB & HBase
對于這兩大資料庫的應用坑點，零跑汽車可以說是相當有發言權了。作為一家典型的新能源車企，零跑汽車在資料存儲選擇上一直都是 MongoDB 和 HBase，随着業務的加速擴張，出現了寫入速度太慢、支撐成本過高等問題。