back
15 comments
I'm curious to read more about Membase, their current homepage is rather sparse and lacking in content, but one of the things that really intrigues me about Membase is how they are adding a persistence layer on top of Memcached that gradually moves less used data down the stack to progressively slower and more expansive storage hardware, starting from ram, going to ssds, then down to hard drives.

One thing that they make a big deal about is ease of use in installing, saying:

"Start storing data in five minutes, or less. Membase is a single-package install. It is easy to get, install, configure and begin using. We consider it a failure if it takes more than five minutes to get up and running."

While I appreciate ease of use and their dedication to that, if I'm looking for something to handle 500,000+ requests per second, then getting it up and running initially within 5 minutes is not something I concerned with.

But that's just a nit pick. I'm intrigued to hear more, and I like that they are building this on top of Memcached while utilizing the existing client API.

Problem is, how is this different than something else: the days when you can claim to be fast, scalable, distributed etc. and get some traction are over. These terms are so overused and overhyped that they have lost all meaning to potential users. In the database world, "scalable" is the new "object-oriented".
I've been working on a distributed scalable social web 2.0 AJAX HTML5 iPhone database in the cloud...it's going to be awesome.
The front page says, "A distributed key-value database for modern web applications".

The heading of this HN submission is "Yet Another Distributed Scalable Key/Value? (answer: no way!)"

The schizophrenia continues on the home page. "Does the world really need another NoSQL database?"

This deliberate confusion is beyond idiotic.

It's not deliberate confusion. There was a lot of work to just getting the code out there, and we're now working on more and more docs.

Have a look at http://blog.northscale.com/northscale-blog/2010/07/what-exac... and http://dustin.github.com/2010/06/29/memcached-vbuckets.html for good technical content.

I am baffled by these new trends. I have seen websites that need scalability cache all the DB queries in memcached, but the queries didn't have any large degree of temporal locality. How is this supposed to do anything other than move the database into memory? Shouldn't the DBMS already do that by itself? The only benefit I can see is that the queries would be memoized instead of having to be run again and again, but I'm not sure that would be such a great advantage if the entire DB was loaded in memory.

Anyway, I'm just thinking aloud here, but it seems to me that in many cases you really don't want a caching layer above the DB...

This one isn't just a cache; it's a database with a simple key-value data model. It has very good clustering support. It can handle datasets too large for memory. It's fast, allegedly easy to set up (I haven't tried it), and you can communicate with it using existing memcached client libraries. I think it sounds like an interesting option.

I also think that, in a few months, Redis will probably have the same nice characteristics of Membase, but with a much nicer set of datatypes. Membase does everything I described right now, though, which is worth something.

After quickly reading the info on the front page I didn't see a direct comparison with other distributed key-value stores. Could anyone point to a comparison? (sorry if I've missed it)

I think membase is analogous to redis (HD-backed memcached), but unlike redis it distributes the data across multiple physical nodes. AFAIK Redis needs the DB to fit on a single disk.

No way? Explain?
yes, please. What the heck did that mean?
Documentation is pretty much nonexistent. It looks like it could be interesting, but I can't even tell what sort of operations, data types, etc. are supported.
To clients, it looks exactly like a memcached server.
It may indeed look exactly like a memcached server, but that's not enough. A client that speaks the memcache protocol assuming that it's talking to a cache can make assumptions and cut corners which a client talking to a persistent store ought not, and users and implementors of clients that speak the protocol need to be aware of these issues.
I downloaded and it looks like I can put all my session data into it instead of MySQL
What kind of session data do you store in MySQL?