股票分钟数据存储方案及海量数据架构方案

 

场景20亿分钟K线数据的更新及查找

 

1，了解数据使用情况

 

　　这些k线数据用于回测，而对于分钟k线回测：

• 大部分回测周期在近几个月或近几年
• 热门股票几多沪深300、上证50等
• 分钟回测需要一定的实时性既在开盘时间进行回测，需要最近的数据
• 数据增量每日几百MB

　　※初始热数据的划分需要对业务进行深入了解

　　※后续热数据的精确划分还是要查看历史查询的记录

　　统计来源：程序中添加的数据操作log；数据库审计；数据库中间件

 

2，根据数据使用频率进行拆分

 

　　我将数据划分2个层级：

　　1，热数据：热门股票的近1个月的数据

　　2，使用频率较低的K线数据

 

　　※根据热度使2种不同的存储方式（时间段划分）：

• 热度数据-redis；
• 频率低及冷数据-bcolz文件（频率低的单独建立文件）

　　每日夜间进行更新：将过时的部分热数据从redis中写入数据库

　　每周进行更新：将数据库过时的数据存入bcolz文件中（bcolz有非常不错的压缩率和速度）

 

 

3，数据库架构演变

 

　　1，针对于量化回测，主要的瓶颈在于读数据（每日读的数据远远大于写的数据）

 

　　2，对于系统日后增长的使用量，我们将划分的数据分配独立的服务器

　　　　※redis集群，数据库集群，文件服务器

　　　　以上都是用中间件进行访问控制

 

　　3，数据库的读瓶颈的演变

• • 数据库瓶颈：一张表存海量数据（解决办法：分表）
  • 服务器瓶颈：查询需求大于磁盘的io性能或负载能力（解决办法：分库）

　　　　※综上所述我们将数据库中的热门股票平均划分到N个库中，并再进行分表

　　　　※分表规则：例如轮动策略就是某些股票会在一个策略中同时出现，因此可以放入一张表中

 

　　4，读写数据量都大的数据表方案

•  在大型的应用中必然存在每日更新频繁和查询频繁的数据表
  • mysql的解决方案：

　　　　　　方法：进行分库分表，加读写分离

　　　　　　好处：可根据自身的数据使用情况来定义中间件来控制资源访问，从而实现资源的最大化利用

　　　　　　缺点：此方案建立于开发者对现有业务和数据使用非常了解的情况下，另外如果日后业务发生变化，变更成本较大(表结构，数据迁移，中间件变更)

• • ES+mongo解决方案：

　　　　　　方法：使用mongo自带的分片功能，且只建立主键索引_id优化写性能；通过ES查询得到_id后再查询数据

　　　　　　好处：对于日后业务的拓展变更成本低(非结构化数据)；ES对海量数据查询效率高

　　　　　　缺点：额外的存储，ES索引字段变更