数据库分表

   

垂直切分的长处

数据库的拆分简单明了，拆分规则明白；

应用程序模块清晰明白，整合easy。

数据维护方便易行，easy定位。

垂直切分的缺点

部分表关联无法在数据库级别完毕。须要在程序中完毕。

对于访问极其频繁且数据量超大的表仍然存在性能平静，不一定能满足要求。

事务处理相对更为复杂；

切分达到一定程度之后，扩展性会遇到限制；

过度切分可能会带来系统过度复杂而难以维护

 

数据的水平切分

我们能够将数据的水平切分理解为是依照数据行的切分。就是将表中的某些行切分到一个数据库，而另外的某些行又切分到其它的数据库中。当然，为了能够比较easy的判定各行数据被切分到哪个数据库中了，切分总是都须要依照某种特定的规则来进行的。

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

水平切分的长处

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

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

◆ 应用程序端总体架构修改相对较少；

◆ 事务处理相对简单；

◆ 仅仅要切分规则能够定义好。基本上较难遇到扩展性限制；

水平切分的缺点

◆ 切分规则相对更为复杂，非常难抽象出一个能够满足整个数据库的切分规则；

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

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

 

 

数据切分及整合方案

mycat AmoebaForMySQL HiveDB MySQLProxy

当我们的应用只需要一台数据库服务器的时候我们并不需要Mycat，而如果你需要分库甚至分表，这时候应用要面对很多个数据库的时候，这个时候就需要对数据库层做一个抽象，来管理这些数据库

数据库是对底层存储文件的抽象，而Mycat是对数据库的抽象。

 

 

 

数据切分与整合可能存在的问题

一般来说，我们可能遇到的问题主要会有以下几点：

◆ 引入分布式事务的问题。

◆跨节点Join的问题；

◆ 跨节点合并排序分页问题

 

 

1. 引入分布式事务的问题

一旦数据进行切分被分别存放在多个MySQLServer中之后，无论我们的切分规则设计的多么的完美（实际上并不存在完美的切分规则），都可能造成之前的某些事务所涉及到的数据已经不在同一个MySQLServer中了。

在这样的场景下，假设我们的应用程序仍然依照老的解决方式。那么势必须要引入分布式事务来解决。而在MySQL各个版本号中，仅仅有从MySQL5.0開始以后的各个版本号才開始对分布式事务提供支持，并且眼下仅有Innodb提供分布式事务支持。不仅如此。即使我们刚好使用了支持分布式事务的MySQL版本号。同一时候也是使用的Innodb存储引擎，分布式事务本身对于系统资源的消耗就是非常大的，性能本身也并非太高。并且引入分布式事务本身在异常处理方面就会带来较多比較难控制的因素。

怎么办？事实上我们能够能够通过一个变通的方法来解决这样的问题。首先须要考虑的一件事情就是：是否数据库是唯一一个能够解决事务的地方呢？事实上并非这样的，我们全然能够结合数据库以及应用程序两者来共同解决。各个数据库解决自己身上的事务。然后通过应用程序来控制多个数据库上面的事务。

也就是说。仅仅要我们愿意。全然能够将一个跨多个数据库的分布式事务分拆成多个仅处于单个数据库上面的小事务。并通过应用程序来总控各个小事务。

当然，这样作的要求就是我们的俄应用程序必须要有足够的健壮性。当然也会给应用程序带来一些技术难度。

 

2.跨节点Join的问题

上面介绍了可能引入分布式事务的问题，如今我们再看看须要跨节点Join的问题。

数据切分之后。可能会造成有些老的Join语句无法继续使用。由于Join使用的数据源可能被切分到多个MySQLServer中了。

怎么办？这个问题从MySQL数据库角度来看，假设非得在数据库端来直接解决的话，恐怕仅仅能通过MySQL一种特殊的存储引擎Federated来攻克了。Federated存储引擎是MySQL解决相似于Oracle的DBLink之类问题的解决方式。

和OracleDBLink的主要差别在于Federated会保存一份远端表结构的定义信息在本地。咋一看，Federated确实是解决跨节点Join非常好的解决方式。可是我们还应该清晰一点，那就似乎假设远端的表结构发生了变更，本地的表定义信息是不会跟着发生对应变化的。假设在更新远端表结构的时候并没有更新本地的Federated表定义信息。就非常可能造成Query执行出错，无法得到正确的结果。

对待这类问题，我还是推荐通过应用程序来进行处理，先在驱动表所在的MySQLServer中取出对应的驱动结果集。然后依据驱动结果集再到被驱动表所在的MySQLServer中取出对应的数据。可能非常多读者朋友会觉得这样做对性能会产生一定的影响，是的，确实是会对性能有一定的负面影响，可是除了此法，基本上没有太多其它更好的解决的方法了。

并且，由于数据库通过较好的扩展之后，每台MySQLServer的负载就能够得到较好的控制。单纯针对单条Query来说，其响应时间可能比不切分之前要提高一些，所以性能方面所带来的负面影响也并非太大。更何况。相似于这样的须要跨节点Join的需求也并非太多。相对于总体性能而言，可能也仅仅是非常小一部分而已。所以为了总体性能的考虑，偶尔牺牲那么一点点。事实上是值得的。毕竟系统优化本身就是存在非常多取舍和平衡的过程。

 

3. 跨节点合并排序分页问题

一旦进行了数据的水平切分之后，可能就并不仅仅仅仅有跨节点Join无法正常执行，有些排序分页的Query语句的数据源可能也会被切分到多个节点。这样造成的直接后果就是这些排序分页Query无法继续正常执行。事实上这和跨节点Join是一个道理。数据源存在于多个节点上，要通过一个Query来解决，就和跨节点Join是一样的操作。相同Federated也能够部分解决。当然存在的风险也一样。

还是相同的问题，怎么办？我相同仍然继续建议通过应用程序来解决。

怎样解决？解决的思路大体上和跨节点Join的解决相似，可是有一点和跨节点Join不太一样。Join非常多时候都有一个驱动与被驱动的关系。所以Join本身涉及到的多个表之间的数据读取一般都会存在一个顺序关系。可是排序分页就不太一样了，排序分页的数据源基本上能够说是一个表（或者一个结果集）。本身并不存在一个顺序关系，所以在从多个数据源取数据的过程是全然能够并行的。

这样。排序分页数据的取数效率我们能够做的比跨库Join更高。所以带来的性能损失相对的要更小，在有些情况下可能比在原来未进行数据切分的数据库中效率更高了。

当然，不论是跨节点Join还是跨节点排序分页。都会使我们的应用server消耗很多其它的资源，尤其是内存资源，由于我们在读取訪问以及合并结果集的这个过程须要比原来处理很多其它的数据。