终于又有点进展～

1秒内多次的ticket数据密度*若干年的数据时间，是一个十分恐怖的值。
为了让我以后的策略能够在这么多数据中快速检索，我想来想去，还是针对交易市场的特征，自己做一个数据库。
经过3周的琐碎时间，经历了2个版本，现在终于小有成果了～～

刚跑了一个测试，存储400000000个数据点，总数据容量为305MB。
存储这么多数据用掉了38.97秒。
把这么多数据读取一遍，用了3.985秒。
在这个数据规模中随机检索10000次，耗时2.977秒。
最后是压缩比差不多为100：1，也就是305MB的数据只用了3.0M就存下了～～

不过测试数据是生成的，也许规律性太强了～不知道实际数据下表现会如何～

下一步开始导入从CTP接收的数据，然后实现自己的图表UI～然后就可以开始研究点策略了～

 

存储时间就是压缩时间～

 

太强大了。牛人都自己写程序存数据和分析数据。

 

kdb+如何啊？

 

不压缩存储，容量就是305M。
存储时间肯定会快很多，我估算下差不多是写入3秒左右。
读取时间未必会快，我估计应该也是3－4秒左右的样子。

但是，我的数据结构就是按照压缩后还能快速检索设计的，不压缩就没意义了。

 

靠，貌似是一个现成的用户交易数据的数据库啊～～～
早说我就不自己写了...

 

........
HYLT上這個軟件討論很熱烈呀，見專版。

 

看了下这个东西～检索的功能比我要强大许多。
并且检索速度上，它只要10ms，而偶的实现需要300ms，高了一个数量级～

它的高级功能对我来说没啥用，偶只需要一个能快速提供任意数据密度，以及任意时间段的交易数据的工具即可～

偶实现的特点是内存使用很小，基本上任何时候都只占用几兆内存，几乎全部直接基于磁盘操作，并且支持高度压缩过的数据，数据文件规模可以上T。

毕竟，偶需要考虑VPS环境，许多VPS环境内存很扣的～

 

好吧...我见过这个缩写...
但是kdb在CS里面有别的含义，于是被我无视了...
我这就找这个专版潜水去～

 

牛！非常羡慕楼主，我有时苦于数据太庞大没法实现某些想法。
能否联系楼主？

 

你可以给我发邮件，但是我现在只投入20％－30％的精力在这上面，所以你的一些要求我未必能有精力去实现～

 

楼主用什么模型，需要秒的数据，将来这交易系统是不是一天会进行海量次数的交易？

 

秒的数据不算海量，tick数据。

 

我目前还没考虑过模型。我的路线是先自己做个平台，
并且为了在这个平台中实现精确的backtest，我需要依据tick的数据。

目前UI部分已经大致完成～明天再导入真实数据看看效果～～

 

你这样的，以后钱还都要给你赚走了啊？

 

我觉得适当的策略才最重要，其他的都可以弥补。
在搭建平台方面仰视LVSOFT这样的高手。。。。。。

 

最近一直在折腾把以前用CTP收的数据导入到新写的数据库的问题。
总是会卡死在内存不足上，我始终以为是内存泄漏等问题，不然不会用掉这么多内存...百思不得其解...

今天去拍了跟2G的内存之后，忽然想明白了原因～～因为我的开发环境是32位系统，而运行环境受限于CTP的限制，是64位系统。同样的代码，同样的数据集，在64位系统上比32位系统多用了将近一倍的内存...

因为Python对象的存储过程中大量运用了指针，因此Python的数据密集型应用在64位系统上内存占用会很明显。这样看来必须构造一个hybrid环境了，自己的机器还好说，VPS的内存相对而言实在是太少了，禁不起这么浪费...