我在这里将讨论一些关于 MySQL 的面向企业级应用的思路,以及能否用 MySQL 替代当前 Oracle 的问题。
首先说明一点的是,我不是说 MySQL 没有大企业级的应用,事实上,可以看到越来越多的成功布署 MySQL 的应用,但是,还不够多,还有许多大企业的关键应用还不敢用 MySQL。或许这篇小文能和大家一起探讨一些比较"虚"的东西。
[b]存储引擎[/b]
由于 MySQL 自己一直没有一个成熟可靠的存储引擎,估计这让他们深感痛处(尤其是目前最成熟的事务型引擎 InnoDB 又在 Oracle 手里)。MySQL 寄予厚望的 Falcon 在开发了两年多之后,建树不大,而该项目带头人 Jim Starkey 前不久又离开了 MySQL,陋屋偏逢连夜雨。
Sun 会给 MySQL 一个稳健的引擎么? 我看短时间内未必能达到。除非,Sun 从 Oracle 手里把 InnoDB 买回来。
如果进行大企业级应用,考虑到引擎本身的稳定性,似乎可选的也只有 InnoDB 了,但 InnoDB 的备份工具又是收费的。至于 MyISAM ,尽管有人的确喜欢用,但对于并发能力要求稍微严格一点,MyISAM 根本不行。
[b]在线 DDL 锁表问题[/b]
MySQL 中,在线对表对象做 DDL 操作是要锁表的,对于可用性要求比较高,而应用变化又比较频繁的环境,这是个非常很糟糕瓶颈。没想到有什么好的办法,除非,像大家开玩笑说的,把所有的表都预留出足够的空闲列,减少类似增加列的变更麻烦。
这个 MySQL 天生的缺陷在 PostgreSQL 中是不存在的,比如创建索引,可以用CREATE INDEX CONCURRENTLY 的方式来减小影响。(MySQL 后续的版本中在逐渐改善这个问题:添加了 ONLINE 关键字)
这个看似是个小问题,但实际上却是对很多人最为困扰的。
[b]在线备份问题[/b]
MySQL 6.0 后终于具备在线备份的能力了。但现在,恐怕比较激进的用户也只能用版本 5 而已。
很多 MySQL 资深用户能够根据自己应用的特点布署适合自己的备份方式(尽管可能也会有缺陷,比如基于时间点的恢复)。
至于另一个常用来衡量 DB 可扩展性的特性:分区,现在 MySQL 已经能够支持了,尽管实现的的确有点晚。而使用 MySQL 的用户,一般都采取 Sharding 的策略对数据进行切分,所以,分区的问题倒似乎并不是最为关键的。
[b]存储引擎[/b]
继续上一篇的讨论,记录针对 MySQL 在大企业级商用上我的一些零星想法。网络上到处都有关于各个引擎之间的对比。这里要提醒一点是,注意各个引擎的锁的粒度。InnoDB 是行锁,锁的实现是依赖于索引的,MyISAM 只是表锁。锁粒度是衡量存储引擎的一个重要指标,其能力很大程度上决定并发能力。
至于 TRANSACTION ISOLATION LEVEL,则是另外一个需要衡量的指标。
老生常谈的,某某引擎适合什么类型的应用,归根结底还是由于其实现的机制决定了引擎的特性。
[b]存储层的解决方案[/b]
相信没有人愿意在 MySQL 上用 RAW 设备,很多人几乎就是直接把数据文件放在文件系统上(个人认为,对于数据库这样的应用来说,文件系统可靠性还有所欠缺)。我还没发现 MySQL 上类似 Oracle ASM 的解决方案。如果用文件系统,单节点的数据存储能力肯定要受到制约--没有人喜欢把几个 T 的数据扔到一个 MySQL DB 上吧? 一旦某个文件系统故障,麻烦就来了。从这个角度考虑,或许 LVM2 是一个可选的方式。
当然,如果把数据文件扔到 SAN 上也还不错。一方面问题是,现在存储厂商对于 MySQL 的重视长度还远不如 Oracle、DB2 等老牌商业数据库。另一方面,很多 MySQL 用户没有 SAN 环境的,数据都是在本地磁盘上。
[b]固态硬盘与 MySQL[/b]
前两天有朋友在上一篇分析留言,提及应注重闪存的应用。其实还不如布署固态硬盘 (SSD) 对 MySQL 可能的影响问题。 相信现在有很多企业需要在 DB 的 IOPS 上寻求突破,SSD 是个可能的突破口,但从目前我收集到的数据来看,还没有足够的数据说明启用了 SSD 的 MySQL 能有预期的数量级上的 IOPS 提升。
[b]商业支持[/b]
现在 MySQL 的背后有 Sun ,但是,如果不购买服务的话,到哪里去找比较正规的商业支持(我是说软件集成商)? 即使购买了服务,如果问题出在存储引擎上,MySQL 能给即时、有效的技术响应么? 这也是 MySQL 没有自有存储引擎的一个弱点,因为衔接的环节多,一旦有商务上的问题,很容易陷入扯皮阶段。
首先说明一点的是,我不是说 MySQL 没有大企业级的应用,事实上,可以看到越来越多的成功布署 MySQL 的应用,但是,还不够多,还有许多大企业的关键应用还不敢用 MySQL。或许这篇小文能和大家一起探讨一些比较"虚"的东西。
[b]存储引擎[/b]
由于 MySQL 自己一直没有一个成熟可靠的存储引擎,估计这让他们深感痛处(尤其是目前最成熟的事务型引擎 InnoDB 又在 Oracle 手里)。MySQL 寄予厚望的 Falcon 在开发了两年多之后,建树不大,而该项目带头人 Jim Starkey 前不久又离开了 MySQL,陋屋偏逢连夜雨。
Sun 会给 MySQL 一个稳健的引擎么? 我看短时间内未必能达到。除非,Sun 从 Oracle 手里把 InnoDB 买回来。
如果进行大企业级应用,考虑到引擎本身的稳定性,似乎可选的也只有 InnoDB 了,但 InnoDB 的备份工具又是收费的。至于 MyISAM ,尽管有人的确喜欢用,但对于并发能力要求稍微严格一点,MyISAM 根本不行。
[b]在线 DDL 锁表问题[/b]
MySQL 中,在线对表对象做 DDL 操作是要锁表的,对于可用性要求比较高,而应用变化又比较频繁的环境,这是个非常很糟糕瓶颈。没想到有什么好的办法,除非,像大家开玩笑说的,把所有的表都预留出足够的空闲列,减少类似增加列的变更麻烦。
这个 MySQL 天生的缺陷在 PostgreSQL 中是不存在的,比如创建索引,可以用CREATE INDEX CONCURRENTLY 的方式来减小影响。(MySQL 后续的版本中在逐渐改善这个问题:添加了 ONLINE 关键字)
这个看似是个小问题,但实际上却是对很多人最为困扰的。
[b]在线备份问题[/b]
MySQL 6.0 后终于具备在线备份的能力了。但现在,恐怕比较激进的用户也只能用版本 5 而已。
很多 MySQL 资深用户能够根据自己应用的特点布署适合自己的备份方式(尽管可能也会有缺陷,比如基于时间点的恢复)。
至于另一个常用来衡量 DB 可扩展性的特性:分区,现在 MySQL 已经能够支持了,尽管实现的的确有点晚。而使用 MySQL 的用户,一般都采取 Sharding 的策略对数据进行切分,所以,分区的问题倒似乎并不是最为关键的。
[b]存储引擎[/b]
继续上一篇的讨论,记录针对 MySQL 在大企业级商用上我的一些零星想法。网络上到处都有关于各个引擎之间的对比。这里要提醒一点是,注意各个引擎的锁的粒度。InnoDB 是行锁,锁的实现是依赖于索引的,MyISAM 只是表锁。锁粒度是衡量存储引擎的一个重要指标,其能力很大程度上决定并发能力。
至于 TRANSACTION ISOLATION LEVEL,则是另外一个需要衡量的指标。
老生常谈的,某某引擎适合什么类型的应用,归根结底还是由于其实现的机制决定了引擎的特性。
[b]存储层的解决方案[/b]
相信没有人愿意在 MySQL 上用 RAW 设备,很多人几乎就是直接把数据文件放在文件系统上(个人认为,对于数据库这样的应用来说,文件系统可靠性还有所欠缺)。我还没发现 MySQL 上类似 Oracle ASM 的解决方案。如果用文件系统,单节点的数据存储能力肯定要受到制约--没有人喜欢把几个 T 的数据扔到一个 MySQL DB 上吧? 一旦某个文件系统故障,麻烦就来了。从这个角度考虑,或许 LVM2 是一个可选的方式。
当然,如果把数据文件扔到 SAN 上也还不错。一方面问题是,现在存储厂商对于 MySQL 的重视长度还远不如 Oracle、DB2 等老牌商业数据库。另一方面,很多 MySQL 用户没有 SAN 环境的,数据都是在本地磁盘上。
[b]固态硬盘与 MySQL[/b]
前两天有朋友在上一篇分析留言,提及应注重闪存的应用。其实还不如布署固态硬盘 (SSD) 对 MySQL 可能的影响问题。 相信现在有很多企业需要在 DB 的 IOPS 上寻求突破,SSD 是个可能的突破口,但从目前我收集到的数据来看,还没有足够的数据说明启用了 SSD 的 MySQL 能有预期的数量级上的 IOPS 提升。
[b]商业支持[/b]
现在 MySQL 的背后有 Sun ,但是,如果不购买服务的话,到哪里去找比较正规的商业支持(我是说软件集成商)? 即使购买了服务,如果问题出在存储引擎上,MySQL 能给即时、有效的技术响应么? 这也是 MySQL 没有自有存储引擎的一个弱点,因为衔接的环节多,一旦有商务上的问题,很容易陷入扯皮阶段。