您当前的位置:首页>>数据库>>正文
 
架构师眼中的MySQL开发模式
作者: 来源:51CTO 日期:2013/7/18 15:27:16  点击次数:

新旧两套开发模式间的不同之处

现在我们来聊聊新旧两种开发模式之间的几项主要差异。

我认为目前我们所使用的开发模式,其最重要的特性就是整个开发流程以2到4个月为周期始终处于随时可发布状态,并且能够稳定地按照每6个月推出新GA版本的进度进行运作。对于可发布状态,我们的定义为:产品质量严格符合候选发布版的相关标准。在过去的开发模式中,我们的标准相对比较宽松,所谓可发布状态是指当前版本到达候选发布要求——但由于在测试阶段仍然可能有新功能不断被添加进来,因此整个发布流程周期常常长达两年,而不是现在的2到4个月。

新模式给MySQL新代码带来的影响

那么这种新模式会给我们的MySQL新代码开发工作带来哪些影响呢?在我看来,这意味着新代码必须以小规模模块的形式添加到产品中来,换句话说新代码中不能混杂过多旧代码,因为这可能会带来新的未知冲突及不稳定因素。总之,如果需要向MySQL Server中某个复杂程度较高的区域添加新功能,我们会首先对该区域进行重新设计,然后才着手实施功能添加工作。如此一来,我们就在某种程度上保持了开发流程的稳定性始终拥有最高优先级。而在过去,我们向MySQL Server中添加新功能时往往会造成系统稳定性优先级别的下降,这对于一款开发模式而言当然不是什么好事。

有趣的是,随着稳定性在开发流程中的重要性得到进一步增强,我们反而获得了放手处理新功能的广阔空间!不过有时候我们未必能按照自己的预期快速开发出特定的新功能。如果一项新功能会对MySQL Server中复杂性较高的某些代码造成干扰,那么为了系统稳定性的考量,我们会事先进行一系列准备工作及测试流程,这是此类新功能出台的必要前提。但是对于大部分与MySQL Server复杂区域不相关的边缘新功能来说,整个添加过程则更加顺畅同时轻松愉快。

新模式下的主要功能开发流程

接下来要谈的是如何在这套模式中处理主要功能的添加工作,其中最需要注意的因素在于如何保证新代码拥有良好的排布结构。也就是说在添加新功能时,我们不能简单地从编写代码着手,而应该首先思考现有代码结构能否与正在开始的新功能紧密契合。举例来说,我们在MySQL 5.6版本中添加了众多新功能,而LOCK_open正是其中之一。如果按照以往传统的MySQL Server开发模式,我们会直接将新功能添加进来,然后检测它会与哪些现有MySQL Server功能组件发生冲突,并确保所有已经确定的新问题在新的GA版本发布之前得到解决。但现在我们的思路更先进、处理方式也完全不同。首先我们会建立一系列重新设计项目,将LOCK_open主功能完全隔离起来,这样就保护了运行中的元数据免遭破坏、同时也为连接中的元数据提供了缓冲措施。在以上步骤的执行过程中,我们可以继续进行手头的其它MySQL 5.6开发工作,而且原本非常重要的LOCK_open功能更新能够以小补丁的形式添加进主系统当中,同时也让功能升级变得更加安全。

新开发模式的灵感来源

我们之所以选择这种全新的开发模式,其灵感显然源自以Linux内核为代表的其它几个典型开源项目。它们的成功为我们的新思路提供了指导与借鉴。

从旧模式向新模式的转换

尽管新模式的优势如此明显,但从旧模式转换为新模式的道路却并不平坦。在决定发起变革之后,我们制定了新的开发流程,并在其中添加了多项意义重大的新功能。然而流程的出台并不意味着实际工作的顺利进行,概念与可发布状态之间仍然相隔十万八千里,因此我们做出了“一个艰难的决定”——以MySQL 5.1开发流程为基础将一切过去推倒重来。这套新流程是我们首次在开发过程中使用“里程碑”模式的尝试,但原先的模式中同样包含很多意义重大的理想方案,因此我们需要一步步将遗留资源与新规划加以整合。整个过程持续了数年之久,由于新的开发流程对于新功能的运作效果及稳定性要求极高,因此进度不快也在情理之中。不过现在我们终于大功告成,所有有价值的功能都已经被迁移到新模式当中,其它的则要么直接弃用、要么利用其它方式加以替代。

对于未来MySQL开发的影响

那么新模式的引入到底会在当下与未来给MySQL开发工作带来哪些影响呢?首先要强调的是,我们在MySQL 5.6中添加了200项新功能,这表明新的开发模式确实能为我们的用户及消费者带来大量激动人心的革命性升级与改进。希望这套开发模式能够继续指引开发工作顺利开展,我们也会继续努力为MySQL技术社区带来更多更具吸引力的功能。作为一位架构师,我非常自豪地关注着MySQL技术团队的一举一动,也为他们针对MySQL架构做出的改善而深感骄傲。相信随着新模式的逐渐完善与新功能的持续加入,MySQL会为全世界使用者带来更加光彩夺目的特性。


上一篇:NoSQL数据库安全优于RDBMS吗?
下一篇:没有了
  北京总部: 4006-505-646
  天 津 部: 4006-505-646
  上 海 部: 4006-505-646
  深 圳 部: 4006-505-646
  广 州 部: 4006-505-646
  重 庆 部: 4006-505-646
  南 京 部: 4006-505-646
  其它地区: 4006-505-646
经典案例
中国石油管理局-Oracle数据库恢
中国网通-IBM EXP300磁盘阵列数
大连鸿德经贸有限责任公司-SQL
中国地质环境监测院-HP LH3000
藁城市东街百货-EFS文件解密成
工商银行某省分行-AIX删除LV数
中央电视台新闻评论部-苹果分
promise乔鼎硬盘阵列数据恢复成
麒麟童文化-苹果分区无法打开,
NAS 8100服务器数据恢复成功 
解决方案
raid磁盘阵列OFFLINE后的应急方
磁盘未被格式化,是否格式化数据
误GHOST、误一键恢复灾难应急方
误删除、误格式化数据灾难应急
LINUX FSCK数据出错灾难应急方
北亚数据恢复 - 联系我们 - 关于北亚 - 友情链接 - 网站地图 - RSS聚合 
版权所有 北亚数据恢复中心
全国统一客服热线:4006-505-646
北京总部:北京市海淀区永丰基地丰慧中路7号新材料创业大厦B座205室
t"><