关于Oracle的rac集群和mysql Galera Cluster的想法
2016-03-18 12:34
344 查看
到了新公司,公司用的是rac,我比较熟悉mysql第三方的集群方案Galera Cluster这类多主集群,
下面是我参考了他人对rac的介绍,然后和mysql方案进行的臆测级别的分析对比。
rac和mysql Galera Cluster(mgc)的对比,
1、实施和运维,rac是商业方案系统化性当然强点,mgc大多使用各种开源高可用负载均衡器,部署起来对实施人员的要求rac比较低,废话。。。rmb都给了甲骨文了,如果是自行配制弄得不好性能2台还不如一台,其实运维方面来说体量大了都一样;
2、相通性,都是多点事务方案,事务可以在事务节点集群中的任何一个开始,理论上将中间失败也可以自动去另一个节点继续,提交事务是到每台节点上同步,看有没有一个节点上因为锁出现不能提交,那样就事务回滚了,
3、不同性,rac事务节点集群跟数据节点集群分离,数据默认并不冗余,只有事务在运行状态下在事务节点冗余,当然有的时候都在一台机器上,但是至少是不同进程,而包mysql在内的其他主流sqldb的事务、数据似乎都在一起,是真正的多主,冗余量高,而rac应该算事务节点冗余,数据不冗余,如果不从底层数据节点做游离于rac架构之外的底层数据节点冗余,那么rac怎么都不可能比同样节点数量的单机甲骨文实例要性能高,
这样产生的优缺点:
1、rac的数据节点当然首先节省硬盘空间,理论上可以针对库、表、表分区级别进行选择物理不同的数据节点、硬盘进行冗余进行底层冗余,不像mgc要么都冗余,要么都不冗余
2、mysql每个节点 同时是适合写和读的,所以mgc的多主不仅提高了事务的并发能力,更同时增加了不上读锁的数据的读取并发能力,这点远超rac
3、rac本身虽然是高可用方案,故障转移方案,有很高的运维上的可用性要求,层次过多,运维要求很高,当然你可以全交给dba和甲骨文付费服务,自己弄要求非常高,这方面mysql的因为层次少些相对容易运维,当然前提是你的运维人员本来就对mysql集群方案玩的很溜,否则你如果是个产品经理或者项目经理只能觉得mysql不好搞
4、mgc同时抱有对读写、事务的性能提升,并且直接是高可用的,结构简单,单点问题比rac,因为层次少了,所以应该会少,
5、rac得益于甲骨文的天生特效,更适合统计类、bi类,这方面mysql没辙,比不了
6、mgc适合主热数据的读写,不太适合做复杂的关联查询,应该比较适宜业务偏简单的互联网应用
本质上,很多人用甲骨文的原因仅仅是不敢把宝押在开源和名声稍有问题的mysql上。企业应用用甲骨文 实在多少有点冤大头 哈哈哈
互联网就该考虑mysql,如果要兼容并联查询能力 实施pgsql吧
下面是我参考了他人对rac的介绍,然后和mysql方案进行的臆测级别的分析对比。
rac和mysql Galera Cluster(mgc)的对比,
1、实施和运维,rac是商业方案系统化性当然强点,mgc大多使用各种开源高可用负载均衡器,部署起来对实施人员的要求rac比较低,废话。。。rmb都给了甲骨文了,如果是自行配制弄得不好性能2台还不如一台,其实运维方面来说体量大了都一样;
2、相通性,都是多点事务方案,事务可以在事务节点集群中的任何一个开始,理论上将中间失败也可以自动去另一个节点继续,提交事务是到每台节点上同步,看有没有一个节点上因为锁出现不能提交,那样就事务回滚了,
3、不同性,rac事务节点集群跟数据节点集群分离,数据默认并不冗余,只有事务在运行状态下在事务节点冗余,当然有的时候都在一台机器上,但是至少是不同进程,而包mysql在内的其他主流sqldb的事务、数据似乎都在一起,是真正的多主,冗余量高,而rac应该算事务节点冗余,数据不冗余,如果不从底层数据节点做游离于rac架构之外的底层数据节点冗余,那么rac怎么都不可能比同样节点数量的单机甲骨文实例要性能高,
这样产生的优缺点:
1、rac的数据节点当然首先节省硬盘空间,理论上可以针对库、表、表分区级别进行选择物理不同的数据节点、硬盘进行冗余进行底层冗余,不像mgc要么都冗余,要么都不冗余
2、mysql每个节点 同时是适合写和读的,所以mgc的多主不仅提高了事务的并发能力,更同时增加了不上读锁的数据的读取并发能力,这点远超rac
3、rac本身虽然是高可用方案,故障转移方案,有很高的运维上的可用性要求,层次过多,运维要求很高,当然你可以全交给dba和甲骨文付费服务,自己弄要求非常高,这方面mysql的因为层次少些相对容易运维,当然前提是你的运维人员本来就对mysql集群方案玩的很溜,否则你如果是个产品经理或者项目经理只能觉得mysql不好搞
4、mgc同时抱有对读写、事务的性能提升,并且直接是高可用的,结构简单,单点问题比rac,因为层次少了,所以应该会少,
5、rac得益于甲骨文的天生特效,更适合统计类、bi类,这方面mysql没辙,比不了
6、mgc适合主热数据的读写,不太适合做复杂的关联查询,应该比较适宜业务偏简单的互联网应用
本质上,很多人用甲骨文的原因仅仅是不敢把宝押在开源和名声稍有问题的mysql上。企业应用用甲骨文 实在多少有点冤大头 哈哈哈
互联网就该考虑mysql,如果要兼容并联查询能力 实施pgsql吧
相关文章推荐
- 关于oracle数据库安装出现 7003/7009
- linux 自启动oracle脚本(使用oracle自带脚本)
- oracle解析xml(增加对9i版本的支持)
- Oracle Linux 6.5 安装Oracle 11G 配置
- oracle 11g dataguard 出现ORA-16143: 终端恢复过程中或之后不允许进行 RFS 连接解决方法
- 【JAVA】存储过程学习之路1(Oracle)
- oracle误删除数据恢复
- Oracle linux 安装 Oracle 11G 报错解决 error: "net.bridge.bridge-nf-call-ip6tables" is an unknown key
- shiyan1连接oracle数据库试验
- Java实现Oracle到MySQL的表迁移
- oracle 日期格式
- Oracle 获取当前日期及日期格式
- oracle数据库服务器启动后需执行的命令(SecureCRT中执行)
- oracle10g 数据库导入dmp数据
- Oracle Day04 子查询
- 把Oracle数据库移植到Mysql
- oracle数据库用户密码将要过期处理办法(ORA-28002)
- Oracle密码过期 怎么修改
- win7 64 安装Oracle 11G 、使用PLSQL进行连接 标准实践
- oracle 集群配置