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就可以了

在数据库存储中，每行占用的空间都是一致的，在这种根据数据自定义的存储中，由于我们知道数据的规律，所以可以定制化的存储减少容量，例如我们这里就是采用增量存储。这当然可以大大的节省空间。