mysql之大型数据库优化方案

方案名称：数据切分 


数据切分的概念：
通过一系列的切分规则将数据水平分布到不同的DB或table中，在通过相应的DB路由 或者 table路由规则找到需要查询的具体的DB或者table，以进行Query操作。这里所说的“sharding”通常是指“水平切分”。


实例：有如下字段的表格
article_id(int),title(varchar(128)),content(varchar(1024)),user_id(int)


实现存储格式：
我们可以这样做，将user_id为 1～10000的所有的文章信息放入DB1中的article表中，将user_id为10001～20000的所有文章信息放入DB2中的 article表中，以此类推，一直到DBn。 


DB路由的概念：
也就是我们知道了这个blog的user_id，就利用这个user_id，利用分库时候的规则，反过来定位具体的数据库，比如user_id是234，利用该才的规则，就应该定位到DB1，假如user_id是12343，利用该才的规则，就应该定位到DB2。以此类推，利用分库的规则，反向的路由到具体的DB，这个过程我们称之为“DB路由”


oracle不可取的原因：费用过高。


主从数据库的设计缺点：
首先它的有效很依赖于读操作的比例，Master往往会成为瓶颈所在，写操作需要顺序排队来执行，过载的话Master首先扛不住，Slaves的数据同步的延迟也可能比较大，而且会大大耗费CPU的计算能力，因为write操作在Master上执行以后还是需要在每台slave机器上都跑一次。这时候 Sharding可能会成为鸡肋了。


如何实现切分：


 方式一：数据切分可以是物理 上的，对数据通过一系列的切分规则将数据分布到不同的DB服务器上，通过路由规则路由访问特定的数据库，这样一来每次访问面对的就不是单台服务器了，而是N台服务器，这样就可以降低单台机器的负载压力。


 方式二：数 据切分也可以是数据库内的 ，对数据通过一系列的切分规则，将数据分布到一个数据库的不同表中，比如将article分为article_001,article_002等子表，若干个子表水平拼合有组成了逻辑上一个完整的article表，这样做的目的其实也是很简单的。
 总结：分库降低了单点机器的负载；分表，提高了数据操作的效率，尤其是Write操作的效率。
  
实现方法：
  1、按号段分：


(1) user_id为区分，1～1000的对应DB1，1001～2000的对应DB2，以此类推；


优点：可部分迁移


缺点：数据分布不均 


 2、hash取模分：


   优点：数据分布均匀


   缺点：数据迁移的时候麻烦，不能按照机器性能分摊数据 


3、在认证库中保存数据库配置 
  优点：灵活性强，一对一关系


  缺点：每次查询之前都要多一次查询，性能大打折扣 


大数据解决方案：http://www.jb51.net/article/23345.htm


负载均衡的实现原理：
具体的规则如下：负载均衡器会分析当前sql的读写特性，如果是写操作或者是要求实时性很强的操作的话，直接将查询负载分到Master，如果是读操作则通过负载均衡策略分配一个Slave。我们的负载均衡器的主要研究放向也就是负载分发策略，通常情况下负载均衡包括随机负载均衡和加权负载均衡 。 


进一步完善：
有了分库，有了集群，有了负载均衡器，是不是就万事大吉了呢？ 事情远没有我们想象的那么简单。虽然有了这些东西，基本上能保证我们的数据层可以承受很大的压力 ，但是这样的设计并不能完全规避数据库宕机的危害。假如Group1中的slave2 宕机了，那么系统的LB并不能得知，这样的话其实是很危险的，因为LB不知道，它还会以为slave2为可用状态，所以还是会给slave2分配负载。这样一来，问题就出来了，客户端很自然的就会发生数据操作失败的错误或者异常。这样是非常不友好的！怎样解决这样的问题呢？ 
方案：我们引入集群节点的可用性探测机制 ，或者是可用性的数据推送机制