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

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

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

{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}

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

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

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

基于 MySQL 的建模

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

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

基于以上的查詢(xún)場(chǎng)景，我們可以選擇兩大路線(xiàn)：

• N 個(gè)證券，每 K 個(gè)證券，放在 1 個(gè) table 中
  • K = 1 時(shí)，相當(dāng)于 1 個(gè)證券 1 個(gè) table
  • K = N 時(shí)，相當(dāng)于用 1 個(gè) table 存放所有數(shù)據(jù)

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

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

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

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

• N 個(gè) 證券，每 K 個(gè)證券，每 D 天 放在 1 個(gè) table
  • 當(dāng) K = 1 時(shí)
    • D = 1，相當(dāng)于 1 個(gè)證券 1 天 1 個(gè) table。1 年下來(lái)有 N/K x 365 = 182,500 個(gè) table。
    • D = 30， 相當(dāng)于 1 個(gè)證券 30 天 1 個(gè) table。1 年下來(lái) 有 6083 個(gè) table。
    • D = INF，相當(dāng)于 1 個(gè)證券 1 個(gè) table。
  • K = N 時(shí)，相當(dāng)于用 1 個(gè) table 存放所有數(shù)據(jù)
    • D = 1，相當(dāng)于所有證券 1 天 1 個(gè) table。1 年下來(lái) 365 個(gè) table。
    • D = 30， 相當(dāng)于 30 天 1 個(gè) table。 1 年下來(lái) 12 個(gè) table。
    • D = INF，相當(dāng)于 1 個(gè) table。

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

基于 TDengine 建模

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

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

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

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

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

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

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

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

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