炼数成金 门户 大数据 Mysql 查看内容

关于Oracle DBA和MySQL DBA

2019-1-10 10:20| 发布者: 炼数成金_小数| 查看: 36713| 评论: 0|原作者: 杨建荣|来自: 杨建荣的学习笔记

摘要: Oracle DBA和MySQL DBA的工作重心也不大一样,Oracle的业务数据库规模都不是很大,如果有上百台就是很大的规模了,而互联网行业里面的MySQL使用广泛,几百台都是很平常的事情。对于DBA的技能范围和要求也有很大的差 ...

SQL MySQL Oracle 开源 DBA

在悟空问答上看到有个同学提问:
现在招聘Oracle DBA的越来越少了,以后Oracle会不会完全被取代?
互联网行业大多数都用MySQL了,传统行业很多也在往MySQL上转。

我做了如下的回答,略作了一些补充。
首先可以肯定的是,完全被取代是完全不可能的。
传统行业稳定为先,早期的业务都是基于商业数据库架构来构建的上下游生态,要去替换核心业务一来需要足够的时间和风险,二来需要开源技术足够牛叉,这是一个互补的过程,从行业的真实情况而言,传统行业里面的Oracle占有率还是很高的,从数量和规模上都占有的优势,但是不可否认,后续新增业务会逐步向开源方向延伸,对企业来说这是件好事,为什么不呢?

互联网行业对于开源技术的使用更加纯粹,追求短平快,所以在新技术和方案尝试上要比传统行业有更丰富的创新试错的土壤,而且很多互联网业务除了金融级业务,对于数据的完整性,一致性要求其实远没有传统行业高(试想一个博客的点赞和评论丢几条,或者你突然看不到,你也不会觉得奇怪,但是银行账户上提示少了100块钱,你肯定着急),所以其实换一个角度来说,互联万各行业里对于MySQL使用普遍是一种常态,而且不光MySQL, Redis,MongoDB,TiDB等等开源新技术方案的使用比例也在不断上升,不能只聚焦于单纯的MySQL方面,MySQL不能代表互联网的所有需求,只是一部分,这个比例和传统数据库相比,那肯定差别就很大了。

Oracle DBA和MySQL DBA的工作重心也不大一样,Oracle的业务数据库规模都不是很大,如果有上百台就是很大的规模了,而互联网行业里面的MySQL使用广泛,几百台都是很平常的事情。对于DBA的技能范围和要求也有很大的差别,直白来说,Oracle的产品已经做得足够好了,Oracle DBA的管理模式主要是集中式,因为业务面大,出问题的概率会更高,高级人才在性能优化这方面投入的精力更多。很多看起来不是问题的问题(比如高可用,比如备份恢复工具)在MySQL里面就是问题,但是换一个角度因为在MySQL里面不够完善,所以MySQL DBA圈里会出现很多的开源工具和产品,MySQL DBA相比Oracle  DBA要更加能够“折腾”,总体表现就是人比较贵,在技术架构和开发方向上的要求比较高。

单纯说MySQL好或者Oracle好,其实是没有营养的话题,国内对于MySQL和Oracle使用的一个误区就是把MySQL当Oracle用,把Oracle当MySQL用。单纯比性能其实意义不大,Oracle肯定完胜MySQL,要比较水平扩展能力,那还是MySQL更加轻量。当然这些还不是最主要的,最主要的是选择适合自己的场景才是真,别傻乎乎的听人说这个数据库不好,那个技术烂,至于说要取代,可行的衡量标准是成本,而不是单纯的技术。

抛开成本之外,可以聊的就是文化层面。在国内轰轰烈烈的去IOE运动,在国外的情况就不一样,对于美国来说,Oracle,MySQL数据库都隶属于Oracle的产品线,一个商业成功,一个开源流行。其实他们选择的入手点和我们就完全不同,对待Oracle的态度也大大不同,从文化排他性上来说,Oracle都可以理解是他们的国产数据库,而欧洲的公司更倾向于用MariaDB,这个也是有文化基因的。当然,从这个角度理解也有道理。

声明:文章收集于网络,如有侵权,请联系小编及时处理,谢谢!

欢迎加入本站公开兴趣群
软件开发技术群
兴趣范围包括:Java,C/C++,Python,PHP,Ruby,shell等各种语言开发经验交流,各种框架使用,外包项目机会,学习、培训、跳槽等交流
QQ群:26931708

Hadoop源代码研究群
兴趣范围包括:Hadoop源代码解读,改进,优化,分布式系统场景定制,与Hadoop有关的各种开源项目,总之就是玩转Hadoop
QQ群:288410967 
1

鲜花

握手

雷人

路过

鸡蛋

刚表态过的朋友 (1 人)

相关阅读

最新评论

热门频道

  • 大数据
  • 商业智能
  • 量化投资
  • 科学探索
  • 创业

即将开课

 

GMT+8, 2019-6-26 14:23 , Processed in 0.209248 second(s), 24 queries .