There is a HTTP plugin for MySQL available at labs.mysql.com. Ulf Wendel covers it in more detail.
The development preview brings three APIs: key-document for nested JSON documents, CRUD for JSON mapped SQL tables and plain SQL with JSON replies. More so: MySQL 5.7.4 has SQL functions for modifying JSON, for searching documents and new indexing methods!
At this point I still have more questions than answers, but I’m definitely intrigued.
6 replies on “HTTP Plugin for MySQL”
MySQL wants to play the NoSQL game…
I think that could be part of it. Though the biggest so called “NoSQL” systems usually point to other features beyond the transport layer as advantages over traditional DBs.
It just makes sense: a web database which cuts off half of the web developers does not sound. It ever made sense to me since I learned about CouchDB. And, if web folks want documents, so be it.
I’m curious, any benchmarks of transactions per second comparing native MySQL transport vs. HTTP?
I’m afraid it is too early. It is not even clear whether we can keep the web server library or have to replace it. Performance was no goal. It is a goal for the Memcache plugins but not for us. We need proper APIs before we can fiddle with performance.
The transport impacts network traffic but not so much query execution performance. Inside MySQL its the same code for running SQL thus the same overall performance can be expected.
The Memcache plugins hint the best possible performance. If you want to see how MySQL compares to a NoSQL Key-Value store, use the Memcache plugins for benchmarking. Then, add a bit to the Memcache plugins due to the more verbose HTTP protocol to extrapolate what might be possible after hefty optimizations. The Memcache plugins are ~2x as fast as comparable SQL request because they bypass the SQL layers inside MySQL. In 2004 I learned MySQL spents ~50% of the total runtime of a simple SELECT for parsing SQL and “overhead” – that’s still the case, thus the 100% speedup (~2x as fast) with the InnoDB Memcache plugin.
The 1.0.0 maps all requests to SQL. After all its just a convenience feature for those who do not want to write a HTTP -> MySQL proxy themselves. We did not do any benchmarking. We only did a quick sanity check on a laptop checking HTTP Request -> Apache -> PHP (SELECT 1) -> MySQL vs. HTTP Request -> Plugin (SELECT 1) -> MySQL. The Plugin won. If one removed the web server overhead and compared PHP/…(connect, SELECT 1, disconnect) -> C/S Protocol -> MySQL vs. HTTP -> Plugin(SELECT 1) -> MySQL there should be no major difference.
If it was on par with the traditional MySQL transport that would be pretty good.
Definitely. It wouldn’t matter how fast it was if it didn’t work properly.