Over the past couple of days a number of people have asked my opinion of the latest MySQL 5.6 release. For those who haven’t seen the news, Oracle announced its first major MySQL release in two years. Since NoSQL has grown rapidly in key markets where MySQL has historically been strong, I guess it’s not surprising that Oracle focused a lot of attention on addressing weaknesses that have made NoSQL such a big success. Tomas Ulin, VP of MySQL Engineering, even goes so far as to say that “MySQL can combine the best of both worlds” and “you no longer need two databases.”
Tomas and MySQL’s view of the database world seems to be that it will be no different than what it’s been for much of the last 40 years – mainly that relational technology can do it all and is the right technology for every need.
We don’t believe that. We believe we’re rapidly moving to an era where multiple database technologies are available to application developers and they will pick the right database for their particular use case and requirements. Each technology will have its inherent strengths and weaknesses and provide a very different set of tradeoffs to pick from. Sometimes a relational technology like MySQL will be a better fit (we certainly don’t believe relational technology is going away). Other times a document database like Couchbase will be the right fit.
This is why I don’t think MySQL 5.6 will have any affect on the rapid growth of NoSQL. The reason NoSQL is taking off isn’t because it has a hot feature or two. It’s because it has made a fundamentally different set of architectural choices and tradeoffs that many app developers prefer for the kinds of applications they’re developing today. Adding a feature to a relational database as a response to what people say they like about NoSQL isn’t going to change these fundamental differences.
For example, relational technology is fundamentally a schema-based technology of tables, rows, and columns. Adding a capability like the new online data definition language (DDL) in MySQL 5.6 to make it easier and less time consuming to change your schema doesn’t make a relational database schema-less. Nor does it address the fact that many developers find it far more intuitive and productive to work with documents (objects) in a document database than the tables in a relational database. So while this feature may be helpful to developers who have selected relational technology for its fundamental tradeoffs, it will do nothing to slow the wave of developers who have moved to document (or other) NoSQL databases for their fundamental tradeoffs.
Likewise, with MySQL 5.6's new memcached API, it might make it easier for developers to access data using the classic get and set APIs, but the implementation is only skin deep. The data being stored still gets mapped to tables and columns at the storage tier. Developers still need to define their table schemas before using these APIs, which means that they still do not get the schema flexibility web applications need. Shredding data that is unstructured – and constantly changing in structure – so that it fits into tables and columns is a forced and inefficient approach.
As a side note it’s curious that the MySQL team seems out of step with other parts of Oracle. While the MySQL team seems to be convinced MySQL can do it all, Oracle’s NoSQL team seems to feel differently and is busily trying to catch up to NoSQL leaders like Couchbase, MongoDB, and Cassandra with their own NoSQL product. If relational technology is a one size fits all technology, why is Oracle itself making such a big investment in developing its own NoSQL product?
What we see is a whole new wave of applications that have very different requirements than applications had just a few years ago. More often than not they are cloud-based, need to support a huge and dynamically changing number of users, need to store huge amounts of data, and need a highly flexible data model that allows them to adjust to rapidly changing data capture requirements and process lots of semi-structured and unstructured data. The fundamentally different architectural decisions embedded in NoSQL technologies – along with the easy scalability, consistently high performance, and flexible data model advantages (along with all the other tradeoffs) NoSQL provides – are turning out to be a better fit for an increasing number of these applications.
That doesn’t mean MySQL (or relational databases) will go away or won’t play a significant role in the database industry in the future. It just means developers will have more choice (always a good thing) and that some very powerful trends are very well aligned with the strengths of NoSQL technology.
IMHO, handlersocket (which allows access to storage engine without SQL layer) was a perfect NoSQL-like bridge between the two worlds. Filling a gap of products which want to provide higher rate of access to objects while maintaining transactional capabilities of the underlying engine. Oracles attempt at \”NoSQL\” is pretty lame. You have to manually create / set up mappings to object stores in a special database, and these special tables have to be defined in a specific way. Thats pretty restricted.
With handlersocket, I simply open the db / table of choice, and then fire away. The big downside atm? Handlersocket won\’t compile with 5.6, and until it does, there is no way to reap the benefits of the improvements Oracle have made at the InnoDB level.
Another downer is the performance of the new memcache nosql interface. On my box running 5.6, it handles 500,000 rows a second read. Handlersocket with 5.5 on same box, manages 800,000 for same data profile. I wish Oracle had just taken the Handlersocket ball and run with that instead.