從建模思路看 MySQL 和 TDengine 哪個更適合處理量化交易場景下的海量時序數(shù)據(jù)

　　在“量化投資分析”場景中，系統(tǒng)需要從數(shù)據(jù)接口、網(wǎng)絡(luò)上等各個地方獲取證券的信息，其中往往以“實(shí)時的價格變動信息”為主要數(shù)據(jù)，然后再對這些數(shù)據(jù)進(jìn)行實(shí)時的分析與存儲，供盤中和盤后使用。某企業(yè)遇到的問題如下：“我們要對 500 個證券品種進(jìn)行監(jiān)控，在開盤時，每 5 秒會更新一次價格數(shù)據(jù)。這樣算下來的話，每個證券品種一天就會產(chǎn)生 2880 條記錄，如果是 500 個的話，就會有 144 萬條數(shù)據(jù)。而這，還僅僅是一天中產(chǎn)生的數(shù)據(jù)。如果使用 MySQL 數(shù)據(jù)庫，我們該如何設(shè)計(jì)數(shù)據(jù)庫和表，來承載這樣的數(shù)據(jù)量呢？”

　　從上述場景及問題出發(fā)，我們邀請到 TDengine 解決方案架構(gòu)師進(jìn)行回復(fù)，并產(chǎn)出本篇文章。

　　144 萬條的數(shù)據(jù)量對于關(guān)系型數(shù)據(jù)庫來說，確實(shí)是個有一定規(guī)模的日增量。但從場景上看，上述問題場景還算不上「量化分析投資」的核心，只能稱之為數(shù)據(jù)抓取的場景。其中抓取對象為「證券」，規(guī)模 N = 500， 抓取時間間隔 T = 5s。我們可以假設(shè)每次抓取的數(shù)據(jù)有：

　　如果要與常見的場景進(jìn)行類比，可以使用 IT 服務(wù)器的運(yùn)維監(jiān)控對比。數(shù)據(jù)如下：

　　通過上述對比我們可以看到，兩種場景很相似。因此，從概念上講，上述問題場景下的監(jiān)控?cái)?shù)據(jù)可以歸納為 metric —— 測量值，并且是隨時間變化的。這是很典型的時序數(shù)據(jù)，問題場景就是一種經(jīng)典的時序數(shù)據(jù)存儲場景。

　　基于 MySQL 的建模

　　如果企業(yè)要用 MySQL 的話，其實(shí)核心要考慮的問題應(yīng)該是：

　　基于以上的查詢場景，我們可以選擇兩大路線：

　　假設(shè)你使用 InnoDB 引擎（innodb_百度百科），不管怎么選，為了性能你都會建索引。而 InnoDB 的索引使用 B-Tree 結(jié)構(gòu)，這個數(shù)據(jù)結(jié)構(gòu)在 Rows > 2000w （經(jīng)驗(yàn)值）時，數(shù)據(jù)寫入會因?yàn)樗饕木S護(hù)成本上升而下降，查詢性能也一樣。只是 K = 1 的時候，這個問題才沒那么明顯：

　　2000w / 2880/day = 6944 days = 19 years

　　也就是說 1 個證券 1 個 table 的時候，存放 19 個自然年數(shù)據(jù)時，才會明顯感知到。

　　當(dāng)然，我們對這個問題有另外一種處理方法：按照時間（一般以天為單位）在進(jìn)行分表（或分庫）：

　　這種方式在一定程度上也能有效避免問題，但是分庫分表還會引來查詢側(cè)改造的工作量，仍然無法徹底解決問題。但是如果我們換用專用的時序數(shù)據(jù)庫，就能更好地解決這個問題。

　　基于 TDengine 建模

　　TDengine 作為國內(nèi) Top 的開源時序數(shù)據(jù)庫，產(chǎn)品定位為「分布式時序數(shù)據(jù)庫」，產(chǎn)品功能專門針對時序數(shù)據(jù)場景設(shè)計(jì)和優(yōu)化，已經(jīng)被廣泛運(yùn)用于金融、車聯(lián)網(wǎng)、工業(yè)互聯(lián)網(wǎng)等時序數(shù)據(jù)場景中。已經(jīng)落地的「量化投資分析」場景方案有《TDengine在同花順組合管理業(yè)務(wù)中的優(yōu)化實(shí)踐》、《TDengine 在弘源泰平量化投資中的實(shí)踐》等。

　　回到上面基于 MySQL 的建模思路，TDengine 的設(shè)計(jì)里面，也是 1 個證券 1 個 table 的理念，通過超級表（stable）的語法糖，快速并行查詢多個證券的數(shù)據(jù)；同時針對常見的業(yè)務(wù)查詢場景做了定向的性能優(yōu)化，從而保證在「海量」數(shù)據(jù)的情況下，性能依舊表現(xiàn)堅(jiān)挺；而且還設(shè)置了很多有趣的特性，助力時序處理更加簡單。

　　標(biāo)準(zhǔn) SQL 語法

　　TDengine 支持標(biāo)準(zhǔn) SQL 語法，比老一代的時序數(shù)據(jù)庫，具備更好的上手體驗(yàn)。

　　動態(tài)與靜態(tài)數(shù)據(jù)分離

　　在 TDengine 當(dāng)中，超級表（stable）結(jié)構(gòu)引入了標(biāo)簽（tag）的概念，這樣一來，我們可以把證券的維度信息放在標(biāo)簽當(dāng)中，減少數(shù)據(jù)存儲空間，提升查詢性能。同時，在建模上采用 1 個證券 1 張表的方式，以此保證高性能讀寫。

　　通過超級表語法糖，TDengine 實(shí)現(xiàn)了并行查詢的能力，大大減少 SQL 的復(fù)雜度：

　　以上便是兩種數(shù)據(jù)庫對于上述問題場景的具體解決思路，你覺得如果是你會選擇哪一種呢？可以在評論區(qū)進(jìn)行留言，一起討論。

　　總而言之，不管是傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，還是 NoSQL 數(shù)據(jù)庫，如果我們沒有針對性地去對應(yīng)時序數(shù)據(jù)特點(diǎn)，在性能提升上極為有限，只能依靠集群技術(shù)，投入更多的計(jì)算資源和存儲資源來處理，系統(tǒng)的運(yùn)營維護(hù)成本也會因此急劇上升。如果你也面臨著海量時序數(shù)據(jù)處理難題，不妨可以加一下小T vx：tdengine1，進(jìn)入 TDengine 用戶交流群，和大家一起來探討解決路徑。