以用户中心为例:User(uid,login_name,passwd,nick_name,age,sex,email,phone,...)
一、问题:
1、如何实施水平切分
2、切分后常见的问题
3、常见的优化思路
二、常见切分算法
1、范围法
优点:
1)切分策略简单,根据uid,按照范围就可以定位到数据库
2)扩容简单,如果容量不够,只需要增加数据库即可
缺点:
1)uid 必须满足递增的属性
2)数据量不均匀,某一段时间内,数据都在一个库上
3)请求量不均匀,一般来说新生成的数据活跃度高,导致服务器利用率不均衡
2、哈希法
优点:
1)切分策略简单
2)数据量均匀
3)请求量均匀
缺点:
1)扩容麻烦,如果容量不够,重新哈希可能会导致数据迁移
三、切分后出现的问题
根据非uid属性上的查询,如何解决。例如login_name,phone等
四、非uid属性上查询业务分析
一般有两类业务需求
1、用户侧,用户访问
用户登录:根据login_name/email/phone查询 用户的实体,1%的需求
用户信息查询:根据uid查询用户实体,99%的需求
用户侧的查询基本是单条查询,访问量较大,服务要求高可用,并且对一致性要求较高
2、运营侧,后台访问
将login_name/email/phone作为查询条件,分页统计,由于是内部系统,访问量低,
对可用性要求不高,一致性也要求不高
五、问题解决的架构思想
针对用户侧:应该采用“建立非uid属性到uid的映射关联”
针对运营侧:应该采用“前台和后台分离”
六、用户侧最佳实践
1、“索引表法”
建立索引表记录 login_name->uid的映射关系,先根据login_name查询到uid,然后根据
uid路由到库,索引表属性较少,一般不需要分库,但是如果数据量很大,也可以login_name
分库。潜在不足,多一次数据库查询,性能下降一倍
2、“缓存关联法”
访问索引表性能较低,可以把映射关系放到缓存中性能更佳
七、运营侧的最佳实践
前台,后台系统web、service、db分离解耦,避免后台低效查询导致前台抖动
可以采用 数据冗余设计方式
可以采用“外置索引”(例如SE搜索系统)或者“大数据处理”(例如hive)来满足后台变态的查询