Memcached buckets - for both in-memory caching & reducing communication between CB server instances


We’d like to start using Memcached buckets for both in-memory caching & reducing communication between CB server instances.

I hope that the community will be able to assist us with the following few questions:

  1. Based on CouchBase documentation it looks like Memcached buckets don’t support replication and persistence. Correct me if I’m wrong but it looks like Memcached buckets can effectively replace REDIS cache - am I correct?

  2. Those buckets do not support replication. If we will be running both the application and the CB services on the same VM AND using “localhost” to connect the application to the CB, will the data stored on the localhost be available ONLY to the application that is running on the localhost’s VM?

  3. Question regarding Java CB client library: if we are using “localhost” as the CB cluster host, will the client be smart enough to store Memchached bucket’s documents only in the localhost CB/memory, instead of spreading them between other servers of the cluster?

Thank you in advance!

Java client (as the others) do not depend on how the address passed during initialization, it uses list of nodes from the server (as server sees them):

The client uses ketama consistent hashing to map key to the node in the cluster.

Thank you Sergey.

So what you’re saying is that the client can decide to store Memcached document NOT on the localhost’s CB server, and later on will know to retrieve it from the server on which it stored it?

If that’s the case - it means that using CB Memcached bucket is not equivalent to using REDIS cache - since it introduces bandwidth costs for inter-VM communication and therefore is more expensive.

Please let me know what you think.

What are you trying to achieve? If you want only cache for local (to app server) machine, why not just use shared application memory to keep values? Couchbase server doesn’t replicate or perist memcached bucket, and distribution is done completely on the client side. All Couchbase SDKs have agreed to use ketama hashing to distribute the keys. In this way it is guaranteed that when some node will fail, the whole cluster will be still operating (only missing keys on that failing node) and you don’t need to reconfigure the cluster or adjust distribution scheme. Also it means that values stored by one node will be readable by the other even if they use different SDKs.

But still as we do it on the client side, you can implement your own distribution algorithm which will meet your requirements “always write to local node”, but I guess you also need to implement the reading routing part. How the other application nodes will know on which memcached node the particular key is leaving? And if that node fails, does it mean that not only old keys will be lost but all future keys also?

We need shared in-memory cache that is not being reset when we restart the application. By its nature shared app cache will be reset if its running within the application framework.

We obviously can use REDIS but would like to refrain from doing so since CouchBase is already deployed on the VM. Therefore having Java CB Client to:

  1. Be forced to communicate only to localhost on Memcached buckets - will provide a great replacement for REDIS cache - improving latency of the application and lowering inter-server bandwidth utilization fees,
  2. Replication of Memcached buckets within the cluster will provide shared cache.

Too bad Memcached buckets and CB client are not working like this.