limitations of memcached buckets in 2.1


I'm looking at using couchbase memcached bucket as a replacement for redis. My main motivation is horizontal scaling. The reason I want to use memcached is to get better response times, and have the data fully in memory.

I found the documentation below, which is relevant to 1.8, but I couldn't find any similar document for 2.1 or for future versions.

1.8 documentation:

My main concerns are the fact that replication, rebalancing and persistence are not supported. Are these all true for current versions as well? Any other thing I should consider?

1 Answer

« Back to question.


You can find information about Couchbase 2.1 Bucket Types here:

As you can see you have the same limitations regarding memcached buckets.

Based on your requirement, you should just use the "Couchbase Bucket" like that you will have replication, failover,... and no impact on performance, if you have the correct sizing. All the disk I/O operations are done asynchronously this is why you won't see any performance impact.


I'm curious how you can say there's no performance impact when you have to go to disk. I understand the writes of the data to disk are asynchronous. But when there's a read request for that data that's been paged out, there's a delay.

I'm in a similar boat to the original poster except I'm trying to replace memcached with CB instead of Redis. I really like memcache's LRU algorithm in that it allows me to define max memory consumption so I know everything will be served out of RAM instantly. I don't have to care how fast my disks are. CB's memcache buckets look like they provide the same functionality. But as mentioned above, then you lose the replication and failover, which a big piece of the original motive for moving to CB.

I think one of the assumptions I'm coming from (and one of the wonderful things about CB) is that I plan to run it on 4 or 5 commodity boxes. Nothing blazing. Just generic servers. But with the max memory limit configured I'd be able to keep everything in RAM and have it be super fast. Letting the kernel go to disk for swap would be painful. Given that, two questions come to mind:

1. So there's no way to have replication and LRU on the same bucket?
2. This is a less elegant (and less guaranteed) solution, but is there any way to set a default TTL for all objects? I'm assuming my app (drupal) doesn't know to set one. Can I just have CB assume a TTL other than zero?