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