6 responses to “De-volatile Your Memcached. Upgrade to Membase”

  1. Perry Krug

    Phil, this is a fantastic blog…thank you very much.

    A few points of clarification. Please take these as constructive criticism, you have done an excellent job up to here and I simply want to add a bit more detail for your/our readers:

    - When talking about the hashing algorithm stuff, you are absolutely correct about how memcached handles things. You are also correct about how Membase handles the “re-routing” of client requests. However, we actually use “vBuckets” (not regular buckets…those are the logical keyspaces within a Membase cluster. Yes, I know it’s confusing…we apologize .

    - Membase doesn’t actually have a cluster size limit. You are correct that you can only have 1024 servers holding “active” data, but if you have more than 1024 nodes in the cluster, some will only be handling replica data. The cluster itself will still be viable. We are also planning on raising this limit in the future when we run into deployments that need it. 1024 was appropriate from a testing and qualification perspective for now. You are still correct about the chattiness of the nodes and that we are continuing development in this area.

    - It’s worth pointing out that running Moxi on the client side is our best-practice for non-”smart” clients and will eliminate any extra network hops when retrieving data since Moxi can go directly to the Membase server for a particular key.

    - ”smart” clients don’t actually embed Moxi within them…they simply contain the same logic that Moxi does. Take a look at the Enyim (http://memcached.enyim.com/) client and our updated spymemcached client for Java (http://wiki.membase.org/display/membase/prerelease+spymemcached+vBucket). We’ve also begun the process of writing a libmembase C library (http://trondn.blogspot.com/2010/12/building-libmembase.html). You can really think of Moxi as the first “smart” client…though it can do much more.

    - It “may” be worthwhile calling out Membase’s features of replication and the TAP interface a bit more if you like…they’re rather key to the whole system (no pun intended)

    Thanks again and I really look forward to your continuing investigation of Membase. Please let me know if there’s anything I can do to help in your pursuit.

    Perry Krug

  2. Peter Smith

    Great article, but just a quick note on memcache limitations. Consistent hashing (the PHP APIs support this, and some other languages too) solves the problems that occur when memcache servers are added/removed from the pool, so this isn’t really a reason not to use memcache (since there’s a simple solution).

  3. Perry Krug

    Consistent hashing does make the addition/removal of servers “less” impactful, but it’s not perfect. As a database, Membase (and now Couchbase Server) needed to be perfectly consistent and the vbucket concept has been extremely valuable to our project.

    As simply a memcached replacement, Membase does offer a number of other advantages like replication and failover, as well as persistence to disk (though some argue that a cache shouldn’t have to be persistent). With the introduction of CouchDB underneath (creating the Couchbase Server 2.0 product) you also get robust indexing and map-reduce functionality (useful even in a “cache”) and cross datacenter replication is close on the horizon.

    We believe that memcached is still an extremely valuable technology and has many valid use cases, we even have customers running “standard” memcached within their Membase cluster. Mostly for the enhanced monitoring and clustering that we bring to it, but also for much more transient data that they truly just need a volatile cache for.

    Full disclosure, I’m a bit biased having worked at Couchbase (formerly Membase, formerly NorthScale) for over a year now, but there is some seriously cool and useful technology being born before our eyes.

    Perry Krug
    Sr. Solutions Architect, Couchbase
    perry@couchbase.com

  4. printf(" SaltwaterC "); » Blog Archive » Use the cache Luke, Part 1: from memcached to Membase memcached buckets

    [...] start with a quote: Matt Ingenthron said internally at Membase Inc they view Memcached as a rabbit. It is fast, but it [...]