技术开发 频道

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

        【IT168 评论】本月初,甲骨文公司发布了正式版的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抛弃。

  原文链接:http://www.searchdatabase.com.cn/showcontent_70636.htm

0
相关文章