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

封装业务逻辑:存储过程

在商业数据库软件的实践方式上,利用存储过程封装业务逻辑是非常通用的做法(也有很大一部分原因是 IT 架构演化造成的)。MySQL 5 之后也支持存储过程,如果要把 Oracle/DB2 等的就有逻辑迁移到 MySQL 当然不是容易的事情。最好的办法可能是:不在存储过程上动脑筋,在应用层想办法。

谁是”推手”?

让我们回过头来,看看当年 Linux 与 FreeBSD ,为什么 Linux 走入企业市场,而 FreeBSD 仍然算非主流。最为主要的一个原因是 Oracle 选择了 Linux 而不是 FreeBSD ,从而带给 Linux 极大的机会。如果说 Oracle 是 Linux 成功背后的推手,那么今天的 MySQL 推手在哪里? 云计算? 前一段时间可能还不能看的很清楚,不过经济危机倒有可能会给 MySQL 带来大规模部署的可能,如何 省钱,是现在很多企业必须要考虑的问题。。

可裁减的 MySQL

类似 Drizzle 这样经过精简后而用户某种特定应用的形式,相信能够在一些企业内部运用,并且成为主体架构的有效补充。

关于 ZFS

这里可能要修正一下之前的某些看法,在存储层其实 ZFS 是个不错的途径。ZFS 可发挥的空间不小,只是看什么时候能够在 Solaris 系之外的操作系统上跑起来。

用户学习成本

相比其他商业数据库软件,MySQL 总体学习成本更低,但如果深入到架构层并非易事。至少国内目前仍然大量缺乏 MySQL 好手。如果 Sun 能在 MySQL 的技术推广上继续深挖,相信会有一大批技术人员投入其中。当然,一个企业采用 MySQL 与否,还要看很多因素。但起码要能改变 MySQL 技术人员”很山寨”这个固定的思维模式。

结语:如果非要写个结语的话,还是觉得 MySQL 下一步能有多大的成就,要看 Sun 如何对待这个宝贝。买椟还珠的事情常有。

EOF

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

15 thoughts on “MySQL 大企业级应用可行性分析(之三)

  1. maincoolbo

    冯大师的技术真是强,仰慕中,,
    大师以前写过很多oracle的文章,希望能在mysql上能有所突破,给我们带来 惊喜

    Reply
  2. Terry Wang

    非常同意,Oracle确实是Linux进入企业应用领域的最大幕后推手。
    即使FreeBSD再稳定再性能好,不被no.1 DB vendor支持是一个硬伤。
    ZFS很值得期待,看了open solaris上的演示和教程,赞叹中… OSX Snow Leopard是铁定有戏,但是不知道在个人OS上应用能否发挥其所有优势,还是个问号。可能更让我期待的只是能在一个人OS上用号称最高性能最优秀的文件系统吧:)
    至于Linux和其他OS,还得看如何摆平license和legal方面的事宜,我是不懂…

    Reply
  3. xxxx

    让我们回过头来,看看当年 Linux 与 FreeBSD ,为什么 Linux 走入企业市场,而 FreeBSD 仍然算非主流。最为主要的一个原因是 Oracle 选择了 Linux 而不是 FreeBSD ,从而带给 Linux 极大的机会
    有点扯了吧……
    没有intel,没有ibm等等,oracle仅仅是个小卒。

    Reply
  4. Fenng

    @xxxx
    IBM 的投入当然是一个原因,至于 Intel ,就算了吧
    还有告诉我 Intel/IBM 有什么应用是真正对 Linux 支持的很好的? 主机么?

    Reply
  5. fmd

    最近给MySQL搞得焦头烂额…..
    毫无征兆, 毫无规律, binlog无记录的情况下, 之前更新的记录自己回滚了…

    Reply
  6. 丁宇

    Solaris之外的Leopard已经可以支持ZFS了,Snow Leopard直接支持ZFS的希望更大(至少为进一步完善Time Machine,这是一个很值的迁移)。
    年初有一篇详细介绍ZFS优点的blog文章,可惜找不到了,记得是发表在一个装有默认皮肤Wordpress的blog上,谁有链接?

    Reply
  7. noname

    这个系列文章应该改名为 Mysql在企业级应用中需要注意的问题
    而不是 大企业级应用可行性分析。

    Reply
  8. Ds.3783

    MySQL 的MyISAM引擎已经让我们郁闷了很久了,我们使用的是5.1.4,里面存在至少两个已知的致命问题:
    1.坏表,相信很多人都遇见过,文件系统是正确(中间没有断电/reset之类的事情)的就是表突然坏掉,并且对表的操作只有insert update delete select.
    2.脏数据,这个是有实践例子的,例如:表A ID为3的Online列数据为0 ,我在0点0分0.000秒update 表A set ONLINE=1 where id=3;但是另外一个connection 在0点0分0.020秒执行select ONLINE from 表A where id=3时得到的结果却是0。(PS:MyISAM引擎表,没有事务)
    Innodb的引擎没有测试过,但是也无力测试了……

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *