爱威尔-数据库分区分库分表演变过程（mysql为例）

<img src="74/20161004000535_352.png" alt=""> 
 
 
 这个话题说实话 到现在为止没有什么非常好的通用解决办法，我们先不说大公司他们都是怎么做的，也很少人知道，就市面上或者网络上面的文章来看，说有一个产品对于数据库拆分做得很好的 几乎没有，也许是我知道的少，这话且不说，我们还是分析一下数据库拆分的演变过程，也好让我们理解为什么这个问题会难倒我们。 
   
 言归正传，我们就从最基本的说起：刚开始一个应用，我们就设计了一个数据库，里面包含所有的表结构，系统做出来之后没什么问题运行都很正常。过了一两年发现系统越来越慢，而且发现数据增量很快，如果数据库正好是用的mysql这种级别的数据库（这里说一下，mysql相对于oracle和db2，数据量在百万千万级别性能就出现大的问题了）。另外为什么使用mysql  更多考虑的还是成本问题，这个在这里不谈。 
   
 这个时候就要考虑读写分离、主从复制这种简单快速的提升性能的办法，主从复制mysql（我们这里就以mysql为例）到现在为止不管是第三方的中间件（Galera Cluster for MySQL 、、 等等）  还是mysql官方的都做得不错了 尤其是mysql5.7之后。在mysql复制这个问题上解决方法很多，基本都可以做到主从、主主、一主多从、多主一从(多源复制mysql5.7新特性)等不同需求，在实现上面都不复杂，很容易配置实现。对于读写分离更多的是代码层面的考虑，你可以自己实现 ，也可以用第三方中间件，目前做得比较好的是mycat(就读写分离这点上来说)。其实就读写分离来过 自己实现的可能会更适合自己的业务需求，我们可以想想 读写分离 就是要分开读操作和写操作，让读操作和写操作去访问不同机器上的数据库，从而达到读写都可以提高性能的目的。 
   
 如果在主从和读写分离基础上业务还是在高速增长，数据增速仍然很快，接下来要做的就是垂直分库，也就是把之前的一个数据库拆分为多个数据库，分散存放数据，每一个数据库中存放的数据库表都是业务关联比较紧密的数据，在此基础上我们还可以做主从和读写分离，这样一来，之前的单个数据库带来的性能压力我们就这样分解了。这样做相对简单容易实现，代码改动也不是很大，我们仅仅是多了几个数据库而已，其实在读写分离时我们已经是多数据源了。 
   
 这个时候如果业务数据还是持续增加，我们还可以来个彻底做法就是 单库单表。一个数据库一个表，当然这种做法显示可能很难做到，这很显然因为业务决定了单库单表的难度，这个地方能做到最好，做不到我们就做分区。分区对于mysql来说也很容易实现，最重要的是分区之后的处理不需要代码来管理而是数据库本身来管理，也就是说分区之后，我们的业务代码不需要做任何调整改动，而是数据库自身负责管理分区，虽然我们需要过一些管理数据库的工作，但是如果我们对分区管理得好，维护起来也是很方便的。分区给我们带来的好处是非常明显的既满足了业务数据的不断增长，而且我们为分区投入的代码改动和数据库维护都是最低的。 
   
 到了这个时候数据的增速还是很快，那就不得不使用终极方法了水平分表(其实还有垂直分表，但是垂直分表好像解决不了数据增速的问题这里暂且不谈)，水平分表就是把数据分散，这里就涉及分布式了，所以它可以满足数据增长的需求，为什么说这个方案是终极的呢？就是因为分布式，一旦做到分布式，那就是走到了终点，这里说的终点是相对于数据增速来说的，那么在分布式领域那就无穷无尽了，在这点上来说可能是未来几年我们需要重点解决的大问题。回到正题，对于分表目前可以说没有什么中间件做的非常好的，大家都在努力包括官方的MySQL Fabric、mycat等等。最关键的还是分布式事务这块，这个是另一个非常重要的话题，我们可以抽时间单独好好聊聊。还包括分表之后的数据管理，分布式数据库管理等等。 
   
 最后说一下数据库集群和高可用HA，在这两点上来说目前的解决方案还是很多的，而且都能满足需求比如 集群有galera for mysql 、MySQL Cluster 等高可用有 keepalived 、lvs、HAProxy等，最后提一下mycat这个可能是国内用的比较多，相对比较好用的中间件。