非死book MySQL工程师吐槽MemSQL：MySQL比你们快无数倍

   <p> <strong>导读：前 非死book 前工程师 Eric Frenkiel 和 Nikita Shamgunov 创办了 MemSQL，对外宣称比 MySQL 快 30 倍。现在 非死book 的 MySQL 工程师 Domas Mituzas 出来说话了，以下是其在个人博客的博文：</strong></p>    <p> 我不喜欢这个愚蠢的基准，这完全是在浪费我的时间。同样，我也不喜欢所谓的市场营销。当然了，有时我还是会关注一下这些东西，现在我就占用你们点些时间来谈谈。</p>    <p> 所谓的 MemSQL，是由一群聪明的小伙儿鼓捣出来的，他们现在正在媒体和技术社区“兴风作浪”。他们的核心论断即：“MemSQL 比传统基于磁盘的数据库快 30 倍。”</p>    <p> 虽然他们这样说没什么意义，但我想知道他们到底哪里做错了。MySQL 和 MemSQL 都在默认设置下运行。他们说这是一个好的基准，通过安装标准包来比较用户体验。</p>    <p> 这已经是在说瞎话了，系统必须在完全不同的配置文件中运行。例如，用于数据缓冲的内存在 MemSQL 中本质上是解除绑定的，而 InnoDB 在 MySQL5.5 把它限制在了 128MB，这是 MySQL5.1 默认设置的 16 倍。</p>    <p> 至于写入性能方面，MemSQL 能写出 2G 的快照日志，而 InnoDB 设置为 10MB 的事务日志，所以会更快地开始检查点。尽管如此，对于基准来说，稳定持久是最重要的。</p>    <p> MemSQL 宣称支持 ACID，其中耐久性是最重要的一环。MySQL 的 InnoDB 默认是很耐用的，如果事务返回为“同意”，就会在崩溃后刻到磁盘上。MemSQL 默认也是很“耐久”的，它也会有一个事务日志，而这并不意味着跟磁盘有关。</p>    <p> MemSQL 也有事务缓冲设置，默认“完全耐久性模式”会不同时地返回“同意”直到 128M 缓冲区充满。本质上这跟 innodb_flush_log_at_trx_commit=2很相似，在我看来不会很持久。</p>    <p> 如果 MemSQL 激活了完全的耐久性会发生什么呢？结局肯定是悲剧。每次提交都得等后台线程才能写事务日志。多久后台线程才能醒一次？50毫秒一次。MemSQL 其实是玩的是计时戏法，每 50 毫秒冲一次，然后说后台线程一直没醒。</p>    <p> <strong>吐槽点一：MemSQL 每秒持久事务比 InnoDB 慢 500 倍</strong></p>    <p> 这一点很容易证明：在磁盘阵列控制器的后写式缓存模式下，InnoDB 能够轻易的维持单线程每秒 10K 的事务，在 fsyncs 空隙不会停 50 毫秒。有一些提交分组，两个线程有 40tps，十个线程有 200tps，但当我选择自己的基准时，MemSQL 单线程持久事务率会变得更慢。</p>    <p> 既然我们已经确立了 MySQL 的领先优势，让我们一起来看读写的表现。我敢肯定这方面 MemSQL 的表现会大亮。MemSQL 扫描表的执行速度还是不错的，每秒扫描 8M 行，这对单线程来说是很了不起的成就。</p>    <p> 说实话，我不想花时间用基准问题测试内存数据库所擅长的。我决定测试我最爱的查询：</p>    <blockquote>    SELECT * FROM table ORDER BY id DESC LIMIT 5    </blockquote>    <p> 网上到处是这个查询，MySQL 通过指向索引位置的游标，然后按照指标顺序逐步游动。而 MemSQL 实际上必须穿越整个目录，分类提供响应。即使是“SELECT MAX (id)”也需要穿越整个目录。</p>    <p> <strong>吐槽点二：MemSQL 在做一些简单的读写查询时，比 MySQL 慢上千倍，也许是慢百万倍</strong></p>    <p> 我们假设 MemSQL 在一些普通运算有O(N) performance，因此我们只需找到那个足够大的N。我不知道我们应该如何责备 MemSQL 的研发人员和被他们误导的那些记者朋友。如果我们回到 ACID，A代表原子性，只在语句级实现，BEGIN/COMMIT 被无视了。隔离性是提交读。持久性是有缺陷的，我不关心字母C所代表的。我必须承认，MemSQL 常见问题中说，MemSQL 支持完整 ACID 事务，当然了，说是这么说。</p>    <p> MemSQL 每秒 80000 次查询没什么值得炫耀的，因为现在 MySQL 有了 HandlerSocket，计算能力接近每秒百万次。当然了，他们也有自己擅长的事情，目前是最快的 MySQL 协议，当然也没超出 MySQL Cluster 多少。NDB 也有很不错的表现。我确信，我上面的两则声明会被一些技术工作所完善。写入性能需要适当的实时与分组提交同步（虽然二进制日志所涉及的工作很复杂，MySQL 最近还是推出了几项重大更新）。</p>    <p> 读取性能需要实现最常见模式的最优化，例如按索引顺序读取。内存是快，但还没快到高并发环境所需要的一遍又一遍的重复读取。即使在 MemSQL 表现良好的部分，我也怀疑 MemSQL 的内存工作负载能否超过 InnoDB30 倍。今天我就不做基准测试了，但我还是能很轻易的证明这一点。</p>    <p> 无论如何，如果我们清楚 MemSQL 的一系列动作或是有一个不错的标杆管理的话，也就不需要我这篇稿子了。接下来我们就开始测试吧，然后得出属于自己的结论。</p>    <p> 文章来源：<a href="/misc/goto?guid=4958346322142776168" target="_blank">dom.as</a></p>    <div id="come_from">    来自:     <a id="link_source2" href="/misc/goto?guid=4958346322945136999" target="_blank">CSDN</a>    </div>