1. 数据切分

关系型数据库本身比较容易成为系统瓶颈，单机存储容量、连接数、处理能力都有限。
数据库分布式核心内容是数据切分（Sharding），以及切分后对数据的定位、整合。
数据切分根据其切分类型，可以分为两种方式：垂直（纵向）切分和水平（横向）切分。

1.1 垂直（纵向）切分

切分方式：垂直分表是基于数据库中的"列"进行，某个表字段较多，可以新建一张扩展表，或者将不经常用或字段长度较大的字段拆分出去到扩展表中。

垂直切分的优点

• 解决业务系统层面的耦合，业务清晰
• 能对不同业务的数据进行分级管理、维护、监控、扩展等
• 高并发场景下，垂直切分一定程度的提升IO、数据库连接数、单机硬件资源的瓶颈

垂直切分的缺点

• 部分表无法join，只能通过接口聚合方式解决，提升了开发的复杂度
• 分布式事务处理复杂
• 依然存在单表数据量过大的问题

1.2 水平（横向）切分

平切分分为库内分表和分库分表。

1.2.1 水平切分的优点：

• 不存在单库数据量过大、高并发的性能瓶颈，提升系统稳定性和负载能力
• 应用端改造较小，不需要拆分业务模块

1.2.2 水平切分的缺点：

• 跨分片的事务一致性难以保证
• 跨库的join关联查询性能较差
• 数据多次扩展难度和维护量大

1.2.3 典型分片规则

典型分片规则有按照数值范围分片和按照数值取模分片，具体如下：

1.2.3.1 按照数值范围

优点：

• 单表大小可控
• 便于水平扩展，后期如果需要扩容，只需添加节点即可，无需对其他分片的数据进行迁移。
  缺点：
• 热点数据容易称为瓶颈

1.2.3.2 按照数值取模

一般采取根据hash值取模的方式。例如：将 Customer 表根据 cusno 字段切分到4个库中，余数为0的放到第一个库，余数为1的放到第二个库，以此类推。这样同一个用户的数据会分散到同一个库中，如果查询条件带有cusno字段，则可明确定位到相应库去查询。
优点：

• 数据分片相对比较均匀，不容易出现热点和并发访问的瓶颈
  缺点：
• 后期分片集群扩容时，需要迁移旧的数据（可以通过提前规划系统容量来规避该问题。或者使用一致性hash算法较好的解决该问题）
• 容易面临跨分片查询的复杂问题。比如上例中，如果频繁用到的查询条件中不带cusno时，将会导致无法定位数据库，从而需要同时向4个库发起查询，再在内存中合并数据，取最小集返回给应用，分库反而成为拖累。

2. 分库分表带来的问题

分表可能带来事务一致性、跨节点关联查询 join 、跨节点分页/排序/函数、自增ID不可用、数据迁移扩容困难等问题。

3. 分库分表时机

进行分库分表时，最好能够遵循如下原则：

• 可预见的时间内，如果能够满足业务需求，最好不要分表
  分表会增加系统复杂度，进行系统设计和开发时，要尽量避免必须要的复杂度的增加。
• 优先对某些字段进行垂直拆分
  相对于水平分表，垂直分表对系统的冲击更小一些。

4. 案例分析

4.1 业务场景

以用户中心为例，对分库分表进行分析。
用户表包含的属性和描述如下：

User(uid, login_name, passwd, sex, age, nickname)
uid为用户ID,  主键
login_name, passwd, sex, age, nickname,  用户属性

在实施分库分表之前，对业务场景需求进行梳理：

• 用户侧
  前台访问，访问数据量大，需要保证高可用和高一致性。需求主要有两类：

1. 用户登录：通过login_name/phone/email查询用户信息，1%请求属于这种类型
2. 用户信息查询：登录之后，通过uid来查询用户信息，99%请求属这种类型

• 运营侧
  后台访问，支持运营需求，按照年龄、性别、登陆时间、注册时间等进行分页的查询。是内部系统，访问量较低，对可用性、一致性的要求不高。

4.2 水平切分方法选择

当数据量大到单表难以承受的时候，需要对表进行水平切分。一般水平切分方法有根据数值范围和根据数值取模。
根据数值范围对表进行水平切分的优势是扩容简单，如果容量不够，只要增加新db即可。劣势是请求量不均匀，一般新注册的用户活跃度会比较高，所以新的user-db2会比user-db1负载高，导致服务器利用率不平衡。
根据数值取模优势是数据量和请求量分布均均匀。劣势是扩容麻烦。

4.3 非uid查询方法

水平切分后，对于按uid查询的需求能很好的满足，可以直接路由到具体数据库。而按非uid的查询，例如login_name，就不知道具体该访问哪个库了，此时需要遍历所有库，性能会降低很多。
用户侧可以使用建立非uid属性到uid的映射关系的方案解决该问题；运营侧可以使用前台与后台分离的方案来解决该问题。

4.3.1 建立非uid属性到uid的映射关系

• 缓存映射
  例如：login_name不能直接定位到数据库，可以建立login_name→uid的映射关系，用索引表或缓存来存储。当访问login_name时，先通过映射表查询出login_name对应的uid，再通过uid定位到具体的库。
  映射表只有两列，可以承载很多数据，当数据量过大时，也可以对映射表再做水平切分。这类kv格式的索引结构，可以很好的使用cache来优化查询性能，而且映射关系不会频繁变更，缓存命中率会很高。
• 分库基因法
  假如通过uid分库，分为8个库，采用uid%8的方式进行路由，此时是由uid的最后3bit来决定这行User数据具体落到哪个库上，那么这3bit可以看为分库基因。
  上面的映射关系的方法需要额外存储映射表，按非uid字段查询时，还需要多一次数据库或cache的访问。如果想要消除多余的存储和查询，可以通过f函数取login_name的基因作为uid的分库基因。生成uid时，参考上文所述的分布式唯一ID生成方案，再加上最后3位bit值=f(login_name)。当查询login_name时，只需计算f(login_name)%8的值，就可以定位到具体的库。不过这样需要提前做好容量规划，预估未来几年的数据量需要分多少库，要预留一定bit的分库基因。

4.3.2 前台与后台分离

对于用户侧，主要需求是以单行查询为主，需要建立login_name/phone/email到uid的映射关系，可以解决这些字段的查询问题。
而对于运营侧，很多批量分页且条件多样的查询，这类查询计算量大，返回数据量大，对数据库的性能消耗较高。此时，如果和用户侧公用同一批服务或数据库，可能因为后台的少量请求，占用大量数据库资源，而导致用户侧访问性能降低或超时。
这类业务最好采用"前台与后台分离"的方案，运营侧后台业务抽取独立的service和db，解决和前台业务系统的耦合。由于运营侧对可用性、一致性的要求不高，可以不访问实时库，而是通过binlog异步同步数据到运营库进行访问。在数据量很大的情况下，还可以使用ES搜索引擎或Hive来满足后台复杂的查询方式。

5. 相关中间件

站在巨人的肩膀上能省力很多，目前分库分表已经有一些较为成熟的开源解决方案：

• sharding-jdbc（当当）
• TSharding（蘑菇街）
• Atlas（奇虎360）
• Cobar（阿里巴巴）
• MyCAT（基于Cobar）
• Oceanus（58同城）
• Vitess（谷歌）