数据库优化
2015-09-27 20:03
344 查看
方案名称:数据切分
数据切分的概念:
通过一系列的切分规则将数据水平分布到不同的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分配负载。这样一来,问题就出来了,客户端很自然的就会发生数据操作失败的错误或者异常。这样是非常不友好的!怎样解决这样的问题呢?
方案:我们引入集群节点的可用性探测机制 ,或者是可用性的数据推送机制
转载:http://blog.csdn.net/james521314/article/details/8483958
数据切分的概念:
通过一系列的切分规则将数据水平分布到不同的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分配负载。这样一来,问题就出来了,客户端很自然的就会发生数据操作失败的错误或者异常。这样是非常不友好的!怎样解决这样的问题呢?
方案:我们引入集群节点的可用性探测机制 ,或者是可用性的数据推送机制
转载:http://blog.csdn.net/james521314/article/details/8483958
相关文章推荐
- MySQL命令大全
- Redis 在线测试
- redis.conf配置详细解析
- Redis 作为多个Windows服务运行配置方法
- Ubuntu 安装mysql和简单操作
- 如何在windows7上的dos界面登录mysql(1)
- centos7 设备 mariadb-10
- MySQL安装
- MYSQL的常用命令和增删改查语句和数据类型
- HTML5 Web SQL Database 数据库
- 【SQL Server性能优化】SQL Server 2008该表压缩
- memcached 使用
- Elasticsearch实现与mysql的数据库的同步
- windows oracle 完全卸载
- 建立ORACLE10G DATA GUARD--->Physical Standby
- 连接 数据库
- 数据库连接、操作(封装使用)
- 当主库发生宕机,从库如何接管主库
- 《数据管理技术和理论》随堂笔记
- Cygwin编译redis