MySQL now includes memcached, and a plugin that allows fast NoSQL-style access

[troyk]

Title should be:

MySQL development server, not meant for production use, in development for almost 2 years, release date unknown, now includes memcached, and a plugin that allows fast NoSQL-style access.

I hope they are taken seriously however; I'd like to see all the major RDMS tightly integrate memcache in front. It only makes sense, web developers have been doing it themselves since LiveJournal's hayday.

[lgas]

This isn't integrating memcache in front, it's letting you query normal InnoDB tables directly using the memcache protocol instead of SQL.

[EzGraphs]

Relevant excerpt:

The MySQL server now includes the widely used memcached in-memory caching system, and a plugin that allows fast NoSQL-style access to InnoDB tables through the memcached protocol. This access method avoids the overhead of SQL parsing and constructing a query optimization plan. You can store the underlying data in a single InnoDB table, or spread it across multiple tables. You can read and write data through both memcached and SQL. For example, you can do fast single-key lookups through memcached get calls, and do statistical reports across all the data through SQL.

[__alexs]

So it's actually an implementation of the memcached API onto the table-space?

[Ecio78]

I've read also about another solution for NoSQL-like access to Mysql, HandlerSocket, that is implemented in the Percona Mysql http://www.percona.com/doc/percona-server/5.5/performance/ha... but I had no opportunity to try it

[nnk]

Does it support range scan selects (example: "where f > 5") as HandlerSocket do?

[al_james]

Seems like a very misleading title. Surly it should be "MySQL now supports the memcache protocol for simple NoSQL-style access on InnoDB tables".

As far as I can make out, the memcached server software itself is not included in MySQL right?

SELF CORRECTION:

No, it does seem to include memcached as well for write through caching. Interesting. http://dev.mysql.com/doc/refman/5.6/en/innodb-memcached-bene...

[est]

This is incredibly helpful.

However, I wish there's something in reverse: Redis as a MySQL storage engine. The most obvious useful things is that you can save a `tags` table without m2m tables, juse use Redis sets.

[sopooneo]

Why have an m2m table? Just have a table with two columns: post_id (or whatever is being tagged) and tag (varchar). If you want to present a list of possible tags just query for uniques. I may be missing something, so please correct me if there is a better way or I am misunderstanding your point.

[geon]

I believe Postgres supports something like that.

[detay]

If mysql would throw flying pigs out of my server I still won't be using it. Not in a world where PostgreSQL exists.

[rhizome]

In a world where perfectly respectable, performant, and resilient companies use MySQL, your comment stinks of inexperience.

[rogcg]

Just what App Engine already offers, its memcache api[1] on its NoSQL datastore.

App Engine FTW!

[1](https://developers.google.com/appengine/docs/python/memcache...)

[nnk]

> Just what App Engine already offers

No, it doesn't.

"The Memcache Python API High performance scalable web applications often use a distributed in-memory data cache in front of or in place of robust persistent storage for some tasks"

MySQL memcached is not a cache, it's a persistent storage with memcached API. And it's fast.

[nirkage]

Given that the most common reason for sticking with MySQL is the maturity of InnoDB and the surrounding toolsets, and the ability to hire knowledge easily this sounds like an excellent development.

[spudlyo]

Have you tried to hire a competent MySQL DBA recently?

[sehrope]

URL: http://dev.mysql.com/doc/refman/5.6/en/innodb-memcached-inte...

Last line: "If there is no innodb_memcache.containers.name value of default, the row with the first name value in alphabetical order is used. "

This is in regards to which table is used as the default for get/set operations. Anyone else foresee this leading to mass confusion/issues for unsuspecting users down the road?

[mithras]

I think this is pretty cool, waiting for some benchmarks.

[spullara]

This makes a lot more sense than adding the HandlerSocket API which provided marginally more utility at the cost of being a completely new API. Being able to bypass the query engine for key lookups is pretty cool and a write through cache is a bonus.

[forkandwait]

Postgresql has had a memcached extension for, um, 8 years. I haven't used it myself, but I think it is well respected.

http://pgfoundry.org/projects/pgmemcache/

[nnk]

pgmemcache is a memcached client, it connects to external memcached server. Which is, um, quite useless.

[lectrick]

I'm actually going to include this as an example of non-innovation in my pitch to take us to postgres.

[genwin]

What does postgres have that's equivalent or better? If I'm understanding this MySQL improvement, it persists memcache data on disk, a great thing. Does postgres already do that, or better?

[nnk]

Is there an example of posgtres nosql doing like 700K requests/sec?

[jakejake]

does anybody know how this would work with a pool of servers? if servers were replicated, would the memcache pool stay in sync as well? I'd assume it has to work that way to be effective. it sounds cool though, I'm glad MySQL continues to evolve.

[andrewcooke]

is it clear how this works? i can't work out what a memcache query would look like. is the key that SQL select statement as a string?

[crazygringo]

It's just a memcache API call.

It doesn't even go over the SQL interface, it's not text-based.