mysql大企业级应用可行性分析--

《mysql大企业级应用可行性分析--》由会员上传分享，免费在线阅读，更多相关内容在应用文档-天天文库。

1、MySQL大企业级应用可行性分析>>　　我在这里将讨论一些关于MySQL的面向企业级应用的思路，以及能否用MySQL替代当前Oracle的问题。　　首先说明一点的是,我不是说MySQL没有大企业级的应用，事实上，可以看到越来越多的成功布署MySQL的应用，但是，还不够多，还有许多大企业的关键应用还不敢用MySQL。或许这篇小文能和大家一起探讨一些比较虚的东西。　　存储引擎　　由于MySQL自己一直没有一个成熟可靠的存储引擎，估计这让他们深感痛处(尤其是目前最成熟的事务型引擎InnoDB又在Oracle手里)。MySQL寄予厚望的Falcon在开发了两年多之后，

2、建树不大，而该项目带头人JimStarkey前不久又离开了MySQL，陋屋偏逢连夜雨。　　Sun会给MySQL一个稳健的引擎么?我看短时间内未必能达到。除非，Sun从Oracle手里把InnoDB买回来。　　如果进行大企业级应用，考虑到引擎本身的稳定性，似乎可选的也只有InnoDB了，但InnoDB的备份工具又是收费的。至于MyISAM，尽管有人的确喜欢用，但对于并发能力要求稍微严格一点，MyISAM根本不行。　　在线DDL锁表问题　　MySQL中，在线对表对象做DDL操作是要锁表的，对于可用性要求比较高，而应用变化又比较频繁的环境，这是个非常很糟糕瓶颈。没想

3、到有什么好的办法，除非，像大家开玩笑说的，把所有的表都预留出足够的空闲列，减少类似增加列的变更麻烦。　　这个MySQL天生的缺陷在PostgreSQL中是不存在的，比如创建索引，可以用createINDEXCONCURRENTLY的方式来减小影响。(MySQL后续的版本中在逐渐改善这个问题：添加了ONLINE关键字)　　这个看似是个小问题，但实际上却是对很多人最为困扰的。　　在线备份问题　　MySQL6.0后终于具备在线备份的能力了。但现在，恐怕比较激进的用户也只能用版本5而已。　　很多MySQL资深用户能够根据自己应用的特点布署适合自己的备份方式(尽管可能也

4、会有缺陷，比如基于时间点的恢复)。　　至于另一个常用来衡量DB可扩展性的特性：分区，现在MySQL已经能够支持了，尽管实现的的确有点晚。而使用MySQL的用户，一般都采取Sharding的策略对数据进行切分，所以，分区的问题倒似乎并不是最为关键的。　　因为是整理思路，这算是这个系列的第一篇。　　存储引擎　　继续上一篇的讨论，记录针对MySQL在大企业级商用上我的一些零星想法。网络上到处都有关于各个引擎之间的对比。这里要提醒一点是，注意各个引擎的锁的粒度。InnoDB是行锁，锁的实现是依赖于索引的，MyISAM只是表锁。锁粒度是衡量存储引擎的一个重要指标，其能力

5、很大程度上决定并发能力。　　至于TRANSACTIONISOLATIONLEVEL，则是另外一个需要衡量的指标。　　老生常谈的，某某引擎适合什么类型的应用，归根结底还是由于其实现的机制决定了引擎的特性。　　存储层的解决方案　　相信没有人愿意在MySQL上用RAySQL上类似OracleASM的解决方案。如果用文件系统，单节点的数据存储能力肯定要受到制约--没有人喜欢把几个T的数据扔到一个MySQLDB上吧?一旦某个文件系统故障，麻烦就来了。从这个角度考虑，或许LVM2是一个可选的方式。　　当然，如果把数据文件扔到SAN上也还不错。一方面问题是，现在存储厂商对于

6、MySQL的重视长度还远不如Oracle、DB2等老牌商业数据库。另一方面，很多MySQL用户没有SAN环境的，数据都是在本地磁盘上。　　固态硬盘与MySQL　　前两天有朋友在上一篇分析留言，提及应注重闪存的应用。其实还不如布署固态硬盘(SSD)对MySQL可能的影响问题。相信现在有很多企业需要在DB的IOPS上寻求突破，SSD是个可能的突破口，但从目前我收集到的数据来看，还没有足够的数据说明启用SSD的MySQL能有预期的数量级上的IOPS提升。　　商业支持　　现在MySQL的背后有Sun，但是，如果不购买服务的话，到哪里去找比较正规的商业支持(我是说软件集

7、成商)?即使购买了服务，如果问题出在存储引擎上，MySQL能给即时、有效的技术响应么?这也是MySQL没有自有存储引擎的一个弱点，因为衔接的环节多，一旦有商务上的问题，很容易陷入扯皮阶段。　　这是这个系列第二篇。如果有第三篇，我倒是想写几点关于MySQL的设想。>>>>这篇文章来自..，。