mysql数据切分

垂直切分     

        一个架构设计较好的应用系统。其总体功能肯定是由非常多个功能模块所组成的。而每一个功能模块所须要的数据对应到数据库中就是一个或者多个表。而在架构设计中，各个功能模块相互之间的交互点越统一越少，系统的耦合度就越低，系统各个模块的维护性以及扩展性也就越好。这样的系统。实现数据的垂直切分也就越easy。

        比方在本书所使用演示样例系统的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分拆。

        所以。我们第一步能够将数据库依照功能模块相关的表进行一次垂直拆分。每一个模块所涉及的表单独到一个数据库中，模块与模块之间的表关联都在应用系统端通过藉口来处理。

        垂直拆分优点：数据库的拆分简单明了，拆分规则明白；应用程序模块清晰明白；数据维护方便易行

        垂直拆分缺点： 部分表关联无法在数据库级别完毕。须要在程序中完毕；对于訪问极其频繁且数据量超大的表仍然存在性能平静，不一定能满足要求；事务处理相对更为复杂；

 

水平切分

        数据的垂直切分基本上能够简单的理解为依照表依照模块来切分数据，而水平切分就不再是依照表或者是功能模块来切分了。一般来说，简单的水平切分主要是将某个訪问极其平庸的表再依照某个字段的某种规则来分散到多个表之中。每一个表中包括一部分数据。

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

水平切分优点：表关联基本能够在数据库端全部完毕；事务处理相对简单；不会存在某些超大型数据量和高负载的表遇到瓶颈的问题；

水平切分缺点：切分规则相对更为复杂，非常难抽象出一个能够满足整个数据库的切分规则；后期数据的维护难度有所添加，人为手工定位数据更困难；