数据的拆分精编版Word文档格式.docx

1、水平切分于垂直切分相比，相对来说稍微复杂一些。因为要将同一个表中的不同数据拆分到不同的数据库中，对于应用程序来说，拆分规则本身就较根据表名来拆分更为复杂，后期的数据维护也会更为复杂一些。当我们某个（或者某些）表的数据量和访问量特别的大，通过垂直切分将其放在独立的设备上后仍然无法满足性能要求，这时候我们就必须将垂直切分和水平切分相结合，先垂直切分，然后再水平切分，才能解决这种超大型表的性能问题。下面我们就针对垂直、水平以及组合切分这三种数据切分方式的架构实现及切分后数据的整合进行相应的分析数据的垂直切分数据的垂直切分，也可以称之为纵向切分。将数据库想象成为由很多个一大块一大块的“数据块”（表）组

2、成，我们垂直的将这些“数据块”切开，然后将他们分散到多台数据库主机上面。这样的切分方法就是一个垂直（纵向）的数据切分。一个架构设计较好的应用系统，其总体功能肯定是由很多个功能模块所组成的，而每一个功能模块所需要的数据对应到数据库中就是一个或者多个表。而在架构设计中，各个功能模块相互之间的交互点越统一越少，系统的耦合度就越低，系统各个模块的维护性以及扩展性也就越好。这样的系统，实现数据的垂直切分也就越容易。当我们的功能模块越清晰，耦合度越低，数据垂直切分的规则定义也就越容易。完全可以根据功能模块来进行数据的切分，不同功能模块的数据存放于不同的数据库主机中，可以很容易就避免掉跨数据库的Join 存

3、在，同时系统架构也非常的清晰。所以，在数据库进行垂直切分的时候，如何切分，切分到什么样的程度，是一个比较考验人的难题。只能在实际的应用场景中通过平衡各方面的成本和收益，才能分析出一个真正适合自己的拆分方案如下图所示:通过这样的垂直切分之后，之前只能通过一个数据库来提供的服务，就被分拆成四个数据库来提供服务，服务能力自然是增加几倍了。垂直切分的优点: 数据库的拆分简单明了，拆分规则明确； 应用程序模块清晰明确，整合容易； 数据维护方便易行，容易定位；垂直切分的缺点： 部分表关联无法在数据库级别完成，需要在程序中完成； 对于访问极其频繁且数据量超大的表仍然存在性能平静，不一定能满足要求； 事务处理

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

5、依靠数据水平切分架构来解决了。数据的水平切分数据的垂直切分基本上可以简单的理解为按照表按照模块来切分数据，而水平切分就不再是按照表或者是功能模块来切分了。一般来说，简单的水平切分主要是将某个访问极其平凡的表再按照某个字段的某种规则来分散到多个表之中，每个表中包含一部分数据。简单来说，我们可以将数据的水平切分理解为是按照数据行的切分，就是将表中的某些行切分到一个数据库，而另外的某些行又切分到其他的数据库中。当然，为了能够比较容易的判定各行数据被切分到哪个数据库中了，切分总是都需要按照某种特定的规则来进行的。如根据某个数字类型字段基于特定数目取模，某个时间类型字段的范围，或者是某个字符类型字段的h

6、ash 值。如果整个系统中大部分核心表都可以通过某个字段来进行关联，那这个字段自然是一个进行水平分区的上上之选了，当然，非常特殊无法使用就只能另选其他了。一般来说，像现在互联网非常火爆的Web2.0 类型的网站，基本上大部分数据都能够通过会员用户信息关联上，可能很多核心表都非常适合通过会员ID 来进行数据的水平切分。而像论坛社区讨论系统，就更容易切分了，非常容易按照论坛编号来进行数据的水平切分。切分之后基本上不会出现各个库之间的交互。如我们的示例系统，所有数据都是和用户关联的，那么我们就可以根据用户来进行水平拆分，将不同用户的数据切分到不同的数据库中。当然，唯一有点区别的是用户模块中的grou

7、ps 表和用户没有直接关系，所以groups 不能根据用户来进行水平拆分。对于这种特殊情况下的表，我们完全可以独立出来，单独放在一个独立的数据库中。其实这个做法可以“数据的垂直切分”方法，后续介绍这种垂直切分与水平切分同时使用的联合切分方法。所以，对于我们的示例数据库来说，大部分的表都可以根据用户ID 来进行水平的切分。不同用户相关的数据进行切分之后存放在不同的数据库中。如将所有用户ID 通过2 取模然后分别存放于两个不同的数据库中。每个和用户ID 关联上的表都可以这样切分。这样，基本上每个用户相关的数据，都在同一个数据库中，即使是需要关联，也可以非常简单的关联上。我们可以通过下图来更为直观的

8、展示水平切分相关信息：水平切分的优点 表关联基本能够在数据库端全部完成； 不会存在某些超大型数据量和高负载的表遇到瓶颈的问题； 应用程序端整体架构改动相对较少； 事务处理相对简单； 只要切分规则能够定义好，基本上较难遇到扩展性限制；水平切分的缺点 切分规则相对更为复杂，很难抽象出一个能够满足整个数据库的切分规则； 后期数据的维护难度有所增加，人为手工定位数据更困难； 应用系统各模块耦合度较高，可能会对后面数据的迁移拆分造成一定的困难。垂直与水平联合切分的使用了解了“垂直”和“水平”这两种切分方式的实现以及切分之后的架构信息，同时也分析了两种架构各自的优缺点。但是在实际的应用场景中，除了那些负载

9、并不是太大，业务逻辑也相对较简单的系统可以通过上面两种切分方法之一来解决，扩展性问题之外，恐怕其他大部分业务逻辑稍微复杂一点，系统负载大一些的系统，都无法通过上面任何一种数据的切分方法来实现较好的扩展性，而需要将上述两种切分方法结合使用，不同的场景使用不同的切分方法。一般来说，我们数据库中的所有表很难通过某一个（或少数几个）字段全部关联起来，所以很难简单的仅仅通过数据的水平切分来解决所有问题。而垂直切分也只能解决部分问题，对于那些负载非常高的系统，即使仅仅只是单个表都无法通过单台数据库主机来承担其负载。我们必须结合“垂直”和“水平”两种切分方式同时使用，充分利用两者的优点，避开其缺点。每一个应

10、用系统的负载都是一步一步增长上来的，在开始遇到性能瓶颈的时候，大多数架构师和DBA 都会选择先进行数据的垂直拆分，因为这样的成本最先，最符合这个时期所追求的最大投入产出比。然而，随着业务的不断扩张，系统负载的持续增长，在系统稳定一段时期之后，经过了垂直拆分之后的数据库集群可能又再一次不堪重负，遇到了性能瓶颈。这时候我们该如何抉择？是再次进一步细分模块呢，还是寻求其他的办法来解决？如果我们再一次像最开始那样继续细分模块，进行数据的垂直切分，那我们可能在不久的将来，又会遇到现在所面对的同样的问题。而且随着模块的不断的细化，应用系统的架构也会越来越复杂，整个系统很可能会出现失控的局面这时候我们就必须

11、要通过数据的水平切分的优势，来解决这里所遇到的问题。而且，我们完全不必要在使用数据水平切分的时候，推倒之前进行数据垂直切分的成果，而是在其基础上利用水平切分的优势来避开垂直切分的弊端，解决系统复杂性不断扩大的问题。而水平拆分的弊端（规则难以统一）也已经被之前的垂直切分解决掉了，让水平拆分可以进行的得心应手。对于我们的示例数据库，假设在最开始，我们进行了数据的垂直切分，然而随着业务的不断增长，数据库系统遇到了瓶颈，我们选择重构数据库集群的架构。如何重构？考虑到之前已经做好了数据的垂直切分，而且模块结构清晰明确。而业务增长的势头越来越猛，即使现在进一步再次拆分模块，也坚持不了太久。我们选择了在垂直

12、切分的基础上再进行水平拆分。在经历过垂直拆分后的各个数据库集群中的每一个都只有一个功能模块，而每个功能模块中的所有表基本上都会与某个字段进行关联。如用户模块全部都可以通过用户ID 进行切分，群组讨论模块则都通过群组ID 来切分，相册模块则根据相册ID 来进切分，最后的事件通知信息表考虑到数据的时限性（仅仅只会访问最近某个事件段的信息），则考虑按时间来切分。下图展示了切分后的整个架构：实际上，在很多大型的应用系统中，垂直切分和水平切这两种数据的切分方法基本上都是并存的，而且经常在不断的交替进行，以不断的增加系统的扩展能力。我们在应对不同的应用场景的时候，也需要充分考虑到这两种切分方法各自的局限，

13、以及各自的优势，在不同的时期（负载压力）使用不同的结合方式。联合切分的优点 可以充分利用垂直切分和水平切分各自的优势而避免各自的缺陷； 让系统扩展性得到最大化提升；联合切分的缺点 数据库系统架构比较复杂，维护难度更大； 应用程序架构也相对更复杂；数据切分及整合方案数据库中的数据在经过垂直和（或）水平切分被存放在不同的数据库主机之后，应用系统面临的最大问题就是如何来让这些数据源得到较好的整合，分析可以使用的各种可以帮助我们实现数据切分以及数据整合的整体解决方案。数据的整合很难依靠数据库本身来达到这个效果，虽然MySQL 存在Federated 存储引擎，可以解决部分类似的问题，但是在实际应用场景

14、中却很难较好的运用。那我们该如何来整合这些分散在各个MySQL 主机上面的数据源呢？总的来说，存在两种解决思路：1. 在每个应用程序模块中配置管理自己需要的一个（或者多个）数据源，直接访问各个数据库，在模块内完成数据的整合；2. 通过中间代理层来统一管理所有的数据源，后端数据库集群对前端应用程序透明；可能90%以上的人在面对上面这两种解决思路的时候都会倾向于选择第二种，尤其是系统不断变得庞大复杂的时候。确实，这是一个非常正确的选择，虽然短期内需要付出的成本可能会相对更大一些，但是对整个系统的扩展性来说，是非常有帮助的。所以，对于第一种解决思路我这里就不准备过多的分析，下面我重点分析一下在第二种解决思路中的一些解决方案。自行开发中间代理层在决定选择通过数据库的中间代理层来解决数据源