数据的水平切分

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

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

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

    如果系统的所有数据都是和用户关联的，那么就可以根据用户来进行水平拆分，将不同用户的数据切分到不同的数据库中。当然，唯一区别是用户模块中的groups表和用户没有直接关系，所以groups不能根据用户来进行水平拆分。对于这种特殊情况下的表，完全可以独立出来，放在一个独立的数据库中。

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

    水平切分的有点：

    1）表关联基本能够在数据库端全部完成；

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

    3）应用程序端整体架构改动相对较少；

    4）事务处理相对简单；

    5）只要切分规则能够定义好，基本上较难遇到扩展性限制。

    水平切分的缺点：

    1）切分规则相对复杂，很难抽象出一个能够满足整个数据库的切分规则；

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

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