数据表的水平拆分

一般人们分析问题，总是从问题现象，原因分析，解决方案这样的思路来分析思考问题，我想对这个数据库的水平拆分也按这样的思路来简单剖析一下。

        先从问题现象入手，随着数据库表中数据日积月累越来越多，当表记录数达到千万甚至亿级别时，数据库表的访问效率下降明显，导致外层应用的访问效率非常差，访问时间急剧上升，用户体验下降。如果是表数据太大的原因导致访问速度变慢，一般情况下当访问与此表相关业务时速度会很慢，而访问与此表无关的业务时速度会很快。

        分析上面的问题现象，明显的一个原因是因为某些表的数据记录太多的原因，导致数据库访问效率下降造成的。

        既然是某些表数据记录太多的原因，那我们的解决办法当然是让这些表的数据记录减少到不影响访问效率为止，同时为了考虑以后这些数据还是会不断的增长，为了让这些数据增长后还是可以扩展，那需要考虑如何可以将这些数据无限制的水平拆分，而不需要修改上层应用，一般来说只要设计得当，从理论上讲水平拆分都是可以无限扩展的。

        那我们先把记录数太多的表分成多张表，这时问题来了。

        1、对记录数多的表我们进行拆分，那对与之相关联的一些表该怎么办？这个问题其实也是现实开发中比较普遍的一个问题，现在数据库表一般都会与其他表有关联的。有人会提出一个方法就是所有的表都不与其他表关联，至少在SQL执行层面上如此，这样不就解决了数据或业务关联问题了啊，但这里有个问题那就是如果都按照这样在SQL层面完全解耦，而在应用层面再关联的话，会导致数据库访问次数增加很多，而且网络传输数据增加，比如A表和B表是关联表，如果在SQL 层面关联，则只执行一个SQL；如果在SQL层面独立，则需要执行两个SQL，分别查询出A表数据和B表数据，因为没有条件关联过滤，则数据肯定比执行关联SQL多很多，然后再在应用层进行关联。所以我个人觉得对性能要求高的系统中，还是需要使用SQL层面的关联的，但这里有一个原则肯定是要遵守，那就是不能让多个需要拆分表关联，因为这会导致拆分标准不一致而导致无法拆分。对关联SQL中的一个表需要拆分，其他都是相对静态的无需拆分的表，这种情况下的解决思路是将需拆分表拆分到多个库中，而静态表则同步到各个拆分库中。这里再上升一下，分析一下系统的表结构中，一般会分动态表（数据变化很大，数据量也可能很大的表）和静态表（数据变化很小的表，一般来说都是基础表，数据量也不会很大），将基础的静态表都放到一个公共库中，将动态表根据标准分拆到分库中，拆分完成后基础数据都在公共库维护，并同步到分库中，在分库中维护动态表，同时在查询时动态表可以与分库中静态表关联查询，这样就解决了这个问题。

        2、数据库表拆分的标准又是什么，按照什么来拆分？一般来说这个拆分标准可以按照数据范围分，比如1-100万一个表，100万-200万又是一个表；也可以按照时间顺序来拆分，比如一年的数据归到一张表中等；也可以按照地域范围来分，比如按照地市来分，每个或多个地市一个库等，反正这个个人觉得是按照具体的情况来分的，一般情况下，对带有较浓的分割标志的数据库表，可以根据分割标志来分割，对没有较浓分割标志的数据库表，则只能按照最笨的方法如数据范围来拆分了，有时候为了增加拆分质量，还可以先根据一个分割标志来分表，在根据另一个分割标志来分区等复合式的拆分方式来水平拆分数据库表。

        3、数据库表水平拆分后，访问数据库表的SQL必须要带上分割标志来确定目标数据库表，如果要对多个拆分数据库表进行查询，则需要通过多次访问数据库表来完成，同时在应用层面将数据合并来做到。但有时候，一般需要可以通过至少两种方式（或分割标志）来获取目标数据库表。举个例子，大型网络游戏中因为玩家太多了（比如达到几千万甚至亿级别时），所以将玩家的用户信息分库分表，当用户登录时，现在一般的做法都是会让用户自己选择是哪一区的，根据这个选择来确定目标数据库表，但如果我们改一下，用户不知道自己是哪一区的，只知道自己的用户编号，输入用户编号后需要由系统自动根据用户编号来路由到目标数据库表。在这种情况下，个人觉得需要有一个规则来保证用户编号的规律性，比如可以在用户申请时，针对选择的不同区来生成不同的用户编号，比如1区是 aaa+8位的顺序编号，2区是bbb+8位的顺序编号，这样的话，对aaa，bbb之类的分类编号是可以通过数据库表来管理的，比如用户编号是aaa开头和abc开头的都是1区的用户这样的规则就可以管理起来，这样当用户输入用户编号时，系统通过截取用户编号前三位，并到数据库表中查询出这前三位对应的哪个区，这样就可以获得这个用户的目标数据库表了。等到查询出这个用户信息后，这个用户信息中必定会存在分割标志信息的（这个例子中就是属于哪个区的），对这个用户信息缓存，就不再需要使用之前那种方式来确定目标数据库表了，而只需要根据缓存的用户信息中的属于哪个区的信息就可以来确定目标数据库表了。分析这两种确定目标数据库表的方式，一般来说前一种方式比较复杂，性能上消耗也较多，这种方式只有在第二种方式无法判断的情况下使用，所以使用频率相对来说非常低，而第二种方式则相对简单，而且性能也很好，这种方式是默认使用方式，使用频率相对来说非常高，但有时候因为信息不全无法使用第二种方式，所以必须要有前一种方式来补充使用。

        4、数据库水平拆分成多个库时，这时有一个事情是必须会碰到的，那就是数据库的连接。一般来说，应用服务器或应用系统对数据库连接的管理一般会通过连接池来管理，这样可以大大提高效率，而不会使用动态连接。这里就出来一个问题，当一个数据库水平拆分成多个数据库时，必然数据库连接池也会增加到多个，在一定范围内应该是不会有问题的，但毕竟应用服务器的性能也是有上限的，当数据库水平拆分成N个数据库时，应用服务器的性能就会吃不消了，这时候需要对应用服务器进行扩展了，比如一台应用服务器对应几个数据库连接等，当然这是比较深入的事情了，这里只把问题抛出来，不再多说。

        5、说到这里要说一下应用设计开发上的问题，首先是对目标数据库表路由模块必须要独立，如果路由不独立出来，那以后万一路由策略变更的话会死的很惨，而且路由算法是一个典型的策略模式应用，最好能实现成策略模式，以方便以后路由策略变更时应用可以无缝的切换路由策略。其次是对开发来说，最好能使用ibatis之类的持久层，既有一定的封装，也可以将SQL独立配置，这样在开发人员开发时，可以灵活的写SQL来实现逻辑，也可以对SQL语句进行管理，同时DBA可以很方便的对这些SQL进行专业的优化，而与应用开发无关。现在一些先行者已经在努力实现将数据库拆分的影响封装在代理中的项目，比如变形虫项目，这些项目的出现将会使数据库拆分后对应用开发的影响越来越小。最后一个是事务，如果可以接受分布式事务的性能那当然是最好的；如果不能接受，那一般的做法就是事务补偿（指在同一业务操作中当事务A提交，但事务B发生错误回滚后，为保持操作一致性和数据正确性，必须要做事务A操作的反操作来补偿事务A的提交，消除事务A的提交对数据结果的影响），但事务补偿会增加开发的工作量等问题；或者不是非常重要的业务操作时，通过保证事务B执行的成功率（比如先进行查询或预执行操作），从而使事务B的失败率下降到可以忽略的程度，从而可以不考虑事务的问题。

        6、还有一个非常重要的需要说一下，一般来说很多都是对原有系统的改造，这样的话就必然会有需要对原有数据的处理割接，这块工作也是非常重要的，数据库拆分方案做得最好，如果原有数据不能无缝的割接到新的拆分后的数据库中的话，那都是白搭。另外还有业务层面的问题，比如数据库表拆分引起的业务流程更改，业务操作习惯更改等方面的问题也要提早考虑和解决。

        总之，数据库表水平拆分是非常复杂的，需要综合各个方面考虑完善，套用网友 cauherk 的说法 “ 系统的切分是个很复杂的技术活，要综合考虑，而不仅仅从数据库层面考虑。 业务的使用、分库的原则、数据的割接、开发的侵入、可操作的易难程度、后期的管理等等都是需要考虑的因素。”