场景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索引字段变动