数据库架构(转)

Posted 酒醉三分醒

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了数据库架构(转)相关的知识,希望对你有一定的参考价值。

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).总结:

        互联网数据量大的业务场景,常常:

        使用水平切分来降低单库数据量

        使用数据冗余的反范式设计来满足不同维度的查询需求

       使用服务同步双写法能够很容易的实现数据冗余

       为了降低时延,可以优化为服务异步双写法

       为了屏蔽“冗余数据”对服务带来的复杂性,可以优化为线下异步双写法

 

内容转自微信公众号:架构师之路

以上是关于数据库架构(转)的主要内容,如果未能解决你的问题,请参考以下文章

转:每个架构师都应该研究下康威定律

分布式架构的演进(转)

[转]SOA架构设计经验分享—架构职责数据一致性

高性能网站架构的思考 (转)

浅谈数据仓库的基本架构(转)

数据库架构(转)