NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



memcached: All content tagged as memcached in NoSQL databases and polyglot persistence

Terrastore and ElasticSearch to Replace MySQL, Memcached and Sphinx

Currently we are using PHP, MySQL, Sphinx, and Memcached to serve up pages so quick. […]

[…] Our (MY) final decision was to use Terrastore. I’m not sure if it is the fastest, but it is fast. The main reason is how easy it is to scale with growth, how well it protects the data and keeps multiple copies always available, and the fast release cycle which means it is always improving.

As a replacement for Sphinx , we have considered many, but have landed on ElasticSearch, which just so happens to have a direct integration with Terrastore. A no-brainer for us to choose ElasticSearch for our search and ranking algorithms.

While each piece is important, sometimes it is also about the combo.

Original title and link: Terrastore and ElasticSearch to Replace MySQL, Memcached and Sphinx (NoSQL databases © myNoSQL)


Redis and Memcached Benchmarks

A long and interesting discussion on comparing Redis and Memcached performance. It all started ☞ here:

After crunching all of these numbers and screwing around with the annoying intricacies of OpenOffice, I’m giving Redis a big thumbs down. My initial sexual arousal from the feature list is long gone. Granted, Redis might have its place in a large architecture, but certainly not a replacement to memcache. When your site is hammering 20,000 keys per second and memcache latency is heavily dependent on delivery times, it makes no business sense to transparently drop in Redis. The features are neat, and the extra data structures could be used to offload more RDBMS activity… but 20% is just too much to gamble on the heart of your architecture.

Salvatore Sanfilippo ☞ followed up:

[…] this is why the sys/toilet benchmark is ill conceived.

  • All the tests are run using a single client into a busy loop.
  • when you run single clients benchmarks what you are metering actually is, also: the round trip time between the client and the server, and all the other kind of latencies involved, and of course, the speed of the client library implementation.
  • The test was performed with very different client libraries

But he also published a new benchmark. And Dormando ☞ published an update picking on the previous two:

The “toilet” bench and antirez’s benches both share a common issue; they’re busy-looping a single client process against a single daemon server. The antirez benchmark is written much better than the original one; it tries to be asyncronous and is much more efficient.

And it didn’t stop here, as Salvatore felt ☞ something was still missing:

The test performed by @dormando was missing an interesting benchmark, that is, given that Redis is single threaded, what happens if I run an instance of Redis per core?

I assume everyone is asking by now: which one of Redis and Memcached performed better? And the answer is: it depends (even if some would like to believe differently).

But why is this the “answer”? Firstly, because creating good benchmarks is really difficult. Most of the benchmarks are focusing on the wrong thing or they are covering not very real-life like problems.

This would be my very simple advise:

  • basic benchmarks will not give you real answers
  • you are better testing for your very specific scenario (data size, concurrency level,

Original title and link: Redis and Memcached Benchmarks (NoSQL databases © myNoSQL)

Membase Releases the 4th Beta, Featuring Memcached Buckets

The forth beta release of Membase, the scalable Memcached big brother, featuring a memcached buckets:

You now can create buckets in your Membase Server cluster that behave exactly like memcached, which means you can use Membase Server as a drop-in replacement for your existing memcached setup. In a single cluster you can now share the resources between memcached buckets and membase buckets.

The compatibility with memcached is a clear statement that Membase is after memcached users. But so is Redis!

Original title and link: Membase Releases the 4th Beta, Featuring Memcached Buckets (NoSQL databases © myNoSQL)


Redis Benchmark Ported to Memcached

Salvatore Sanfilippo:

This is a straightforward port of redis-benchmark to memcache protocol.

This way it is possible to test Redis and Memcache with not just an apple to apple comparison, but also using the exactly same mouth… :)

Does it mean that Redis is going after Memcached? I guess Membase is after the same users, so we will have some interesting competition.

Original title and link: Redis Benchmark Ported to Memcached (NoSQL databases © myNoSQL)


What Are Virtual Buckets?

A fantastic article explaining the rationale behind and usage of virtual buckets for scaling memcached:

  1. Never service a request on the wrong server.
  2. Allow scaling up and down at will.
  3. Servers refuse commands that they should not service, but
  4. Servers still do not know about each other.
  5. We can hand data sets from one server another atomically, but
  6. There are no temporal constraints.
  7. Consistency is guaranteed.
  8. Absolutely no network overhead is introduced in the normal case.

As described in what is membase, virtual buckets/vbuckets is exactly the approach used by membase, Riak, and probably every solution involving consistent hashing.


Heroku Encourages Polyglot Persistence

Heroku published an article preaching polyglot persistence through a Database-as-a-Service approach:

Database-as-as-service is one of the coming decade’s most promising business models. […] DaaS also goes hand-in-glove with polyglot persistence. Thanks to database services, you won’t need to learn how to sysadmin/DBA for every datastore you use – you can instead outsource that job to a service provider specializing in each database.

While it definitely sounds exciting to be able to use all these NoSQL databases , we should always keep in mind the cost of complexity even if DaaS will help alleviate some of the complexity of heterogeneous systems.

The article includes also some interesting use cases for a couple of NoSQL databases:

  • Frequently-written, rarely read statistical data (for example, a web hit counter) should use an in-memory key/value store like Redis, or an update-in-place document store like MongoDB.
  • Big Data (like weather stats or business analytics) will work best in a freeform, distributed db system like Hadoop.
  • Binary assets (such as MP3s and PDFs) find a good home in a datastore that can serve directly to the user’s browser, like Amazon S3.
  • Transient data (like web sessions, locks, or short-term stats) should be kept in a transient datastore like Memcache. (Traditionally we haven’t grouped memcached into the database family, but NoSQL has broadened our thinking on this subject.)
  • If you need to be able to replicate your data set to multiple locations (such as syncing a music database between a web app and a mobile device), you’ll want the replication features of CouchDB.
  • High availability apps, where minimizing downtime is critical, will find great utility in the automatically clustered, redundant setup of datastores like Casandra and Riak.

These are good examples, but you can find many more in our coverage of NoSQL uses cases and the per-product case studies: CouchDB case studies or MongoDB case studies, etc.

Heroku Encourages Polyglot Persistence originally posted on the NoSQL blog: myNoSQL


Japanese Blogs Post Benchmarks on Membase, Memcached, Tokyo Tyrant and Redis

Two japanese blogs[1] have published some benchmarks comparing the newly released membase with memcached, Tokyo Tyrant and Redis.

Unfortunately both of them are just new examples of useless benchmarks:

  • only 1000 keys
  • the benchmark doesn’t vary the size of keys and values
  • no concurrency
  • no mixed reads/writes

I’d strongly suggest anyone planning to build a solid benchmark to take a look at these NoSQL benchmarks and performance evaluations to learn how to build useful/correct ones[2].

  1. The two benchmarks are published ☞ here and ☞ here. Unfortunately I don’t read Japanese and I’ve used Google Translator (which pretty much didn’t work)  ()
  2. Another useful resource about building correct benchmarks is Jan Lehnardt’s ☞ Benchmarks: You are Doing it Wrong  ()

What is Membase?

It is kind of difficult to figure out a complete description of what Membase is as the ratio of signal to noise in today’s announcement is still very low[1]. Anyways, here is what I’ve been able to put together:

  • a cache using memcached protocol
  • Apache licensed open source version of NorthScale Membase Server[2]
  • project homepage is and (some) code can be found on GitHub
  • can persist data
  • supports replication (note: source code repository contains a reference to master-slave setup)
  • elastic, allowing addition and removal of new nodes and automatic rebalancing
  • used by Zynga and NHN[3], which are also listed as project contributors

While details are extremely scarce, this sounds a lot like Gear6 Memcached.

Membase Persistency

According to this paper the execution of a write operation involves the following steps

  1. The set arrives into the membase listener-receiver.
  2. Membase immediately replicates the data to replica servers – the number of replica copies is user defined. Upon arrival at replica servers, the data is persisted.
  3. The data is cached in main memory.
  4. The data is queued for persistence and de-duplicated if a write is already pending. Once the pending write is pulled from the queue, the value is retrieved from cache and written to disk (or SSD).
  5. Set acknowledgment return to application.

There is also:

In membase 1.6, data migration is based on an LRU algorithm, keeping recently used items in low-latency media while “aging out” colder items; first to SSD (if available) and then to spinning media.

A couple of comments:

  1. it looks like a write operation is blocking until data is completely replicated
  2. it is not completely clear if “hot data” is persisted to disk on a write operation or only once it’s becoming “cold”

Membase Replication

Membase uses the notion of virtual buckets or vBucket (currently it supports up to 4096) which contains or owns a subset of the key space (note this is similar to Riak Vnodes[4]). Each vBucket replication can be configured independently, but at any time there is only 1 master node that coordinates reads and writes.

Membase Rebalancing

Membase runs on each node a couple of “processes” that are dealing with data rebalancing (part of a so called: cluster manager). Once it is determined that a master node (the coordinator for all reads and writes for a particular virtual bucket) becomes unavailable, a Rebalance Orchestrator process will coordinate the migration of the virtual buckets (note: both master and replica data of the virtual bucket will be moved).

When machines are scheduled to join or leave the cluster, these are placed in a pending operation set that is used upon the next rebalancing operation. I’m not sure, but I think it is possible to manually trigger a rebalancing op.

  1. Sources:  ()
  2. NorthScale Membase Server web page  ()
  3. While I read that “Membase is currently serving data for some of the busiest web applications on the planet.”, I couldn’t find any other users besides Zynga and NHN.  ()
  4. Riak is using a similar notion: vnode. While the terms are the same you should not confuse Riak buckets for membase buckets though.  ()

Memcached on top of Redis?

I read a couple of posts[1] talking about Gear6 Memcached native query support and Redis integration. Anyways, based on the details I’ve found so far[2], what I understand is:

  1. Gear6 memcached provides an enhanced API that allows querying the key/value space
  2. Gear6 memcached is looking to support more data types by using Redis support for types like lists, sets, ordered sets, hashes[3]
  3. or Gear6 is looking to provide commercial support for Redis

These left me with the question: why would you use memcached on top of Redis?

Possible answers:

  1. if the integration would preserve the same memcached API (nb I am not sure though this would be possible) then
  2. such a product might be useful for projects needing both RDBMS and Redis (note: but in the end the project would still need to be aware of both storage APIs)
  3. such a product might be useful for transitioning towards Redis alone

  4. the integration would just add features missing from the current version of Redis (f.e. elastic scaling, sharding, etc.)

Do you see any other reasons for using memcahed on top of Redis?


Usecase: Superfeedr uses Redis to replace MySQL+Memcached

We all love “war stories” and the one of Superfeedr using Redis to replace their MySQL + Memcached setup is really interesting. The features that made Redis fit better Superfeedr scenario were mostly additions to the Redis 1.2.0 release

And I’m pretty sure that Superfeedr will benefit of Redis Virtual Memory once it becomes available considering their deployment on 2GB slices at Slicehost.


A Very Specific Benchmark: Files vs MySQL vs Memcached vs Redis vs MongoDB

This sort of very specific benchmarks are valid/interesting if and only if:

  • they simulate extremely close the real life scenario that will be supported by the final application
  • they are not generalized to compare the overall performance of the NoSQL stores
  • the NoSQL store is correctly configured to fulfill the app requirements (f.e. durability)
  • it is understood that the driver has an impact on the results

In this case the benchmark measured requests/s for a usecase of session storage for a Tornado-based web app. You can see the results below:

Reference MySQL Memcached MongoDB Redis
1626 req/s 1353 req/s 1473 req/s 1582 req/s 1418 req/s

Note: The benchmark doesn’t provide enough details about the drivers used.


Simple way to memcache (almost) all database queries

I’d probably argue that’s way too simple (and probably not so useful). What I’d do is:

  1. make sure that I don’t have duplicates in the cache

    Supporting this behavior is not so complex: a query cache will just store the keys of the results and use the multi_get for fetching these. In case objects are missing from the cache then you go on an execute the query making sure that this time you are caching each result object and the set of keys.

  2. look into using a key-value store

    This would definitely be more fun, not to mention that it might give you extremely good results. Take for example Redis, which is sometimes called memcached on steroids and check this benchmark results to get an idea of the performance.