memsql和mysql_facebook 工程师吐槽“memsql”-比mysql更快的的数据库

我不喜欢愚蠢的基准，因为他们浪费我的时间。我不喜欢愚蠢的营销，因为它浪费我的时间了。有时候，我屈服于那些东西，现在作为回报我不想浪费你的时间了一下。

所以，这MemSQL的事情，写一些聪明的家伙一直在轮在媒体和技术社区。所有通信的核心是：

“ MemSQL ，他们已经开发在过去一年的数据库，比传统的基于磁盘的数据库快30倍”

虽然我通常理解，这些说法没有任何意义，我想知道哪里错了。显然，他们得到了MySQL的使用默认设置运行和MemSQL与运行默认设置，然后比较这两个。他们说，这是一个很好的基准，因为它比什么用户得到的只是通过安装标准封装。

这已经是欺骗，因为系统是被迫工作在完全不同的配置文件。例如，内存用于数据缓冲，是MemSQL基本上是未绑定的，但InnoDB的有它限制在128MB 5.5 (这是16倍于5.1所使用的默认设置) 。

对于写基准MemSQL将写出快照2G日志标记， InnoDB的配置有10MB的事务日志，因此它会检查点开始几乎立即。

不过，对于任何基准，最重要的就是耐用性。见， MemSQL声称他们支持ACID，和耐用性是该核心部分。 MySQL的InnoDB的(我不认为其他引擎是可用的)，经久耐用默认情况下，确保如果它说，交易返回“OK” ，它是在磁盘上和在崩溃后会在那里。 MemSQL也是“耐用默认” ，这意味着它会写入事务日志，但它并没有真正意味着它会撞到磁盘。

见， MemSQL也有“交易缓冲区”设置，该设置，在默认的“完全持久性模式”，将异步返回“OK ”，直到128M缓冲区已满(或后台日志冲水器线程将其写出来) 。本质上讲，这是类似的innodb_flush_log_at_trx_commit = 2的东西。在我看来，不耐用。

如果你真的能在MemSQL完全持久性，会发生什么？绝对的悲伤呢。显然，每一次提交会等待后台线程醒来并写出事务日志。多久后台线程醒来？每50ms 。那么，它实际上并占时间的魔法，冲洗每50ms ，并要求非常精确的睡眠。

根据权利要求1： MemSQL是500倍慢于耐用交易第二个比InnoDB的。

这是比较容易做后盾的时候了 - 与具有后写缓存体面的RAID控制器时，InnoDB可以轻松地维持10K的交易从单个线程一秒钟，因为它不睡50ms的fsyncs之间。有一些犯有分组，两个线程将有40tps ，十个线程将有200tps ，但我能选择我自己的标杆我声称MemSQL是500倍慢于单线程耐用的成交率。

现在，我们建立了MySQL的优势(哈哈) ，让我们来看看的读取性能。我当然同意，这就是MemSQL应该大放异彩。我不同意，其执行速度表扫描不坏 - 8M行扫描的秒( SELECT COUNT ( * )查询)从单个线程肯定是一个了不起的成就。

说实话，我不想花我的时间基准是什么一个内存数据库应善于(我敢肯定，它并随机点上skiplist就好读取) 。相反，我决定测试一下我最喜欢的查询：

SELECT * FROM表ORDER BY ID DESC LIMIT 5 ;

你知道，这是一切围绕网络查询 - 向您展示各种列表的头。 MySQL的过程是由一个指向光标处的索引位置，然后步行通过记录在记录索引顺序。不MemSQL ，它实际上将不得不遍历整个表和排序，返回你答案。即使是“ SELECT MAX ( ID )”不能抓取整个表。

索赔＃ 2 ： MemSQL是比MySQL慢千倍。或万次慢。在简单的读查询。 (我一直在纠正这个 - 显然是在MemSQL指标是单向的，所以你必须定义单独的索引你要读取表中的每个方向) 。

那么，一旦我们确定MemSQL将会对一些常见的操作为O(N )的性能，我们需要的只是找到一个N足够大;-)

我不知道我们有多少应该责怪MemSQL家伙，多少应该冲着记者说，被炒作的技术。如果我们得到返酸，我们会看到一种原子仅在语句级完成， BEGIN / COMMIT被忽略。隔离是只提交读(很难有重复读，没有真正的交易) 。耐用性是有缺陷的，而且我没有检查的C部分。我得承认， MemSQL常见问题指出，“是的， MemSQL完全支持ACID事务” 。这是对他们的话。

80000查询上MemSQL数第二个是没有什么令人印象深刻的，与什么比较现代的MySQL可以做(特别是与HandlerSocket的) - 人正在接近亿元查询几秒钟之内有:-)

但是，绝对，的东西，它做得很好，它是目前速度最快的MySQL协议来说事，虽然它不是那么远的MySQL集群，和人交谈，以NDB是有也相当不错的表现(真是惊人表现，这是) 。

我敢肯定，我的这两个要求可以固定一些工程工作。写性能需要适当的实时与组做同步处理提交(已有关于最近太在MySQL世界上一些大的发展 - 虽然当二进制日志是参与事情的方式比较复杂) 。

读取性能需要适当的优化，为最常见的模式 - 索引顺序读取，例如。内存的速度很快，但还不够快，如果高并发环境下需要做这样一遍又一遍。甚至为它做什么好，我有点相信它不会出格表现InnoDB的30倍在内存中的工作负载。我懒得基准日，但这个'索赔＃ 3 '是不是很难证明:-)

无论如何，我们就不需要这个职位，如果有一个像样的披露行为和正确的标杆。现在，我们得到多个相互冲突的声称，实在是太容易测试的几分钟之内发现。太简单了。

转载请注明本文链接：http://www.simapple.com/247.html