吐槽：MySQL 5.6的NoSQL功能如“鸡肋”

2013年初，甲骨文公司发布了正式版的MySQL 5.6数据库(参考：甲骨文发布最新MySQL 5.6版 )，其中增加了一些NoSQL特性，即通过Memcached API对InnoDB的灵活NoSQL访问，提供了InnoDB数据的简单、关键值查找。然而在一些业内人士看来，MySQL 5.6的NoSQL功能却形如“鸡肋”。

　　大数据创业公司DataStax的技术总监Jonathan Ellis近期就在博客中对MySQL 5.6的NoSQL功能进行了“深度”的吐槽，他认为甲骨文还没有摸到NoSQL的门呢。以下就是Jonathan Ellis的几个观点：

　　1. 扩展性

　　普遍的观点认为NoSQL的一个主要优势就是横向扩展(Scale Out)，这也是许多公司从MySQL转向NoSQL(Cassandra)数据库的一个重要原因。而随着MongoDB的崛起，越来越多的公司也开始从MySQL转向MongoDB阵营。

　　Cassandra能够简单透明地在多个机器上进行扩展，它们可以是廉价的硬件组成的集群，而无需购买昂贵的服务器或者SAN存储。但同样重要的是，透明地按需扩展和缩减集群的能力，使得公司能够更好地利用云的灵活性，针对小型工作负载可以添加合适的计算能力。这一点MySQL 5.6是做不到的。

　　2. 持续可用性

　　Cassandra的普及率在不断的升高，其中一个原因就是扩多数据中心组成单一集群的能力。可协调的一致性使得Cassandra能够在数据中心内部进行同步复制，同时异步复制到其他数据中心。

　　另一方面，基于主机的复制由于限制往往会造成较大的延迟，即便多主复制在关系型数据库方面也无法解决这一问题，因为两步提交机制也需要多个round-trip。

　　而通过多数据中心的无主复制，Cassandra能够对整个数据中心进行无缝的故障转移，并在电力或连接修复之后对未同步的机器进行修复。

　　3. 灵活性

　　NoSQL另外一个流行的原因，就是让设计原型更加灵活，特别是面向文档型的数据库，如MongoDB。添加JSON的支持是非常有用的，就像PostgreSQL最新的更新一样。

　　但是MySQL的memcached层只提供了一个键值(key/value)API，在表达性方面存在巨大缺陷与限制。

　　4. 性能

　　基于B-tree的存储引擎(InnoDB和MyISAM)事实上并不适合传统磁盘和SSD，因为有很多小的随机写入操作。但为何关系型数据库又是如此强势呢，主要还是因为SQL语义。比如，INSERT或UPDATE需要首先进行一个行的读取以确保它是否存在。

　　这也是为什么MySQL数据库的写性能在数据集增长的时候会随之下降的原因。即使是针对相对合适的数据集，在混合的工作负载之下，这一结果也会逐渐显现。

　　5. 查询语言

　　在NoSQL世界中，相对不太重要的就是查询语言，但甲骨文还是非常重视这一点，这也是没办法的事。比较讽刺的是，Cassandra现在也开始越来越多地转向SQL语言，以改进分布式架构中的性能。而像 batch_mutate 和 get_slice_range这样的复杂API已经被Cassandra抛弃。