数据库水平切分
范围法
优点
根据uid,1000万存db1,1000-2000万存db2,切分策略简单、扩容简单
缺点
uid必须自增
数据量不均,如新增db3 初期数据特别少
请求量不均,可能存在活跃用户都在某一台db上
哈希法
优点
切分策略简单,根据uid,按照hash很快定位到哪个库上
数据量均衡,uid是随机的
请求量均衡,uid是随机的
使用分布式id生成器,id一定是随机的
缺点
扩容麻烦,增加一个库,会导致重新hash
双倍扩容策略
采用双倍扩容策略,避免数据迁移。扩容前每个节点的数据,有一半要迁移至一个新增节点中,对应关系比较简单。
具体操作如下(假设已有 2 个节点 A/B,要双倍扩容至 A/A2/B/B2 这 4 个节点):
-
无需停止应用服务器;
-
新增两个数据库 A2/B2 作为从库,设置主从同步关系为:A=>A2、B=>B2,直至主从数据同步完毕(早期数据可手工同步);
-
调整分片规则并使之生效:
原 ID%2=0 => A 改为 ID%4=0 => A, ID%4=2 => A2;
原 ID%2=1 => B 改为 ID%4=1 => B, ID%4=3 => B2。
-
解除数据库实例的主从同步关系,并使之生效;
-
此时,四个节点的数据都已完整,只是有冗余(多存了和自己配对的节点的那部分数据),择机清除即可(过后随时进行,不影响业务)。
基础补充-垂直分库分表
垂直分库:过将表按业务分类,然后分布在不同数据库,并且可以将这些数据库部署在不同服务器上,从而达到多个服务器共同分摊压力的效果,但是依然没有解决单表数据量过大的问题
垂直分表:如商品信息,将访问频次较高的属性存到一张表中,将访问频次较低且内容多的存在另一张表中;
水平分库:垂直分库后,某个业务类别也无法再进行垂直拆分,则进行水平拆分,按照uid规则分到不同的库
水平分表:将同一数据结构的信息,根据算法,拆分不同的表
垂直:拆分不同业务(独立库-分库),拆分不同功能(独立表-分表)
水平:拆分同一业务(独立库-分库),拆分同一功能(独立表-分表)
用户中心,非id属性查询
用户端
单条查询,高可用,高性能
建立索引表
通过索引表 映射非id属性 与id之间的关系,在定位所在库
基因法
通过非id属性 通过算法 生成为一的id,这样非id属性和id就有关系了,但在入库前,又如何验证非id是否重复呢?
运营端
批量,复杂查询
冗余数据库或通过hive等大数据处理来满足需求