作者：陶建輝｜TDengine 創始人、核心開發

> 經常有人問我，為什麼 2017 年在市場上已經有這麼多時序資料庫的背景之下，你還敢去開發一款新的時序資料庫？為什麼你的團隊都 80 多人了，五年過去，還在埋頭研發 TDengine 這一款產品？週末寫篇博文，與大家分享一下我的想法。

[時序資料庫]( https://www.taosdata.com/?zh"時序資料庫")（Time Series Database）並不是一個新興的概念。追溯其歷史，1999 年問世的 RRDtool 應該是最早的專用時序資料庫了。在著名的資料庫排行網站 DB-engines 上面，時序資料庫的逐步流行起始於 2015 年，而在過去的兩年，時序資料庫成為流行度最高的資料庫。

![](http://img.blog.itpub.net/blog/2022/08/02/e8e9d466649f81e1.png?x-oss-process=style/bb)
過去兩年資料庫發展趨勢榜

2016 年底，我看到萬物互聯的時代已經到來，高效處理各種感測器、裝置產生的時序資料將成為一重要的技術領域，因此就著手開發 TDengine 這個新的時序資料庫系統，2017 年 6 月正式組建團隊。

TDengine 面市以來，從 1.0 到 2.0，從核心功能開源到叢集功能開源，得到了大量商業客戶和社群使用者的高度認可，全球安裝的 TDengine 執行例項數已經超過 13 萬，每天克隆原始碼的人次都超過 1000，在全球開發者社群產生了一定的影響力。

剛開始創業的時候，我就進行了深入的思考：新的時序資料庫還有生存空間嗎？換句話說，現有的這些資料庫對應用而言是不是已經足夠好了？它們能滿足業務需求嗎？現在我也經常思考，時序資料庫值得你死磕嗎？今天我從技術的角度來分析一下這個問題，與大家分享。

**1、可擴充套件性 / Scalability**
由於 IT 基礎設施的爆炸性增長和物聯網（IoT）的出現，資料的規模正在迅速增長。一個現代的資料中心可能需要收集多達 1 億個指標——從網路裝置和伺服器到虛擬機器、容器和微服務的一切都在不斷地傳送[時間序列資料]( https://www.taosdata.com/time-series-data"時間序列資料")。再比如，分散式電網中的每個智慧電錶每分鐘至少產生一個資料點，而中國的智慧電錶，至少有十億個。任何一臺計算機都不可能處理這麼多的資料，所以任何旨在處理時間序列資料的系統必須是可擴充套件的。

然而，許多市場領先的時序資料庫並沒有提供可擴充套件的解決方案。就拿 Prometheus 來說，它可以算是用於 Kubernetes 環境的時序資料庫的一個事實標準，但它並沒有提供分散式的設計，而必須依靠 Cortex、Thanos 或其他第三方工具來實現可擴充套件性。InfluxDB 有叢集功能，但是隻向企業客戶提供，沒有選擇開源。

為了解決這個問題，很多開發者的選擇是，在應用程式和時序資料庫伺服器（如 InfluxDB 或 Prometheus）之間部署一個代理伺服器，來建立自己的可擴充套件的解決方案。然後根據時序 ID 的雜湊值，將收集到的時序資料在多個時序資料庫伺服器之間分配。從資料寫入角度看，這確實解決了可擴充套件性的問題。但對於查詢，代理伺服器必須合併來自每個底層節點的查詢結果，而這是一個很大的技術挑戰。對於一些查詢，比如計算標準差，還不能只是合併結果，而是必須從每個節點檢索原始資料。這意味著需要重寫整個查詢引擎，需要的工作量相當之大。

進一步，仔細研究一下 InfluxDB 和 TimeScaleDB 的設計，就會發現，它們的可擴充套件性實際上是相當有限的。它們將後設資料儲存在一箇中心位置，每個時間序列總是會關聯一組標籤或標識。這意味著，如果你有 10 億個時間序列，系統就需要儲存 10 億組標籤。看出問題了嗎？當你要聚合多個時間序列時，系統需要首先確定哪些時間序列符合標籤過濾條件，而在一個很大的資料集中，這會導致很大的延遲。這就是所謂的時間序列資料庫的 High-cardinality 問題。

那麼應該如何解決這個問題呢？答案就是後設資料處理的分散式設計。後設資料不能儲存在一箇中心位置，否則它很快就會成為一個瓶頸。一個簡單的解決方案是，使用分散式關聯式資料庫來處理後設資料，但是這會增加系統的複雜度，使得系統更難維護，成本也更高了。

TDengine 1.x 的設計就是將所有後設資料儲存在管理節點（mnode）上，所以它也有 High-cardinality 的問題。在 TDengine 2.x 中，我們做了一些改進，就是將標籤值儲存在每個虛擬節點（vnode）而不是中央管理節點上, 聚合查詢速度有保證，但系統啟動時間在時間線超過千萬後不可忍受，沒有完全解決這個業內的難題。

**2、複雜性 / Complex**
資料庫是儲存和分析資料的工具，但時序資料處理需要的可不僅僅是儲存和分析。在一個典型的時序資料處理平臺中，時序資料庫總是要與支援流處理、快取、資料訂閱以及其他功能的工具整合，因此整個資料處理系統是有一定的複雜度的。

**流式處理 / Stream Processing**
時序資料就是一個流。為了更快地執行操作或者發現錯誤，我們需要在資料點到達系統時就進行分析和處理，所以流處理天然適合時序資料。流處理可以是時間驅動的，即在設定的時間間隔內產生新的結果（在時序資料庫中一般稱為連續查詢），也可以是事件驅動的，即只要有新的資料點到達就產生新的結果。

InfluxDB、Prometheus、TimescaleDB 和 TDengine 都支援連續查詢。這對於監控儀表盤是非常有用的，因為所有的圖表都可以定期更新。但連續查詢並不能滿足所有的資料處理要求，就像 ETL，複雜事件處理，所以時序資料庫需要支援事件驅動的流處理。

遺憾的是，目前市面上還沒有哪款時序資料庫支援。一般的方式是，將時序資料庫與 Spark、Flink 或其他流處理工具整合，而這些工具並不是為時序資料處理設計的。這些工具很難處理時間序列資料集中的數百萬甚至數十億的流，即使它們能夠勝任，也要以大量的計算資源為代價。

**快取 / Caching**
對於很多時序資料應用，像應用效能監控，某個特定時間的資料值並不重要，這些應用只關注趨勢。然而，物聯網場景是個例外，應該特別注意。比如，一個車隊管理系統總是要知道每輛卡車的當前位置。對於一個智慧工廠，系統總是需要知道每個閥門的當前狀態和每個電錶的當前讀數。

大多數時序資料庫，包括 InfluxDB、TimescaleDB 和 Prometheus，本身都不能保證以最小的延遲返回時間序列中最新的資料點。為了使每個時間序列的當前值能夠儘可能快地返回，沒有高延遲，很多開發者選擇將這些資料平臺與 Redis 整合。當新的資料點到達系統時，它們必須被同時寫入 Redis 以及資料庫中。這種解決方案確實有效，但增加了系統的複雜性和運維成本。

TDengine 從其第一個版本開始就支援快取了。在 TDengine 的很多使用者案例中，Redis 可以完全從系統中移除，從而使整個資料平臺的執行更加簡單，成本更低。

**資料訂閱 / Data Subscription**
訊息佇列在很多系統架構中有著重要的作用。傳入的資料點首先被寫入訊息佇列，然後被系統中的其他元件消費，包括資料庫。訊息佇列中的資料通常會被保留一段指定的時間（比如 Kafka 中的 7 天）。這與時序資料庫中的保留策略是一樣的。某個角度上來看，儲存的設計上，訊息佇列與時序資料庫沒有本質的區別。

大多數時序資料庫寫入資料的效率非常高，一秒鐘可以達到數百萬個資料點。這意味著，如果時序資料庫能夠提供資料訂閱功能，它們可以完全取代訊息佇列，這就再次簡化了系統的設計，進而降低了成本。

目前市場上僅僅 TDengine 提供資料訂閱的功能，但現有版本訂閱的效能不夠，在大部分場景下，無法將 Kafka 這類軟體從系統中剔除。

結論：沒有事件驅動的流處理、快取和資料訂閱這些功能，儘管時序資料庫仍然可以工作，但開發人員不得不將其與其他工具整合，來實現所需的功能。這使得系統設計會相當複雜，需要更多資源，也更難維護。如果時序資料庫內建了這些功能，整個系統架構就可以極大簡化，運維成本也會大大降低。

**3、雲原生 / Cloud Native**
雲端計算越來越流行，雲端計算最美妙最吸引人的地方在於它的彈性——儲存資源和計算資源沒有上限，而我們只需要為實際使用的資源付費。這也是所有應用程式，包括時序資料庫，都在向雲上轉移的一個主要原因。

遺憾的是，大多數資料庫只是“雲就緒”（cloud-ready），而非雲原生（cloud-native）。當你購買某些資料庫供應商提供的雲服務時，比如 TimescaleDB，你需要告訴系統你想要多少虛擬伺服器（包括 CPU 和記憶體配置），以及多少儲存。即使你沒有執行任何查詢，你仍然不得不為計算資源付費，如果你的資料規模增長了，你還需要決定是否購買更多資源。這種雲解決方案，其實只是資料庫服務提供商在轉售雲平臺。

要充分利用雲平臺提供的優勢，時序資料庫必須是雲原生的。為了實現這一點，時序資料庫需要重新設計。這時候要重點考慮如下幾點。

1. 計算和儲存分離：在容器化環境中，特定的容器可能在任何時候啟動或關閉，但儲存的資料是持久化的。傳統的資料庫設計無法應對這種情況，因為資料都儲存在本地。此外，為了執行復雜的查詢或執行批處理，需要動態地增加更多計算節點，以加快處理速度。 
2. 可伸縮性：系統必須能夠根據負載和延遲要求，實現儲存和計算資源的水平擴充套件或水平伸縮。對於計算資源來說，系統不難做出決定。但是儲存資源就不一樣了。要實現分散式資料庫的伸縮，當資料實時寫入，或者查詢正在執行的時候，資料庫的分片可能需要進行合併或分割。設計一個能夠完成這一任務的系統並不容易。
3. 自動化、可觀測性：時序資料庫的狀態必須能與系統的其他組成部分一起被監控，所以一個好的時序資料庫需要提供全面的可觀測性。同時系統必須提供便於在 K8S 下自動化管理的介面，否則運營管理將變得複雜。

現在這個時候，任何新開發的時序資料庫都必須是雲原生的。雖然 TDengine 的設計從第一天起就是一個具有水平擴充套件、高可用、高可靠的的分散式架構，但目前的 2.x 還不能算為雲原生資料庫，因為它不支援存算分離，而且在雲平臺的部署和管理還較為欠缺。

**4、方便易用 / Ease of use**
儘管方便易用這個詞有點主觀，但是我們可以嘗試在這裡列出幾點，從不同方面說說一個對開發者更友好的時序資料庫應該做到哪些。

1. 查詢語言：因為 SQL 仍然是最流行的資料庫查詢語言，能支援 SQL，對開發者而言就沒什麼使用門檻了。另一方面，專用的查詢語言需要開發者花費自己寶貴的時間來學習，還會增加向其他資料庫遷移的成本。InfluxDB，OpenTSDB，Prometheus，RRDTool 等都不支援 SQL，但 TDengine 與 TimeScaleDB 支援 SQL。
2. 互動式控制檯：對開發者而言，使用一個互動式的控制檯來管理執行的資料庫或執行即席查詢是最方便的。對於部署在雲上的時序資料庫也是如此。
3. 示例程式碼：開發者往往不會花時間把整個文件通讀一遍，而是直接學習如何使用某個特定的特性或 API。新的資料庫必須用主流的程式語言提供示例程式碼，開發者只需要把這些程式碼複製貼上到自己的應用中，如果需要的話再根據自己的具體情況稍加修改即可。
4. 資料遷移工具：資料庫管理系統需要提供一到多個方便高效的資料匯入匯出工具。源頭和目標可能是一個檔案、另一個資料庫或者是遠端資料中心中的一個副本。要遷移的資料可能是整個資料庫，一組表，或者是一個指定時間段中的資料點。

**技術的挑戰**
上面我總結了目前市場上時序資料庫（Time Series Database）幾大亟待解決的問題，包括 Scalability，Complex，Cloud Native 與 Ease of Use。這些問題，從技術上來看，都是硬骨頭，否則早被廠商解決了。有問題，那就有機會。2016 年底，我就是由於研究後，發現 InfluxDB，TimeScaleDB，Prometheus，OpenTSDB 等有各種不足，才開始決定進入這個行業的。5 年多過去，我帶領 TDengine 團隊力圖去解決這些問題，版本從最開始的 1.0，到 1.6，到 2.0、2.6，團隊從 5 個人發展到了 80 多人，專職研發都已經超過 50 人。TDengine 與很多時序資料庫相比，是一不錯的產品，但遺憾的是，上述的問題還只是部分的解決。

作為一個堅信技術能改變世界的創始人，不解決這些問題難以入眠，難以證明自己以及整個團隊的技術實力。因此在 2021 年 6 月，我決定正式啟動 TDengine 3.0 的研發，投入了公司最大的資源，讓所有研發同學專心新版本的研發，以解決上述技術難題為目標。TDengine 3.0 不僅要瞄準未來，成為一個雲原生時序資料庫，它還需要能支援 100 億條時間線，100 個節點，讓其具備極強的水平擴充套件和伸縮能力，徹底解決業內的“High Cardinality”問題。內建的流式計算、資料訂閱、快取等功能在時序資料場景下，要能完勝 Spark，Kafka，Redis 等通用場景下的工具。最終的目標就是降低時序資料處理系統的總擁有成本，幫助使用者挖掘出資料的價值，讓終端使用者成功；而且讓開發者用的順手、用的放心，讓開發者成功。

一年多過去，TDengine 的研發同學沒日沒夜的設計、編碼和測試，TDengine 3.0 終於可以揭開面紗。我們決定在 8 月 13 日召開 TDengine 開發者大會，為大家詳細揭秘 TDengine 3.0 的核心設計，並將 3.0 正式釋出，在 GitHub 上公開其核心原始碼。我們還邀請了業內的很多技術專家、投資人，以及我們的使用者，共同奉上一整天的精彩分享。

8 月 13 日，我在 TDengine 開發者大會上等你。

陶建輝

2022 年 7 月 24 日於北京望京

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

想了解更多 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)")

研發了 5 年的時序資料庫，到底要解決什麼問題？

相關文章