MySQL 大企业级应用可行性分析(之二)

广而告之: 7月26日QClub杭州站-- 支付宝首席架构师程立与您分享"当SOA遭遇现实"的心得

再说存储引擎

继续上一篇的讨论,记录针对 MySQL 在大企业级商用上我的一些零星想法。网络上到处都有关于各个引擎之间的对比。这里要提醒一点是,注意各个引擎的锁的粒度。InnoDB 是行锁,锁的实现是依赖于索引的,MyISAM 只是表锁。锁粒度是衡量存储引擎的一个重要指标,其能力很大程度上决定并发能力。

至于 TRANSACTION ISOLATION LEVEL,则是另外一个需要衡量的指标。

老生常谈的,某某引擎适合什么类型的应用,归根结底还是由于其实现的机制决定了引擎的特性。

存储层的解决方案

相信没有人愿意在 MySQL 上用 RAW 设备,很多人几乎就是直接把数据文件放在文件系统上(个人认为,对于数据库这样的应用来说,文件系统可靠性还有所欠缺)。我还没发现 MySQL 上类似 Oracle ASM 的解决方案。如果用文件系统,单节点的数据存储能力肯定要受到制约–没有人喜欢把几个 T 的数据扔到一个 MySQL DB 上吧? 一旦某个文件系统故障,麻烦就来了。从这个角度考虑,或许 LVM2 是一个可选的方式。

当然,如果把数据文件扔到 SAN 上也还不错。一方面问题是,现在存储厂商对于 MySQL 的重视长度还远不如 Oracle、DB2 等老牌商业数据库。另一方面,很多 MySQL 用户没有 SAN 环境的,数据都是在本地磁盘上。

固态硬盘与 MySQL

前两天有朋友在上一篇分析留言,提及应注重闪存的应用。其实还不如布署固态硬盘 (SSD) 对 MySQL 可能的影响问题。 相信现在有很多企业需要在 DB 的 IOPS 上寻求突破,SSD 是个可能的突破口,但从目前我收集到的数据来看,还没有足够的数据说明启用了 SSD 的 MySQL 能有预期的数量级上的 IOPS 提升。

商业支持

现在 MySQL 的背后有 Sun ,但是,如果不购买服务的话,到哪里去找比较正规的商业支持(我是说软件集成商)? 即使购买了服务,如果问题出在存储引擎上,MySQL 能给即时、有效的技术响应么? 这也是 MySQL 没有自有存储引擎的一个弱点,因为衔接的环节多,一旦有商务上的问题,很容易陷入扯皮阶段。

–思路中断,这是这个系列不成熟的第二篇。如果有第三篇,我倒是想写几点关于 MySQL 的设想。

EOF

此文作者:, 位于 Database 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

  • kxn

    为什么没有人愿意在 MySQL 上面用 RAW 设备呢?
    貌似 InnoDB 直接用裸盘还成,反正备份数据也是用 innodb 的 hotcopy。

  • xlight.openid.cn

    QClub杭州负责人:冯大辉
    冯大辉,就职于阿里巴巴集团旗下支付宝(中国)网络科技有限公司,担任数据库架构师,负责支付宝数据库架构规划、解决方案等相关工作。2007 年国内首批 Oracle ACE。网上 ID 为“Fenng”,业余时间关注 Web 2.0 网站架构技术。个人Blog:http://www.dbanotes.net,网络电话或邮件联系为:dbanotes[AT]gmail.com。
    免费免费免费!

  • http://xx.com xxx

    你为什么不把三篇整在一起呢?就这么短还分开。怎么想的?想多点文章??

  • betty

    oracle,db2等商业数据库的大型应用的资料有很多,可查,有参考的东西。而mysql的资料比较封闭,虽然有些大型的互联网企业也用mysql进行大型的应用,但是人家不愿意分享。这可能是一原因。

  • http://www.dbanotes.net/ Fenng

    @betty
    您这个看法可真奇怪。
    MySQL是最开放的东西. 所有信息都能找到