博主历时三年倾注大量心血创作的《大数据平台架构与原型实现：数据中台建设实战》一书已由知名IT图书品牌电子工业出版社博文视点出版发行，真诚推荐给每一位读者！点击《重磅推荐：建大数据平台太难了！给我发个工程原型吧！》了解图书详情，扫码进入京东购书页面！



 

本文着重介绍sharding的基本思想和理论上的切分策略，关于更加细致的实施策略和参考事例请参考我的另一篇博文：数据库分库分表(sharding)系列(一) 拆分实施策略和示例演示 

 

一、基本思想

      Sharding的基本思想就要把一个数据库切分成多个部分放到不同的数据库(server)上，从而缓解单一数据库的性能问题。不太严格的讲，对于海量数据的数据库，如果是因为表多而数据多，这时候适合使用垂直切分，即把关系紧密（比如同一模块）的表切分出来放在一个server上。如果表并不多，但每张表的数据非常多，这时候适合水平切分，即把表的数据按某种规则（比如按ID散列）切分到多个数据库(server)上。当然，现实中更多是这两种情况混杂在一起，这时候需要根据实际情况做出选择，也可能会综合使用垂直与水平切分，从而将原有数据库切分成类似矩阵一样可以无限扩充的数据库(server)阵列。下面分别详细地介绍一下垂直切分和水平切分.


      垂直切分的最大特点就是规则简单，实施也更为方便，尤其适合各业务之间的耦合度非

常低，相互影响很小，业务逻辑非常清晰的系统。在这种系统中，可以很容易做到将不同业

务模块所使用的表分拆到不同的数据库中。根据不同的表来进行拆分，对应用程序的影响也

更小，拆分规则也会比较简单清晰。（这也就是所谓的”share nothing”）。




      水平切分于垂直切分相比，相对来说稍微复杂一些。因为要将同一个表中的不同数据拆

分到不同的数据库中，对于应用程序来说，拆分规则本身就较根据表名来拆分更为复杂，后

期的数据维护也会更为复杂一些。




      让我们从普遍的情况来考虑数据的切分：一方面，一个库的所有表通常不可能由某一张表全部串联起来，这句话暗含的意思是，水平切分几乎都是针对一小搓一小搓（实际上就是垂直切分出来的块）关系紧密的表进行的，而不可能是针对所有表进行的。另一方面，一些负载非常高的系统，即使仅仅只是单个表都无法通过单台数据库主机来承担其负载，这意味着单单是垂直切分也不能完全解决问明。因此多数系统会将垂直切分和水平切分联合使用，先对系统做垂直切分，再针对每一小搓表的情况选择性地做水平切分。从而将整个数据库切分成一个分布式矩阵。



 

二、切分策略

      如前面所提到的，切分是按先垂直切分再水平切分的步骤进行的。垂直切分的结果正好为水平切分做好了铺垫。垂直切分的思路就是分析表间的聚合关系，把关系紧密的表放在一起。多数情况下可能是同一个模块，或者是同一“聚集”。这里的“聚集”正是领域驱动设计里所说的聚集。在垂直切分出的表聚集内，找出“根元素”（这里的“根元素”就是领域驱动设计里的“聚合根”），按“根元素”进行水平切分，也就是从“根元素”开始，把所有和它直接与间接关联的数据放入一个shard里。这样出现跨shard关联的可能性就非常的小。应用程序就不必打断既有的表间关联。比如：对于社交网站，几乎所有数据最终都会关联到某个用户上，基于用户进行切分就是最好的选择。再比如论坛系统，用户和论坛两个模块应该在垂直切分时被分在了两个shard里，对于论坛模块来说，Forum显然是聚合根，因此按Forum进行水平切分，把Forum里所有的帖子和回帖都随Forum放在一个shard里是很自然的。


      对于共享数据数据，如果是只读的字典表，每个shard里维护一份应该是一个不错的选择，这样不必打断关联关系。如果是一般数据间的跨节点的关联，就必须打断。

 

      需要特别说明的是：当同时进行垂直和水平切分时，切分策略会发生一些微妙的变化。比如：在只考虑垂直切分的时候，被划分到一起的表之间可以保持任意的关联关系，因此你可以按“功能模块”划分表格，但是一旦引入水平切分之后，表间关联关系就会受到很大的制约，通常只能允许一个主表（以该表ID进行散列的表）和其多个次表之间保留关联关系，也就是说：当同时进行垂直和水平切分时，在垂直方向上的切分将不再以“功能模块”进行划分，而是需要更加细粒度的垂直切分，而这个粒度与领域驱动设计中的“聚合”概念不谋而合，甚至可以说是完全一致，每个shard的主表正是一个聚合中的聚合根！这样切分下来你会发现数据库分被切分地过于分散了（shard的数量会比较多，但是shard里的表却不多），为了避免管理过多的数据源，充分利用每一个数据库服务器的资源，可以考虑将业务上相近，并且具有相近数据增长速率（主表数据量在同一数量级上）的两个或多个shard放到同一个数据源里，每个shard依然是独立的，它们有各自的主表，并使用各自主表ID进行散列，不同的只是它们的散列取模（即节点数量）必需是一致的。（

本文着重介绍sharding的基本思想和理论上的切分策略，关于更加细致的实施策略和参考事例请参考我的另一篇博文：数据库分库分表(sharding)系列(一) 拆分实施策略和示例演示 

）



1.事务问题：

解决事务问题目前有两种可行的方案：分布式事务和通过应用程序与数据库共同控制实现事务下面对两套方案进行一个简单的对比。

方案一：使用分布式事务

    优点：交由数据库管理，简单有效

    缺点：性能代价高，特别是shard越来越多时

方案二：由应用程序和数据库共同控制

     原理：将一个跨多个数据库的分布式事务分拆成多个仅处

           于单个数据库上面的小事务，并通过应用程序来总控

           各个小事务。

     优点：性能上有优势

     缺点：需要应用程序在事务控制上做灵活设计。如果使用  

           了spring的事务管理，改动起来会面临一定的困难。

2.跨节点Join的问题

      只要是进行切分，跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。


3.跨节点的count,order by,group by以及聚合函数问题

      这些是一类问题，因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。解决方案：与解决跨节点join问题的类似，分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多。但如果结果集很大，对应用程序内存的消耗是一个问题。

 

参考资料：

《MySQL性能调优与架构设计》

 

注：本文图片摘自《MySQL性能调优与架构设计》一 书

 

 

 

相关阅读：

数据库分库分表(sharding)系列(五) 一种支持自由规划无须数据迁移和修改路由代码的Sharding扩容方案

 

 

 

数据库分库分表(sharding)系列(四) 多数据源的事务处理

数据库分库分表(sharding)系列(三) 关于使用框架还是自主开发以及sharding实现层面的考量

 

数据库分库分表(sharding)系列(二) 全局主键生成策略

 

数据库分库分表(sharding)系列(一) 拆分实施策略和示例演示

 

关于垂直切分Vertical Sharding的粒度

数据库Sharding的基本思想和切分策略

 

 

 

 

何为数据切分？
简单来说，就是通过某种特定的条件，将存放在同一个数据库中的数据分散存放到多个数据库上面，已达到分散单台设备负载的效果
数据切分（sharding）根据其切分规则类型，可以分为两种切分模式。一种是按照不同的表来切分到不同的数据库，这种切分被称为垂直切分；另一种根据表中数据的逻辑关系，将同一个表中的数据切分到多台数据库上，这种称为水平切分
垂直切分的最大特点就是规则简单，实施起来方便，尤其适合业务之间耦合度低，相互影响小，业务逻辑非常清晰的系统。在这种系统中，可以很容易的做到将不同业务模块所使用的表拆分到不同数据库中。根据不同的表进行拆分，对应用程序的影响也更小，拆分规则也会比较简单清晰
水平切分相对复杂，因为要将同一个表中的数据拆分到不同的数据库中，对应用程序来说，拆分规则本身就较根据表名来拆分更为复杂，后期的维护也会更复杂
垂直切分
一个数据库由多个表组成，每个表对应不同的业务，垂直切分是指按照业务对表进行分类，分部到不同的数据库中


系统被切分成用户，订单交易，支付几个模块
优点
拆分后业务清晰，拆分规则明确

系统整合容易

数据维护性好
缺点
部分业务表无法join，只能通过接口方式解决，提高了系统复杂度

受每种业务不同的限制存在单库性能瓶颈，不易数据扩展跟性能提高

事务处理复杂
由于垂直切分按照业务的分类将表分散到不同的数据库，所以有些业务表会过于庞大，存在单库读写与存储瓶颈，所以需要水平拆分来解决
水平切分
相对于垂直切分，水平切分不是按表做分类，而是按照某种字段的规则来分散到多个数据库中，每个表中包含一部分数据。简单来说，我们可以将数据库的水平切分理解为按照数据行的切分，就是将表中的某些行切分到数据库，而另外的某些行又切分到不同数据库中



拆分规则就需要定义分片规则。关系数据库是行列的二维模型，拆分的第一原则就是找到拆分维度。
几种典型的分片规则包括：
按照用户ID求模，将数据分散到不同的数据库，具有相同的数据用户的数据被分到一个裤中
按照日期，将不同月甚至不同日的数据分散到不同库中
按照某个特定的字段求模，或根据特定范围分散到不同数据库中


优点
不存在单库大数据，高并发的性能瓶颈
应用端改造少
提高了系统的稳定性跟负载能力
缺点
拆分规则难以抽象
分片事务难以解决
数据多次扩展难度跟维护量极大

假设要把长度为 n 厘米的木棒切分为 1 厘米长的小段，但是 1 根木棒只能由 1 人切分，当木棒被切分为 3 段后，可以同时由 3 个人分别切分木棒（ 图2 ）。

求最多有 m 个人时，最少要切分几次。譬如 n ＝ 8，m ＝ 3 时如下图所示，切分 4 次就可以了。


这个题思路的核心就在于尽快让更多的人参与到工作中来
方法一：使用递归调用实现。显然这个切的过程中，前面可以按照指数方式进行递增，后面就只能一条一条的切了。
# n是多少厘米长的木棒，m是几个人，current是目前切了几段了
def cutbar(n, m, current):  
    if current >= n:
        return 0
    if current < m:
        return 1 + cutbar(n, m, current*2)
    else:
        return 1 + cutbar(n, m, current + m)

方法二：逆向思考。 本题可以等价为m个人黏合1厘米的木棒以组成n厘米的木棒。也就是说，最后黏合的木棒长度总长为n厘米就够了。
def cutbar2(n, m):
    count = 0
    current = 1 # current是当前长度，同顺序思维是一样的，开始只能加一次，加两次，一直到数m之前。
    while n > current:
        current += current if current < m else m
        count = count + 1
        
    return count  

切分木头
题目如下
假设要把长度为n厘米的木棒切分为1厘米长的小段，但是1根木棒只能由1人切分。当木棒被切分为3段后，可以同时由3个人分别切分木棒。求最多有m个人时，最少要切分几次。譬如n=8，m=3时，切分4次就可以了。
问题
求当n=100，m=5时的最少切分次数。
思路
n厘米长的木头，需要切n-1刀才能得到全是1厘米长的小段。把切分木头的情形分为两种，人等木头和木头等人。第一种情形的切分数量就是所有被切分的木头的总数，第二种情形的切分数量就是总刀数减去第一种情形的数再与人数去分别相除和求余，最后两者相加。
我的解题代码
切分木头
public int qieGeMu(int n, int m) {//n是木头总长度，m是人数。
        int base = 0;
        int num = 0;
        for (int i = 0; i < 50; i++) {
            base += Math.pow(2, i);
            if (m >= i * i && m < ((i + 1) * (i + 1))) {
                num = i + 1;//for循环是从0开始的，而这里要的是人等木头的最大次数，所以加1。
                break;
            }
        }
        int diff = n - 1 - base;
        int re = diff / m;
        int yu = diff % m;
        return yu == 0 ? (num + re) : (num + re + 1);
    }

测试用例
    @Test
    public void qieGeMuTou() {
        int n = 100;
        int m = 5;
        System.out.println("当n=" + n + "，m=" + m + "时的最少切分次数为：" + qieGeMu(n, m));
    }

程序运行结果如下

当n=100，m=5时的最少切分次数为：22
总结
这道题给出的目标作答时间为10分钟，而自己多用了好几倍时间，看来得加把劲了。