1.场景一:
建立一个历史his系统,将公司的一些历史个人游戏数据保存到这个his系统中,主要是写入,还有部分查询,读写比约为1:4;
由于是所有数据的历史存取,所以并发要求比较高;
分析:
- 历史数据
- 写多读少
- 越近日期查询越频繁?
- 什么业务数据?用户游戏数据
- 有没有大规模分析查询?
- 数据量多大?
- 保留多久?
- 机器资源有多少?
方案1:按照日期每月一个分片
带来的问题:1.数据热点问题(压力不均匀)
方案2:按照用户取模,
带来的问题:后续扩容困难(某个分片上的用户特别活跃,那个分片压力就大。用户的数量是会增长的,扩容是数据迁移麻烦)
方案3:按用户ID范围分片(1-1000万=分片1,xxx)
带来的问题:用户活跃度无法掌握,可能存在热点问题
1.场景二:
建立一个商城订单系统,保存用户订单信息。
分析:
- 电商系统
- 一号店或京东类?淘宝或天猫?
- 实时性要求高
- 存在瞬时压力
- 基本不存在大规模分析
- 数据规模?
- 机器资源有多少?
- 维度?商品?用户?商户?
方案1:按照用户取模,
带来的问题:后续扩容困难
方案2:按用户ID范围分片(1-1000万=分片1,xxx)
带来的问题:用户活跃度无法掌握,可能存在热点问题
方案3:按省份地区或者商户取模
数据分配不一定均匀
1.场景3:
上海公积金,养老金,社保系统
分析:
- 社保系统
- 实时性要求不高
- 不存在瞬时压力
- 大规模分析?
- 数据规模大
- 数据重要不可丢失
- 偏于查询?
方案1:按照用户取模,
带来的问题:后续扩容困难
方案2:按用户ID范围分片(1-1000万=分片1,xxx)
带来的问题:用户活跃度无法掌握,可能存在热点问题
方案3:按省份区县地区枚举
数据分配不一定均匀