NoSQL on MySQL: stating the obvious

Some of the NoSQL vendors seemed to have stirred up a mild controversy with their reactions to the launch of NoSQL access to InnoDB in MySQL 5.6 and their suggestions that NoSQL access is only a part of the NoSQL story.

Mark Leith, software development senior manager at Oracle has described the criticism as laughable and Oracle’s director of MySQL product marketing, Mat Keep, accused the NoSQL vendors of “trying to stand on the shoulders of giants” (which is pretty ironic given we are talking about Oracle adding NoSQL capabilities to one of its databases).

In any case I don’t see what the fuss is all about.

Sure, Couchbase and DataStax laid it on a bit thick, but these are corporate blog posts – it goes with the territory.

Besides while it might seem churlish to criticise NoSQL access to InnoDB in MySQL 5.6 for not being a document database or for enabling masterless multi-datacenter replication, the responses are valid in the context of hyperbolic claims that “MySQL can provide the best of both worlds… You don’t have to split your data and manage two databases.”

The caveat to all these claims, and indeed probably any claim ever made in a corporate blog, is “if it suits your particular application requirement.”

Back in early 2011 when we first considered the momentum behind NoSQL development and adoption we highlighted six key drivers:

  • Scalability
  • Performance
  • Relaxed consistency
  • Agility
  • Intricacy
  • Necessity

How many of those are addressed by key value access to the InnoDB storage engine? Query performance and agility, certainly. Necessity, perhaps – but only if your application workload requires both SQL and key value access.

As we stated when Oracle first began previewing key value access to the InnoDB storage engine:

“Support for data access using the memcached API by no means alleviates the need for NoSQL alternatives, but it will provide additional flexibility and agility for existing MySQL adopters.”

I also have to agree with Couchbase that this is a point that is illustrated by the existence of Oracle’s own NoSQL Database. As we stated at the time of its launch:

“The launch of Oracle NoSQL is… a clear indication that there are trends at work here that cannot be solved by adding non-SQL querying to existing relational databases.”

And that’s really all Couchbase and DataStax are pointing out.

If you’re looking for an offering that provides direct, key value insertion and querying of data in addition to SQL-based access to relational database tables, then MySQL 5.6 is clearly a leading contender. If that’s all you’re looking for, then you could arguably forget the need to manage two databases.

That clearly doesn’t necessarily make MySQL 5.6 suitable for use as a pure key value store, let alone a document database, or wide-column store, or graph database. If those are your requirements, MySQL 5.6 isn’t the best of any world, let alone both.