标签：好的 出现 用户表 amp 影响 单表 日志 迁移 对齐
随着业务的增长，一般的公司都会经历一个从单库单表到分库分表的过程 , 需要考虑以下要素判断是否开始分库分表
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上。
标签：好的 出现 用户表 amp 影响 单表 日志 迁移 对齐
原文地址：https://www.cnblogs.com/taoshihan/p/14116232.html
