码迷,mamicode.com
首页 > 其他好文 > 详细

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

时间:2018-01-28 16:31:43      阅读:305      评论:0      收藏:0      [点我收藏+]

标签:回测   class   写入   迁移   查看   策略   成本   控制   文件中   

 
场景20亿分钟K线数据的更新及查找
 
1,了解数据使用情况
 
  这些k线数据用于回测,而对于分钟k线回测:
  • 大部分回测周期在近几个月或近几年
  • 热门股票几多沪深300、上证50等
  • 分钟回测需要一定的实时性既在开盘时间进行回测,需要最近的数据
  • 数据增量每日几百MB
  ※初始热数据的划分需要对业务进行深入了解
  ※后续热数据的精确划分还是要查看历史查询的记录
  统计来源:程序中添加的数据操作log;数据库审计;数据库中间件
 
2,根据数据使用频率进行拆分
 
  我将数据划分4个层级:
  1,热数据:热门股票的近N个月的数据及最近数据
  2,较热数据近3年K线数据
  3,使用频率较低的K线数据(06-08 14-15 遇到大行情时期)
  4,几乎没人使用的数据(06年以前)
 
  ※根据热度使用3种不同的存储方式(时间段划分):
  • 热度数据-redis;
  • 较热数据-mysql or mongo;
  • 频率低及冷数据-bcolz文件(频率低的单独建立文件)
  每日夜间进行更新:将过时的部分热数据从redis中写入数据库
  每周进行更新:将数据库过时的数据存入bcolz文件中(bcolz有非常不错的压缩率和速度)
  ※建议程序中单独书写一个数据中间件,以便后续架构演化时独立更改
 
 
3,数据库架构演变
 
  1,针对于量化回测,主要的瓶颈在于读数据(每日读的数据远远大于写的数据)
 
  2,对于系统日后增长的使用量,我们将划分的数据分配独立的服务器
    ※redis集群,数据库集群,文件服务器
    以上都是用中间件进行访问控制
 
  3,数据库的读瓶颈的演变
    • 数据库瓶颈:一张表存海量数据(解决办法:分表)
    • 服务器瓶颈:查询需求大于磁盘的io性能或负载能力(解决办法:分库)
    ※综上所述我们将数据库中的热门股票平均划分到N个库中,并再进行分表
    ※分表规则:例如轮动策略就是某些股票会在一个策略中同时出现,因此可以放入一张表中
 
  4,读写数据量都大的数据表方案
  •  在大型的应用中必然存在每日更新频繁和查询频繁的数据表
    • mysql的解决方案:
      方法:进行分库分表,加读写分离
      好处:可根据自身的数据使用情况来定义中间件来控制资源访问,从而实现资源的最大化利用
      缺点:此方案建立于开发者对现有业务和数据使用非常了解的情况下,另外如果日后业务发生变化,变更成本较大(表结构,数据迁移,中间件变更)
    • ES+mongo解决方案:
      方法:使用mongo自带的分片功能,且只建立主键索引_id优化写性能;通过ES查询得到_id后再查询数据
      好处:对于日后业务的拓展变更成本低(非结构化数据);ES对海量数据查询效率高
      缺点:额外的存储,ES索引字段变更

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

标签:回测   class   写入   迁移   查看   策略   成本   控制   文件中   

原文地址:https://www.cnblogs.com/dxf813/p/8365995.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!