4.资讯厂商如何转发和存储高频行情数据(LEVELI&II)?
请关注个人小站:http://sqlhis.com/
券商和基金公司都有LEVEL1数据的接口,如果不需要将历史行情存储下来的话,自己开发一个行情接收程序是不难的,这些公司购买的交易系统,本身就带有接入行情的功能。
但是如果需要将历史数据存储下来,通常需要借助于资讯产商,理论上自己写个程序存也是可以的,问题的难点在于如果行情出现中断,数据丢了就没有地方可以补,所以一般来说,只要需要用到历史的交易数据,通常会找资讯产商购买一套软件。特别是LEVEL2,没有资讯产商似乎不太可能.
每个资讯产商落地行情的方式不太一样,笔者接触过三家,第一家是笔者实际实施的,后面两家都只是了解。
第一家是比较老牌的产商,后来被一家大牌的产商收购了。其LEVEL2行情分为实时和历史,提供一个接口访问数据,数据的压缩率很高,LEVEL2数据一天1个G就存下来了。
优点:数据压缩率高
缺点:使用不方便,对于笔者这种程序员来说都感觉麻烦,更不用说那些需要进行数据分析的研究员了,门槛太高。
注:当时接入的时候,花了几个月给这家找各种问题,数据准确性问题很多,由此可以退出其实国内真正使用LEVEL2数据的公司其实不多。
第二家比较弱,做学校项目比较多,使用的时候只用了LEVEL1的数据,每天打包一个文件,只提供历史数据,通过FTP方式访问。
第三家也做了一个接收发送程序,从他们的服务器上取数据,数据存在数据库里面,好几种数据库都可以。
优点:存关系数据库里面使用方便一些
缺点:数据库设计太差,表设计及其不合理,占用空间极大。
所以就笔者理解,要不然就是采用文件形式高压缩,要不然就是采用数据库方式占用空间很大。
说下文件的高压缩方式,文件的高压缩方式一定能比数据库省空间,但是文件的压缩绝对不是说生成一个二进制文件,然后拿zip或者rar压缩一把就可以了,这还是达不到高压缩的效果。以第一家为例,压缩模式类似于这样:
假设行情如下:
时间 | 价格 |
---|---|
9:30:00 | 9.99 |
9:30:03 | 9.99 |
9:30:06 | 10.00 |
则存储为:
第一行 | 时间:34200,距离0点的秒数 价格:999 |
时间占用2个字节 价格带小数,但是存成整数,知道最大价格,例如9999.99,占用2.5个字节 |
第二行 | 时间:+3 价格:不变 |
只存储时间增量,4个BIT即可 不变的价格用一个BIT就可以了 |
第三行 | 时间:+3 价格:+1 |
只存储时间增量,4个BIT即可 变化的价格只用4个BIT就可以了 |
在数据库存储中,每行占用的空间都是一致的,在这种根据数据自定义的存储中,由于我们知道数据的规律,所以可以定制化的存储减少容量,例如我们这里就是采用增量存储。这当然可以大大的节省空间。