eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

« Oracle DataGuard对跨平台数据迁移的支持 | Blog首页 | 2015 ACOUG中国之旅-北京站活动成功举行 »

行成于思:从Oracle到MySQL的抉择及DBA

OMP.jpg

这篇文章来自于微信群的问答,我和周彦伟互相配合,彦伟回答了我的四个关于MySQL和Oracle的问题,对于来自两个不同领域的人,这些问题我想对很多人具备参考价值。整理收录于此,供参考。

 

1.用户该选择怎样的MySQL?

盖国强问:随着Oracle囊括MySQL而去,用户对于MySQL命运的担忧从未停止,然而官方版本的各种特性确实在不断增强,从GTID到MTS,Oracle解决了MySQL的很多历史问题,同时诸如MariaDB等新的分支又激活了开源的引擎,Oracle官方分支与其他分支相比,是否具备明确的更新优势,用户该怎样去进行选择?进一步的,周总认为MySQL最吸引用户的地方是什么,比如和Oracle数据库对比(不谈成本)?

周彦伟答

MySQL的版本,个人认为比较靠谱的有三,MySQL官方版本,Percona版本,MariaDB版本

MySQL官方版本当然是正统,不管是代码开发人员,还是各种测试,文档,社区维护都是最强大,最全面的。我估计(官方版本)也是目前使用量最大的版本。它对bug的修改和功能性代码补丁的merge都很专业,谨慎,可靠性比较高。它的缺点,庞大的机构和冗长的流程,会导致代码更新缓慢,一些热点功能不能很快的反应到官方GA版本上,如果希望用到比较实用的社区开发人员提供的补丁,可能需要等待很长时间。MySQL官方在企业版和社区版之间徘徊,感觉他们还没想好到底怎么发展MySQL,很好的工具不能免费提供给使用者,要走收费的道路,然后又等着开源社区来革命。

反之,MariaDB在这方面比较接地气,很多最新的功能都能快速的加入和实现,很多人选择它就是因为这点。Monty本人感觉比较激进,比较从谏如流。但是MariaDB还是太年轻,各个环节还不够成熟,专职的开发者也少,并且很重要的是,很可能上了道之后就回不来了,慢慢的会偏离MySQL。

Percona版本是官方版的超集,它在官方版本的基础之上又加入了很多补丁,同时Percona已经修成一个基于MySQL的生态圈了,各种工具,方案,文档都很齐全。对MySQL用户来说是一个不错的选择。但是令人堪忧的事情是,Percona自身的开发能力,特别是对InnoDB的开发和修改能力慢慢趋于弱势,真正有实力的人,应该还在官方。不过,鉴于Percona完全兼容官方版本,我目前还是选择了它。

我认为自由是开源数据库的兴起之源,特别是在互联网行业,自由之风盛行,所以开源数据库可以大行其道。作为使用者来说,知其然并知其所以然的状态是最好,并且,在开源面前不仅仅如此,知其所以然而后对其拆骨动筋,使其为我所用,听我所嘱,这也只有开源可以办得到。

另外,开源社区的氛围,也是大家学习和进步之源,不仅能直接吸收其编码的精华,也可以借鉴他人之经验,整体欣欣向荣,互相促进,共同进步,如此蓝图,岂不乐乎。

2.从代码到运维,MySQL的DBA何去何从?

盖国强问:有人说玩开源产品就要玩源码,MySQL DBA中有一类独特的群体是代码开发者,和Oracle DBA比较起来,单纯的MySQL的运维似乎可以腾挪的空间更小,作为MySQL DBA,应该如何选择MySQL入行的方向,不同方向的关系又是如何的?我也非常想知道周总在MySQL的职业生涯中,是从哪个角度入行,对于源码的认识是怎样的,从人人网到去哪儿,角色和技术上又有哪些转变?

周彦伟答

我个人是抱着读源码的信心入行运维DBA的。当时改行做DBA,我已经做开发超过5年有余,陡然换一个新的职业的信心来自于自己编程的经验,当时要决定做DBA时,我对自己说了一句话:MySQL不就是一个程序么,代码都在那里,还有啥搞不定的?

但造化弄人,我并没有对源码有过很多深入的研究,甚至没有通读过一遍。在当时的工作,研发和DBA比例超过200:1。工作压力巨大,早期的MySQL知识恰恰都是从运维中获得的。从这点可以说,运维也可以干得很不错。我也相信,到目前为止还是有很多人没有看过源码,但在DBA的岗位上非常优秀和成功的。

同时,我也注意到,很多从源码起步的人,并不一定能把运维这个事儿搞得很好,甚至会一团糟,各种理论的书面经验并不能有效转化为生产力,有时候甚至会捅大娄子。认真总结可以发现,源码和运维是两种完全不同的思维模式和做事方式,相对而言,源码需要的是更为抽象的算法,编程能力,思维能力,而运维更侧重于经验的总结,行为的准则,人性的展示,运维往往更能反映人性。我之前在人人上发状态有过这样的表达:DBA是一种生活方式。DBA是一种态度。

我个人比较幸运的是,在经历了大规模,高强度,超负荷的运维DBA的过程中,不断接触到了数据库源码和研究数据库源码的人,他们给我纠正了很多我在运维过程中猜到的一些经验,这些经验在源码面前被揭露的一览无余,让我改变看法,积累正确的知识,不断进步。在此,我要谢谢这些好朋友,竹峰,立勋,丁奇,古雷,利兵,登博,禇霸等等。当然,获取数据库的知识也来自从运维入手的一批朋友,诸如炳锡,金荣,启荣,发明,李凌,应钢等等,这些都是良师益友。

关于源码和运维,我的周围还有这样的奇才,从源码转而运维,从运维转而源码,总而言之,二者如果能很好的结合起来,在运维过程中参照源码来指导工作,把运维的需求变成源码沉淀,这才是MySQL DBA最好的工作方式,这些人的成就,我已经望尘莫及了。

MySQL DBA或者DBA的发展,除了更深入的钻研源码以达到MySQL届扫地僧的造诣之外,可发展的空间还有两条路:

一是对底层架构的把握和设计,MySQL是需要架构的,而且需要功力很深的设计,不管是扩展性还是可用性,它自身都没有很好得解决方案,这需要从上层角度,根据自己业务的需求和特点,选择不能的架构思路,甚至在一个公司内部,根据公司的业务不同,也需要选择不同的方案,物尽其用,物有所值才是持家之道。

二是对业务逻辑和架构的深入。我记得这是在跟童家旺大师聊天时候他提到的一个观点,我对此非常认同。数据库跟业务再也不是路人甲乙的身份了,数据库的优化需要了解业务的真实需求和特点,业务技术架构和方案的设定也需要深入了解数据库的特点,把二者结合起来考虑,各自扬长避短,才能和谐工作,提升效率。DBA就是这其中的桥梁,DBA要上得厅堂,下得厨房,做到深入了解每一个分表,每个sql的真正意义,才能更好得去优化和设计。这样的DBA才是有价值的DBA,才是业务和企业最离不开的人,这其中的空间无比的宽广,非常非常值得探究。目前来看,MySQL DBA在逐渐往这条路上(深入业务)前行,但是Oracle方面,由于传统的习惯和Oracle数据库大包大揽的特点,反而数据库和业务离得比较远一些。目前的Oracle DBA没有MySQL DBA那么抢手,这是不是也是一个原因?


我个人从之前的人人网到去哪儿网之后,担任了数据库总监的职务,在短期内把DBA团队发展壮大到超过原来的3倍,同时扩大了DBA的业务,从原来狭义的DBA只顾MySQL这一项内容扩展到MySQL,HBase,redis,甚至SQL Server。这其中有公司的需求,也有个人以及团队发展的考虑。在MySQL上的主要工作是作为架构师的角色,带领和伙同兄弟们一起做了不少底层的革新。从制定MySQL开发规范,到架构PXC,从开拓redis业务到目前的HBase的初见成效,从带动公司硬件的革命,到推出开源审核产品InceptionSQL,也算做了一些事情。


3.MySQL的版本更新?

盖国强问:在我的职业生涯里,Oracle从8i、9i、10g、11g进化到现在的12c,而MySQL已经在5版上徘徊了超过10年,MySQL是如何规划版本的,开源产品在活跃的社区下为何反而不如商业产品迭代和扩展得快?那么是否意味着在Oracle的支持下,MySQL官方分支会加快MySQL的演进更新?

周彦伟答

我对商业产品的市场行为不是太了解,不过从周围的手机,电器,医药等产品的更新换代来看,我觉得这种大版本的不断更新换代绝对有商业的意图在里面,至于细节,就不知道,也不好评说了。

相反,我对MySQL还是比较了解的,我是从5.0.27开始使用MySQL的,到现在的MySQL5.7.8。MySQL看似让人失望了,MySQL 5版本徘徊了已经很久很久了,久得让人觉得MySQL5是一个产品的名称了,而不是MySQL,连MariaDB都10了。但是回过头来看,MySQL每一个最小版本的升级,都走得踏踏实实,细看Release Notes你会发现,MySQL真是解决了很多很多的问题啊。并且几次大的升级,5.0到5.1,5.1到5.5,5.5到5.6以及5.7,每次升级都有亮点,都让人欣喜。当然我上面也吐槽过,MySQL还是不够激进,效率也不够高,很多好用的特点没有被官方接纳,官方的官僚冗长的作风,也值得批评。

MySQL一直是5还有一个原因是,上面的开发框架这几个版本Server框架没动,都是基于Server+引擎的Plugin的方式,最近几年主要是针对引擎上做各种工作了,例如InnoDB的变动,实际上是不表现在MySQL Server的大版本上的。MySQL版本选择方面很重要一点是是针对引擎的选择或是针对业务解决方案来选择,这是和Oracle差别很大的地方

另外,MySQL产品升级的历史,也可以看做是互联网发展的一个缩影。从最初的简单的Myisam存储,到InnoDB的大规模推广,从replication受到热捧到各种集群方案的推出,从数据库访问的效率,到对数据库一致性,安全性的追求,反映到互联网上,难道不是web1.0,2.0,搜索引擎,社交产品,电子商务,金融服务的写照么?现在在电子商务产品上使用MySQL已经不是什么稀奇的事情了,进而,包括阿里在内的大厂们都在考虑如何提高一致性和安全性,要把MySQL用在金融上,这也包括我从去年开始认真研究的PXC,也是应此需求而来得。这就是MySQL的进步。

4.MySQL在国内的发展会否"成也阿里,败也阿里"?

盖老师问:在我的视野里,最近几年MySQL在国内的快速发展,一部分得益于阿里在去"IOE"中,使用MySQL替代了Oracle数据库,进而不断推动国内关于MySQL的技术讨论,但是随着阿里自有OB的使用,包括最近热议的PG,以及在云上全面的数据库产品布局,会否使得MySQL沉寂下来,MySQL和PG的竞争该如何判定?

周彦伟答:

首先,我认为国内的MySQL"成也阿里"是不准确的,据我所知,阿里在MySQL方面有比较好的成果和公开的分享,怎么也得是2009年之后了吧。那么在此之前,事实上国内的MySQL已经如火如荼了,例如我的挚友吴炳锡,叶金荣,在那个时候已经是多年的MySQL DBA了。我当时供职的人人网,已经是数百台实体机器,数千个实例的规模了。还有更多的一些专家,一些公司,其实在很早很早就开始用MySQL了。我相信腾讯的使用MySQL的历史和规模应该都大于当时的阿里。这也是开源社区的特点,真真的藏龙卧虎,高人辈出。

事实上,互联网一直有MySQL的身影和基因,去IOE只不过是把MySQL推到了一些传统的企业和政府面前,看似一下子火起来了而已,其实,火,一直在那里烧,只是关注者的侧重点不同而已

"败也阿里"也值得商榷,正是这几年以阿里的一些数据库爱好者的推动,MySQL技术得到了长足的发展,不管是MySQL的社区,还是MySQL自身的性能,安全性,都在广大MySQL DBA和源码贡献者的推动下不断得到优化,MySQL的使用范围也越来越广,据我所知,不仅仅是大家知道的阿里淘宝,连QQ的财付通,QQ的游戏支付,大家平时玩的微信红包,都是在用MySQL。上面提到,MySQL马上要走入到正统的金融领域了。我之所以说是正统,是指的银行或者类银行的权威机构,是要处理账务的,不仅仅是上面提到的这些电子商务的流水账目。因为我知道很多金融网站,P2P金融服务在用MySQL,但是他们的技术人员并没有认识到MySQL的不足,直接上来就用,真可谓初生之犊不惧虎,我个人是不会买这类网站的金融产品的。支付环境是安全性和一致性主导的,这方面如果新型的P2P公司要使用MySQL最好找人咨询一下。  

另外,现在传统企业的跟进,必然也会从互联网公司挖一批从事的老兵,这些老兵也会把互联网的经验带到传统企业,所以MySQL的使用,已经不只看阿里或者互联网了。 另外我看到各种MySQL培训,例如炳锡的泰岳学院,恩墨的恩墨学院做的也挺火的,可以说现在市场需求真的不到是阿里了。 也许阿里会向更高的层面发展,如同google推出Spanner这种东东,一般企业也不需要,也不容易部署起来。 再反观,MySQL做为一个成熟的成品在一般企业在搞定千万或是上亿用户的规模系统里,互联网现在的技术也可以顶一段时间了。

至于有类似OB和PG竞争,我一直觉得这是一件非常好的事情,我所在的公司是有PG的,并且PG不在我的控制之下。但这一点也不影响我对PG的喜爱和支持。好东西为什么要刻意回避?竞争才能意味着进步,如果MySQL过不了这一关,那么它的死掉也不足惜了。按照历史的发展经验和MySQL活跃程度,我认为败只是臆断,只是担心,这个发生的可能性很小。

 

当然,我也再次呼吁,大家一起努力,把社区做好,把产品最好,把数据库用好。

------------------------------------------------------------

以上是问答的实录,我从周彦伟的回复中也获益良多,收录这里供大家参考。


历史上的今天...
    >> 2013-08-28文章:
    >> 2008-08-28文章:
    >> 2007-08-28文章:
           RAC相关的一则DBA招聘需求
    >> 2006-08-28文章:
    >> 2004-08-28文章:
           如何分配磁盘组(EMC阵列)
           如何在VCS中创建共享磁盘

无觅

By eygle on 2015-08-28 08:12 | Comments (0) | Beginner | HowTo | 3178 |


CopyRight © 2004~2020 云和恩墨,成就未来!, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话:400-600-8755 业务咨询:010-59007017-7040 or 7037 业务合作: marketing@enmotech.com