[架构师之路] 数据库拆分 系列（上）

一分钟掌握数据库垂直拆分

http://chuansong.me/n/1363948946536

一、缘起

当数据库的数据量非常大时， 水平切分和垂直拆分是两种常见的降低数据库大小，提升性能的方法。假设有用户表：

user(     uid bigint,     name varchar(16),     pass varchar(16),     age int,     sex tinyint,     flag tinyint,     sign varchar(64),     intro varchar(256) …);

     水平切分是指，以 某个字段为依据 （例如uid），按照一定规则（例如取模），将一个库（表）上的数据拆分到多个库（表）上，以降低单库（表）大小，达到提升性能的目的的方法，水平切分后，各个库（表）的特点是：

    1）每个库（表）的 结构都一样

    2）每个库（表）的 数据都不一样，没有交集

    3）所有库（表）的 并集是全量数据

二、什么是垂直拆分

    垂直拆分是指， 将一个属性较多，一行数据较大的表，将不同的属性拆分到不同的表中，以降低单库（表）大小，达到提升性能的目的的方法，垂直切分后，各个库（表）的特点是：

    1）每个库（表）的 结构都不一样

    2）一般来说，每个库（表）的 属性至少有一列交集，一般是主键

    3）所有库（表）的 并集是全量数据

还是以上文提到的用户表为例，如果要垂直拆分，可能拆分结果会是这样的：

user_base(     uid bigint,     name varchar(16),     pass varchar(16),     age int,     sex tinyint,     flag tinyint, …);

user_ext(     uid bigint,     sign varchar(64),     intro varchar(256) …);

三、垂直切分的依据是什么

    当一个表属性很多时，如何来进行垂直拆分呢？如果没有特殊情况，拆分依据主要有几点：

        1） 将长度较短，访问频率较高的属性尽量放在一个表里，这个表暂且称为主表

        2） 将字段较长，访问频率较低的属性尽量放在一个表里，这个表暂且称为扩展表

    如果1和2都满足，还可以考虑第三点：

        3） 经常一起访问的属性，也可以放在一个表里

    优先考虑1和2，第3点不是必须。 另如果实在属性过多，主表和扩展表都可以有多个。

    一般来说，数据量并发量比较大时，数据库的上层都会有一个服务层。 需要注意的是，当应用方需要同时访问主表和扩展表中的属性时，服务层不要使用join来连表访问，而应该分两次进行查询：

    原因是，大数据高并发互联网场景下，一般来说，吞吐量和扩展性是主要矛盾：

        1）join更消损耗数据库性能

        2） join会让base表和ext表耦合在一起（必须在一个数据库实例上），不利于数据量大时拆分到不同的数据库实例上（机器上）。毕竟减少数据量，提升性能才是垂直拆分的初衷。

四、为什么要这么这么拆分

    为何要将字段短，访问频率高的属性放到一个表内？为何这么垂直拆分可以提升性能？因为：

        1） 数据库有自己的内存buffer，会将磁盘上的数据load到内存buffer里（暂且理解为进程内缓存吧）

        2） 内存buffer缓存数据是以row为单位的

        3）在内存有限的情况下，在数据库内存buffer里缓存短row，就能缓存更多的数据

        4） 在数据库内存buffer里缓存访问频率高的row，就能提升缓存命中率，减少磁盘的访问

    举个例子就很好理解了：

    假设数据库内存buffer为1G，未拆分的user表1行数据大小为1k，那么只能缓存100w行数据。

    如果垂直拆分成user_base和user_ext，其中：

        1）user_base访问频率高（例如uid, name, passwd, 以及一些flag等），一行大小为0.1k

        2）user_ext访问频率低（例如签名, 个人介绍等），一行大小为0.9k

    那边内存buffer就就能缓存近乎1000w行user_base的记录，访问磁盘的概率会大大降低，数据库访问的时延会大大降低，吞吐量会大大增加。

五、总结

    1）水平拆分和垂直拆分都是降低数据量大小，提升数据库性能的常见手段

    2）流量大，数据量大时，数据访问要有service层，并且service层不要通过join来获取主表和扩展表的属性

    3）垂直拆分的依据，尽量把长度较短，访问频率较高的属性放在主表里

希望没有浪费你这一分钟，帮转哈。

---

单KEY业务，数据库水平切分架构实践

http://zhuanlan.51cto.com/art/201706/542828.htm

本文将以“用户中心”为例，介绍“单KEY”类业务，随着数据量的逐步增大，数据库性能显著降低，数据库水平切分相关的架构实践：

    1）如何来实施水平切分

    2）水平切分后常见的问题

    3）典型问题的优化思路及实践

一、用户中心

    用户中心是一个非常常见的业务，主要提供用户注册、登录、信息查询与修改的服务，其核心元数据为：

        User(uid, login_name, passwd, sex, age, nickname, …)

    其中：

        uid为用户ID，主键

        login_name, passwd, sex, age, nickname, …等用户属性

    数据库设计上，一般来说在业务初期，单库单表就能够搞定这个需求，典型的架构设计为：

        user-center：用户中心服务，对调用者提供友好的RPC接口

        user-db：对用户进行数据存储

二、用户中心水平切分方法

    当数据量越来越大时，需要对数据库进行水平切分，常见的水平切分算法有“范围法”和“哈希法”。

• 范围法

    以用户中心的业务主键uid为划分依据，将数据水平切分到两个数据库实例上去：

         

        user-db1：存储0到1千万的uid数据

        user-db2：存储1到2千万的uid数据

    范围法的优点是：

        切分策略简单，根据uid，按照范围，user- center很快能够定位到数据在哪个库上

         扩容简单，如果容量不够，只要增加user-db3即可

    范围法的不足是：

        uid必须要满足递增的特性

        数据量不均，新增的user-db3，在初期的数据会比较少

         请求量不均，一般来说，新注册的用户活跃度会比较高，故user-db2往往会比user-db1负载要高，导致服务器利用率不平衡

• 哈希法

    也是以用户中心的业务主键uid为划分依据，将数据水平切分到两个数据库实例上去：

     

        user-db1：存储uid取模得1的uid数据

        user-db2：存储uid取模得0的uid数据

    哈希法的优点是：

        切分策略简单，根据uid，按照hash，user-center很快能够定位到数据在哪个库上

         数据量均衡，只要uid是均匀的，数据在各个库上的分布一定是均衡的

         请求量均衡，只要uid是均匀的，负载在各个库上的分布一定是均衡的

    哈希法的不足是：

         扩容麻烦，如果容量不够，要增加一个库，重新hash可能会导致数据迁移，如何平滑的进行数据迁移，是一个需要解决的问题

三、用户中心水平切分后带来的问题

    使用uid来进行水平切分之后，整个用户中心的业务访问会遇到什么问题呢?

    对于uid属性上的查询可以直接路由到库，假设访问uid=124的数据，取模后能够直接定位db-user1

    

     对于非uid属性上的查询，例如login_name属性上的查询，就悲剧了，假设访问login_name=shenjian的数据，由于不知道数据落在哪个库上，往往需要遍历所有库，当分库数量多起来，性能会显著降低。

    

    如何解决分库后，非uid属性上的查询问题，是后文要重点讨论的内容。

四、用户中心非uid属性查询需求分析

    任何脱离业务的架构设计都是耍流氓，在进行架构讨论之前， 先来对业务进行简要分析，看非uid属性上有哪些查询需求。

    根据楼主这些年的架构经验，用户中心非uid属性上经常有两类业务需求：

        1) 用户侧，前台访问，最典型的有两类需求

            用户登录：通过login_name/phone/email查询用户的实体，1%请求属于这种类型

            用户信息查询：登录之后，通过uid来查询用户的实例，99%请求属这种类型

         用户侧的查询基本上是单条记录的查询，访问量较大，服务需要高可用，并且对一致性的要求较高。

        2) 运营侧，后台访问，根据产品、运营需求，访问模式各异，按照年龄、性别、头像、登陆时间、注册时间来进行查询。

         运营侧的查询基本上是批量分页的查询，由于是内部系统，访问量很低，对可用性的要求不高，对一致性的要求也没这么严格。

这两类不同的业务需求，应该使用什么样的架构方案来解决呢?

五、用户中心水平切分架构思路

    用户中心在数据量较大的情况下，使用uid进行水平切分，对于非uid属性上的查询需求，架构设计的核心思路为：

        1） 针对用户侧，应该采用“建立非uid属性到uid的映射关系”的架构方案

        2）针对运营侧，应该采用“前台与后台分离”的架构方案

六、用户中心-用户侧最佳实践

【索引表法】

思路：uid能直接定位到库，login_name不能直接定位到库，如果通过login_name能查询到uid，问题解决

解决方案：

    建立一个索引表记录login_name->uid的映射关系

    用login_name来访问时，先通过索引表查询到uid，再定位相应的库

    索引表属性较少，可以容纳非常多数据，一般不需要分库

    如果数据量过大，可以通过login_name来分库

潜在不足：

     多一次数据库查询，性能下降一倍

【缓存映射法】

思路：访问索引表性能较低，把映射关系放在缓存里性能更佳

解决方案：

    login_name查询先到cache中查询uid，再根据uid定位数据库

    假设cache miss，采用扫全库法获取login_name对应的uid，放入cache

    login_name到uid的映射关系不会变化，映射关系一旦放入缓存，不会更改，无需淘汰，缓存命中率超高

    如果数据量过大，可以通过login_name进行cache水平切分

潜在不足：

多一次cache查询

【login_name生成uid】

思路：不进行远程查询，由login_name直接得到uid

解决方案：

     在用户注册时，设计函数login_name生成uid，uid=f(login_name)，按uid分库插入数据

    用login_name来访问时，先通过函数计算出uid，即uid=f(login_name)再来一遍，由uid路由到对应库

潜在不足：

    该函数设计需要非常讲究技巧，有uid生成冲突风险

【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直接定位到库

     注：相当于生成一个全局ID作为第一部分，然后利用login_name生成的uid来做Hash作为第二部分。第一部分保证唯一性，第二部用于快速定位。

七、用户中心-运营侧最佳实践

    前台用户侧，业务需求基本都是单行记录的访问，只要建立非uid属性 login_name / phone / email 到uid的映射关系，就能解决问题。

    后台运营侧，业务需求各异，基本是批量分页的访问，这类访问计算量较大，返回数据量较大，比较消耗数据库性能。

     如果此时前台业务和后台业务公用一批服务和一个数据库，有可能导致，由于后台的“少数几个请求”的“批量查询”的“低效”访问，导致数据库的cpu偶尔瞬时100%，影响前台正常用户的访问(例如，登录超时)。

    

     而且，为了满足后台业务各类“奇形怪状”的需求，往往会在数据库上建立各种索引，这些索引占用大量内存，会使得用户侧前台业务uid/login_name上的查询性能与写入性能大幅度降低，处理时间增长。

    对于这一类业务，应该采用“前台与后台分离”的架构方案：

    

    用户侧前台业务需求架构依然不变， 产品运营侧后台业务需求则抽取独立的web / service / db 来支持，解除系统之间的耦合，对于“业务复杂”“并发量低”“无需高可用”“能接受一定延时”的后台业务：

    1)  可以去掉service层，在运营后台web层通过dao直接访问db

    2)  不需要反向代理，不需要集群冗余

    3)  不需要访问实时库，可以通过MQ或者线下异步同步数据

    4) 在数据库非常大的情况下， 可以使用更契合大量数据允许接受更高延时的“索引外置”或者“HIVE”的设计方案

     

八、总结

将以“用户中心”为典型的“单KEY”类业务，水平切分的架构点，本文做了这样一些介绍。

水平切分方式：

    水平切分后碰到的问题：

        通过uid属性查询能直接定位到库，通过非uid属性查询不能定位到库

        非uid属性查询的典型业务：

            用户侧，前台访问，单条记录的查询，访问量较大，服务需要高可用，并且对一致性的要求较高

            运营侧，后台访问，根据产品、运营需求，访问模式各异，基本上是批量分页的查询，由于是内部系统，访问量很低，对可用性的要求不高，对一致性的要求也没这么严格

    这两类业务的架构设计思路：

        用户前台侧，“建立非uid属性到uid的映射关系”最佳实践：

            索引表法：数据库中记录login_name->uid的映射关系

            缓存映射法：缓存中记录login_name->uid的映射关系

            login_name生成uid

            login_name基因融入uid

        运营后台侧，“前台与后台分离”最佳实践：

            前台、后台系统web/service/db分离解耦，避免后台低效查询引发前台查询抖动

            可以采用数据冗余的设计方式

            可以采用“外置索引”(例如ES搜索系统)或者“大数据处理”(例如HIVE)来满足后台变态的查询需求

---

1对多业务，数据库水平切分架构一次搞定

http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651960274&idx=1&sn=81714a692f3c29395c6e2ff3e8f00350&chksm=bd2d060e8a5a8f188c90253a496c97661da7f3bcab9d42c48b95665fae3916b2c2cdc2ea33e6&scene=21#wechat_redirect

本文将以“帖子中心”为例，介绍“1对多”类业务，随着数据量的逐步增大，数据库性能显著降低，数据库水平切分相关的架构实践：

    1) 如何来实施水平切分

    2) 水平切分后常见的问题

    3) 典型问题的优化思路及实践

一、什么是1对多关系

    所谓的“1对1”，“1对多”，“多对多”，来自数据库设计中的“实体-关系”ER模型，用来描述实体之间的映射关系。

     1对1

        一个用户只有一个登录名，一个登录名只对应一个用户

        一个uid对应一个login_name，一个login_name只对应一个uid

    这是一个1对1的关系。

    1对多

        一个用户可以发多条微博，一条微博只有一个发送者

        一个uid对应多个msg_id，一个msg_id只对应一个uid

    这是一个1对多的关系。

     多对多

        一个用户可以关注多个用户

        一个用户也可以被多个粉丝关注

    这是一个多对多的关系。

二、帖子中心业务分析

    帖子中心是一个典型的1对多业务。一个用户可以发布多个帖子，一个帖子只对应一个发布者。任何脱离业务的架构设计都是耍流氓，先来看看帖子中心对应的业务需求。

    帖子中心，是一个提供帖子发布/修改/删除/查看/搜索的服务。

     写操作：

        1) 发布(insert)帖子

        2) 修改(update)帖子

        3) 删除(delete)帖子

     读操作：

        1) 通过tid查询(select)帖子实体， 单行查询

        2) 通过uid查询(select)用户发布过的帖子， 列表查询

        3) 帖子检索(search)，例如通过时间、标题、内容 搜索符合条件的帖子

    在 数据量较大，并发量较大的时候，通常通过元数据与索引数据分离的架构来满足不同类型的需求：

     

    架构中的几个关键点：

        tiezi-center：帖子服务

        tiezi-db：提供元数据存储

        tiezi-search：帖子搜索服务

        tiezi-index：提供索引数据存储

        MQ：tiezi-center与tiezi-search通讯媒介，一般不直接使用RPC调用，而是通过MQ对两个子系统解耦（为何这么解耦，请参见《到底什么时候该使用MQ？》）

    其中，tiezi-center和tiezi-search分别满足两类不同的读需求：

     

    如上图所示：

        tid和uid上的查询需求，可以由tiezi-center从元数据读取并返回

        其他类检索需求，可以由tiezi-search从索引数据检索并返回

    

    对于写需求：

    

    如上图所示：

        增加，修改，删除的操作都会从tiezi-center发起

        tiezi-center修改元数据

        tiezi-center将信息修改通知发送给MQ

        tiezi-search从MQ接受修改信息

        tiezi-search修改索引数据

    tiezi-search，搜索架构不是本文的重点（外置索引架构设计，请参见《100亿数据1万属性数据架构设计》），后文将重点描述帖子中心元数据这一块的水平切分设计。

三、帖子中心元数据设计

    通过帖子中心业务分析，很容易了解到，其核心元数据为：

        Tiezi(tid, uid, time, title, content, …);

    其中：

        tid为帖子ID，主键

        uid为用户ID，发帖人

        time, title, content …等为帖子属性

    数据库设计上，在业务初期， 单库就能满足元数据存储要求，其典型的架构设计为：

     

        tiezi-center：帖子中心服务，对调用者提供友好的RPC接口

        tiezi-db：对帖子数据进行存储

    在相关字段上建立索引，就能满足相关业务需求：

        帖子记录查询，通过tid查询， 约占读请求量90%

            select * from t_tiezi where tid=$tid

        帖子列表查询，通过uid查询其发布的所有帖子， 约占读请求量10%

            select * from t_tiezi where uid=$uid

四、帖子中心水平切分-tid切分法

    当数据量越来越大时，需要对帖子数据的存储进行线性扩展。

    既然是帖子中心，并且帖子记录查询量占了总请求的90%，很容易想到 通过tid字段取模来进行水平切分：

    

    这个方法简单直接，优点：

         100% 写 请求可以直接定位到库

        90%的读请求可以直接定位到库

    缺点：

        一个用户发布的所有帖子可能会落到不同的库上， 10%的请求通过uid来查询会比较麻烦

         

    如上图，一个uid访问需要遍历所有库。

五、帖子中心水平切分-uid切分法

    有没有一种切分方法， 确保同一个用户发布的所有帖子都落在同一个库上，而在查询一个用户发布的所有帖子时，不需要去遍历所有的库呢？

        答： 使用uid来分库可以解决这个问题。

    新出现的问题： 如果使用uid来分库，确保了一个用户的帖子数据落在同一个库上， 那通过tid来查询，就不知道这个帖子落在哪个库上了，岂不是还需要遍历全库，需要怎么优化呢？

        答：tid的查询是单行记录查询， 只要在数据库（或者缓存）记录tid到uid的映射关系，就能解决这个问题。

    新增一个索引库：

            t_mapping(tid, uid);

        这个库只有两列，可以承载很多数据

        即使数据量过大，索引库可以利用tid水平切分

        这类kv形式的索引结构，可以很好的利用cache优化查询性能

        一旦帖子发布，tid和uid的映射关系就不会发生变化，cache的命中率会非常高

    使用uid分库，并增加索引库记录tid到uid的映射关系之后，每当有uid上的查询：

     

    可以通过uid直接定位到库。

    每当有tid上的查询：

        

        先查询索引表，通过tid查询到对应的uid，再通过uid定位到库

    这个方法的优点：

        一个用户发布的所以帖子落在同一个库上

        10%的请求过过uid来查询列表，可以直接定位到库

         索引表cache命中率非常高，因为tid与uid的映射关系不会变

    缺点：

         90%的tid请求，以及100%的修改请求，不能直接定位到库，需要先进行一次索引表的查询，当然这个查询非常块，通常在5ms内可以返回

        数据插入时需要操作元数据与索引表， 可能引发潜在的一致性问题。

六、帖子中心水平切分-基因法

    有没有一种方法， 既能够通过uid定位到库，又不需要建立索引表来进行二次查询呢，这就是本文要叙述的“1对多”业务分库 最佳实践，基因法。

     什么是分库基因？

     通过uid分库，假设分为16个库，采用uid%16的方式来进行数据库路由，这里的uid%16，其本质是uid的最后4个bit决定这行数据落在哪个库上，这4个bit，就是分库基因。

    

    什么是基因法分库？

    在“1对多”的业务场景， 使用“1”分库，在“多”的数据id生成时，id末端加入分库基因，就能同时满足“1”和“多”的分库查询需求。

    

    如上图所示，uid=666的用户发布了一条帖子（666的二进制表示为：1010011010）：

        使用uid%16分库，决定这行数据要插入到哪个库中

        分库基因是uid的最后4个bit，即1010

        在生成tid时，先使用一种分布式ID生成算法生成前60bit（上图中绿色部分）

        将分库基因加入到tid的最后4个bit（上图中粉色部分）

        拼装成最终的64bit帖子tid（上图中蓝色部分）

（怎么生成60bit分布式唯一ID，请参见《分布式ID生成算法》）

    这般，保证了同一个用户发布的所有帖子的tid，都落在同一个库上，tid的最后4个bit都相同，于是：

        通过uid%16能够定位到库

        通过tid%16也能定位到库

     注：这个本质上还是使用uid进行分库的，但是由于tid中携带了uid的信息，所以tid单独也可以定位到库。本质上《单KEY业务，数据库水平切分架构实践》是这一篇的特殊情况。log_name对应一个用户，而一个uid则对应多个帖子。但是，最后都是用“额外”那个信息来作为分库依据，让主键生成过程中包含这个依据。

     潜在问题一：同一个uid发布的tid落在同一个库上，会不会出现数据不均衡？

        答： 只要uid是均衡的，每个用户发布的平均帖子数是均衡的，每个库的数据就是均衡的。

    潜在问题二：最开始分16库，分库基因是4bit，未来要扩充成32库，分库基因变成了5bit，那怎么办？

        答： 需要提前做好容量预估，例如事先规划好5年内数据增长256库足够，就提前预留8bit基因。

七、总结

    将以“帖子中心”为典型的“1对多”类业务，在架构上，采用元数据与索引数据分离的架构设计方法：

        帖子服务，元数据满足uid和tid的查询需求

        搜索服务，索引数据满足复杂搜索寻求

    对于元数据的存储，在数据量较大的情况下，有三种常见的切分方法：

         tid切分法，按照tid分库，同一个用户发布的帖子落在不同的库上，通过uid来查询要遍历所有库

         uid切分法，按照uid分库，同一个用户发布的帖子落在同一个库上，需要通过索引表或者缓存来记录tid与uid的映射关系，通过tid来查询时，先查到uid，再通过uid定位库

         基因法，按照uid分库，在生成tid里加入uid上的分库基因，保证通过uid和tid都能直接定位到库

对于1对多的业务场景，分库架构不再是瓶颈。