做高频交易，储存和查询数据都有哪些较好的解决方案？

用于量化投资策略（最高日频率）研究的金融数据库，用 MySQL 是否足够？有哪些可能遇到的瓶颈？ - Bruce Ashbey 的回答

如果你是来做高频数据，SQL绝对不是解决方案，光是调取数据的查询就要等死你。至于如何解决可以另开一个专题讨论。

腾天 · 2018-10-15 23:55:22

kdb。不过Q语言真的是很虐心

量化交易员 · 2018-10-15 23:55:24

存储：裸数据文件
查询：读文件

刘磊 · 2018-10-15 23:55:25

放内存是肯定的。数据结构自己设计就是。

Mr.Dim · 2018-10-15 23:55:26

实时交易时，一般也就保存当天数据，低频些的保存N天就够了，可以直接内存保存，自己设计数据结构与查询，因为都是时间序列，其实很简单了。历史数据一般可以保存到磁盘，然后启动程序时加载到内存，这样来保证效率。

陈欣 · 2018-10-15 23:55:27

我们做高频的数据都是在内存里，有多少放多少，因为实时写数据库这个十分不现实。主要是数据在落地和吞吐的时候很慢，高频的算法经常会用到一些前面的数据，即便是日内的数据也会多次查询，读取，而且操作频繁。一般在延时之后，会把数据以小文件的形式写库，具体数据库怎么建表存储，那是另外一回事了。一旦秒内高并发产生，你处理不好只有宕机。上海交易所每秒能处理8万笔交易，但所有数据也是先放在内存，后延时写库。

detail lee · 2018-10-15 23:55:28

可以用hbase试下

双木成林 · 2018-10-15 23:55:29

如果是做数据存储，sql够了。如果是做数据分析，sql也够了。如果是做交易，什么数据库都白搭。

做高频交易，储存和查询数据都有哪些较好的解决方案？

7 个回复