金融分析量化系统，高频交易程序数据库通常采用哪种方式存贮数据？

目前考虑过一些大型的数据库存贮系统，例如关系型数据Mysql，Oracle。
还有一些NoSQL数据库，Cassandra，redis，MongoDB。
额外参考了HDF5数据库。

每天会存贮大量的交易记录和交易信息，整体的市场数据信息，希望能够做到实时的数据钻取和分析功能，对市场出现的情形能够及时预警。

like · 2018-10-13 14:24:53

做过大量的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
只可惜人家收费。。。还很贵

专业打杂的砖头 · 2018-10-13 14:24:54

从场景来看，题主主要想问的是

历史数据的存储
实时行情接收
实时交易信息的记录与分析（预警也算是分析的一种，分析完给个信号）

那就分这三部分来说。
第一部分是历史数据的存储，股票的量最大，就拿股票来说。特别指出，抛开使用场景谈数据库都是耍流氓！存历史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也是适用的。如果题主有需求再往上，也有相应的办法，再补充。

李发 · 2018-10-13 14:24:55

数据库没卵用，我们是直接自定义数据格式配合自己写的分段压缩加内存解压库函数，压缩部分用了gpu加速，压缩程序是在开源程序基础上改并优化的，主要是提高并行效率并支持多gpu加速，速度满足需要。小而杂的数据直接用matlab自带的mat存。

Rascalrr · 2018-10-13 14:24:56

智能交易系统和历史回测系统一般需要分开对待。
以近期的沪深全市场交易情况而言：
1. L2实时行情（行情，逐笔委托，委托队列，逐笔成交）大约在8000万至1亿3千万件左右，每秒数据流量在5000-9000件左右，交易火爆的时候峰值13000左右，不压缩存储的话，大约是一天35G左右，因此对于实时交易预警，64G的内存就可以搞定了，当然如果继续额外的指标的话，内存用量也要进一步增加。

2.历史库我们目前使用的是 SQLServer + 文件的方式进行存储 + 磁带备份。2007年至现在的全部历史数据占用磁盘空间已经接近10T了。
说实话，性能是比较差的，我试过对某一天的市场做完整扫描，耗时在4个小时以上。非常不建议对整个市场做tick级别的历史数据扫描。

总的来说，依托廉价的内存和强大的CPU，对当日数据做实时处理问题不大。
历史数据回测的话，还是挑选一部分标的比较好。

菜鸟1号策略 · 2018-10-13 14:24:58

日内的数据可以直接放在内存，历史数据最好用NoSQL，我们公司是MongoDB+HBase构架的，需要详细的参数指标可以私信我。

赵成业 · 2018-10-13 14:24:59

对于原始的高频行情数据（不针对日线等中低频率的行情），我们的经验是用KV存储的方式存储。Key可以取“股票ID+日期+字段名”， Value可以是一天或者一周内属于该股票的该字段（或者某些字段）的所有行情值。这个方案比较好的地方是：1）可以按照某个特定的字段（或者字段组）查询和修改。2）KV存储的选型很多：Redis, 分布式文件系统，RocksDB, WiredTiger等都可以供使用。3）其他高级的查询功能可以在KV查询的基础上扩展开发。

李伟 · 2018-10-13 14:25:00

@袁浩瀚
他应该知道。
有个专门的问题：
Quant 如何运算百万行的数据？

不知道解答你的问题没，只知道这么多。

find goo · 2018-10-13 14:25:02

上硬件有时比软件更有效。工作站用新版mac pro，价格也不贵一辆破车，有十二核处理器， 64g内存，1tb的ssd。服务器买个新版的，新版服务器最大支持TB级内存，可把内存虚拟成硬盘用。如果追求性价比，用ssd比扩展内存更划算。

软件用Redis，ssdb，mongodb，apache ignite，或自定义c++流存储。如果用数据库有memsql，timesten，可能要收费，单机版的sqlite，h2，leveldb的内存模式开源免费，并发时需要编程。

未来数据处理发展方向是内存计算，充分利用内存，硬盘io是现在很多数据处理程序的瓶颈。

Mr Mistake · 2018-10-13 14:25:03

Kdb

tradercoder · 2018-10-13 14:25:04

首先这是个解决方案，不能简单的用一个数据库就全部搞定数据持久化，得混合用。
1. 存储交易记录/数据用关系型数据库oracle msqlsever mysql传统的3大数据库就可以，ibm的db2就不要选了，尽管银行还用它，也是历史原因。oracle存储绝对够了，如果交易数据真的很多，可以用分区表，肯定能够秒杀你的应用。如果你还嫌慢，花钱联系我。
2.至于结构化的行情数据，可用hbase等，或者直接基于hd5下写个自己的行情专业数据库，不过我相信hbase够用了，尽管它是java写的。不要跟我说你实时交易的时候每次还要去重头从数据库里提一遍数据，那你的架构方向就错了。
3.至于交易用的大数据，裸信息存在hbase下，加工后的结果数据可以存储在oracle中，毕竟加工后的数据结构很清晰了，等等。
这个没有标准答案，适合自己的就好。

手机打字真tmd的累。

Jerry He · 2018-10-13 14:25:05

不推荐SQL数据库和mongodb数据库，原因是最终数据太大，期货市场一天的tick数据，如果用csv存的话，一天应该在400M，所以一年就是100G左右。这种数据库用在这太慢，用起来也没那么方便。
推荐HDF5，次一点直接用csv文件存都挺好。一个合约一天一个文件，再按月或者按品种组织一下，简单好用。csv的好处是可读性、兼容性更好；缺点是文件大，读入比HDF5慢挺多。
实盘行情落地的话我们用google的leveldb数据库，在此之上提供如以API接口（C++, python, etc），http接口，但是缺点是不直接，得用我们自己开发的特殊的程序（接口）才能拿到数据。

杨东东 · 2018-10-13 14:25:06

时间序列数据存取？看看这个是否有用https://yq.aliyun.com/articles/54480

木十一 · 2018-10-13 14:25:08

当然是关系型数据库，就是Oracle、MySQL、SQL Server、Sybase这些。
行情数据是结构化数据，数据结构忒简单，当然最适合关系型数据库。
至于性能，以上任何一个数据库在处理结构化数据都可以秒杀Redis、MongoDB、HDF，csv就更别提了好吗。轻型数据库的性能优势，其实源于放弃其他计算元素。
本人一贯使用RDBMS存储行情数据，很少遇到不能优化解决的问题。话说以前为移动写程序，一个省一个月的话单轻松过百亿，用过Oracle、Sybase，没见到有什么不适。全省几百台客户机连上来，高并发，重事务，除了这些大哥级数据库，谁能挺得住？
任意时间、任意地点，各种变态查询，统计分析，数据挖掘，大多一句SQL搞定。搞不定的，也可以前置筛选计算，导出数据再喂给pandas，事半功倍。
经常用的查询，保存成视图，下次直接调用。
极端需要考虑性能的，procedure上。
还有，既然交易为生，你搭建的是生产系统，不是IT技术研究，请尊重自己的劳动，至少选用企业级产品，要存储、要计算，还要考虑可用性、备份、恢复、共享、权限、安全。请尽量使用通用技术，一旦发生数据灾难，OCP比Redis专家好找得多。

weljohn · 2018-10-13 14:25:09

kdb，基本上大行都用这个。kdb不仅仅是数据库，配合自带的q语言，处理金融tick数据，做历史回测无敌了

yang sky · 2018-10-13 14:25:10

以天软在量化金融圈多年的数据整合经验来看，nosql存储是合适的，对历史百亿级别的tick数据访问也可以做到很高效，有兴趣可以找我试试，不是广告！

一级防御宝石 · 2018-10-13 14:25:11

Kdb32位统，免费，可以做实时系统，接口也多，目前正在折腾离线转在线。还有一个monetdb。关键是要列式数据库。

徐同学 · 2018-10-13 14:25:12

KDB+
32位貌似不收费，了解到貌似国内的外资投行在时间序列处理方面都用到这一数据库。但价格较高

金融分析量化系统，高频交易程序数据库通常采用哪种方式存贮数据？

17 个回复