在“量化投資分析”場景中，系統需要從數據接口、網絡上等各個地方獲取證券的信息，其中往往以“實時的價格變動信息”為主要數據，然后再對這些數據進行實時的分析與存儲，供盤中和盤后使用。某企業遇到的問題如下：“我們要對 500 個證券品種進(jin)行監控(kong)，在開盤時，每 5 秒會(hui)更新一(yi)次價(jia)格數(shu)(shu)據(ju)(ju)。這(zhe)樣算下(xia)來的(de)話，每個證券品種一(yi)天就(jiu)會(hui)產(chan)生 2880 條(tiao)記錄，如果(guo)是 500 個的(de)話，就(jiu)會(hui)有 144 萬(wan)條(tiao)數(shu)(shu)據(ju)(ju)。而這(zhe)，還僅僅是一(yi)天中產(chan)生的(de)數(shu)(shu)據(ju)(ju)。如果(guo)使用(yong) MySQL 數(shu)(shu)據(ju)(ju)庫，我們該(gai)如何設計數(shu)(shu)據(ju)(ju)庫和表，來承載這(zhe)樣的(de)數(shu)(shu)據(ju)(ju)量呢？”

從上述場景及問題出發，我們邀請到 TDengine 解決方案架構師進行回(hui)復，并產(chan)出本篇文章。

144 萬(wan)條(tiao)的數(shu)據(ju)量對(dui)于(yu)關系(xi)型數(shu)據(ju)庫(ku)來說，確實(shi)是個(ge)有一定(ding)規(gui)(gui)模(mo)(mo)的日(ri)增量。但從場景上(shang)看，上(shang)述問題場景還(huan)算不上(shang)「量化(hua)分析投資」的核心，只(zhi)能稱(cheng)之為數(shu)據(ju)抓(zhua)(zhua)取(qu)的場景。其(qi)中抓(zhua)(zhua)取(qu)對(dui)象為「證券」，規(gui)(gui)模(mo)(mo) N = 500， 抓(zhua)(zhua)取(qu)時(shi)間(jian)間(jian)隔 T = 5s。我們可(ke)以假設每次抓(zhua)(zhua)取(qu)的數(shu)據(ju)有：

{scrawlTime: '2023-01-01 00:00:00'stock_code: 12345,price: 12.00,volumn: 134,bid_price_1: 12.01,bid_pridce_2: 12.02}

如(ru)果要(yao)與(yu)常見的(de)場景進(jin)行類(lei)比，可以使用 IT 服務器的(de)運維(wei)監(jian)控對比。數據如(ru)下：

{timestamp: '2023-01-01 00:00:00'ip: '172.16.8.1',cpu_usage: 0.81,memory_usage: 0.23}

通過上(shang)(shang)述對(dui)比我們可(ke)以看到(dao)，兩種(zhong)場景(jing)很(hen)相似(si)。因此，從概(gai)念上(shang)(shang)講，上(shang)(shang)述問題場景(jing)下的監(jian)控(kong)數據可(ke)以歸納為 metric —— 測量值，并且是隨時間變化的。這是很(hen)典(dian)型的時序(xu)(xu)數據，問題場景(jing)就(jiu)是一種(zhong)經典(dian)的時序(xu)(xu)數據存儲場景(jing)。

基于 MySQL 的建模

如果企業要用(yong) MySQL 的(de)話，其實核(he)心要考慮的(de)問題應該是

• 如何保證能夠及時寫入：500 rows/5s = 100 rows/s（但這個基本不是問題）。
• 如何保證能夠快速查出？從 IT 運維看，常見的查詢包括：
  • 查詢單個證券：
    • 基于時間范圍查詢：ts in [startTs, endTs)
    • 基于監控值的過濾：WHERE bid_price_1 >= 10.00;
    • 最新值查詢：ORDER BY ts DESC LIMIT 1
  • 查詢多個證券：在單個證券相同的情況下，只需要更快地返回，能在 1 個查詢里返回更好。
  • 基于時間的計算：
    • 滑動窗口：如 5 日均線圖
    • 狀態窗口：根據成交量分段統計
    • 。。。

基(ji)于(yu)以上的查詢場景，我們可以選擇兩(liang)大路線(xian)：

• N 個證券，每 K 個證券，放在 1 個 table 中
  • K = 1 時，相當于 1 個證券 1 個 table
  • K = N 時，相當于用 1 個 table 存放所有數據

假設你(ni)使(shi)用 InnoDB 引(yin)擎（），不(bu)管怎么選，為了性能(neng)你(ni)都會建索引(yin)。而 InnoDB 的(de)索引(yin)使(shi)用 B-Tree 結構，這(zhe)個數據(ju)(ju)結構在(zai) Rows > 2000w （經驗值）時，數據(ju)(ju)寫(xie)入會因(yin)為索引(yin)的(de)維護成本上升而下降，查詢性能(neng)也一(yi)樣。只是 K = 1 的(de)時候(hou)，這(zhe)個問題才沒(mei)那么明顯：

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

也就是(shi)說 1 個(ge)證券 1 個(ge) table 的時候，存放(fang) 19 個(ge)自(zi)然年數據時，才會明顯感知到(dao)。

當然，我們對(dui)這個問(wen)題有另外一種(zhong)處理方法(fa)：按照時間（一般以天為單位(wei)）在(zai)進行(xing)分表（或分庫）：

• N 個 證券，每 K 個證券，每 D 天 放在 1 個 table
  • 當 K = 1 時
    • D = 1，相當于 1 個證券 1 天 1 個 table。1 年下來有 N/K x 365 = 182,500 個 table。
    • D = 30， 相當于 1 個證券 30 天 1 個 table。1 年下來 有 6083 個 table。
    • D = INF，相當于 1 個證券 1 個 table。
  • K = N 時，相當于用 1 個 table 存放所有數據
    • D = 1，相當于所有證券 1 天 1 個 table。1 年下來 365 個 table。
    • D = 30， 相當于 30 天 1 個 table。 1 年下來 12 個 table。
    • D = INF，相當于 1 個 table。

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

基于 TDengine 建模

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

回到上面(mian)基于 MySQL 的建模思路(lu)，TDengine 的設計里(li)面(mian)，也是 1 個(ge)證券 1 個(ge) table 的理念，通過超(chao)級表(biao)（stable）的語法糖，快速并行查詢多個(ge)證券的數據(ju)；同(tong)時針對常見的業(ye)務查詢場(chang)景(jing)做了定向的性能(neng)優(you)化，從而保證在(zai)「海(hai)量」數據(ju)的情況下，性能(neng)依舊表(biao)現堅挺；而且(qie)還設置了很多有趣的特性，助力時序處理更加簡單(dan)。

標準 SQL 語法

TDengine 支持標(biao)準(zhun) SQL 語法，比老一代的(de)時序數據庫，具備更(geng)好的(de)上手體驗。

動態與靜態數據分離

在 TDengine 當中，超級表(biao)（stable）結(jie)構引入了標簽（tag）的概念，這樣(yang)一來，我(wo)們可以把證券的維度信(xin)息放在標簽當中，減少數據(ju)存儲空間，提升查詢性能。同時，在建模上采用 1 個證券 1 張表(biao)的方式，以此保證高性能讀寫。

通過超級(ji)表(biao)語法糖，TDengine 實現了(le)并行查(cha)詢的能力，大(da)大(da)減少 SQL 的復雜度：

以上便(bian)是兩種(zhong)數據庫對于上述問題(ti)場景的具(ju)體解決思(si)路，你覺(jue)得(de)如果是你會選擇(ze)哪一種(zhong)呢？可(ke)以在評論(lun)區進行留(liu)言，一起討論(lun)。

總(zong)而言(yan)之，不(bu)管是(shi)(shi)傳統的關系型數(shu)據(ju)庫，還是(shi)(shi) NoSQL 數(shu)據(ju)庫，如(ru)果我們沒有針對性地去對應時序數(shu)據(ju)特點，在性能(neng)提升上極為有限(xian)，只能(neng)依靠(kao)集(ji)群技術，投入更(geng)多的計算(suan)資源(yuan)和存儲資源(yuan)來處理(li)，系統的運營維護成本也(ye)會因此急劇上升。如(ru)果你也(ye)面臨著(zhu)海量時序數(shu)據(ju)處理(li)難題，不(bu)妨可(ke)以加一下小T vx：tdengine1，進入 TDengine 用戶交(jiao)流(liu)群，和大(da)家一起來探(tan)討解決路徑(jing)。