1,项目分库分表实现-股票数据预期增长分析

1、股票数据预期增长分析

由于今日指数是偏向海量数据分析的产品，而股票的数据会随着时间的积累越来越多，这会严重影响查询性能，所以合理的分库分表规划就迫在眉睫了。

接下来我们分析下股票数据的预期增长情况：

表名	时间周期	累计数量	分库分表策略
股票流水表-stock_rt_info	月	1(钟)x60（时）x4（天）x21(月)x1500（重点股票）约等于：750W+	按年分库，按月分表
股票主营业务表-stock_business		3000+	公共表|广播表	数据量少 数据变化频率低 各个数据库都会用到
国内大盘流水表-stock_market_index_info	年	1x60x4x21x12x10约等于：60W+	按年分库不分表	方便数据按年维护
外盘流水表-stock_outer_market_index_info	年	1x60x4x21x12x10约等于：60W+	按年分库不分表	方便数据按年维护
股票板块-stock_block_rt_into	年	1x60x4x21x12x60约等于：360w+	按年分库不分表	方便数据按年维护
系统表 -sys_log、sys_user、sys_role等		数据量少	单库默认数据源

说明：

在数据库运维中，一般将不常用的历史数据会导出到指定格式的文件中，然后压缩保存处理； 当前项目中的股票数据，同样与时间成正相关。股票数据经过一定的周期后，对于不怎么被使用的数据，一般会导出归档处理；

所以，对于股票相关的流水数据按年分库后，对后续数据库的线性扩容和数据的归档维护都带来极大的便利；

思考：当前我们选择使用cur_time日期字段作为分库分表的片键比较合适，那如果使用主键字段作为分片，会存在哪些问题呢？

• 数据库扩容时各节点存储均衡问题

  • 股票数据的持续流入会导致前期分库的各个节点不堪重负，最终势必要进行节点扩容，而新加入的节点和旧的节点之间数据不平衡，需要重新规划，这会导致数据迁移的成本过高；

• 股票查询条件问题

  • 股票数据多以日期作为条件查询，如果基于主键ID作为分片键，则会导致分库的全节点查询，性能开销加大；

2、股票数据库表拆分规划

2.1 数据分库分表规划

基于上一小节的分析，我们得出一些结论：

• 对于股票流水表按照月维度和年维护进行库表拆分，也就是说一年会产生一个库用于后期数据归档，而每个库下则按照月份产生12张表，对应一年的数据；

• 对于板块表和大盘数据表，我们则以年为单位，与股票流水表年份一致即可，也就是按照年分库分表；

• 对于主营业务表，因为数据量较少，且查询都会用到，作为公共表处理；

• 对于系统表数据量相对较少，作为默认数据源即可；

整体架构如下：

数据详见：讲义\v-2\资料\今日指数分库分表SQL脚本

综上，我们以日期时间字段cur_time作为库表的分偏键，分库分表的逻辑存在一定的复杂性，采用标准分片策略比较合适。