架构设计系统存储MySQL横向拆分与业务透明化.docxVIP

架构设计：系统存储MySQL横向拆分与业务透明化

使用MyCat配置横向拆分

之前文章中我们介绍了如何使用MyCat进行读写分离，类似的关系型数据库的读写分离存储方案可以在保持上层业务系统透明度的基础上满足70%业务系统的数据承载规模要求和性能要求。比起单纯使用LVS+Replicaion的读写分离方案而言最大的优势在于更能增加对上层业务系统的透明性。当然如果

您觉得单个MyCat节点在高可用范畴或者性能范畴上还需要增强，还可以使用Keepalived、LVS等组件在多个MyCat节点上组成高可用集群或者负载集群。

但是这个方案也有一个明显的问题，那就是它没有解决数据存储规模的瓶颈。如果单个节点上某个单表的数据规模超过了千万级，那么这个节点的读操作也会产生性能瓶颈。所以我们还需要进一步使用MyCat的分片技术对业务数据表进行横向拆分。

要说清楚MyCat对横向拆分的支持，就首先要说清楚关系型数据库横向拆分所面临的主要问题，以及MyCat为了解决这些问题所作的努力。总的来说横向拆分的所面临的问题主要分为两大类，一类是数据读的问题一类是数据写的问题。本节我们首先分析讨论一下数据读的问题，后文中介绍MyCat对分布式事务的支持时我们再来讨论横向拆分时的数据写问题。

4-3-1、数据分片中的数据读操作问题

selectTableA.*,TableB.xname,TableC.xcodefromTableA

leftjoinTableBonTableB.id=TableA.b_codeid

leftjoinTableConTableC.a_id=TableA.id

whereTableA.groupname=XXXX

以上查询语句是我们在业务系统数据查询的过程中经常使用的一种查询类型，是一种多个数据表进行左外连接的查询语句。其中TableA业务表拥有大量的数据且变化频率非常高，是需要进行拆分的主要数据表；TableB业务表可能是一张字典表，虽然它有比较大的数据，但远远没有达到千万级别并且变化频率很低（每天最多有10000次数据写操作）；TableC业务表中的数据量也很大，从技术角度上说该业务表可以做拆分也可以不做拆分，其中的TableC.a_id字段和TableA.id字段也是一种弱关联，也就是说TableC中的业务数据就算没有关联TableA中的业务数据也可以相对独立的工作。当然以上说的是一种可能的业务数据状态，实际情况还可能更复杂。

如果这些业务表同在一个数据库中，甚至是存在于同一个MySQL实例的不同数据库中，那么执行以上查询语句基本上没有什么难度，技术人员使用MySQL的执行计划也可以很清晰的看到查询语句的执行过程：

但是如果在分库状态下，那么查询过程就没有这么简单了。首先来说，主要需要进行数据拆分处理的TableA中的数据分布在不同的数据库中，这些数据库工作在不同的MySQL实例上。另外业务表TableC中的数据也进行了拆分，但是拆分时并没有参考和其可能有关联的TableA中的业务数据存储分片情况，也就是说原来已有的关联在拆分存储后可能就消失了，而且即使拆分后的数据关联还存在，但拆分前和拆分后执行数据排序操作的结构也可能是不同的。至于字典表TableB，由于可预见的时间内数据总规模不大，所以可以不进行拆分——所有拆分后的数据库中TableB数据表的数据内容完全一样。下图展示了一种数据表中数据进行随机拆分后可能的存储结构和产生的问题：

这样来看，数据表横向拆分过程中至少需要考虑以下读操作问题：

横向拆分后数据表之间的逻辑关联问题：数据表间存在各种关联，有的关联甚至还存在外键约束。数据拆分后的关联关系应该和拆分前的关联关系保持一致，至少应该保证通过数据库中间件查询得到的数据关联结果和拆分前的关联结果保持一致。

横向拆分后数据的排序和分页问题：由于数据拆分后，排序动作会分别在各个拆分后的数据库中单独执行，这可能就会导致拆分后的排序和分页结果和拆分前的结果不一致。那么数据库中间件需要保证能够将这些结果集合进行整合并还原成拆分前的排序和分页结果。

横向拆分后数据的分组操作问题：分组和统计操作同样存在和以上描述类似的问题，各个拆分后的数据库将单独执行分组和统计，这就可能导致用一个分区条件在各个拆分数据库中都有分组和统计结果。数据库中间件还是需要保证能够合并这些分组统计结果，并保证它们和拆分前的数据库操作结果一致。

4-3-2、全局表

在数据库的横向拆分过程中，各种数据字典表基本上不需要进行拆分。这是因为这些数据表的数据规模都不会太大且变化频率较低，另外一个原因是减少横向拆分后表关联操作的难度。类似省市县信息、手机区号信息、功能菜单信息等数据都应算作字典数据。根据实际工作经验，并不会出现所有业务表