? ? ? ? 【IT168?评论】摘要：本文讲述了Anders Karlsson在发现MySQL与MongoDB对比中处于劣势后挖空心思的对MySQL进行提升。各种存储引擎、各种内存管理引擎及嵌入式思想，在各种尝试后MySQL也是终于取得了胜利。然而这种胜利真的能称为胜利吗?或者这种胜利真的是大家想要的吗?

　　初步的键值比较，MongoDB完胜

　　快还要更快，这一直都是我们给予数据库系统的目标MySQL Dragster把磁盘的速度当作它的最大障碍，这真的能说通吗?姑且就把作一个障碍，那解决方案呢?!如果一个障碍限制了你的Dragster，你完全可以选择更快的绕过它或者在计算机方面提升。举个例子：

　　·避免使用磁盘，尽可能的以内存替代

　　·用更快的磁盘(如SSD)

　　其实上面这对类比并不好，因为来自磁盘的限制是如此之大，而且出人意料的是从未得到过改善。你可能会说，我们不是有SSD吗?对，这的确让硬盘得到了提升，但是别忘了：CPU和RAM提升的速度比之硬盘来的更快!但是不妨假设一下，我们的内存大到可以直接取代硬盘了，那么一切就运行的与光一样快了?显然不是，所以不要再露出硬盘是你最大限制的丑恶嘴脸了!

　　如同CPU核心的提升速度越来越快，有一天突然不再像以前提升的那么迅速了。为了解决这个问题，多核心技术诞生。然而限制新CPU性能的问题接踵而至，成为了最令人头痛的问题!比如线程的互斥!又比如MySQL里的Query Cache互斥!

　　言归正传，现在终于可以开始测试在5月拟定的基准了(英语文献)。这里说一下为什么这么久才开始，因为把数据加载到MySQL中花了很多的时间。在这个过程中，我创建了一个开源项目，用于把JSON中的数据导出来然后导进MySQL中。这项工作完成后，我就拥有了以现实世界规则分类的数据。在这里，还必须得删除一些列从而MySQL就可以处理这些数据了，因为MySQL Cluster只能在磁盘上存储定长的数据。这个给我来了很大的工作量：

　　·大量的原材料要写入磁盘

　　·UTF-8编码更意味着3倍以上的数据要写入

　　这样就保证了MySQL Cluster的良好的运作，但是还有一些特殊的情况，这个取决于值的类型。假如值的类型是文本或者类，那么我们还必须使用VARCHAR或者类似的格式，这些才真正的限制了MySQL Cluster。为了让MySQL运行的更加完美，只能创建很简单的表格：

　　在这张表格里，加载了大约1.05亿行数据。这对于MySQL Cluster来说应该是小菜一碟，对吧?但是还要除下MySQL Cluster只支持每部分512MB哈希数据(真正愚蠢的限制)。万般无奈之下只能把数据分成5个部分，这一部分工作也算是完成了。

　　不得不说，没有磁盘数据，MySQL Cluster运作起来稳定了很多。偶尔的数据丢失和其他古怪在加载VARCHAR格式数据表格时都没有发生。因此，不仅是磁盘上的数据限制了你，你的数据类型(VARCHAR)看起来也需要进一步的完善。

　　言归正传，我的服务器(8核心的AMD CPU和16GB RAM)已经就绪。将对拥有InnoDB储存引擎的MySQL、MySQL Cluster及MongoDB进行测试。测试的项目是在同等情况下10次对分布在100个线程上100万行数据进行读取。为了公平起见，必须确保我需要安装进内存的数据已经被放在内存上，所以先试运行了两次。NDB情况下，将使用MySQL API(NDBAPI将在最后进行测试)。结果如下：

　　·MongoDB 110000 rows read per second

　　·MySQL with InnoDB 30000 rows read per second

　　·MySQL with NDB 32000 rows read per second