数据拆分.doc

何谓数据切分 就是指通过某种特定的条件，将我们存放在同一个 数据库中的数据分散存放到多个数据库（主机）上面，以达到分散单台设备负载的效果。数据的切分同时还可以提高系统的总体可用性，因为单台设备Crash 之后，只有总体数据的 某部分不可用，而不是所有的数据。 数据的切分（Sharding）根据其切分规则的类型，可以分为两种切分模式。一种是按照 不同的表（或者Schema）来切分到不同的数据库（主机）之上，这种切可以称之为数据的 垂直（纵向）切分；另外一种则是根据表中的数据的逻辑关系，将同一个表中的数据按照某 种条件拆分到多台数据库（主机）上面，这种切分称之为数据的水平（横向）切分。 垂直切分的最大特点就是规则简单，实施也更为方便，尤其适合各业务之间的耦合度非 常低，相互影响很小，业务逻辑非常清晰的系统。在这种系统中，可以很容易做到将不同业 务模块所使用的表分拆到不同的数据库中。根据不同的表来进行拆分，对应用程序的影响也 更小，拆分规则也会比较简单清晰。 水平切分于垂直切分相比，相对来说稍微复杂一些。因为要将同一个表中的不同数据拆 分到不同的数据库中，对于应用程序来说，拆分规则本身就较根据表名来拆分更为复杂，后 期的数据维护也会更为复杂一些。 当我们某个（或者某些）表的数据量和访问量特别的大，通过垂直切分将其放在独立的 设备上后仍然无法满足性能要求，这时候我们就必须将垂直切分和水平切分相结合，先垂直 切分，然后再水平切分，才能解决这种超大型表的性能问题。 下面我们就针对垂直、水平以及组合切分这三种数据切分方式的架构实现及切分后数据 的整合进行相应的分析 数据的垂直切分 数据的垂直切分，也可以称之为纵向切分。将数据库想象成为由很多个一大块一大块的“数据块”（表）组成，我们垂直的将这些“数据块”切开，然后将他们分散到多台数据库主机上面。这样的切分方法就是一个垂直（纵向）的数据切分。 一个架构设计较好的应用系统，其总体功能肯定是由很多个功能模块所组成的，而每一 个功能模块所需要的数据对应到数据库中就是一个或者多个表。而在架构设计中，各个功能 模块相互之间的交互点越统一越少，系统的耦合度就越低，系统各个模块的维护性以及扩展 性也就越好。这样的系统，实现数据的垂直切分也就越容易。 当我们的功能模块越清晰，耦合度越低，数据垂直切分的规则定义也就越容易。完全可 以根据功能模块来进行数据的切分，不同功能模块的数据存放于不同的数据库主机中，可以 很容易就避免掉跨数据库的Join 存在，同时系统架构也非常的清晰。 所以，在数据库进行垂直切分的时候，如何切分，切分到什么样的程度，是一个比较考 验人的难题。只能在实际的应用场景中通过平衡各方面的成本和收益，才能分析出一个真正 适合自己的拆分方案 如下图所示: 通过这样的垂直切分之后，之前只能通过一个数据库来提供的服务，就被分拆成四个数 据库来提供服务，服务能力自然是增加几倍了。 垂直切分的优点: ◆ 数据库的拆分简单明了，拆分规则明确； ◆ 应用程序模块清晰明确，整合容易； ◆ 数据维护方便易行，容易定位； 垂直切分的缺点： ◆ 部分表关联无法在数据库级别完成，需要在程序中完成； ◆ 对于访问极其频繁且数据量超大的表仍然存在性能平静，不一定能满足要求； ◆ 事务处理相对更为复杂； ◆ 切分达到一定程度之后，扩展性会遇到限制； ◆ 过读切分可能会带来系统过渡复杂而难以维护。 对于垂直切分可能遇到数据切分及事务问题，在数据库层面实在是很难找到一个较好 的处理方案。实际应用案例中，数据库的垂直切分大多是与应用系统的模块相对应，同一个 模块的数据源存放于同一个数据库中，可以解决模块内部的数据关联问题。而模块与模块之 间，则通过应用程序以服务接口方式来相互提供所需要的数据。虽然这样做在数据库的总体 操作次数方面确实会有所增加，但是在系统整体扩展性以及架构模块化方面，都是有益的。 可能在某些操作的单次响应时间会稍有增加，但是系统的整体性能很可能反而会有一定的提 升。而扩展瓶颈问题，就只能依靠数据水平切分架构来解决了。 数据的水平切分 数据的垂直切分基本上可以简单的理解为按照表按照模块来切分数据，而水平切分就不再是按照表或者是功能模块来切分了。一般来说，简单的水平切分主要是将某个访问极其平凡的表再按照某个字段的某种规则来分散到多个表之中，每个表中包含一部分数据。 简单来说，我们可以将数据的水平切分理解为是按照数据行的切分，就是将表中的某些 行切分到一个数据库，而另外的某些行又切分到其他的数据库中。当然，为了能够比较容易 的判定各行数据被切分到哪个数据库中了，切分总是都需要按照某种特定的规则来进行的。 如根据某个数字类型字段基于特定数目取模，某个时间类型字段的范围，或者是某个字符类 型字段的hash 值。如果整个系统