金融分析量化系統，高頻交易程序資料庫通常採用哪種方式存貯數據？

12-27

目前考慮過一些大型的資料庫存貯系統，例如關係型數據Mysql，Oracle。

還有一些NoSQL資料庫，Cassandra，redis，MongoDB。

額外參考了HDF5資料庫。

每天會存貯大量的交易記錄和交易信息，整體的市場數據信息，希望能夠做到實時的數據鑽取和分析功能，對市場出現的情形能夠及時預警。

做過大量的tick級別數據處理，被東京交易所的壓力測試以及225個basket order折磨過，個人意見是：

1. 直接放棄，Mysql和Oracle在這個問題上就是大坑，沒有任何優勢沒有任何便利，無法大家方便共享分析，查詢極度緩慢等等

2. NoSQL資料庫。不錯的選擇，但是需要看你將來預測的數據量，如果&>32G你使用redis起來就已經沒那麼爽了，至於其他的存硬碟類型NoSql DB也是可以的，可以滿足需求沒有問題。但是我建議選一個pandas直接能支持的，便於最快速度結合。仍舊最後不是我的最優選擇，那麼最優選擇在最後：

3. HDF5極度強大。支持java、python、c沒有問題。內部你做好group、dataset的分類天然就是資料庫並且也可以隨處遷移。我大概試了下10年的分鐘級別數據只需要100-200G左右的HDF5文件淡然你可以每個股票單獨存一個10年的。大家需要研究的時候發給對方即可，也可以搭建一個share file system解決。這裡對於2的優勢是存儲空間極小相對於DB format。
那麼最關鍵的點來了：速度。我用的是java + 經過了warmup（pre 2000 iteration JIT compile）之後，讀取任意一天的minute bar的速度是30-40 micro second，碾壓2的選擇。PS：使用的是mac Book Pro + SSD
另外HDF5和pandas無縫對接，所以研究也快。

但是但是。。。最強的呢還是KDB : http://kx.com/software.php
只可惜人家收費。。。還很貴

從場景來看，題主主要想問的是

歷史數據的存儲
實時行情接收
實時交易信息的記錄與分析（預警也算是分析的一種，分析完給個信號）

那就分這三部分來說。

第一部分是歷史數據的存儲，股票的量最大，就拿股票來說。特別指出，拋開使用場景談資料庫都是耍流氓！存歷史Tick主要是為了回測。回測主要的需求就是把Tick讀進內存，交給CPU處理策略的邏輯即可。針對這種場景，阿里的OSS就夠了（跑回測的機器也是在阿里上，所以其實是內網環境），等於是一個沒有容量限制的文件系統。一般每天全市場3000個股票Tick數據在600M上下，壓縮過之後就算100M，也內網傳輸也只需要1-2秒左右。其實回測的時候，瓶頸還是在CPU上，而不是I/O和內網延遲。當然，為了讀取方便，在策略和文件系統中間，建一層把一些基本的讀取邏輯寫在這層裡面，暴露方便自己策略用的介面。

第二部分是行情接收，實時主要是接收tick級別的行情數據，內存資料庫是逃不掉的，題主提到的Redis夠用了。除了可以用來做收數據之外，還可以做轉發，Redis本身就提供了消息隊列的功能，如果有多個策略一起跑要拿相同的數據源，Redis就很適用。就像前面有答主說的，確實Redis體量一大會虛，但如果我們只是把Redis當作實時接收 + 轉發，一般裡面的數據都不會超過2天，所以體量也就不是問題了。

第三部分是和委託/成交相關的信息的記錄，這塊的場景主要是盤中的監控和盤後的分析

盤中監控的信息一般內容不多（相比盤後分析），對速度要求高，可以用Influxdb這類時間序列。除了時間序列常見的優點外，查詢語言與SQL很接近，用起來方便，對接Grafana這類的前段框架也方便。如果在數據搜集上面有更多需求，比如對histogram的支持，也可以用Telegraf。架構是Telegraf -&> Influx -&> Grafana。另外，近期的行情數據，其實也可以放在influxdb裡面，別放太多就行，算是當一個行情的緩存。
盤後分析對應的數據量比較大，一般來說針對每個委託/成交都有不少的數據要存，特別是和策略相關的信息，推薦用ElasticSearch。一方面可以支持Nested的結構，在debug的時候想要對存的field做增減，代碼也變動很小，不需要改資料庫的結構。另外搜索功能確實強大，時間聚合方面的函數也支持的很好。當然如果對Mongo熟悉用Mongo也ok。另外ES的話就是查詢語言相對學習曲線陡一些，不像Influx那麼好上手

最後，以上架構經過驗證，支持幾十TB肯定沒問題，幾百個G也是適用的。如果題主有需求再往上，也有相應的辦法，再補充。

資料庫沒卵用，我們是直接自定義數據格式配合自己寫的分段壓縮加內存解壓庫函數，壓縮部分用了gpu加速，壓縮程序是在開源程序基礎上改並優化的，主要是提高並行效率並支持多gpu加速，速度滿足需要。小而雜的數據直接用matlab自帶的mat存。

智能交易系統和歷史回測系統一般需要分開對待。
以近期的滬深全市場交易情況而言：
1. L2實時行情（行情，逐筆委託，委託隊列，逐筆成交）大約在8000萬至1億3千萬件左右，每秒數據流量在5000-9000件左右，交易火爆的時候峰值13000左右，不壓縮存儲的話，大約是一天35G左右，因此對於實時交易預警，64G的內存就可以搞定了，當然如果繼續額外的指標的話，內存用量也要進一步增加。

2.歷史庫我們目前使用的是 SQLServer + 文件的方式進行存儲 + 磁帶備份。2007年至現在的全部歷史數據佔用磁碟空間已經接近10T了。
說實話，性能是比較差的，我試過對某一天的市場做完整掃描，耗時在4個小時以上。非常不建議對整個市場做tick級別的歷史數據掃描。

總的來說，依託廉價的內存和強大的CPU，對當日數據做實時處理問題不大。
歷史數據回測的話，還是挑選一部分標的比較好。

實時數據我們用的oracle的內存資料庫，想過用kdb的，但在中國招懂它的人太難了

日內的數據可以直接放在內存，歷史數據最好用NoSQL，我們公司是MongoDB+HBase構架的，需要詳細的參數指標可以私信我。

對於原始的高頻行情數據（不針對日線等中低頻率的行情），我們的經驗是用KV存儲的方式存儲。Key可以取「股票ID+日期+欄位名」， Value可以是一天或者一周內屬於該股票的該欄位（或者某些欄位）的所有行情值。這個方案比較好的地方是：1）可以按照某個特定的欄位（或者欄位組）查詢和修改。2）KV存儲的選型很多：Redis, 分散式文件系統，RocksDB, WiredTiger等都可以供使用。3）其他高級的查詢功能可以在KV查詢的基礎上擴展開發。

@袁浩瀚
他應該知道。
有個專門的問題：
Quant 如何運算百萬行的數據？

不知道解答你的問題沒，只知道這麼多。

高頻交易一般實時交易的時候用不著資料庫的，一般用到的數據並不多。
但是回測的時候，數據量倒是非常的大。
目前mongodb和casanndra比較好點。但是cassandrea是基於java的。因為高頻交易一般都是基於linux系統下面的c++編寫的，所以建議mongodb。

上硬體有時比軟體更有效。工作站用新版mac pro，價格也不貴一輛破車，有十二核處理器， 64g內存，1tb的ssd。伺服器買個新版的，新版伺服器最大支持TB級內存，可把內存虛擬成硬碟用。如果追求性價比，用ssd比擴展內存更划算。

軟體用Redis，ssdb，mongodb，apache ignite，或自定義c++流存儲。如果用資料庫有memsql，timesten，可能要收費，單機版的sqlite，h2，leveldb的內存模式開源免費，並發時需要編程。

未來數據處理髮展方向是內存計算，充分利用內存，硬碟io是現在很多數據處理程序的瓶頸。

Kdb

首先這是個解決方案，不能簡單的用一個資料庫就全部搞定數據持久化，得混合用。
1. 存儲交易記錄/數據用關係型資料庫oracle msqlsever mysql傳統的3大資料庫就可以，ibm的db2就不要選了，儘管銀行還用它，也是歷史原因。oracle存儲絕對夠了，如果交易數據真的很多，可以用分區表，肯定能夠秒殺你的應用。如果你還嫌慢，花錢聯繫我。
2.至於結構化的行情數據，可用hbase等，或者直接基於hd5下寫個自己的行情專業資料庫，不過我相信hbase夠用了，儘管它是java寫的。不要跟我說你實時交易的時候每次還要去重頭從資料庫里提一遍數據，那你的架構方向就錯了。
3.至於交易用的大數據，裸信息存在hbase下，加工後的結果數據可以存儲在oracle中，畢竟加工後的數據結構很清晰了，等等。
這個沒有標準答案，適合自己的就好。

手機打字真tmd的累。

不推薦SQL資料庫和mongodb資料庫，原因是最終數據太大，期貨市場一天的tick數據，如果用csv存的話，一天應該在400M，所以一年就是100G左右。這種資料庫用在這太慢，用起來也沒那麼方便。

推薦HDF5，次一點直接用csv文件存都挺好。一個合約一天一個文件，再按月或者按品種組織一下，簡單好用。csv的好處是可讀性、兼容性更好；缺點是文件大，讀入比HDF5慢挺多。

實盤行情落地的話我們用google的leveldb資料庫，在此之上提供如以API介面（C++, python, etc），http介面，但是缺點是不直接，得用我們自己開發的特殊的程序（介面）才能拿到數據。

時間序列數據存取？看看這個是否有用https://yq.aliyun.com/articles/54480

兩方面來看：1，研究。2，實戰。
1，研究。常見資料庫我認為都可以，或者說會有用武之地。關鍵在於如何方便。涉及到研究員熟悉的終端工具對接，比如Matlab，或者是Python，又或SASS。
如果只是Tick數據，核心問題是如何保存到本地進行處理，只要能到本地，問題解決了大半。按目前的狀態，一天的數據應該是10GB+，去年峰值能達到30GB，從下載到處理完成，可能需要40分鐘左右（按我目前的經驗值）。
2，實戰。我只能說自己的情況，資料庫完全被否決了，日內交易數據是全部存入內存，實戰程序我使用的C++，vector/map/hashtable可以秒掉絕大多數的資料庫（包括內存資料庫）。
KDB+我沒有用過，推測上，最終底層還是最基礎的一些數據結構，所以在明確需求的情況下，我認為不具備性能優勢（相對vector/map等有序結構）。

當然是關係型資料庫，就是Oracle、MySQL、SQL Server、Sybase這些。

行情數據是結構化數據，數據結構忒簡單，當然最適合關係型資料庫。

至於性能，以上任何一個資料庫在處理結構化數據都可以秒殺Redis、MongoDB、HDF，csv就更別提了好嗎。輕型資料庫的性能優勢，其實源於放棄其他計算元素。

本人一貫使用RDBMS存儲行情數據，很少遇到不能優化解決的問題。話說以前為移動寫程序，一個省一個月的話單輕鬆過百億，用過Oracle、Sybase，沒見到有什麼不適。全省幾百台客戶機連上來，高並發，重事務，除了這些大哥級資料庫，誰能挺得住？

任意時間、任意地點，各種變態查詢，統計分析，數據挖掘，大多一句SQL搞定。搞不定的，也可以前置篩選計算，導出數據再餵給pandas，事半功倍。

經常用的查詢，保存成視圖，下次直接調用。

極端需要考慮性能的，procedure上。

還有，既然交易為生，你搭建的是生產系統，不是IT技術研究，請尊重自己的勞動，至少選用企業級產品，要存儲、要計算，還要考慮可用性、備份、恢復、共享、許可權、安全。請盡量使用通用技術，一旦發生數據災難，OCP比Redis專家好找得多。

kdb，基本上大行都用這個。kdb不僅僅是資料庫，配合自帶的q語言，處理金融tick數據，做歷史回測無敵了

以天軟在量化金融圈多年的數據整合經驗來看，nosql存儲是合適的，對歷史百億級別的tick數據訪問也可以做到很高效，有興趣可以找我試試，不是廣告！

Kdb32位統，免費，可以做實時系統，介面也多，目前正在折騰離線轉在線。還有一個monetdb。關鍵是要列式資料庫。

KDB+
32位貌似不收費，了解到貌似國內的外資投行在時間序列處理方面都用到這一資料庫。但價格較高