数据库分库分表(sharding).doc

一、基本思想 Sharding 的基本思想就要把一个数据库切分成多个部分放到不同的数据库(server) 上,从而缓解单一数据库的性能问题。对于海量数据的数据库,如果是因为表多而数据多,这时候适合使用垂直切分,即把关系紧密(比如同一模块)的表切分出来放在一个服务器上。如果表并不多,但每张表的数据非常多, 这时候适合水平切分,即把表的数据按某种规则(比如按 ID 散列)切分到多个数据库(server) 上。根据实际情况做出选择,也可能会综合使用垂直与水平切分。 1、垂直切分数据的垂直切分,也可以称之为纵向切分。将数据库想象成为由很多个一大块一大块的“数据块”(表)组成,我们垂直的将这些数据块切开,然后将他们分散到多台数据库主机上面,这样的切分方法就是一个垂直(纵向)的数据切分。系统功能可以基本分为以下四个功能模块:用户、群组消息、相册以及事件,分别对应为如下这些表: 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 、 ment 4. 事件信息表 event 模块之间的关系: 1. 群组讨论模块和用户模块之间主要存在通过用户或者是群组关系来进行关联。一般关联的时候都会是通过用户 id 或者 nick_name 以及 grou p 的id 来进行关联,,通过模块之间的接口实现不会带来太多麻烦。 2. 相册模块仅仅与用户模块存在通过用户的关联。这两个模块之间的关联基本就有通过用户 id 关联的内容,简单清晰,接口明确。 3. 事件模块与各个模块可能都有关联,但是都只关注其各个模块中对象的信息 ID ,同样可以做到很容易分拆。所以,我们第一步可以将数据库按照功能模块相关的表进行一次垂直拆分, 每个模块涉及的表单独到一个数据库中,模块与模块之间的表关联都在应用系统端通过接口来处理。如下图所示: 通过这样的垂直切分之后,之前只能通过一个数据库来提供的服务,就被分拆成四个数据库来提供服务,服务能力自然是增加几倍了。垂直切分的优点?数据库的拆分简单明了,拆分规则明确?应用程序模块清晰明确,整合容易?数据维护方便易行,容易定位垂直切分的缺点?部分表关联无法在数据库级别完成,需要在程序中完成?对于访问极其频繁且数据量超大的表仍然存在性能平静,不一定能满足要求?事务处理相对更为复杂?切分达到一定程度之后,扩展性会遇到限制?过度切分可能会带来系统过渡复杂而难以维护 2、水平切分数据的水平切分,一般来说,简单的水平切分主要是将某个访问极其平凡的表再按照某个字段的某种规则来分散到多个表之中,每个表中包含一部分数据。简单来说,我们可以将数据的水平切分理解为是按照数据行的切分,就是将表中的某些行切分到一个数据库,而另外的某些行又切分到其他的数据库中。对于我们的示例数据库来说,大部分的表都可以根据用户 ID 来进行水平的切分,不同用户相关的数据进行切分之后存放在不同的数据库中。如将所有用户 ID 通过 2 取模,然后分别存放于两个不同的数据库中,每个和用户 ID 关联上的表都可以这样切分。这样,基本上每个用户相关的数据,都在同一个数据库中, 即使是需要关联,也可以非常简单的关联上。我们可以通过下图来更为直观的展示水平切分相关信息: 水平切分的优点?表关联基本能够在数据库端全部完成?不会存在某些超大型数据量和高负载的表遇到瓶颈的问题?应用程序端整体架构改动相对较少?事务处理相对简单?只要切分规则能够定义好,基本上较难遇到扩展性限制水平切分的缺点?切分规则相对更为复杂,很难抽象出一个能够满足整个数据库的切分规则?后期数据的维护难度有所增加,人为手工定位数据更困难?应用系统各模块耦合度较高,可能会对后面数据的迁移拆分造成一定的困难 3、垂直与水平联合切分一般来说,我们数据库中的所有表很难通过某一个(或少数几个)字段全部关联起来,所以很难简单的仅仅通过数据的水平切分来解决所有问题。而垂直切分也只能解决部分问题,对于那些负载非常高的系统,即使仅仅只是单个表都无法通过单台数据库主机来承担其负载,我们必须结合“水平”和“垂直”两种切分方式同时使用,充分利用两者的优点,避开其缺点。每一个应用系统的负载都是一步一步增长上来的,在开始遇到性能瓶颈的时候,大多数架构师和 DBA 都会选择先进行数据的垂直拆分,然而,随着业务的不断扩张,系统负载的持续增长,在系统稳定一段时期之后,经过了垂直拆分之后的数据库集群可能又再一次不堪重负,遇到了性能瓶颈。这时候我们就必须要通过数据的水平切分的优