逐步分表
和房子不够就需要重新建一处房子一样，当一个数据表记录太多太大，从而影响了查询效率的时候，我们就应该考虑分表，把新增的数据都保存到另一个表上，依次进行下去。和上面找人的问题一样，我们应该有一个什么样的策略来判断某个ID的记录在那个表上。这里有几种方式：
一：把记录ID和数据表名的对应关系保存在一个独立的表（找人问题中的本子）中，可是这样当记录很多的时候这个表的记录就会很多，虽然这个表结构很简单，但是也会影响到查询效率。还有就是在插入删除的时候都得关联这个表的操作，不方便。
二：一次性把现有的所有数据根据某个字段（通常是ID）按照某种规则重新散列到各个表（包括新建的）上。这样原有程序改动不大（如果设计合理的话，可能改动的只是一个配置的参数），而且每个表的访问压力相当（如果Hash规则足够随机的话），不过这一次性的数据迁移代价可能很高，有风险。
三：如果ID是一个自动自增主键，那么我们就可以把每个表的初始ID记录在配置文件里，这样我们的程序就很容易根据ID找到对应的数据表了。这种方法没有数据大规模迁移的麻烦，可是每个表的访问压力会有比较大的差别。
第一种显然是不能用的，第二种和第三种那种好点，就应该根据实际情况来确定（通常可能都是第三种好点）。
一次性分表
逐步分表的思想是在需要的时候，新增一个表，以保证查询效率。但是如果我们在系统设计的时候就可以对将来的数据量有一个比较准确的估计，我们就可以在一开始的时候就设计N个分表，如果这个N值较大的话，最好独立成一个数据库。在插入数据的时候，我们根据记录ID把数据Hash到某个表上，这样在操作数据的时候就可以根据ID来计算表名了。
这种做法很简单，省了很多功夫，不过需求并没有像预期的变化，原来的N值还是小了，这时就会比较麻烦，得执行逐步分表的步骤。而如果发现N值设置太大了，这样就会导致数据表利用率太低，有点浪费了资源。（例如，在mysql中myisam类型的数据表，一个表对应三个文件，这样N值太大就是说文件过多了，同样也会影响到效率）
分表带来的问题
对于很多的互联网应用，我们主要关注的是查询的优化（经常不惜以空间换时间），但是我们在查询的时候可能并不是只根据ID来查询，而且还通常需要分页。我们上面的分表却无法胜任这些，所以我们得另外想办法，例如把结果缓存起来（如内存表，文件，APC，Memcache等）。不过不管怎么缓存，总感觉有点别扭，不够完美。
假如有这样三个对象表：用户表，影片表和Tag表，他们各自对应的主键ID为：user_id，movie_id和tag_id，他们两两之间的对应关系是多对多的（例如一个用户可以收藏多个影片，可以为每个收藏的影片填写多个tag）。现在要做的就是可以根据其中的任一个对象来迅速查找其它两个对象的相关信息，数据表结构应该怎么样设计？
如果每次只是对一种ID进行分表，显然我们要建立三种散列表，如果考虑把散列表独立成库的话，就得用三个数据库，管理和操作都有一定的麻烦。后来灵光一闪，想到了一种比较好的解决方法：表中除了保存user_id，movie_id和tag_id外，另外加了一个flag字段，这四个字段组成组合主键（当然表还可以保存其他的信息，特别适合保存一些统计信息，排序的时候很有用）。其中flag字段标志此记录是根据哪种ID进行散列的，不妨设flag=1时根据user_id散列，flag=2时根据movie_id散列，flag=3时根据tag_id散列。
这时假如我们要根据movie_id查找关联的用户和tag_id，这时我们的where条件可以这样写：
SELECT * FROM {$table} WHERE movie_id='{$movie_id}' AND flag='2' ...
（注：假设我们根据movie_id的值计算得到相应的Hash表名为$table，实际上这也是很容易得到的。）
其他的两种也一样，这显然对查询很有利。当然这样设计之后，对数据的增删改操作就有点麻烦了（通过把对散列表的操作封装在一个类里面可以减少很多麻烦），不过为了查询效率的提升，这种牺牲应该还是值得的。
一些思考
接触关系数据库越多，就越发现关系数据库也有不少的局限，例如在查询效率和并发连接数方面，关系数据库通常会比key-value型数据库（例如MemcacheDB，Tokyo Tyrant，Bigtable等）差很多，而且key-value型数据库很容易和Memcache结合，以实现持久化存储，从而很容易做到分布式存储。也许以后会有人考虑开发一种专门存储JSON格式的数据库，呵呵～
还有就是，以前觉得Mysql很小，相比那些SQL Server，甚至oracle等等，但是现在觉得Mysql已经很庞然大物了，于是有人要给mysql瘦身，弄了个Drizzle出来。（就像我们觉得apache已经是庞然大物了，所以我们弄了很多轻量级的服务器，如Lighthttpd，Nginx等，来实现相应特定的功能）
当然，所有的这些并不是说关系数据库已经“死了”，而只是细化了分工，从而弥补了关系数据库某些方面的不足。所以总的来说，“关系数据库已死”这样的论断还有点言之过早了。
来源：http://blog.csdn.net/yycai/article/details/4423882
2.1.3怎么做到数据切分
说到数据切分，再次我们讲对数据切分的方法和形式进行比较详细的阐述和说明。
数据切分可以是物理 上的，对数据通过一系列的切分规则将数据分布到不同的DB服务器上，通过路由规则路由访问特定的数据库，这样一来每次访问面对的就不是单台服务器了，而是N台服务器，这样就可以降低单台机器的负载压力。
数 据切分也可以是数据库内的 ，对数据通过一系列的切分规则，将数据分布到一个数据库的不同表 中，比如将article分为article_001,article_002等子表，若干个子表水平拼合有组成了逻辑上一个完整的article表，这 样做的目的其实也是很简单的。 举个例子说明，比如article表中现在有5000w条数据，此时我们需要在这个表中增加（insert）一条新的数 据，insert完毕后，数据库会针对这张表重新建立索引，5000w行数据建立索引的系统开销还是不容忽视的。但是反过来，假如我们将这个表分成100 个table呢，从article_001一直到article_100，5000w行数据平均下来，每个子表里边就只有50万行数据，这时候我们向一张 只有50w行数据的table中insert数据后建立索引的时间就会呈数量级的下降，极大了提高了DB的运行时效率，提高了DB的并发量。当然分表的好 处还不知这些，还有诸如写操作的锁操作等，都会带来很多显然的好处。
综上，分库降低了单点机器的负载；分表，提高了数据操作的效率，尤其是Write操作的效率。 行文至此我们依然没有涉及到如何切分的问题。接下来，我们将对切分规则进行详尽的阐述和说明。
上文中提到，要想做到数据的水平切分，在每一个表中都要有相冗余字符 作为切分依据和标记字段，通常的应用中我们选用user_id作为区分字段，基于此就有如下三种分库的方式和规则： （当然还可以有其他的方式）
按号段分：
(1) user_id为区分，1～1000的对应DB1，1001～2000的对应DB2，以此类推；
优点：可部分迁移
缺点：数据分布不均
(2)hash取模分：
对user_id进行hash（或者如果user_id是数值型的话直接使用user_id 的值也可），然后用一个特定的数字，比如应用中需要将一个数据库切分成4个数据库的话，我们就用4这个数字对user_id的hash值进行取模运算，也 就是user_id%4,这样的话每次运算就有四种可能：结果为1的时候对应DB1；结果为2的时候对应DB2；结果为3的时候对应DB3；结果为0的时 候对应DB4，这样一来就非常均匀的将数据分配到4个DB中。
优点：数据分布均匀
缺点：数据迁移的时候麻烦，不能按照机器性能分摊数据
(3)在认证库中保存数据库配置
就是建立一个DB，这个DB单独保存user_id到DB的映射关系，每次访问数据库的时候都要先查询一次这个数据库，以得到具体的DB信息，然后才能进行我们需要的查询操作。
优点：灵活性强，一对一关系
缺点：每次查询之前都要多一次查询，性能大打折扣
以上就是通常的开发中我们选择的三种方式， 有些复杂的项目中可能会混合使用这三种方式。 通过上面的描述，我们对分库的规则也有了简单的认识和了解。当然还会有更好更完善的分库方式，还需要我们不断的探索和发现。
分布式数据方案提供功能如下：
（1）提供分库规则和路由规则（RouteRule简称RR），将上面的说明中提到的三中切分规则直接内嵌入本系统，具体的嵌入方式在接下来的内容中进行详细的说明和论述；
（2）引入集群（Group）的概念，保证数据的高可用性；
（3）引入负载均衡策略（LoadBalancePolicy简称LB）；
（4）引入集群节点可用性探测机制，对单点机器的可用性进行定时的侦测，以保证LB策略的正确实施，以确保系统的高度稳定性；
（5）引入读/写分离，提高数据的查询速度；
仅仅是分库分表的数据层设计也是不够完善的，当某个节点上的DB服务器出现了宕机的情况的时 候，会是什么样的呢？是的，我们采用了数据库切分方案，也就是说有N太机器组成了一个完整的DB ，如果有一台机器宕机的话，也仅仅是一个DB的N分之一的 数据不能访问而已，这是我们能接受的，起码比切分之前的情况好很多了，总不至于整个DB都不能访问。一般的应用中，这样的机器故障导致的数据无法访问是可 以接受的，假设我们的系统是一个高并发的电子商务网站呢？单节点机器宕机带来的经济损失是非常严重的。也就是说，现在我们这样的方案还是存在问题的，容错 性能是经不起考验的。当然了，问题总是有解决方案的。我们引入集群的概念，在此我称之为Group，也就是每一个分库的节点我们引入多台机器，每台机器保 存的数据是一样的，一般情况下这多台机器分摊负载，当出现宕机情况，负载均衡器将分配负载给这台宕机的机器。这样一来，
就解决了容错性的问题。所以我们引入了集群的概念，并将其内嵌入我们的框架中，成为框架的一部分。
如上图所示： ，整个数据层有Group1，Group2，Group3三个集群组成，这三个集 群就是数据水平切分的结果，当然这三个集群也就组成了一个包含完整数据的DB。 每一个Group包括1个Master（当然Master也可以是多个）和 N个Slave，这些Master和Slave的数据是一致的。 比如Group1中的一个slave发生了宕机现象，那么还有两个slave是可以用的 ，这样的模型总是不会造成某部分数据不能访问的问题，除非整个 Group里的机器全部宕掉，但是考虑到这样的事情发生的概率非常小（除非是断电了，否则不易发生吧）。
在没有引入集群以前，我们的一次查询的过程大致如下：请求数据层，并传递必要的分库区分字段 （通常情况下是user_id）?数据层根据区分字段Route到具体的DB?在这个确定的DB内进行数据操作。
这是没有引入集群的情况，当时引入集群会 是什么样子的呢？看图一即可得知，我们的路由器上规则和策略其实只能路由到具体的Group，也就是只能路由到一个虚拟的Group，这个Group并不 是某个特定的物理服务器。接下来需要做的工作就是找到具体的物理的DB服务器，以进行具体的数据操作。基于这个环节的需求，我们引入了负载均衡器的概念 （LB）。负载均衡器的职责就是定位到一台具体的DB服务器。 具体的规则如下：负载均衡器会分析当前sql的读写特性，如果是写操作或者是要求实时性很强 的操作的话，直接将查询负载分到Master，如果是读操作则通过负载均衡策略分配一个Slave。我们的负载均衡器的主要研究放向也就是负载分发策略， 通常情况下负载均衡包括随机负载均衡和加权负载均衡 。 随机负载均衡很好理解，就是从N个Slave中随机选取一个Slave。这样的随机负载均衡是不考虑 机器性能的，它默认为每台机器的性能是一样的。假如真实的情况是这样的，这样做也是无可厚非的。假如实际情况并非如此呢？ 每个Slave的机器物理性能和 配置不一样的情况，再使用随机的不考虑性能的负载均衡，是非常不科学的，这样一来会给机器性能差的机器带来不必要的高负载，甚至带来宕机的危险， 同时高性 能的数据库服务器也不能充分发挥其物理性能。基于此考虑从，我们引入了加权负载均衡，也就是在我们的系统内部通过一定的接口，可以给每台DB服务器分配一 个权值，然后再运行时LB根据权值在集群中的比重，分配一定比例的负载给该DB服务器。当然这样的概念的引入，无疑增大了系统的复杂性和可维护性。有得必 有失，我们也没有办法逃过的。
有了分库，有了集群，有了负载均衡器，是不是就万事大吉了呢？ 事情远没有我们想象的那么简 单。虽然有了这些东西，基本上能保证我们的数据层可以承受很大的压力 ，但是这样的设计并不能完全规避数据库宕机的危害。假如Group1中的slave2 宕机了，那么系统的LB并不能得知，这样的话其实是很危险的，因为LB不知道，它还会以为slave2为可用状态，所以还是会给slave2分配负载。这 样一来，问题就出来了，客户端很自然的就会发生数据操作失败的错误或者异常。这样是非常不友好的！怎样解决这样的问题呢？ 我们引入集群节点的可用性探测机 制 ，或者是可用性的数据推送机制 。这两种机制有什么不同呢？首先说探测机制吧，顾名思义，探测即使，就是我的数据层客户端，不定时对集群中各个数据库进行 可用性的尝试，实现原理就是尝试性链接，或者数据库端口的尝试性访问，都可以做到，当然也可以用JDBC尝试性链接，利用Java的Exception机 制进行可用性的判断，具体的会在后面的文字中提到。那数据推送机制又是什么呢？其实这个就要放在现实的应用场景中来讨论这个问题了，一般情况下应用的DB 数据库宕机的话我相信DBA肯定是知道的，这个时候DBA手动的将数据库的当前状态通过程序的方式推送到客户端，也就是分布式数据层的应用端，这个时候在 更新一个本地的DB状态的列表。并告知LB，这个数据库节点不能使用，请不要给它分配负载。一个是主动的监听机制，一个是被动的被告知的机制。两者各有所 长。但是都可以达到同样的效果。这样一来刚才假设的问题就不会发生了，即使就是发生了，那么发生的概率也会降到最低。
来源：http://zhengdl126.iteye.com/blog/419850 （重要参考）
水平切分数据库，可以降低单台机器的负载，同时最大限度的降低了了宕机造成的损失。
通过负载均衡策略，有效的降低了单台 机器的访问负载，降低了宕机的可能性；
通过集群方案，解决了数据库宕机带来的单点数据库不能访问的问题；
通过读写分离策略更是最大限度了提高了应用中读取 （Read）数据的速度和并发量。