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