数据库架构(转)
1. 业界难题-“跨库分页”的四种方案
1). 方法一:全局视野法
a.将order by time offset X limit Y,改写成order by time offset 0 limit X+Y
b.服务层对得到的N*(X+Y)条数据进行内存排序,内存排序后再取偏移量X后的Y条记录
这种方法随着翻页的进行,性能越来越低。
2). 方法二:业务折衷法-禁止跳页查询
a. 用正常的方法取得第一页数据,并得到第一页记录的time_max
b. 每次翻页,将order by time offset X limit Y,改写成order by time where time>$time_max limit Y
以保证每次只返回一页数据,性能为常量。
3). 方法三:业务折衷法-允许模糊数据(多个数据库平均查出数据,损失一定的精度)
a. 将order by time offset X limit Y,改写成order by time offset X/N limit Y/N
4). 方法四:二次查询法
a. 将order by time offset X limit Y,改写成order by time offset X/N limit Y
b. 找到最小值time_min
c. between二次查询,order by time between $time_min and $time_i_max
d.设置虚拟time_min,找到time_min在各个分库的offset,从而得到time_min在全局的offset
e. 得到了time_min在全局的offset,自然得到了全局的offset X limit Y
2. 单KEY业务,数据库水平切分架构实践
1).水平切分方法
a.范围法,以用户中心的业务主键uid为划分依据,将数据水平切分到两个数据库实例上去:
user-db1:存储0到1千万的uid数据
user-db2:存储1到2千万的uid数据
a).范围法的优点是:切分策略简单,根据uid,按照范围,user- center很快能够定位到数据在哪个库上 ; 扩容简单,如果容量不够,只要增加user-db3即可
b).范围法的不足是:
uid必须要满足递增的特性
数据量不均,新增的user-db3,在初期的数据会比较少
请求量不均,一般来说,新注册的用户活跃度会比较高,故user-db2往往会比user-db1负载要高,导致服务器利用率不平衡
b.哈希法,也是以用户中心的业务主键uid为划分依据,将数据水平切分到两个数据库实例上去:
user-db1:存储uid取模得1的uid数据
user-db2:存储uid取模得0的uid数据
a).哈希法的优点是:切分策略简单,根据uid,按照hash,user-center很快能够定位到数据在哪个库上
数据量均衡,只要uid是均匀的,数据在各个库上的分布一定是均衡的
请求量均衡,只要uid是均匀的,负载在各个库上的分布一定是均衡的
b).哈希法的不足是:扩容麻烦,如果容量不够,要增加一个库,重新hash可能会导致数据迁移,如何平滑的进行数据迁移,是一个需要解决的问题
2).用户中心水平切分后带来的问题:
对于uid属性上的查询可以直接路由到库,假设访问uid=124的数据,取模后能够直接定位db-user1:对于非uid属性上的查询,例如login_name属性上的查询,就悲剧了:
假设访问login_name=shenjian的数据,由于不知道数据落在哪个库上,往往需要遍历所有库,当分库数量多起来,性能会显著降低。
3).根据楼主这些年的架构经验,用户中心非uid属性上经常有两类业务需求:
a.用户侧,前台访问,最典型的有两类需求
用户登录:通过login_name/phone/email查询用户的实体,1%请求属于这种类型
用户信息查询:登录之后,通过uid来查询用户的实例,99%请求属这种类型
用户侧的查询基本上是单条记录的查询,访问量较大,服务需要高可用,并且对一致性的要求较高。
b.运营侧,后台访问,根据产品、运营需求,访问模式各异,按照年龄、性别、头像、登陆时间、注册时间来进行查询。
运营侧的查询基本上是批量分页的查询,由于是内部系统,访问量很低,对可用性的要求不高,对一致性的要求也没这么严格。
这两类不同的业务需求,应该使用什么样的架构方案来解决呢?
4).用户中心水平切分架构思路
用户中心在数据量较大的情况下,使用uid进行水平切分,对于非uid属性上的查询需求,架构设计的核心思路为:
针对用户侧,应该采用“建立非uid属性到uid的映射关系”的架构方案
针对运营侧,应该采用“前台与后台分离”的架构方案
5).用户中心-用户侧最佳实践
a.索引表法
思路:uid能直接定位到库,login_name不能直接定位到库,如果通过login_name能查询到uid,问题解决
解决方案:
建立一个索引表记录login_name->uid的映射关系
用login_name来访问时,先通过索引表查询到uid,再定位相应的库
索引表属性较少,可以容纳非常多数据,一般不需要分库
如果数据量过大,可以通过login_name来分库
潜在不足:多一次数据库查询,性能下降一倍
b.缓存映射法:
思路:访问索引表性能较低,把映射关系放在缓存里性能更佳
解决方案:
login_name查询先到cache中查询uid,再根据uid定位数据库
假设cache miss,采用扫全库法获取login_name对应的uid,放入cache
login_name到uid的映射关系不会变化,映射关系一旦放入缓存,不会更改,无需淘汰,缓存命中率超高
如果数据量过大,可以通过login_name进行cache水平切分
潜在不足:多一次cache查询
c.login_name生成uid:
思路:不进行远程查询,由login_name直接得到uid
解决方案:
在用户注册时,设计函数login_name生成uid,uid=f(login_name),按uid分库插入数据
用login_name来访问时,先通过函数计算出uid,即uid=f(login_name)再来一遍,由uid路由到对应库
潜在不足:该函数设计需要非常讲究技巧,有uid生成冲突风险
d.login_name基因融入uid
思路:不能用login_name生成uid,可以从login_name抽取“基因”,融入uid中。假设分8库,采用uid%8路由,潜台词是,uid的最后3个bit决定这条数据落在哪个库上,这3个bit就是所谓的“基因”。
解决方案:在用户注册时,设计函数login_name生成3bit基因,login_name_gene=f(login_name),如上图粉色部分
同时,生成61bit的全局唯一id,作为用户的标识,如上图绿色部分
接着把3bit的login_name_gene也作为uid的一部分,如上图屎黄色部分
生成64bit的uid,由id和login_name_gene拼装而成,并按照uid分库插入数据
用login_name来访问时,先通过函数由login_name再次复原3bit基因,login_name_gene=f(login_name),通过login_name_gene%8直接定位到库
e.用户中心-运营侧最佳实践
前台用户侧,业务需求基本都是单行记录的访问,只要建立非uid属性 login_name / phone / email 到uid的映射关系,就能解决问题。
后台运营侧,业务需求各异,基本是批量分页的访问,这类访问计算量较大,返回数据量较大,比较消耗数据库性能。
如果此时前台业务和后台业务公用一批服务和一个数据库,有可能导致,由于后台的“少数几个请求”的“批量查询”的“低效”访问,导致数据库的cpu偶尔瞬时100%,影响前台正常用户的访问(例如,登录超时)。
而且,为了满足后台业务各类“奇形怪状”的需求,往往会在数据库上建立各种索引,这些索引占用大量内存,会使得用户侧前台业务uid/login_name上的查询性能与写入性能大幅度降低,处理时间增长。
对于这一类业务,应该采用“前台与后台分离”的架构方案:
户侧前台业务需求架构依然不变,产品运营侧后台业务需求则抽取独立的web / service / db 来支持,解除系统之间的耦合,对于“业务复杂”“并发量低”“无需高可用”“能接受一定延时”的后台业务:
可以去掉service层,在运营后台web层通过dao直接访问db
不需要反向代理,不需要集群冗余
不需要访问实时库,可以通过MQ或者线下异步同步数据
在数据库非常大的情况下,可以使用更契合大量数据允许接受更高延时的“索引外置”或者“HIVE”的设计方案
f.总结
将以“用户中心”为典型的“单KEY”类业务,水平切分的架构点,本文做了这样一些介绍。
水平切分方式:范围法;哈希法
水平切分后碰到的问题:通过uid属性查询能直接定位到库,通过非uid属性查询不能定位到库
非uid属性查询的典型业务:用户侧,前台访问,单条记录的查询,访问量较大,服务需要高可用,并且对一致性的要求较高;运营侧,后台访问,根据产品、运营需求,访问模式各异,基本上是批量分页的查询,由于是内部系统,访问量很低,对可用性的要求不高,对一致性的要求也没这么严格
这两类业务的架构设计思路:
针对用户侧,应该采用“建立非uid属性到uid的映射关系”的架构方案
针对运营侧,应该采用“前台与后台分离”的架构方案
用户前台侧,“建立非uid属性到uid的映射关系”最佳实践:
索引表法:数据库中记录login_name->uid的映射关系
缓存映射法:缓存中记录login_name->uid的映射关系
login_name生成uid
login_name基因融入uid
运营后台侧,“前台与后台分离”最佳实践:
前台、后台系统web/service/db分离解耦,避免后台低效查询引发前台查询抖动
可以采用数据冗余的设计方式
可以采用“外置索引”(例如ES搜索系统)或者“大数据处理”(例如HIVE)来满足后台变态的查询需求
3. 100亿数据1万属性数据架构设计
1). 什么是数据库扩展的version + ext方案?
使用ext来承载不同业务需求的个性化属性,使用version来标识ext里各个字段的含义。
优点:a.可以随时动态扩展属性,扩展性好 ;b.新旧两种数据可以同时存在,兼容性好
不足:a.ext里的字段无法建立索引 ; b.ext里的key值有大量冗余,建议key短一些
2). 如何将不同品类,异构的数据统一存储起来,采用的就是类似version+ext的方式:
tiezi(tid,uid, time, title, cate, subcate, xxid, ext)
a.一些通用的字段抽取出来单独存储
b.通过cate, subcate, xxid等来定义ext是何种含义(和version有点像?)
c.通过ext来存储不同业务线的个性化需求
3). 解决了海量异构数据的存储问题,遇到的新问题是:
a.每条记录ext内key都需要重复存储,占据了大量的空间,能否压缩存储
b.cateid已经不足以描述ext内的内容,品类有层级,深度不确定,ext能否具备自描述性
c.随时可以增加属性,保证扩展性
4).统一类目属性服务
抽象出一个统一的类目、属性服务,单独来管理这些信息,而帖子库ext字段里json的key,统一由数字来表示,减少存储空间。
数字是什么含义,属于哪个子分类,值的校验约束,统一都存储在类目、属性服务里。
除此之外,如果ext里某个key的value不是正则校验的值,而是枚举值时,需要有一个对值进行限定的枚举表来进行校验
5). 统一检索服务
数据量很大的时候,不同属性上的查询需求,不可能通过组合索引来满足所有查询需求,怎么办呢?
58同城的先贤们,从一早就确定了“外置索引,统一检索服务”的技术路线:
a.数据库提供“帖子id”的正排查询需求
b.所有非“帖子id”的个性化检索需求,统一走外置索引
6).元数据与索引数据的操作遵循:
a.对帖子进行tid正排查询,直接访问帖子服务
b.对帖子进行修改,帖子服务通知检索服务,同时对索引进行修改
c.对帖子进行复杂查询,通过检索服务满足需求
4.数据库秒级平滑扩容架构方案
1).部署方案:
a.并发量大,流量大的互联网架构,一般来说,数据库上层都有一个服务层,服务层记录了“业务库名”与“数据库实例”的映射关系,通过数据库连接池向数据库路由sql语句以执行
b.随着数据量的增大,数据要进行水平切分,分库后将数据分布到不同的数据库实例(甚至物理机器)上,以达到降低数据量,增强性能的扩容目的
c.互联网架构需要保证数据库高可用,常见的一种方式,使用双主同步+keepalived+虚ip的方式保证数据库的可用性
d.综合上文的(2)和(3),线上实际的架构,既有水平切分,又有高可用保证
提问:如果数据量持续增大,分2个库性能扛不住了,该怎么办呢?
回答:继续水平拆分,拆成更多的库,降低单库数据量,增加库主库实例(机器)数量,提高性能。
2).停服务方案:暂停所有服务,迁移数据。
回滚方案:如果数据迁移失败,或者迁移后测试失败,则将配置改回x库,恢复服务,改天再挂公告。
方案优点:简单
方案缺点:a.停服务,不高可用;
b.技术同学压力大,所有工作要在规定时间内做完,根据经验,压力越大约容易出错(这一点很致命)
c.如果有问题第一时间没检查出来,启动了服务,运行一段时间后再发现有问题,难以回滚,需要回档,可能会丢失一部分数据
3).秒级、平滑、帅气方案
a.修改配置
主要修改两处:
a).数据库实例所在的机器做双虚ip,原来%2=0的库是虚ip0,现在增加一个虚ip00,%2=1的另一个库同理
b).修改服务的配置(不管是在配置文件里,还是在配置中心),将2个库的数据库配置,改为4个库的数据库配置,修改的时候要注意旧库与辛苦的映射关系:
%2=0的库,会变为%4=0与%4=2;
%2=1的部分,会变为%4=1与%4=3;
这样修改是为了保证,拆分后依然能够路由到正确的数据。
b.reload配置,实例扩容
服务层reload配置,reload可能是这么几种方式:
a).比较原始的,重启服务,读新的配置文件
b).高级一点的,配置中心给服务发信号,重读配置文件,重新初始化数据库连接池
不管哪种方式,reload之后,数据库的实例扩容就完成了,原来是2个数据库实例提供服务,现在变为4个数据库实例提供服务,这个过程一般可以在秒级完成。
整个过程可以逐步重启,对服务的正确性和可用性完全没有影响:
a).即使%2寻库和%4寻库同时存在,也不影响数据的正确性,因为此时仍然是双主数据同步的
b).服务reload之前是不对外提供服务的,冗余的服务能够保证高可用
完成了实例的扩展,会发现每个数据库的数据量依然没有下降,所以第三个步骤还要做一些收尾工作
c.收尾工作,数据收缩:
有这些一些收尾工作:
a).把双虚ip修改回单虚ip
b).解除旧的双主同步,让成对库的数据不再同步增加
c).增加新的双主同步,保证高可用
d).删除掉冗余数据,例如:ip0里%4=2的数据全部干掉,只为%4=0的数据提供服务啦
这样下来,每个库的数据量就降为原来的一半,数据收缩完成。
5. 100亿数据平滑数据迁移,不影响服务
针对互联网很多“数据量较大,并发量较大,业务复杂度较高”的业务场景,在
a.底层表结构变更
b.分库个数变换
c.底层存储介质变换
的众多需求下,需要进行数据迁移,完成“平滑迁移数据,迁移过程不停机,保证系统持续服务”有两种常见的解决方案。
1).追日志法,五个步骤:
a.服务进行升级,记录“对旧库上的数据修改”的日志
b.研发一个数据迁移小工具,进行数据迁移
c.研发一个读取日志小工具,追平数据差异
d.研发一个数据比对小工具,校验数据一致性
e.流量切到新库,完成平滑迁移
2).双写法,四个步骤:
a.服务进行升级,记录“对旧库上的数据修改”进行新库的双写
b.研发一个数据迁移小工具,进行数据迁移
c.研发一个数据比对小工具,校验数据一致性
d.流量切到新库,完成平滑迁移
6. MySQL冗余数据的三种方案
1).为什么要冗余数据
例如:订单业务,对用户和商家都有订单查询需求:
Order(oid, info_detail);
T(buyer_id, seller_id, oid);
如果用buyer_id来分库,seller_id的查询就需要扫描多库。
如果用seller_id来分库,buyer_id的查询就需要扫描多库。
此时可以使用数据冗余来分别满足buyer_id和seller_id上的查询需求:
T1(buyer_id, seller_id, oid)
T2(seller_id, buyer_id, oid)
同一个数据,冗余两份,一份以buyer_id来分库,满足买家的查询需求;一份以seller_id来分库,满足卖家的查询需求。
2).服务同步双写
顾名思义,由服务层同步写冗余数据,如上图1-4流程:
业务方调用服务,新增数据
服务先插入T1数据
服务再插入T2数据
服务返回业务方新增数据成功
优点:
不复杂,服务层由单次写,变两次写
数据一致性相对较高(因为双写成功才返回)
缺点:
请求的处理时间增加(要插入两次,时间加倍)
数据仍可能不一致,例如第二步写入T1完成后服务重启,则数据不会写入T2
3).服务异步双写
数据的双写并不再由服务来完成,服务层异步发出一个消息,通过消息总线发送给一个专门的数据复制服务来写入冗余数据,如上图1-6流程:
业务方调用服务,新增数据
服务先插入T1数据
服务向消息总线发送一个异步消息(发出即可,不用等返回,通常很快就能完成)
服务返回业务方新增数据成功
消息总线将消息投递给数据同步中心
数据同步中心插入T2数据
优点:请求处理时间短(只插入1次)
缺点:系统的复杂性增加了,多引入了一个组件(消息总线)和一个服务(专用的数据复制服务)
因为返回业务线数据插入成功时,数据还不一定插入到T2中,因此数据有一个不一致时间窗口(这个窗口很短,最终是一致的)
在消息总线丢失消息时,冗余表数据会不一致
不管是服务同步双写,还是服务异步双写,服务都需要关注“冗余数据”带来的复杂性。如果想解除“数据冗余”对系统的耦合,引出常用的第三种方案。
如果系统对处理时间比较敏感,引出常用的第二种方案。
4).线下异步双写:
为了屏蔽“冗余数据”对服务带来的复杂性,数据的双写不再由服务层来完成,而是由线下的一个服务或者任务来完成,如上图1-6流程:
业务方调用服务,新增数据
服务先插入T1数据
服务返回业务方新增数据成功
数据会被写入到数据库的log中
线下服务或者任务读取数据库的log
线下服务或者任务插入T2数据
优点:数据双写与业务完全解耦; 请求处理时间短(只插入1次)
缺点:返回业务线数据插入成功时,数据还不一定插入到T2中,因此数据有一个不一致时间窗口(这个窗口很短,最终是一致的)
数据的一致性依赖于线下服务或者任务的可靠性
5).总结:
互联网数据量大的业务场景,常常:
使用水平切分来降低单库数据量
使用数据冗余的反范式设计来满足不同维度的查询需求
使用服务同步双写法能够很容易的实现数据冗余
为了降低时延,可以优化为服务异步双写法
为了屏蔽“冗余数据”对服务带来的复杂性,可以优化为线下异步双写法
内容转自微信公众号:架构师之路