在金融量化交易場景中，每天都會產(chǎn)生大量的交易記錄和交易信息需要存儲，同時對數(shù)據(jù)也有較高要求的查詢需求，整體需求概括起來就是歷史數(shù)據(jù)的存儲、實時數(shù)據(jù)的接收以及數(shù)據(jù)的監(jiān)控和分析。對于這類有典型時序特征的數(shù)據(jù)，很多企業(yè)在業(yè)務(wù)初期選擇了團隊熟悉的 HBase、MySQL、MongoDB 等數(shù)據(jù)庫。但是隨著業(yè)務(wù)的快速發(fā)展，這些數(shù)據(jù)庫已經(jīng)無法滿足大體量數(shù)據(jù)的寫入、存儲、分析監(jiān)控等業(yè)務(wù)需求。

為了幫助一眾金融企業(yè)尋找到合適的數(shù)據(jù)庫解決方案，我們匯總了幾個比較有代表性的企業(yè)客戶案例，希望他們的相關(guān)實踐經(jīng)驗應(yīng)該能夠給到行業(yè)從業(yè)者一些解決思路。

TDengine x 同花順

“目前從大數(shù)據(jù)監(jiān)控這個場景看，TDengine 在成本、性能和使用便利性方面都顯示出非常大的優(yōu)勢，尤其是在節(jié)省成本方面給我們帶來了很大驚喜。在預(yù)研和項目落地過程中，濤思數(shù)據(jù)的工程師也提供了專業(yè)、及時的幫助，后續(xù)我們也將在同花順的更多場景中嘗試應(yīng)用 TDengine?！?/p>

業(yè)務(wù)背景

同花順每天需要接收海量交易所行情數(shù)據(jù)，確保行情數(shù)據(jù)的數(shù)據(jù)準(zhǔn)確。但由于該部分?jǐn)?shù)據(jù)過于龐大，而且使用場景頗多，每天會產(chǎn)生很多的加工數(shù)據(jù)，整個系統(tǒng)除了對實時數(shù)據(jù)的讀寫性能及延時有較高要求外，還需要聚焦歷史日級別數(shù)據(jù)做投資組合的各種分析，在整個分析過程中，涉及巨量的數(shù)據(jù)集，這對歷史數(shù)據(jù)庫的讀寫性能也提出了很高的要求。之前采用的 Postgres+LevelDB 數(shù)據(jù)存儲方案，除了依賴多、穩(wěn)定性較差外，性能方面也無法滿足需求（點擊下方案例鏈接獲取具體業(yè)務(wù)痛點問題）。通過對 ClickHouse、InfluxDB、TDengine 等時序數(shù)據(jù)存儲方案的調(diào)研，最終其選擇了 TDengine。

架構(gòu)圖

改造后性能對比

點擊案例查看更多技術(shù)細節(jié)

TDengine x 弘源泰平

“在寫入上，單節(jié)點TDengine可以輕松實現(xiàn)每秒大概 3 萬行數(shù)據(jù)的寫入量，同時消耗服務(wù)器資源又比 InfluxDB 與 MySQL 要小很多。目前我們通過 TDengine 錄入的兩個信號表已經(jīng)寫入了 82 億條數(shù)據(jù)，原數(shù)據(jù)大概為 92GB，實際占用存儲空間為 20G 左右，壓縮率高達 23%。除了寫入與存儲，TDengine 進行日常查詢的速度也十分優(yōu)秀，面對幾十億級別的大表，也能實現(xiàn)毫秒級響應(yīng)?！?/p>

業(yè)務(wù)背景

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

資源消耗

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

點擊案例查看更多技術(shù)細節(jié)

TDengine x 同心源（三亞）基金

“對入庫的總數(shù)據(jù)量進行下估算，粗略計算為 408*320 億行，大概 12TB 左右，后面經(jīng)過統(tǒng)計最終實際占用磁盤空間卻只有2T左右，這令我們十分震驚——壓縮率高達 16.7%。在查詢方面，從TDengine客戶端服務(wù)器使用Python從服務(wù)端拉取連續(xù)兩個月的期貨行情數(shù)據(jù)，耗時僅需 0.16 秒?！?/p>

業(yè)務(wù)背景

從同心源的業(yè)務(wù)模式出發(fā)，業(yè)務(wù)人員主要通過數(shù)據(jù)挖掘和自動模式識別這兩種方式來發(fā)現(xiàn)市場的交易規(guī)律，其工作場景基于大量的金融數(shù)據(jù)之上。經(jīng)過多年發(fā)展，股票市場數(shù)據(jù)量越發(fā)龐大，隨著每日新數(shù)據(jù)的清洗寫入，總量變得更加水漲船高。對于十幾 TB 的數(shù)據(jù)量，單是進行存儲已經(jīng)不易，如果還要對數(shù)據(jù)進行查詢下載等操作，更是難上加難。種種問題疊加，同心源對市面上的主流數(shù)據(jù)庫逐漸喪失信心，嘗試使用更有針對性的時序數(shù)據(jù)庫，TDengine 便是他們的選擇之一。

點擊案例查看更多技術(shù)細節(jié)

TDengine x 青島金融研究院

“根據(jù)不同類型的業(yè)務(wù)，我們創(chuàng)建了 7 張不同的超級表，子表數(shù)量為 33076 張，目前我們導(dǎo)入的數(shù)據(jù)總量已經(jīng)達到了 46 億之多，其中最大的一張超級表達到了 26 億行，實際磁盤占用大概在 130GB 左右?！?/p>

業(yè)務(wù)背景

在其業(yè)務(wù)場景中，TDengine 主要負責(zé)三點：一是對回測的數(shù)據(jù)支持，二是基于以上數(shù)據(jù)進行的回測數(shù)據(jù)分析，三是部分盤中策略的數(shù)據(jù)預(yù)加載。目前其數(shù)據(jù)入庫方式是使用 Python 連接器直接寫入 TDengine（6030 端口）。具體方式為：會通過券商的直連接口將他們提供的數(shù)據(jù)做一個 SQL 拼接，利用拼接 SQL 的方式，單個 SQL 寫入幾千行數(shù)據(jù)，將大批數(shù)據(jù)一次性寫入到一個表中。

點擊案例查看更多技術(shù)細節(jié)

寫在最后

從上述案例中我們也能看到，看似簡單的數(shù)據(jù)處理需求，但由于數(shù)據(jù)記錄條數(shù)巨大，導(dǎo)致數(shù)據(jù)的實時寫入成為瓶頸，查詢分析極為緩慢，數(shù)據(jù)存儲成本顯著，技術(shù)挑戰(zhàn)層出不窮。而傳統(tǒng)的關(guān)系型數(shù)據(jù)庫、NoSQL Database 沒有針對性去對應(yīng)時序數(shù)據(jù)特點，在性能提升上極為有限，只能依靠集群技術(shù)，投入更多的計算資源和存儲資源來處理，系統(tǒng)的運營維護成本也因此急劇上升。從他們的改造實踐出發(fā)，選擇時序數(shù)據(jù)庫也是真正的實現(xiàn)了“對癥下藥”。

添加 TDengine 小助手小T，找專業(yè)的解決方案架構(gòu)師聊一聊