摘要：本文介绍做数据库切分的两种思路，艰深了解就是：「垂直拆分」等于“列”变“行”不变，「程度拆分」等于“行”变“列”不变。

分布式系统做「伸缩性」最重要的就是先做好「无状态」，如此才能够得心应手的进行横向“扩大”，而不必放心在多个正本之间切换会产生错乱。

《分布式系统关注点——「无状态」详解》聊的就是这个。

不过，就算做好了横向扩大，实质上还是一个“大程序”，只是变得「可复制」了而已。

如果要毁灭“大程序”，那就得“切分”，做好切分必然离不开「高内聚低耦合」的核心思想。《分布式系统关注点——「高内聚低耦合」详解》这篇聊的就是这个。

题外话： 当你遇到单点单利用撑持不住应用的时候，Z 哥给你的普适性倡议是：先思考“扩”，再思考“切”。这个和写代码一样，“减少”新性能往往比在老性能上改容易。

“扩”的话先思考「垂直扩」（加硬件，钱能解决的都不是问题），再思考「程度扩」（无状态革新 + 多节点部署，这是小手术）。

“切”的话个别就是「垂直切」（依据业务切分，这是大手术），偶然会用到「程度切」（其实就是单个利用里的分层，比方前后端拆散）。

第三篇《分布式系统关注点——弹性架构》咱们聊了常见的两种「松耦合」架构模式，为的是让应用程序的「伸缩性」更上一层楼。

以上这些呢都是应用程序层面的工作。个别状况下，在应用程序层面做做手术，再配合以缓存的充分运用，就能够撑持零碎倒退很长时间了。特地是数据量不大，只是申请量大的「CPU 密集型」场景。

然而，如果所处的工作场景是一个十分成熟且具备肯定规模的我的项目，越倒退到前面瓶颈总是呈现在数据库这里。甚至会呈现 cpu 长期高负荷、宕机等景象。

在如此场景下，就不得不对数据库开刀了。这次 Z 哥就来和你聊聊做数据库的「伸缩性」有哪些好办法。
外围诉求

面临数据库须要开刀的时候，整个零碎往往曾经长成这个样子了。

正如后面所说，这时候的瓶颈往往会体现在「CPU」上。

因为对数据库来说，硬盘和内存的扩容绝对容易，因为它们都能够间接用“减少”的形式进行。

CPU 就不同了，一旦 CPU 飙高，最多查看下索引有没有做好，完了之后根本就只能干看着。

所以解决这个问题的思路天然就变成了：如何将一个数据库的 CPU 压力摊派到多个 CPU 下来。甚至能够做到按需随时减少。

那这不就是和应用程序一样做「切分」嘛。也是分布式系统的「分治」思维体现。

既然是切分，实质上就和应用程序一样，也分为「垂直切分」和「程度切分」。

垂直切分

垂直切分有时候也会被称作「纵向切分」。

同应用程序一样，它是以「业务」为维度的切分形式，在不同的数据库服务器上跑不同业务的数据库，各司其职。

个别状况下，Z 哥倡议你优先思考「垂直切分」而不是「程度切分」，为什么呢？你能够随便关上手头我的项目中的 SQL 语句看看，我想必然存在着大量的「join」和「transaction」关键字，这种关联查问和事务操作，实质上是一种「关系绑定」，一旦面临数据库拆分之后，就没法玩了。

此时你只有 2 个抉择。

1. 要么将不必要的「关系 *」逻辑舍弃掉，这须要在业务上作出调整，去除不必要的“批量操作”业务，或者去除不必要的强一致性事务。不过你也晓得，必定有一些场景是去不完的。
2. 要么将「合并」，「关联」等逻辑上浮，体现到业务逻辑层甚至是应用层的代码中。

最终，不管怎么抉择，改变起来都是一个大工程。

为了让这个工程尽可能的动作小一些，谋求更好的性价比，须要保持一个准则——“防止拆分严密关联的表”。

因为两个表之间关联越严密，意味着对「join」和「transaction」的需要越多，所以保持这个准则能够使得雷同的模块，严密相干的业务都落在同一个库中，这样它们能够持续应用「join」和「transaction」来工作。

因而，咱们该当优先采纳「垂直切分」的形式。

做「垂直切分」思路很简略，个别状况下，倡议是与切分后的应用程序一一对应就好，不必多也不必少。

理论工作中，要做好「垂直切分」次要体现在「业务」的相熟度上，所以这里就不持续开展了。

「垂直切分」的长处是：

1. 高内聚，拆分规定清晰。相比「程度切分」数据冗余度更低。
2. 与应用程序是 1:1 的关系，不便保护和定位问题。一旦某个数据库中发现异常数据，排查这个数据库的关联程序就行了。

然而这并不是一个「一劳永逸」的计划，因为没人能预料到将来业务会倒退的怎么样，所以最显著的毛病就是：对于拜访极其频繁或者数据量超大的表依然存在性能瓶颈。

的确须要解决这个问题的话，就须要搬出「程度切分」了。

题外话： 不到迫不得己，尽量避免进行「程度切分」。看完接下去的内容你就晓得起因了。
上面 Z 哥就给你好好聊聊「程度切分」，这才是本文的重点。
程度切分

设想一下，在你做了「垂直切分」之后，还是在某个数据库中发现了一张数据量超过 10 亿条的表。

这个时候要对这个表做「程度切分」，你会怎么思考这个事件？

Z 哥教给你的思路是：

1. 先找到“最高频“的「读」字段。
2. 再看这个字段的理论应用中有什么特点（批量查问多还是单个查问多，是否同时是其它表的关联字段等等）。
3. 再依据这个特点抉择适合的切分计划。

为什么要先找到高频的「读」字段呢？

因为在理论的应用中，「读」操作往往是远大于「写」操作的。个别进行「写」之前都得通过「读」来做后行校验，然而「读」还有本人独自的应用场景。所以针对更高频的「读」场景去思考，产生的价值必然也更大。

比方，当初那张 10 亿数据量的表是一张订单表，构造是这样：

order (orderId long, createTime datetime, userId long)

上面咱们先来看看有哪几种「程度切分」的形式，完了能力明确什么样的场景适宜哪种形式。

范畴切分

这是一种「连续式」的切分形式。

比方依据工夫（createTime）切分的话，咱们能够按年月来分，order_201901 一个库，order_201902 一个库，以此类推。

依据程序数（orderId）切分的话，能够 100000～199999 一个库，200000～299999 一个库，以此类推。

这种切分法的长处是：单个表的大小可控，扩大的时候无需数据迁徙。

毛病也很显著，一般来说工夫越近或者序号越大的数据越“新”，因而被拜访的频率和概率相比“老”数据更多。会导致压力次要集中在新的库中，而历史越久的库，越闲暇。

Hash 切分

与「范畴切分」正好相同，这是一种「离散式」的切分形式。

它的长处就是解决了「范畴切分」的毛病，新数据被扩散到了各个节点中，防止了压力集中在多数节点上。

同样，毛病与「范畴切分」的长处相同，一旦进行二次扩大，必然会波及到数据迁徙。因为 Hash 算法是固定的，算法一变，数据分布就变了。

大多数状况下，咱们的 hash 算法能够通过简略的「取模」运算来进行即可。就像上面这样：

如果分成 11 个库的话，公式就是 orderId % 10。

100000 % 10 = 0，调配到 db0。
100001 % 10 = 1，调配到 db1。
….
100010 % 10 = 0，调配到 db0。
100011 % 10 = 1，调配到 db1。

其实，在某些场景下，咱们能够通过自定义 id 的生成（能够参考之前的文章，《分布式系统中的必备良药 —— 全局惟一单据号生成》）来做到既能够通过 hash 切分来打散热点数据，又能够缩小依赖全局表来定位具体的数据。

比方，在 orderId 中退出 userId 的尾数，以此达到 orderId 和 userId 取模后果相等的成果。还是来举个例子：
一个用户的 userId 是 200004，如果取一个 4bit 尾数的话，这里就是 4，用 0100 示意。

而后，咱们通过自定义 id 算法生成 orderId 的前 60 位，在前面补上 0100。
于是，orderId % 10 和 userId % 10 的后果就是一样的了。

当然，除了 userId 之外还想退出其余的因子就不好使了。也就是，能够在不减少全局表的状况下，额定多反对 1 个维度。

提到了两次全局表，那么啥是全局表呢？

全局表

这种形式就是将用作切分根据的分区 Key 与对应的每一条具体数据的 id 保留到一个独自的库或者表中。例如要减少一张这样的表：

1     nodeId    orderId
2      01          100001
3     02          100002
4     01          100003
5     01          100004...
6    ...

如此一来，确实将大部分具体的数据分布在了不同服务器上，然而这张全局表会给人一种「形散神不散」的感觉。

因为申请数据的时候无奈间接定位须要的数据在哪台服务器上，所以每一次操作都要先查问一下这张全局表好晓得具体的数据被寄存在哪里。

这种「中心化」的模式带来的副作用就是瓶颈和危险转移到了这张全局表上。然而，胜在逻辑简略。

好了，那么这几种切分计划怎么抉择呢？

Z 哥给你的倡议是，如果热点数据不是特地集中的场景，倡议先用「范畴切分」，否则抉择另外 2 种。

抉择另外两种的时候，数据量越大越偏向抉择 Hash 切分。因为后者在整体的可用性和性能上都比前者好，就是实现老本高一些。

「程度切分」真正做到了能够“有限扩大”，然而也存在相应的弊病。

1）批量查问、分页等须要做更多的额定工作。特地是当一个表存在多个高频字段用于 where、order by 或者 group by 的时候。
2）拆分规定不如「垂直切分」那么明确。

所以还是多说一句“废话”：没有完满的计划只有适合的计划，要联合具体的场景来抉择。（欢送你在留言区提出你有纳闷的场景，和 Z 哥来探讨探讨）

如何施行

当你在具体实施「程度切分」的时候能够在 2 个层面动刀，能够是「表」层面，也能够是「库」层面。

表

在同一个数据库上面分表，表名 order_0 ,order_1, order_2…..。

它能够解决单表数据过大，但并不能解决 CPU 负荷的问题。所以，当 CPU 并没多少压力，只是因为表太大，导致执行 SQL 操作比较慢的话，能够抉择这种形式。

库

这个时候表名能够不变，都叫 order，只是分成 10 个库。那么就是 db0-user db1-user db2-user……。

咱们后面大篇幅都是基于这个模式在聊，就不多说了。

表 + 库

也能够既分库又分表，比方先分 10 个库，而后每个库再分 10 张表。

这其实是个二级索引的思路，通过库来进行第一次定位，缩小肯定的资源耗费。

比方，先按年分库，再按月分表。如此一来，如果须要获取的数据只跨月但不跨年，咱们就能够在单个库内做聚合运算来实现，不波及到跨库操作。
不过，不论抉择哪种形式来进行，你还是会或多或少面临以下两个问题，逃不掉的。

1. 跨库 join。
2. 全局聚合或者排序操作。

解决第一个问题最佳形式还是须要扭转你的编程思维。尽量将一些逻辑、关系、束缚等体现在应用程序的代码中，防止因为不便而在 SQL 中做这些事件。

毕竟代码是能够写成“无状态”的，能够随时做扩大，然而 SQL 是跟着数据走的，而数据就是“状态”，人造不利于扩大。

当然了，退而求其次，你也能够冗余大量的全局表来应答。只是如此一来，对「数据一致性」工作是个很大的考验，另外，对存储资源也是很大的开销。

第二个问题的解决方案就是须要将本来的一次聚合或者一次排序变成两次操作。其中的遍历多个节点能够以「并行」的形式进行。

那么数据切分完之后程序如何来应用呢？这又能够分为两种模式，「过程内」和「过程外」。
「过程内」的话，能够在封装好的 DAL 拜访框架中做，也能够在 ORM 框架中做，还能够在数据库驱动中做。这个模式比拟出名的解决方案如阿里的 tddl。

「过程外」的话，就是代理模式，这个模式比拟出名的解决方案是 mycat、cobar、atlas 等等，绝对多一些，因为这种模式对应用程序是「低侵入」的，应用起来像“一个数据库”。然而因为多了一道网络通信，性能上会多一些损耗。
老规矩，上面再分享一些最佳实际。

最佳实际

首先分享两个能够不停机做数据切分的小窍门。咱们以施行 hash 法做程度切分的例子来看一下。

第一次做切分的时候，你能够以「主 - 从」的模式将新增的节点作为原始节点的正本，进行全量实时同步。

而后在这个根底上删除不属于它的数据。（当然了，不删也没啥问题，就是多占用一些空间）

这样就能够不必停机了。

第二，随着工夫的推移，如果后续撑持不住了，须要二次切分的话，咱们能够抉择用 2 的倍数来扩大。

如此一来，数据的迁徙变得很简略，只须要做部分的迁徙，和第一次做切分的思路是一样的。

当然了，如果抉择的切分形式是「范畴切分」的话，就没有二次切分时的困扰，数据天然跑到最新的节点下来了。比方咱们按年月分表的话。2019 年 3 月的数据天然就落到了 xxxx_201903 的表中。

到这里，Z 哥还是想特别强调的是，能不切分尽量不要切分，能够先应用「读写拆散」之类的计划先来应答面临的问题。

如果切实要进行切分的话，务必先「垂直切分」，再思考「程度切分」。

一般来说，以这样的程序来思考，性价比更好。

总结

好了，咱们总结一下。
这次呢，就先向你介绍了做数据库切分的两种思路。两种思路艰深了解就是：「垂直拆分」等于“列”变“行”不变，「程度拆分」等于“行”变“列”不变。

而后着重聊了下「程度切分」的 3 种实现形式和具体实施的思路。
最初分享了一些实际中的教训给你。
心愿对你有所启发。
相干文章：
• 分布式系统关注点——「无状态」详解
• 分布式系统关注点——「高内聚低耦合」详解
• 分布式系统关注点——弹性架构
• 分布式系统中的必备良药 —— 全局惟一单据号生成

本文由博客群发一文多发等经营工具平台 OpenWrite 公布