mysql如何实现数据切分-木庄网络博客

本文摘自PHP中文网，作者coldplay.xixi，侵删。

mysql实现数据切分的方法：1、使用数据的垂直切分；2、使用数据的水平切分；3、利用MySQL Proxy实现数据切分及整合；4、利用Amoeba实现数据切分；5、利用HiveDB实现数据切分及整合。

更多相关免费学习推荐：mysql教程(视频)

mysql实现数据切分的方法：

何谓数据切分

简单来说，就是指通过某种特定的条件，将存放在同一个数据库中的数据分散存放到多个数据库（主机）上面，以达到分散单台设备负载的效果。数据的切分同时还可以提高系统的总体可用性，因为单台设备Crash之后，只有总体数据的某部分不可用，而不是所有的数据。

数据的切分（Sharding）根据其切分规则的类型，可以分为两种切分模式。一种是按照不同的表（或者Schema）来切分到不同的数据库（主机）之上，这种切分可以称之为数据的垂直（纵向）切分；另外一种则是根据表中数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库（主机）上，这种切分称之为数据的水平（横向）切分。

垂直切分的最大特点就是规则简单，实施也更为方便，尤其适合各业务之间的耦合度非常低、相互影响很小、业务逻辑非常清晰的系统。在这种系统中，可以很容易做到将不同业务模块所使用的表分拆到不同的数据库中。根据不同的表来进行拆分，对应用程序的影响也更小，拆分规则也会比较简单清晰。

水平切分与垂直切分相比，稍微复杂一些。因为要将同一个表中的不同数据拆分到不同的数据库中，对于应用程序来说，拆分规则本身就较根据表名来拆分更为复杂，后期的数据维护也会更复杂。

当某个（或者某些）表的数据量和访问量特别大，通过垂直切分将其放在独立的设备上后仍然无法满足性能要求时，就必须将垂直切分和水平切分相结合，先垂直切分，然后再水平切分，这样才能解决这种超大型表的性能问题。

下面就针对垂直、水平及组合切分这三种数据切分方式的架构实现及切分后数据的整合进行相应的分析。

数据的垂直切分

我们先来看一下，数据的垂直切分到底是如何切分的。数据的垂直切分，也可以称为纵向切分。将数据库想象成由很多个一大块一大块的“数据块”（表）组成，垂直地将这些“数据块”切开，然后把它们分散到多台数据库主机上面。这样的切分方法就是垂直（纵向）的数据切分。

一个架构设计较好的应用系统，其总体功能肯定是由很多个功能模块所组成的，而每一个功能模块所需要的数据对应到数据库中就是一个或多个表。而在架构设计中，各个功能模块相互之间的交互点越统一、越少，系统的耦合度就越低，系统各个模块的维护性及扩展性也就越好。这样的系统，实现数据的垂直切分也就越容易。

功能模块越清晰，耦合度越低，数据垂直切分的规则定义也就越容易。完全可以根据功能模块来进行数据的切分，不同功能模块的数据存放于不同的数据库主机中，可以很容易就避免跨数据库的Join存在，同时系统架构也非常清晰。

当然，很难有系统能够做到所有功能模块使用的表完全独立，根本不须要访问对方的表，或者须要将两个模块的表进行Join操作。这种情况下，就必须根据实际的应用场景进行评估权衡。决定是迁就应用程序将需要Join的表的相关模块都存放在同一个数据库中，还是让应用程序做更多的事情――完全通过模块接口取得不同数据库中的数据，然后在程序中完成Join操作。

一般来说，如果是一个负载相对不大，而且表关联又非常频繁的系统，那可能数据库让步，将几个相关模块合并在一起，减少应用程序工作的方案可以减少较多的工作量，是一个可行的方案。

当然，通过数据库的让步，让多个模块集中共用数据源，实际上也是间接默许了各模块架构耦合度增大的发展，可能会恶化以后的架构。尤其是当发展到一定阶段，发现数据库实在无法承担这些表所带来的压力，不得不面临再次切分时，所带来的架构改造成本可能远远大于最初就使用切分的架构设计。

所以，在数据库进行垂直切分的时候，如何切分、切分到什么样的程度，是一个比较考验人的难题。这只能在实际的应用场景中通过平衡各方面的成本和收益，才能分析出一个真正适合自己的拆分方案。

比如在本文所使用的示例系统的example数据库中，我们简单分析一下，然后设计一个简单的切分规则，进行一次垂直拆分。

系统功能基本可以分为4个功能模块：用户、群组消息、相册以及事件，分别对应为如下这些表：

用户模块表：user,user_profile,user_group,user_photo_album
群组讨论表：groups,group_message,group_message_content,top_message
相册相关表：photo,photo_album,photo_album_relation,photo_comment
事件信息表：event

初略一看，没有哪个模块可以脱离其他模块独立存在，模块与模块之间都存在着关系，莫非无法切分？

当然不是，再稍微深入分析一下，可以发现，虽然各个模块所使用的表之间都有关联，但是关联关系还算清晰，也比较简单。

群组讨论模块和用户模块之间主要存在通过用户或群组关系来进行关联。一般都会通过用户的id或nick_name及group的id来进行关联，通过模块之间的接口实现不会带来太多麻烦。

相册模块仅仅与用户模块存在用户的关联。这两个模块之间的关联基本只有通过用户id关联的内容，简单清晰，接口明确。

事件模块与各个模块可能都有关联，但是都只关注其各个模块中对象的ID信息，同样比较容易分拆。

所以，第一步可以将数据库按照功能模块相关的表进行一次垂直拆分，每个模块所涉及的表单独分到一个数据库中，模块与模块之间的表关联在应用系统端都通过接口来处理。如数据垂直切分示意图（图1）所示：

通过这样的垂直切分之后，之前只能通过一个数据库来提供的服务，就被分拆成4个数据库来提供服务，服务能力自然是增加几倍了。

垂直切分的优点：

数据库的拆分简单明了，拆分规则明确；
应用程序模块清晰明确，整合容易；
数据维护方便易行，容易定位。

垂直切分的缺点：

部分表关联无法在数据库级别完成，要在程序中完成；
对于访问极其频繁且数据量超大的表仍然存在性能瓶颈，不一定能满足要求；
事务处理相对复杂；
切分达到一定程度之后，扩展性会受到限制；
过度切分可能会带来系统过于复杂而难以维护。

针对于垂直切分可能遇到数据切分及事务问题，在数据库层面实在是很难找到一个较好的处理方案。实际应用案例中，数据库的垂直切分大多是与应用系统的模块相对应的，同一个模块的数据源存放于同一个数据库中，可以解决模块内部的数据关联问题。而模块与模块之间，则通过应用程序以服务接口的方式来相互提供所需要的数据。虽然这样做在数据库的总体操作次数方面确实会有所增加，但是在系统整体扩展性及架构模块化方面，都是有益的。可能某些操作的单次响应的时间会稍有增加，但是系统的整体性能很可能反而会有一定的提升。而扩展瓶颈问题，就只能依靠下一节将要介绍的数据水平切分架构来解决了。

数据的水平切分

上面一节分析介绍了数据的垂直切分，本节分析数据的水平切分。数据的垂直切分基本上可以简单地理解为按照表或模块来切分数据，而水平切分则不同。一般来说，简单的水平切分主要是将某个访问极其平凡的表再按照某个字段的某种规则分散到多个表中，每个表包含一部分数据。

简单来说，可以将数据的水平切分理解为按照数据行的切分，就是将表中的某些行切分到一个数据库，而另外的某些行又切分到其他的数据库中。当然，为了能够比较容易地判定各行数据被切分到哪个数据库中了，切分总是须要按照某种特定的规则来进行的：如根据某个数字类型字段基于特定数目取模，某个时间类型字段的范围，或者某个字符类型字段的hash值。如果整个系统中大部分核心表都可以通过某个字段来进行关联，那这个字段自然是一个进行水平分区的上上之选了，当然，非常特殊无法使用的情况除外。

一般来说，像现在非常火爆的Web 2.0类型网站，基本上大部分数据都能够通过会员用户信息关联上，可能很多核心表都非常适合通过会员ID来进行数据的水平切分。而像论坛社区讨论系统，就更容易切分了，可以按照论坛编号来进行水平切分。切分之后基本上不会出现各个库之间的交互。

如果示例系统的所有数据都是和用户关联的，那么就可以根据用户来进行水平拆分，将不同用户的数据切分到不同的数据库中。当然，唯一区别是用户模块中的groups表和用户没有直接关系，所以groups不能根据用户来进行水平拆分。对于这种特殊情况下的表，完全可以独立出来，放在一个独立的数据库中。其实这个做法可以说是利用了前面一节所介绍的“数据的垂直切分”方法，将在下一节中更为详细地介绍这种垂直切分与水平切分同时使用的联合切分方法。

所以，对于示例数据库来说，大部分的表都可以根据用户ID来进行水平切分。不同用户相关的数据进行切分之后存放在不同的数据库中。如将所有用户ID通过被2取模然后分别存放于两个不同的数据库中。每个和用户ID关联上的表都可以这样切分。这样，基本上每个用户相关的数据，都在同一个数据库中，即使须要关联，也非常容易实现。

可以通过水平切分示意图（图2）更为直观地展示水平切分相关信息：

水平切分的优点：

表关联基本能够在数据库端全部完成；
不会存在某些超大型数据量和高负载的表遇到瓶颈的问题；
应用程序端整体架构改动相对较少；
事务处理相对简单；
只要切分规则能够定义好，基本上较难遇到扩展性限制。

水平切分的缺点：

切分规则相对复杂，很难抽象出一个能够满足整个数据库的切分规则；
后期数据的维护难度有所增加，人为手工定位数据更困难；
应用系统各模块耦合度较高，可能会对后面数据的迁移拆分造成一定的困难。
垂直与水平联合切分的使用

前面两节内容中，分别了解了“垂直”和“水平”这两种切分方式的实现和切分之后的架构信息，以及两种架构各自的优缺点。但是在实际的应用场景中，除了那些负载并不是太大、业务逻辑也相对简单的系统可以通过上面两种切分方法之一来解决扩展性问题之外，恐怕其他大部分业务逻辑复杂、系统负载大的系统，都无法通过上面任何一种数据的切分方法来实现较好的扩展性，这就需要将上述两种切分方法结合使用，不同的场景使用不同的切分方法。

本节将结合垂直切分和水平切分各自的优缺点，进一步完善整体架构，并提高系统的扩展性。

一般来说，数据库中的所有表很难通过某一个（或少数几个）字段全部关联起来，所以仅仅通过数据的水平切分无法解决所有问题。而垂直切分也只能解决部分问题，对于那些负载非常高的系统，即使只是单个表都无法通过单台数据库主机来承担其负载。必须结合“垂直”和“水平”两种切分方式，充分利用两者的优点，避开其缺点。

每一个应用系统的负载都是一步一步增长上来的，在开始遇到性能瓶颈的时候，大多数架构师和DBA都会选择先进行数据的垂直拆分，因为这样的成本最低，最符合这个时期所追求的最大投入产出比。然而，随着业务的不断扩张，系统负载的持续增长，在系统稳定一段时期之后，经过了垂直拆分之后的数据库集群可能再次不堪重负，遇到了性能瓶颈。

此时该如何抉择？是再次进一步细分模块，还是寻求其他的解决办法？如果我们再像最开始那样继续细分模块，进行数据的垂直切分，那可能在不久的将来，又会遇到现在所面临的同样问题。而且随着模块的不断细化，应用系统的架构也会越来越复杂，整个系统很可能会出现失控的局面。

这时候就必须要利用数据水平切分的优势来解决遇到的问题。而且，完全不必在使用数据水平切分时，推倒之前进行数据垂直切分的成果，而是在其基础上利用水平切分的优势来避开垂直切分的弊端，解决系统复杂性不断扩大的问题。而水平拆分的弊端（规则难以统一）也已经被之前的垂直切分解决掉了，让水平切分可以进行得得心应手。

对于示例数据库，假设在最开始进行了数据的垂直切分，然而随着业务的不断增长，数据库系统遇到了瓶颈，我们选择重构数据库集群的架构。如何重构？考虑到之前已经做好了数据的垂直切分，而且模块结构清晰明确，而业务增长的势头越来越猛，即使现在再次拆分模块，也坚持不了太久。所以选择了在垂直切分的基础上再进行水平切分。

经历过垂直切分后的数据库集群中的各个数据库都只有一个功能模块，而每个功能模块中的所有表基本上都会与某个字段进行关联。如用户模块全部都可以通过用户ID进行切分，群组讨论模块则都通过群组ID来切分，相册模块则根据相册ID来进切分，最后的事件通知信息表考虑到数据的时限性（仅仅访问最近某个事件段的信息），则按时间来切分。

组合切分展示了切分后的整个架构：

实际上，在很多大型的应用系统中，垂直切分和水平切分基本上是并存的，而且经常在不断地交替进行，以增加系统的扩展能力。我们在应对不同的应用场景时，也须要充分考虑到这两种切分方法的局限及优势，在不同的时期（负载压力）使用不同的方式。

联合切分的优点：

可以充分利用垂直切分和水平切分各自的优势而避免各自的缺陷；
让系统扩展性得到最大化提升。

联合切分的缺点：

数据库系统架构比较复杂，维护难度更大；
应用程序架构也更复杂。
数据切分及整合方案

通过前面的章节，已经清楚了通过数据库的数据切分可以极大地提高系统的扩展性。但是，数据库中的数据经过垂直和（或）水平切分被存放在不同的数据库主机之后，应用系统面临的最大问题就是如何让这些数据源得到较好的整合，可能这也是很多读者非常关心的一个问题。本节主要的内容就是分析各种可以帮助我们实现数据切分及数据整合的整体解决方案。

阅读剩余部分