MariaDB和MySQL二者的比较

MariaDB是MySQL源代的一个分支，在意识到Oracle会对MySQL许可做什么后分离了出来（MySQL先后被Sun、Oracle收购）。这些担忧是有依据的，我会在本文的后面讲到。

现在选择继续使用MySQL或抛弃它切换到MariaDB有足够的理由。

MariaDB博客上的性能测试。

MariaDB是MySQL源代的一个分支，在意识到Oracle会对MySQL许可做什么后分离了出来（MySQL先后被Sun、Oracle收购）。这些担忧是有依据的，我会在本文的后面讲到。除了作为一个Mysql的“向下替代品”，MariaDB包括的一些新特性使它优于MySQL。

在介绍这些特性前，我想先谈谈MariaDB的版本编号模式。首先，MariaDB版本与Mysql版本相匹配——比如MariaDB 5.1，与MySQL 5.1使用相同的代。由于更新和修复是针对MySQL源的，这的话MariaDB可以采纳这些补丁（理论上，MariaDB每月都与MySQL源合并）。但是如果新的独特特性定期添的话，我想代验肯定会是一个恶梦。

MariaDB团队应该也意识到这一点，他们已经开始制定新的编号方案。最新的MariaDB版本（目前仍处于alpha状态）是Maria 10.0，后面跟着一个小数：

mysql -P 3406 -u root -p

Enter password: ********

Welcome to the MariaDB monitor. Commands end with ; or \g.

Your MariaDB connection id is 1

Server version: 10.0.2-MariaDB mariadb.org binary
distribution

Copyright (c) 2000, 2013, Oracle, Monty Program Ab and
others.

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current
input statement.

MariaDB [(none)]> select version();

+—————-+

| version() |

+—————-+

| 10.0.2-MariaDB |

+—————-+

1 row in set (0.01 sec)

MariaDB [(none)]>

MariaDB再三甚至有些散漫地解释为什么他们这做——尽管这让开发者感到不适，但它就是这。如果依旧完全兼容Mysql的话他们不能继续添新特性。

至于新特征？让我们看一下其中的个。

Cassandra引擎

MariaDB的一个独特特性是它的连接到Cassandra后端的引擎。引擎本身只是一个入到Cassandra服务器中单独运行中介（Cassandra是一个NoSQL类型的键-值存储，由Facebook创建后来成为了Apache的项目；它可用于集群且没有单点故障，它同不是完全ACID的）。通常，如果使用Cassandra引擎的话就法获得与InnoDB或extradb相近的速度或性能。

但是可以通过MySQL访问数据，通过允许selects、inserts、updates、deletes甚至拓展的join就像使用SQL感觉一，但MariaDB团队表示Cassandra引擎不适合大量数据的分析类查询。

所以这个功能可能有用如果……，呃，让我们接着看……

如果在写一个需要访问Cassandra数据应用软件，那么最好直接使用Cassandra的原生API而不是通过MySQL。如果的注意力在MySQL命令行，且需要抓一些数据，这种情况Cassandra引擎可以派上用场——但如果打算这做的话，可能只想尝试下Cassandra的命令行界面。

所以我真的不知道哪种是适用情况，但这并没有阻止一些人在博客上抒发对此功能的兴奋之情。

OQGraph引擎

我不会介绍这个特性的全部，为它跟Cassandra想法相同：这个引擎是图计算引擎的开放查询接口。这对一些特定的应用可能有用，尽管表面上看将图形结构射到SQL式有些古怪。

MariaDB的一个重要的增强力量是使用xtradb作为InnoDB的向下替代。而且xtradb增了现代软件所需要的可扩展能力——这是心不同点。Oracle声称MySQL现在的拓展性比以前好，可能的确如此，但引擎还是那个引擎。如果引擎不能真正具备拓展性，那么MySQL也同不具备。

原子写

选择关系型数据库而不是NoSQL的主要原是前者对ACID的完全支持。简单的说，如果有失败，不想丢失数据。尽管故障可能并不经常在我们的开发用机上发生，但在很多的IT中心却很常见。目前，默认的InnoDB/XtraDB引擎采用双缓冲的方法来写入数据以确保崩溃时数据能写入成功。然而，当使用高速的SSD设备时（打个比方），双缓存对性能有负面影响——会减小SSD在访问速度方面的优势。解决办法是什么呢？现在可以关掉双缓冲打开所谓的原子写。先在磁盘上验证再应用到生产环境。

同是一个有趣的功能，但还不是那个让转用MariaDB抛弃MySQL的特性。

MySQL和MariaDB的性能比较

现在把目光移到benchmark上面来，它其实也是由MariaDB团队开发的，并了一下额外的说明。这篇博客提到了一个有趣的地方：把MYSQL5.6的线程数一直增到16，性能都很好，但是超过了16的话，尽管性能也有提升一点点，但比较发现，远不如其他版本(包括MairaDB-5.5.28a和MairaDB-10.0.1;参考文顶部的性能测试图）。这在单计算机里面试图达到多多线程的效果的并行程序时，都会有此类的通病。如果算法设计得当，随着CPU心数的增，性能也会跟着提升。当然问题是，必须在并行程序中处理好2个方面：(1)跨多的多线程问题(2)矢量化。这也是当前面向多编程的两个方向，编写的必须能很好的控制这两个方面。

如果没有正确的编写代将会得到一个共同的结果，即在用8到16个线程的开始就想看到好的结果，但在这些线程运行之后不会看到期望的结果。将会看到这个问题，这意味这可能是算法问题。(这也不是超线程或是硬件线程成的)这就是我们在这里看到MySQL 基准的问题。对于我来说，这就是MySQL规模化产生问题的迹象，这也是令人担心的原之一。MariaDB在同的基准中也有一些小问题，但是比MySQL要轻微的多，只能说是勉强吧；我推测这个问题在并行计算中可能不会出现。
我也不知道在测试中怎才能很好的据不同机器指定不同的编译器来与之匹配。当为Intel编译代时，需要为目机器编译生成合适的SIMD代；如果不匹配，将不会得到所期望执行的矢量代。为了能正确处理，需要在代中插入正确的编译指示代，然后要写下正确的矢量算法，最后在选择合适的编译器。我知道这看起来很愚笨，但我看过一个发行产品用错误的编译器所成的结果是法想象的。好歹，很明显，MySQL代在多和矢量化中的优化没有MariaDB好。

(我真正想看到的是，MySQL或MariaDB的一个分支为Intel Xeon Phi处理器心做一个特别的编译，使代转移到61 心协处理器，并且有人能尝试速所有244个线程。可惜我没有接触过这的机器。同的，如果想学更多关于向量化和并行方式编写代方面的知识，检索最近Intel公司 James Jeffers 与 James Reinders写的文“Intel Xeon Phi 协处理器高性能编程”。）

应该转移吗?

很明显，MariaDB的新特性并不是都这么好——可能需要连接 Cassandra 来获取一些数据，但是我很怀疑会使用 MySQL 去做这件事情。关于这个平台上提供的其他引擎也有类似的争议。MariaDB的性能看起来在多环境下表现不错，但是我强烈怀疑其实通过调优，MySQL 也可以做到。

所以还应该转移到 MariaDB 吗？

首先，考虑潜在的风险（高层管理者都喜欢听风险和利益）。如果迁移到 MariaDB，可能会使用特定于 MariaDB 的特性（但目前似乎还不可能），然后发现很难再用很小的资源切换回 MySQL 。但是我想说的是，这个并不真的是一个风险，下面从更大的范围里讨论一些问题。

考虑一下关于 Oracle 以及 Oracle 对 MySQL 授权的问题。免费以及开源的 MySQL 要与 Oracle 极具竞争力的专有软件竞争。那么，Oracle 会做什么事情阻止 MySQL 的开发呢？（一些人可能会说，这的事情已经发生了）

那么，MySQL 和 MariaDB 的兼容性如何呢？MariaDB 团队正尽力去保持对 MySQL 的全面兼容，他们继续向源中提交 bug 修复。但那些新特性（以及版本方案）表明，尽管尽了最大的努力，这两个平台还是会继续分裂。

如果 Oracle 向 MySQL 添 MariaDB 不采纳的新特性，这些特性明显不会对可用。如果正在使用 MySQL 不具备的 MariaDB 特性，将不能轻易地切换到 MySQL 。 MariaDB 表示这的情况很可能存在一段时间，然而也不能说相同的情况不会在 MySQL 中出现。就是说，即使 MariaDB 的新特性并不那么有用，但是（在我看来）已经有足够的理由从 MySQL 迁移到 MariaDB 了。

（在结束这篇文前说一件事：即在 blogosphere 的作者提出过的一个关键问题——服务协议。如果在的公司总经理疯狂到向 Oracle 购买了服务协议来帮助开发管理 MySQL 数据库，那么可能愿意停留在MySQL 以避免为违反协议而成的财务和法律上的问题。但除此以外，我看不到什么理由继续使用 MySQL 数据库）