[MySQL] 分库分表需要考虑的问题
随着业务的增长,一般的公司都会经历一个从单库单表到分库分表的过程 , 需要考虑以下要素判断是否开始分库分表
1. 如果mysql单库的QPS超过1000就要考虑分库了 , 一般根据业务进行分库
目前新浪邮箱的主库是sinanet 各种辅助库 userservice客服系统 sinastore 文件存储库 entsales 销售系统库
2. 单表的数据量非常大时 , 需要考虑分表 , 超过1000万就要考虑了 , 因为此时b+树索引的高度是3-5左右
如果有单字段特别大 , 就要把该字段独立出来 ,这就是垂直分表 , 遵循冷热拆分 , 大小拆分
这里基本在设计的时候就已经考虑好了 , 一般不会出现这种情况
如果是数据量特别大 , 就要结合业务需求和产品特性 , 选择合适的拆分算法
如何切分?
a:哈希取模算法 hash(id)/NUM,
本表的id是数据库auto_incr id,hash拆分后数据分散是特别均匀的,但是后面的NUM设置没有经验值,只能依靠人工来计算; max_row/day_incr= year ,保证能扛住近四年的数据增量。
考虑到后续扩展表的数据时,数据迁移会比较难做。
新浪邮箱的用户表是根据默认域邮箱hash取模进行的拆分
b:一致性hash算法
为了保证后续迁移数据影响面较小,建议使用一致性hash算法。
新浪邮箱的订单表是根据一致性hash算法根据 , 不同值的范围大小选择存储表节点
c:range(timestamp)
具有天然的时间字段,非常好拆分,具有很好的扩展性。
目前查询都是带时间戳的,所以会出现表的访问冷热不均。但同时也避免了跨节点join等问题
新浪邮箱用户的日志表是根据月份加哈希拆分了 1024张表
如何迁移数据?
这是不可避免的问题,可以采用了实时数据双写,历史数据采用脚本导入的方式,在线上数据对齐后,慢慢将流量灌到新的db上。
相关文章
- 优化杭州某著名电子商务网站高并发千万级大型数据库经验之- 磁盘I/O性能
- 参与投标某单位软件项目经历分享(软件招标:浙江杭州、项目金额:40-50万)
- 给浙江杭州某猎头公司开发猎头行业软件.NET接口的经验小结分享
- 网站同样是1000次访问程序测试,但是分100个线程、每个线程100次循环来测试程序的大并发压力会更靠谱
- C#.NET 权限管理系统组件 - 大数据读写分离实现的例子
- C#.NET 权限管理系统组件 - 大数据只获取更新部分数据列的标准例子
- ASP.NET权限组件,生成10万条测试数据检测程序的大数据性能改进
- C# ASP.NET 通用权限管理系统组件的数据访问层的调用方法参考2 - 多种类型的多数据库连接方法
- C# ASP.NET 通用权限管理系统组件的数据访问层的调用方法参考1 - 基本功能
- 【转载★架构】百万级访问量网站的技术准备工作
- 软件合作开发:2012年年底给苏州工业园区某家软件企业实施C#.NET软件开发系统框架的经验小结
- C# CharacterToBinary 将类似2进制字符串 10010110111 转换为数值型源码
- C#.NET 通用权限管理系统组件 大数据多表分页获取部分列的参考方法
- ASP.NET 实现轻量级的工作流[审批流程]
- 大公司业务流程审批组件【部门的员工—部门经理—部门副总—人力经理—人力副总】实现参考,强大的基础数据管理工具-C#.NET通用权限管理系统组件
- 节假日批量设置的C#.NET程序代码参考
- 多个业务子系统的集中统一管理用户权限,SQL脚本批量事务运行的参考代码
- 在c#.net通用权限管理系统组件里的 部门经理,分管副总 的管理方法参考
- 现在物价虽然高得离谱,但是内存条都白菜价格了,需要调整程序架构的思维“与时俱进” --- 改进系列之二
- 分享从带头拼死拼活开发软件项目到不去现场异地坐镇远程遥控照样可以把上海的软件项目管理好