
You Got NoSQL in MySQL: Memcached Plugin in MySQL Technology Preview - Anon84
http://www.readwriteweb.com/hack/2011/04/you-got-nosql-in-mysql-memcach.php
======
seldo
The much-more-informative original blog post from MySQL's site, which RWW
doesn't seem to link to for some reason:

[http://dev.mysql.com/tech-resources/articles/nosql-to-
mysql-...](http://dev.mysql.com/tech-resources/articles/nosql-to-mysql-with-
memcached.html)

What wasn't obvious to me from RWW's article is that this isn't actually
memcached at all -- it's InnoDB, speaking the memcached protocol, to save
having to create a whole new protocol and a bunch of new clients. Essentially,
it's MySQL pretending to be memcache, but a memcache with persistence. Pretty
cool!

~~~
vessenes
Thanks for the link. For some reason, this release totally bugs me! This
strategy from the MySQL team is exactly the opposite of what their customers
need, in my opinion.

The number of people using key-value stores because of their query semantics
is dwarfed by those using them for their speed. What MySQL needs is the
converse of this -- a way to lock tables / rows / query results to RAM for
custom access patterns as determined by developers.

"Helping customers preserve memcache investments" is just silly -- nobody
would have made memcache investments if MySQL did what I just described above.

Anyway, this should be a blog post rather than an HN comment, but, ... I'm
surprised. I thought that the Oracle product managers were better than this.

~~~
riffraff
but the mysql folks have already explained that accessing innodb without the
overhead of SQL (both protocol and semantic) implies a huge difference in
performances.

So this goes in the direction of your implied problem: faster access to data.

~~~
vessenes
They do mention this in their press release -- no sql engine overhead, etc.

My experience with MySQL (and Postgres and Oracle to a lesser extent) is that
it is precisely the general-case optimizations built into the database that
make the NoSQL use case really hard.

Have you ever designed a large MySQL database that you wish to persist to disk
but the use cases of your app require keeping the entire table in RAM?

NoSQL implies a developer commitment to a certain, restricted set of use cases
for data access (and sometimes storage). In exchange, you get extreme
granularity over how the server stores and retrieves data. Once you do that,
you frequently get at least an order of magnitude speedup in your data, maybe
2 orders, depending on the data and access patterns.

I do not anticipate significant numbers of people dumping their redis or
membase stores for this solution, because the press release strongly implies a
1.2-1.5x speedup for certain data access, not 10x-100x. 1.5x isn't good
enough; if it were, people would have tuned MySQL some other way originally
rather than moving architecture over to KV stores like they did.

This will likely get uptake from people who are already committed to MySQL and
occasionally want to use a KV store for certain data patterns. I would
anticipate, though, that this will just make it easier for those folks to move
their KV store out of MySQL once it scales.

And that's not such a bad thing to offer to people, so I take back my earlier
disappointment.

------
gaius
It is easy to do NoSQL in _any_ RDBMS:

    
    
      create table nosql (id number primary key, some_data clob);
    

Congrats! You now have a key-value store!

~~~
TY
Unfortunately, it's not that easy. Don't forget about the impact of SQL
parsing and connection costs.

Here is a very illuminating post about it:

[http://yoshinorimatsunobu.blogspot.com/2010/10/using-
mysql-a...](http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-
nosql-story-for.html)

The authors created a MySQL plugin that served as a network server and hooked
into InnoDB without SQL parsing overhead. It also avoided the cost of
opening/closing tables by keeping them open.

According to their benchmark, performance went from 100,000 queries per second
to 750,000 per second on the same server.

Well worth the read.

~~~
EGreg
Facebook uses mysql as a key-value store. HandlerSocket is great for avoiding
SQL parsing -- is it the same thing basically as ODBC?

------
davidhollander
If anyone is interested in direct access to InnoDB (without relying on Oracle
who has stopped distributing it for download on their website) you can embed
it directly into your applications using HailDB, which is an open source
project continuing its development:

<http://www.haildb.com/>

------
mcorrientes
Sounds to me like MySQL is trying to keep up with mongodb.

A littte bit late but I cant wait for some benchmarks.

If they also going to implement sharding next time, they keep my primary
choice for new web projects.

------
rfugger
Anyone care to explain what this accomplishes exactly?

~~~
rfugger
Answering my own question:

[http://dev.mysql.com/tech-resources/articles/whats-new-in-
my...](http://dev.mysql.com/tech-resources/articles/whats-new-in-
mysql-5.6.html#nosql)

This appears to be a way to access InnoDB storage as a memcached-type key-
value store using the memcached API. I didn't get that from the article.

------
prodigal_erik
Of all the key/value stores out there, why did they choose memcached to
emulate? Compare-and-set doesn't cut it, you need a better API than it offers
to get any benefit from InnoDB transactions. And if any value should happen to
grow beyond 1 MB, some legacy memcache clients will just start blowing up.

~~~
swaits
Maybe it doesn't suit your needs. If not, don't use it. But lots of folks are
using memcached. Seems like a great project to me.

