mysql数据库分库分表(Sharding)（转）

mysql数据库切分

前言

经过MySQLReplication功能所实现的扩展老是会受到数据库大小的限制。一旦数据库过于庞大，尤为是当写入过于频繁，很是难由一台主机支撑的时候，咱们仍是会面临到扩展瓶颈。这时候，咱们就必须许找其它技术手段来解决这个瓶颈，那就是咱们这一章所要介绍恶的数据切分技术。

 

何谓数据切分

可能很是多读者朋友在网上或者杂志上面都已经屡次见到关于数据切分的相关文章了，仅仅只是在有些文章中称之为数据的Sharding。事实上不管是称之为数据的Sharding仍是数据的切分，其概念都是同样的。

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

数据的切分（Sharding）依据其切分规则的类型。可以分为两种切分模式。

一种是依照不一样的表（或者Schema）来切分到不一样的数据库（主机）之上，这样的切可以称之为数据的垂直（纵向）切分。另一种则是依据表中的数据的逻辑关系，将同一个表中的数据依照某种条件拆分到多台数据库（主机）上面。这样的切分称之为数据的水平（横向）切分。

 

垂直切分的最大特色就是规则简单，实施也更为方便，尤为适合各业务之间的耦合度很是低。相互影响很是小，业务逻辑很是清晰的系统。在这样的系统中，可以很是easy作到将不一样业务模块所使用的表分拆到不一样的数据库中。依据不一样的表来进行拆分。对应用程序的影响也更小，拆分规则也会比較简单清晰。

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

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

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

 

 

数据的垂直切分

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

一个架构设计较好的应用系统。其整体功能确定是由很是多个功能模块所组成的。而每个功能模块所需要的数据对应到数据库中就是一个或者多个表。

而在架构设计中，各个功能模块相互之间的交互点越统一越少，系统的耦合度就越低，系统各个模块的维护性以及扩展性也就越好。这样的系统。实现数据的垂直切分也就越easy。

当咱们的功能模块越清晰，耦合度越低，数据垂直切分的规则定义也就越easy。全然可以依据功能模块来进行数据的切分，不一样功能模块的数据存放于不一样的数据库主机中，可以很是easy就避免掉跨数据库的Join存在。同一时候系统架构也很是的清晰。

固然。很是难有系统可以作到所有功能模块所使用的表全然独立，全然不需要訪问对方的表或者需要两个模块的表进行Join操做。这样的状况下，咱们就必须依据实际的应用场景进行评估权衡。决定是迁就应用程序将需要Join的表的相关某快都存放在同一个数据库中，仍是让应用程序作不少其它的事情，也就是程序全然经过模块接口取得不一样数据库中的数据，而后在程序中完毕Join操做。

通常来讲。假设是一个负载相对不是很是大的系统，而且表关联又很是的频繁。那可能数据库让步。将几个相关模块合并在一块儿下降应用程序的工做的方案可以下降较多的工做量。是一个可行的方案。

固然。经过数据库的让步，让多个模块集中共用数据源，实际上也是简单介绍的默许了各模块架构耦合度增大的发展，可能会让之后的架构愈来愈恶化。尤为是当发展到必定阶段以后，发现数据库实在没法承担这些表所带来的压力。不得不面临再次切分的时候。所带来的架构改形成本可能会远远大于最初的时候。

因此。在数据库进行垂直切分的时候，怎样切分，切分到什么样的程度，是一个比較考验人的难题。仅仅能在实际的应用场景中经过平衡各方面的成本和收益。才干分析出一个真正适合本身的拆分方案。

 

比方在本书所使用演示样例系统的example数据库，咱们简单的分析一下。而后再设计一个简单的切分规则，进行一次垂直垂直拆分。

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

1. 用户模块表：user,user_profile,user_group,user_photo_album

2. 群组讨论表：groups,group_message,group_message_content,top_message

3. 相冊相关表：photo,photo_album,photo_album_relation,photo_comment

4. 事件信息表：event

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

固然不是，咱们再略微深刻分析一下，可以发现，尽管各个模块所使用的表之间都有关联，但是关联关系还算比較清晰，也比較简单。

◆群组讨论模块和用户模块之间主要存在经过用户或者是群组关系来进行关联。通常关联的时候都会是经过用户的id或者nick_name以及group的id来进行关联。经过模块之间的接口实现不会带来太多麻烦。

◆相冊模块仅仅与用户模块存在经过用户的关联。这两个模块之间的关联基本就有经过用户id关联的内容。简单清晰，接口明白；

◆ 事件模块与各个模块可能都有关联，但是都仅仅关注其各个模块中对象的ID信息，相同可以作到很是easy分拆。

 

因此。咱们第一步可以将数据库依照功能模块相关的表进行一次垂直拆分。每个模块所涉及的表单独到一个数据库中，模块与模块之间的表关联都在应用系统端经过藉口来处理。例如如下图所看到的：

经过这样的垂直切分以后。以前仅仅能经过一个数据库来提供的服务。就被分拆成四个数据库来提供服务，服务能力天然是添加几倍了。

垂直切分的长处

◆ 数据库的拆分简单明了，拆分规则明白；

◆ 应用程序模块清晰明白，整合easy。

◆ 数据维护方便易行，easy定位。

垂直切分的缺点

◆ 部分表关联没法在数据库级别完毕。需要在程序中完毕。

◆ 对于訪问极其频繁且数据量超大的表仍然存在性能平静，不必定能知足要求。

◆ 事务处理相对更为复杂；

◆ 切分达到必定程度以后，扩展性会遇到限制；

◆ 过读切分可能会带来系统过渡复杂而难以维护。

针对于垂直切分可能遇到数据切分及事务问题，在数据库层面实在是很是难找到一个较好的处理方案。实际应用案例中，数据库的垂直切分大可能是与应用系统的模块相对应，同一个模块的数据源存放于同一个数据库中，可以解决模块内部的数据关联问题。而模块与模块之间，则经过应用程序以服务接口方式来相互提供所需要的数据。

尽管这样作在数据库的整体操做次数方面确实会有所添加，但是在系统整体扩展性以及架构模块化方面，都是故意的。可能在某些操做的单次响应时间会稍有添加。但是系统的整体性能很是可能反而会有必定的提高。而扩展瓶颈问题。就仅仅能依靠下一节将要介绍的数据水平切分架构来攻克了。

 

数据的水平切分

上面一节分析介绍了数据的垂直切分，这一节再分析一下数据的水平切分。数据的垂直切分基本上可以简单的理解为依照表依照模块来切分数据，而水平切分就再也不是依照表或者是功能模块来切分了。通常来讲，简单的水平切分主要是将某个訪问极其平庸的表再依照某个字段的某种规则来分散到多个表之中。每个表中包括一部分数据。

 

简单来讲。咱们可以将数据的水平切分理解为是依照数据行的切分。就是将表中的某些行切分到一个数据库，而另外的某些行又切分到其它的数据库中。固然，为了可以比較easy的断定各行数据被切分到哪一个数据库中了，切分老是都需要依照某种特定的规则来进行的。

如依据某个数字类型字段基于特定数目取模，某个时间类型字段的范围。或者是某个字符类型字段的hash值。假设整个系统中大部分核心表都可以经过某个字段来进行关联。那这个字段天然是一个进行水平分区的上上之选了，固然，很是特殊没法使用就仅仅能另选其它了。

通常来讲，像现在互联网很是火爆的Web2.0类型的站点。基本上大部分数据都可以经过会员用户信息关联上，可能很是多核心表都很是适合经过会员ID来进行数据的水平切分。

而像论坛社区讨论系统。就更easy切分了，很是easy依照论坛编号来进行数据的水平切分。

切分以后基本上不会出现各个库之间的交互。

如咱们的演示样例系统。所有数据都是和用户关联的。那么咱们就可以依据用户来进行水平拆分，将不一样用户的数据切分到不一样的数据库中。固然，惟一有点差异的是用户模块中的groups表和用户没有直接关系。因此groups不能依据用户来进行水平拆分。对于这样的特殊状况下的表，咱们全然可以独立出来。单独放在一个独立的数据库中。

事实上这个作法可以说是利用了前面一节所介绍的“数据的垂直切分”方法。我将在下一节中更为具体的介绍这样的垂直切分与水平切分同一时候使用的联合切分方法。

因此，对于咱们的演示样例数据库来讲，大部分的表都可以依据用户ID来进行水平的切分。不一样用户相关的数据进行切分以后存放在不一样的数据库中。如将所有用户ID经过2取模而后分别存放于两个不一样的数据库中。

每个和用户ID关联上的表都可以这样切分。这样，基本上每个用户相关的数据。都在同一个数据库中，即便是需要关联，也可以很是简单的关联上。

 

咱们可以经过下图来更为直观的展现水平切分相关信息：水平切分的长处

◆ 表关联基本可以在数据库端所有完毕；

◆ 不会存在某些超大型数据量和高负载的表遇到瓶颈的问题；

◆ 应用程序端整体架构修改相对较少；

◆ 事务处理相对简单；

◆ 仅仅要切分规则可以定义好。基本上较难遇到扩展性限制；

水平切分的缺点

◆ 切分规则相对更为复杂，很是难抽象出一个可以知足整个数据库的切分规则；

◆ 后期数据的维护难度有所添加，人为手工定位数据更困难；

◆ 应用系统各模块耦合度较高，可能会对后面数据的迁移拆分形成必定的困难。

 

 

垂直与水平切分的联合使用

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

在这一节中。我将结合垂直切分和水平切分各自的优缺点，进一步无缺咱们的整体架构，让系统的扩展性进一步提升。

 

通常来讲。咱们数据库中的所有表很是难经过某一个（或少数几个）字段所有关联起来，因此很是难简单的仅仅经过数据的水平切分来解决所有问题。而垂直切分也仅仅能解决部分问题，对于那些负载很是高的系统，即便仅仅仅仅是单个表都没法经过单台数据库主机来承担其负载。

咱们必须结合“垂直”和“水平”两种切分方式同一时候使用，充分利用二者的长处，避开其缺点。

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

这时候咱们该怎样抉择？是再次进一步细分模块呢，仍是寻求其它的办法来解决？假设咱们再一次像最開始那样继续细分模块，进行数据的垂直切分，那咱们可能在不久的未来，又会遇到现在所面对的相同的问题。而且随着模块的不断的细化，应用系统的架构也会愈来愈复杂，整个系统很是可能会出现失控的局面。

 

这时候咱们就必需要经过数据的水平切分的优点，来解决这里所遇到的问题。而且，咱们全然没必要要在使用数据水平切分的时候，推倒以前进行数据垂直切分的成果，而是在其基础上利用水平切分的优点来避开垂直切分的弊端。解决系统复杂性不断扩大的问题。

而水平拆分的弊端（规则难以统一）也已经被以前的垂直切分解决掉了。让水平拆分可以进行的驾轻就熟。

对于咱们的演示样例数据库。假设在最開始。咱们进行了数据的垂直切分，然而随着业务的不断增加，数据库系统遇到了瓶颈，咱们选择重构数据库集群的架构。怎样重构？考虑到以前已经作好了数据的垂直切分，而且模块结构清晰明白。

而业务增加的势头愈来愈猛。即便现在进一步再次拆分模块，也坚持不了过久。

咱们选择了在垂直切分的基础上再进行水平拆分。

 

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

下图展现了切分后的整个架构：

实际上，在很是多大型的应用系统中，垂直切分和水平切这两种数据的切分方法基本上都是并存的。而且常常在不断的交替进行，以不断的添加系统的扩展能力。咱们在应对不一样的应用场景的时候，也需要充分考虑到这两种切分方法各自的局限，以及各自的优点。在不一样的时期（负载压力）使用不一样的结合方式。

联合切分的长处

◆ 可以充分利用垂直切分和水平切分各自的优点而避免各自的缺陷；

◆ 让系统扩展性获得最大化提高。

联合切分的缺点

◆ 数据库系统架构比較复杂。维护难度更大。

◆ 应用程序架构也相对更复杂；

 

数据切分及整合方案

经过前面的章节。咱们已经很是清晰了经过数据库的数据切分可以极大的提升系统的扩展性。但是，数据库中的数据在通过垂直和（或）水平切分被存放在不一样的数据库主机以后，应用系统面临的最大问题就是怎样来让这些数据源获得较好的整合。可能这也是很是多读者朋友很是关心的一个问题。这一节咱们主要针对的内容就是分析可以使用的各类可以帮助咱们实现数据切分以及数据整合的整体解决方式。

数据的整合很是难依靠数据库自己来达到这个效果，尽管MySQL存在Federated存储引擎，可以解决部分类似的问题。但是在实际应用场景中却很是难较好的运用。那咱们该怎样来整合这些分散在各个MySQL主机上面的数据源呢？

总的来讲，存在两种解决思路：

1. 在每个应用程序模块中配置管理本身需要的一个（或者多个）数据源。直接訪问各个数据库，在模块内完毕数据的整合；

2. 经过中间代理层来统一管理所有的数据源。后端数据库集群对前端应用程序透明；

可能90%以上的人在面对上面这两种解决思路的时候都会倾向于选择另一种，尤为是系统不断变得庞大复杂的时候。

确实。这是一个很是正确的选择，尽管短时间内需要付出的成本可能会相对更大一些，但是对整个系统的扩展性来讲，是很是有帮助的。

 

因此，对于第一种解决思路我这里就不许备过多的分析，如下我重点分析一下在另一种解决思路中的一些解决方式。

★ 自行开发中间代理层

在决定选择经过数据库的中间代理层来解决数据源整合的架构方向以后，有很多公司（或者企业）选择了经过自行开发符合自身应用特定场景的代理层应用程序。

经过自行开发中间代理层可以最大程度的应对自身应用的特定。最大化的定制很是多个性化需求，在面对变化的时候也可以灵活的应对。这应该说是自行开发代理层最大的优点了。

固然，选择自行开发，享受让个性化定制最大化的乐趣的同一时候，天然也需要投入不少其它的成原本进行前期研发以及后期的持续升级改进工做。而且自己的技术门槛可能也比简单的Web应用要更高一些。因此，在决定选择自行开发以前，仍是需要进行比較全面的评估为好。

 

因为自行开发不少其它时候考虑的是怎样更好的适应自身应用系统，应对自身的业务场景，因此这里也很差分析太多。后面咱们主要分析一下当前比較流行的几种数据源整合解决方式。

 

★利用MySQLProxy实现数据切分及整合

MySQLProxy是MySQL官方提供的一个数据库代理层产品，和MySQLServer同样，相同是一个基于GPL开源协议的开源产品。可用来监视、分析或者传输他们之间的通信信息。他的灵活性赞成你最大限度的使用它，眼下具有的功能主要有链接路由，Query分析，Query过滤和修改，负载均衡。以及主要的HA机制等。

实际上，MySQLProxy自己并不具备上述所有的这些功能。而是提供了实现上述功能的基础。

要实现这些功能，还需要经过咱们自行编写LUA脚原本实现。

MySQLProxy其实是在client请求与MySQLServer之间创建了一个链接池。所有client请求都是发向MySQLProxy，而后经由MySQLProxy进行对应的分析。推断出是读操做仍是写操做，分发至对应的MySQLServer上。对于多节点Slave集群，也可以起作到负载均衡的效果。如下是MySQLProxy的基本架构图：

经过上面的架构简图。咱们可以很是清晰的看出MySQLProxy在实际应用中所处的位置，以及能作的基本事情。

关于MySQLProxy更为具体的实施细则在MySQL官方文档中有很是具体的介绍和演示样例。感兴趣的读者朋友可以直接从MySQL官方站点免费下载或者在线阅读，我这里就不累述浪费纸张了。

 

★利用Amoeba实现数据切分及整合

Amoeba是一个基于Java开发的，专一于解决分布式数据库数据源整合Proxy程序的开源框架，基于GPL3开源协议。眼下，Amoeba已经具备Query路由，Query过滤，读写分离，负载均衡以及HA机制等相关内容。

Amoeba 主要解决的如下几个问题：

1. 数据切分后复杂数据源整合；

2. 提供数据切分规则并下降数据切分规则给数据库带来的影响。

3. 下降数据库与client的链接数。

4. 读写分离路由；

咱们可以看出，Amoeba所作的事情，正好就是咱们经过数据切分来提高数据库的扩展性所需要的。

Amoeba并不是一个代理层的Proxy程序，而是一个开发数据库代理层Proxy程序的开发框架，眼下基于Amoeba所开发的Proxy程序有AmoebaForMySQL和AmoebaForAladin两个。

 

AmoebaForMySQL主要是专门针对MySQL数据库的解决方式，前端应用程序请求的协议以及后端链接的数据源数据库都必须是MySQL。对于client的不论什么应用程序来讲，AmoebaForMySQL和一个MySQL数据库没有什么差异。不论什么使用MySQL协议的client请求，都可以被AmoebaForMySQL解析并进行对应的处理。下如可以告诉咱们AmoebaForMySQL的架构信息（出自Amoeba开发人员博客）：

AmoebaForAladin则是一个适用更为普遍。功能更为强大的Proxy程序。

他可以同一时候链接不一样数据库的数据源为前端应用程序提供服务，但是仅仅接受符合MySQL协议的client应用程序请求。也就是说，仅仅要前端应用程序经过MySQL协议链接上来以后，AmoebaForAladin会本身主动分析Query语句，依据Query语句中所请求的数据来本身主动识别出该所Query的数据源是在什么类型数据库的哪个物理主机上面。下图展现了AmoebaForAladin的架构细节（出自Amoeba开发人员博客）：

咋一看，二者好像全然同样嘛。细看以后，才会发现二者主要的差异仅在于经过MySQLProtocalAdapter处理以后。依据分析结果推断出数据源数据库。而后选择特定的JDBC驱动和对应协议链接后端数据库。

事实上经过上面两个架构图你们可能也已经发现了Amoeba的特色了，他仅仅仅仅是一个开发框架。咱们除了选择他已经提供的ForMySQL和ForAladin这两款产品以外。还可以基于自身的需求进行对应的二次开发。获得更适应咱们本身应用特色的Proxy程序。

当对于使用MySQL数据库来讲。不管是AmoebaForMySQL仍是AmoebaForAladin都可以很是好的使用。固然，考虑到不论什么一个系统越是复杂，其性能确定就会有必定的损失，维护成本天然也会相对更高一些。因此，对于仅仅需要使用MySQL数据库的时候，我仍是建议使用AmoebaForMySQL。

AmoebaForMySQL的使用很是简单，所有的配置文件都是标准的XML文件，总共同拥有四个配置文件。分别为：

◆amoeba.xml：主配置文件，配置所有数据源以及Amoeba自身的參数设置。

◆rule.xml：配置所有Query路由规则的信息。

◆functionMap.xml：配置用于解析Query中的函数所对应的Java实现类；

◆ rullFunctionMap.xml：配置路由规则中需要使用到的特定函数的实现类；

假设您的规则不是太复杂，基本上仅需要使用到上面四个配置文件里的前面两个就可完毕所有工做。Proxy程序常用的功能如读写分离。负载均衡等配置都在amoeba.xml中进行。此外。Amoeba已经支持了实现数据的垂直切分和水平切分的本身主动路由。路由规则可以在rule.xml进行设置。

眼下Amoeba少有欠缺的主要就是其在线管理功能以及对事务的支持了，之前在与相关开发人员的沟经过程中提出过相关的建议，但愿可以提供一个可以进行在线维护管理的命令行管理工具，方便在线维护使用，获得的反馈是管理专门的管理模块已经归入开发日程了。另外在事务支持方面临时仍是Amoeba没法作到的，即便client应用在提交给Amoeba的请求是包括事务信息的，Amoeba也会忽略事务相关信息。固然，在通过不断无缺以后，我相信事务支持确定是Amoeba重点考虑添加的feature。

关于Amoeba更为具体的用法读者朋友可以经过Amoeba开发人员博客（http://amoeba.sf.net）上面提供的使用手冊获取，这里就再也不细述了。

 

★利用HiveDB实现数据切分及整合

和前面的MySQLProxy以及Amoeba同样，HiveDB相同是一个基于Java针对MySQL数据库的提供数据切分及整合的开源框架，仅仅是眼下的HiveDB仅仅支持数据的水平切分。

主要解决大数据量下数据库的扩展性及数据的高性能訪问问题，同一时候支持数据的冗余及主要的HA机制。

 

HiveDB的实现机制与MySQLProxy和Amoeba有必定的差别，他并不是借助MySQL的Replication功能来实现数据的冗余，而是自行实现了数据冗余机制，而其底层主要是基于HibernateShards来实现的数据切分工做。

在HiveDB中，经过用户本身定义的各类Partitionkeys（事实上就是制定数据切分规则），将数据分散到多个MySQLServer中。在訪问的时候。在执行Query请求的时候。会本身主动分析过滤条件，并行从多个MySQLServer中读取数据，并合并结果集返回给client应用程序。

单纯从功能方面来说，HiveDB可能并不如MySQLProxy和Amoeba那样强大，但是其数据切分的思路与前面两者并没有本质差别。此外，HiveDB并不只仅仅仅是一个开源爱好者所共享的内容，而是存在商业公司支持的开源项目。

 

如下是HiveDB官方站点上面一章图片，描写叙述了HiveDB怎样来组织数据的基本信息，尽管不能具体的表现出太多架构方面的信息，但是也基本可以展现出其在数据切分方面独特的一面了。

★ mycat 数据整合：具体http://www.songwie.com/articlelist/11

★ 其它实现数据切分及整合的解决方式

除了上面介绍的几个数据切分及整合的整体解决方式以外，还存在很是多其它相同提供了数据切分与整合的解决方式。如基于MySQLProxy的基础上作了进一步扩展的HSCALE，经过Rails构建的SpockProxy。以及基于Pathon的Pyshards等等。

不管你们选择使用哪种解决方式，整体设计思路基本上都不该该会有不论什么变化。那就是经过数据的垂直和水平切分，加强数据库的整体服务能力，让应用系统的整体扩展能力尽量的提高。扩展方式尽量的便捷。

仅仅要咱们经过中间层Proxy应用程序较好的攻克了数据切分和数据源整合问题。那么数据库的线性扩展能力将很是easy作到像咱们的应用程序同样方便。仅仅需要经过加入便宜的PCServerserver，就能够线性添加数据库集群的整体服务能力，让数据库再也不轻易成为应用系统的性能瓶颈。

 

 

 

数据切分与整合可能存在的问题

这里。你们应该对数据切分与整合的实施有了必定的认识了。也许很是多读者朋友都已经依据各类解决方式各自特性的优劣基本选定了适合于本身应用场景的方案，后面的工做主要就是实施准备了。

 

在实施数据切分方案以前，有些可能存在的问题咱们仍是需要作一些分析的。

通常来讲，咱们可能遇到的问题主要会有如下几点：

◆ 引入分布式事务的问题。

◆跨节点Join的问题；

◆ 跨节点合并排序分页问题。

 

1. 引入分布式事务的问题

一旦数据进行切分被分别存放在多个MySQLServer中以后，不管咱们的切分规则设计的多么的完美（实际上并不存在完美的切分规则），均可能形成以前的某些事务所涉及到的数据已经不在同一个MySQLServer中了。

在这样的场景下，假设咱们的应用程序仍然依照老的解决方式。那么势必需要引入分布式事务来解决。而在MySQL各个版本号中，仅仅有从MySQL5.0開始之后的各个版本号才開始对分布式事务提供支持，而且眼下仅有Innodb提供分布式事务支持。不只如此。即便咱们恰好使用了支持分布式事务的MySQL版本号。同一时候也是使用的Innodb存储引擎，分布式事务自己对于系统资源的消耗就是很是大的，性能自己也并不是过高。而且引入分布式事务自己在异常处理方面就会带来较多比較难控制的因素。

怎么办？事实上咱们可以可以经过一个变通的方法来解决这样的问题。首先需要考虑的一件事情就是：是否数据库是惟一一个可以解决事务的地方呢？事实上并不是这样的，咱们全然可以结合数据库以及应用程序二者来共同解决。各个数据库解决本身身上的事务。而后经过应用程序来控制多个数据库上面的事务。

也就是说。仅仅要咱们愿意。全然可以将一个跨多个数据库的分布式事务分拆成多个仅处于单个数据库上面的小事务。并经过应用程序来总控各个小事务。

固然，这样做的要求就是咱们的俄应用程序必需要有足够的健壮性。固然也会给应用程序带来一些技术难度。

 

2.跨节点Join的问题

上面介绍了可能引入分布式事务的问题，现在咱们再看看需要跨节点Join的问题。

数据切分以后。可能会形成有些老的Join语句没法继续使用。因为Join使用的数据源可能被切分到多个MySQLServer中了。

怎么办？这个问题从MySQL数据库角度来看，假设非得在数据库端来直接解决的话，恐怕仅仅能经过MySQL一种特殊的存储引擎Federated来攻克了。Federated存储引擎是MySQL解决类似于Oracle的DBLink之类问题的解决方式。

和OracleDBLink的主要差异在于Federated会保存一份远端表结构的定义信息在本地。咋一看，Federated确实是解决跨节点Join很是好的解决方式。但是咱们还应该清晰一点，那就彷佛假设远端的表结构发生了变动，本地的表定义信息是不会跟着发生对应变化的。假设在更新远端表结构的时候并无更新本地的Federated表定义信息。就很是可能形成Query执行出错，没法获得正确的结果。

 

对待这类问题，我仍是推荐经过应用程序来进行处理，先在驱动表所在的MySQLServer中取出对应的驱动结果集。而后依据驱动结果集再到被驱动表所在的MySQLServer中取出对应的数据。可能很是多读者朋友会以为这样作对性能会产生必定的影响，是的，确实是会对性能有必定的负面影响，但是除了此法，基本上没有太多其它更好的解决的方法了。

而且，因为数据库经过较好的扩展以后，每台MySQLServer的负载就可以获得较好的控制。单纯针对单条Query来讲，其响应时间可能比不切分以前要提升一些，因此性能方面所带来的负面影响也并不是太大。更况且。类似于这样的需要跨节点Join的需求也并不是太多。相对于整体性能而言，可能也仅仅是很是小一部分而已。因此为了整体性能的考虑，偶尔牺牲那么一点点。事实上是值得的。毕竟系统优化自己就是存在很是多取舍和平衡的过程。

 

3. 跨节点合并排序分页问题

一旦进行了数据的水平切分以后，可能就并不只仅仅仅有跨节点Join没法正常执行，有些排序分页的Query语句的数据源可能也会被切分到多个节点。这样形成的直接后果就是这些排序分页Query没法继续正常执行。事实上这和跨节点Join是一个道理。数据源存在于多个节点上，要经过一个Query来解决，就和跨节点Join是同样的操做。相同Federated也可以部分解决。固然存在的风险也同样。

仍是相同的问题，怎么办？我相同仍然继续建议经过应用程序来解决。

 

怎样解决？解决的思路大致上和跨节点Join的解决类似，但是有一点和跨节点Join不太同样。Join很是多时候都有一个驱动与被驱动的关系。因此Join自己涉及到的多个表之间的数据读取通常都会存在一个顺序关系。但是排序分页就不太同样了，排序分页的数据源基本上可以说是一个表（或者一个结果集）。自己并不存在一个顺序关系，因此在从多个数据源取数据的过程是全然可以并行的。

这样。排序分页数据的取数效率咱们可以作的比跨库Join更高。因此带来的性能损失相对的要更小，在有些状况下可能比在原来未进行数据切分的数据库中效率更高了。

固然，不管是跨节点Join仍是跨节点排序分页。都会使咱们的应用server消耗不少其它的资源，尤为是内存资源，因为咱们在读取訪问以及合并结果集的这个过程需要比原来处理不少其它的数据。

分析到这里，可能很是多读者朋友会发现，上面所有的这些问题，我给出的建议基本上都是经过应用程序来解决。你们可能内心開始犯嘀咕了。是否是因为我是DBA，因此就很是多事情都扔给应用架构师和开发人员了？

事实上全然不是这样，首先应用程序因为其特殊性。可以很是easy作到很是好的扩展性，但是数据库就不同。必须借助很是多其它的方式才干作到扩展。而且在这个扩展过程当中，很是难避免带来有些原来在集中式数据库中可以解决但被切分开成一个数据库集群以后就成为一个难题的状况。

要想让系统整体获得最大限度的扩展，咱们仅仅能让应用程序作不少其它的事情。来解决数据库集群没法较好解决的问题。

 

 

小结

经过数据切分技术将一个大的MySQLServer切分红多个小的MySQLServer，既攻克了写入性能瓶颈问题，同一时候也再一次提高了整个数据库集群的扩展性。不管是经过垂直切分，仍是水平切分。都可以让系统遇到瓶颈的可能性更小。尤为是当咱们使用垂直和水平相结合的切分方法以后，理论上将不会再遇到扩展瓶颈了。

 

转自：http://songwie.com/