在金融量(liang)化交易(yi)場景中(zhong)，每(mei)天都會產生大量(liang)的(de)(de)(de)交易(yi)記錄(lu)和(he)交易(yi)信息需要(yao)(yao)存(cun)儲，同時對數(shu)(shu)(shu)據(ju)(ju)(ju)也(ye)有較高要(yao)(yao)求的(de)(de)(de)查詢需求，整體需求概括起(qi)來就是(shi)歷(li)史數(shu)(shu)(shu)據(ju)(ju)(ju)的(de)(de)(de)存(cun)儲、實時數(shu)(shu)(shu)據(ju)(ju)(ju)的(de)(de)(de)接收以(yi)及數(shu)(shu)(shu)據(ju)(ju)(ju)的(de)(de)(de)監控(kong)和(he)分析(xi)。對于這(zhe)類(lei)有典型時序特征的(de)(de)(de)數(shu)(shu)(shu)據(ju)(ju)(ju)，很(hen)多(duo)企業(ye)在業(ye)務初期選擇了(le)團隊熟悉(xi)的(de)(de)(de) HBase、MySQL、MongoDB 等(deng)數(shu)(shu)(shu)據(ju)(ju)(ju)庫(ku)。但是(shi)隨著業(ye)務的(de)(de)(de)快速發展，這(zhe)些數(shu)(shu)(shu)據(ju)(ju)(ju)庫(ku)已經無(wu)法滿足大體量(liang)數(shu)(shu)(shu)據(ju)(ju)(ju)的(de)(de)(de)寫入、存(cun)儲、分析(xi)監控(kong)等(deng)業(ye)務需求。

為了幫助(zhu)一(yi)(yi)眾金融企(qi)業尋找到(dao)合適(shi)的(de)數據庫(ku)解決方(fang)案(an)，我們(men)匯總了幾個比較有代表性(xing)的(de)企(qi)業客(ke)戶案(an)例，希(xi)望他們(men)的(de)相(xiang)關(guan)實踐經驗應該能夠給到(dao)行業從業者一(yi)(yi)些解決思路(lu)。

TDengine x 同花順

“目前從大(da)數據(ju)監控這個(ge)場景(jing)(jing)看，TDengine 在(zai)(zai)成本、性能和使用便利性方面都顯示出非常大(da)的(de)優(you)勢(shi)，尤其(qi)是在(zai)(zai)節省成本方面給我們帶來了(le)很大(da)驚喜(xi)。在(zai)(zai)預研和項目落(luo)地過程中，濤思數據(ju)的(de)工(gong)程師也提供(gong)了(le)專(zhuan)業、及(ji)時的(de)幫助，后(hou)續我們也將在(zai)(zai)同(tong)花(hua)順的(de)更多場景(jing)(jing)中嘗試應(ying)用 TDengine。”

業務背景

同(tong)花順每天需(xu)要接收海量交易所行情(qing)(qing)數(shu)據(ju)(ju)，確保(bao)行情(qing)(qing)數(shu)據(ju)(ju)的數(shu)據(ju)(ju)準確。但由(you)于該部分數(shu)據(ju)(ju)過(guo)(guo)于龐(pang)大(da)，而且(qie)使(shi)用(yong)場景頗多，每天會產生(sheng)很多的加工(gong)數(shu)據(ju)(ju)，整(zheng)個系(xi)統除了對(dui)實時數(shu)據(ju)(ju)的讀(du)(du)寫性能及(ji)(ji)延時有較高要求(qiu)外(wai)，還需(xu)要聚焦(jiao)歷(li)史日級別數(shu)據(ju)(ju)做(zuo)投資組合的各種分析，在整(zheng)個分析過(guo)(guo)程中(zhong)，涉及(ji)(ji)巨(ju)量的數(shu)據(ju)(ju)集，這對(dui)歷(li)史數(shu)據(ju)(ju)庫的讀(du)(du)寫性能也提出(chu)了很高的要求(qiu)。之(zhi)前采用(yong)的 Postgres+LevelDB 數(shu)據(ju)(ju)存儲方(fang)案，除了依賴多、穩(wen)定(ding)性較差外(wai)，性能方(fang)面也無(wu)法滿足需(xu)求(qiu)（點擊下方(fang)案例(li)鏈(lian)接獲取(qu)具體業務痛(tong)點問題）。通過(guo)(guo)對(dui) ClickHouse、InfluxDB、TDengine 等時序數(shu)據(ju)(ju)存儲方(fang)案的調研，最終其選擇了 TDengine。

架構圖

改造后性能對比

點擊案例查看更多技術細節

TDengine x 弘源泰平

“在寫入(ru)上(shang)，單節點TDengine可以輕松實(shi)現每秒大概 3 萬行數(shu)(shu)據(ju)的寫入(ru)量，同(tong)時消耗服(fu)務(wu)器資源(yuan)又比 InfluxDB 與 MySQL 要小很多。目前我們通過(guo) TDengine 錄入(ru)的兩個信(xin)號表已經寫入(ru)了 82 億條數(shu)(shu)據(ju)，原數(shu)(shu)據(ju)大概為 92GB，實(shi)際(ji)占用存儲空間為 20G 左右，壓縮(suo)率高達 23%。除了寫入(ru)與存儲，TDengine 進行日常查詢的速度也十(shi)分(fen)優秀，面對幾十(shi)億級(ji)別的大表，也能實(shi)現毫秒級(ji)響(xiang)應(ying)。”

業務背景

弘源泰平的量化交易系統每天要接收大量的行情數據，也要基于行情產生大量的決策信號。這些數據都需要及時存下來，供盤中和盤后使用。傳統存放行情數據的方式有文件系統、關系型數據庫或者文檔數據庫。此前他們分別嘗試了 MySQL 和知名的時序數據庫（Time Series Database） InfluxDB，但是性能都沒有達到預期(qi)，出(chu)現了(le)響(xiang)應時間長(chang)、資源浪費等諸多問題（點擊下方案(an)例(li)鏈接(jie)獲取具體(ti)業務痛點問題）。最終，其改用 TDengine 徹(che)底解決了(le)實時寫入大(da)量數(shu)據點和快速查詢(xun)的(de)問題。

資源消耗

服務(wu)器(qi)配(pei)置如下：64G內存+40核 1.8GHz CPU+機械硬盤。在(zai)業務(wu)運行期間，taosd 的(de) CPU 在(zai) 4% 上下浮(fu)動(dong)，進程使用的(de)物理內存百分比(bi)為 11.2%。由于其 vnode 配(pei)置較多(duo)，而每個 vnode 都(dou)有自己固定(ding)的(de)內存緩沖(chong)區，因(yin)此內存占(zhan)用稍多(duo)，但后續即便是繼續大量增加(jia)(jia)新表或者加(jia)(jia)大寫入量，內存占(zhan)用也不會再有明顯的(de)浮(fu)動(dong)了。

點擊案例查看更多技術細節

TDengine x 同心源（三亞）基金

“對入(ru)庫(ku)的總(zong)數據(ju)量進(jin)行(xing)下估算，粗(cu)略計(ji)算為(wei) 408*320 億行(xing)，大概 12TB 左右(you)，后面經(jing)過統計(ji)最終實(shi)際占用(yong)磁盤空間卻只有(you)2T左右(you)，這令我們十分震驚——壓縮率高(gao)達 16.7%。在(zai)查(cha)詢(xun)方面，從TDengine客戶端(duan)服(fu)(fu)務(wu)器使(shi)用(yong)Python從服(fu)(fu)務(wu)端(duan)拉取連續兩個月的期貨行(xing)情數據(ju)，耗時僅需 0.16 秒。”

業務背景

從同心源(yuan)的(de)(de)(de)業務模式出發，業務人員主要通過數(shu)據挖掘和自動模式識別這(zhe)兩種方式來發現市場(chang)(chang)的(de)(de)(de)交易規律，其工(gong)作(zuo)場(chang)(chang)景(jing)基于(yu)大量的(de)(de)(de)金融數(shu)據之上(shang)。經過多年發展，股票市場(chang)(chang)數(shu)據量越發龐大，隨著每日新數(shu)據的(de)(de)(de)清(qing)洗寫入，總(zong)量變(bian)得(de)更加(jia)水(shui)漲船高(gao)。對于(yu)十幾 TB 的(de)(de)(de)數(shu)據量，單是進行存儲已經不易，如果還要對數(shu)據進行查詢下載(zai)等(deng)操作(zuo)，更是難上(shang)加(jia)難。種種問題疊加(jia)，同心源(yuan)對市面上(shang)的(de)(de)(de)主流(liu)數(shu)據庫逐漸喪失信心，嘗試使用更有針對性(xing)的(de)(de)(de)時(shi)序(xu)數(shu)據庫，TDengine 便(bian)是他們的(de)(de)(de)選擇之一(yi)。

點擊案例查看更多技術細節

TDengine x 青島金融研究院

“根(gen)據不(bu)同(tong)類型(xing)的(de)(de)業(ye)務，我們(men)創建了 7 張不(bu)同(tong)的(de)(de)超級表(biao)，子表(biao)數量(liang)(liang)為 33076 張，目前(qian)我們(men)導(dao)入的(de)(de)數據總量(liang)(liang)已(yi)經達到了 46 億(yi)之多，其中(zhong)最(zui)大的(de)(de)一張超級表(biao)達到了 26 億(yi)行，實際磁盤占(zhan)用大概在 130GB 左右。”

業務背景

在其(qi)業務場景中，TDengine 主要負(fu)責三(san)(san)點：一(yi)(yi)是對回(hui)測的(de)數(shu)(shu)據(ju)支持，二是基(ji)于以上數(shu)(shu)據(ju)進行(xing)的(de)回(hui)測數(shu)(shu)據(ju)分(fen)析，三(san)(san)是部分(fen)盤中策略(lve)的(de)數(shu)(shu)據(ju)預加(jia)載。目前其(qi)數(shu)(shu)據(ju)入庫方式是使用 Python 連接(jie)器直接(jie)寫(xie)入 TDengine（6030 端口(kou)）。具體方式為：會通過券商的(de)直連接(jie)口(kou)將他們提供的(de)數(shu)(shu)據(ju)做一(yi)(yi)個(ge) SQL 拼(pin)接(jie)，利用拼(pin)接(jie) SQL 的(de)方式，單(dan)個(ge) SQL 寫(xie)入幾千(qian)行(xing)數(shu)(shu)據(ju)，將大批數(shu)(shu)據(ju)一(yi)(yi)次性寫(xie)入到一(yi)(yi)個(ge)表中。

點擊案例查看更多技術細節

寫在最后

從上述案例中我們也(ye)能(neng)看(kan)到(dao)，看(kan)似簡單的(de)(de)數(shu)(shu)據(ju)處理需求，但由(you)于數(shu)(shu)據(ju)記(ji)錄條數(shu)(shu)巨大(da)，導致數(shu)(shu)據(ju)的(de)(de)實時(shi)寫(xie)入成(cheng)為(wei)瓶頸，查(cha)詢分析極為(wei)緩慢，數(shu)(shu)據(ju)存儲成(cheng)本顯著(zhu)，技(ji)術挑戰層出(chu)不窮(qiong)。而(er)傳(chuan)統的(de)(de)關系型數(shu)(shu)據(ju)庫(ku)、NoSQL Database 沒(mei)有(you)針(zhen)對性去(qu)對應時(shi)序數(shu)(shu)據(ju)特點，在(zai)性能(neng)提升上極為(wei)有(you)限，只(zhi)能(neng)依靠集群(qun)技(ji)術，投(tou)入更多的(de)(de)計算資源和存儲資源來處理，系統的(de)(de)運(yun)營維(wei)護成(cheng)本也(ye)因此急劇(ju)上升。從他們的(de)(de)改造(zao)實踐出(chu)發，選擇時(shi)序數(shu)(shu)據(ju)庫(ku)也(ye)是真(zhen)正的(de)(de)實現了“對癥(zheng)下藥(yao)”。

添加(jia) TDengine 小(xiao)助手(shou)小(xiao)T，找專業的解決方案架構(gou)師(shi)聊一聊