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

alex1 · November 15, 2016, 12:08pm

Hi,

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:

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?
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?
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!
Alex

avsej · November 15, 2016, 12:25pm

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):

github.com

couchbase/couchbase-jvm-core/blob/master/src/main/java/com/couchbase/client/core/config/DefaultMemcachedBucketConfig.java#L54


      
           * @param rev the revision of the config.
           * @param name the name of the bucket.
           * @param uri the URI for this bucket.
           * @param streamingUri the streaming URI for this bucket.
           * @param nodeInfos related node information.
           * @param portInfos port info for the nodes, including services.
           */
          @JsonCreator
          public DefaultMemcachedBucketConfig(
                  @JacksonInject("env")ConfigParserEnvironment env,
                  @JsonProperty("rev") long rev,
                  @JsonProperty("uuid") String uuid,
                  @JsonProperty("name") String name,
                  @JsonProperty("uri") String uri,
                  @JsonProperty("streamingUri") String streamingUri,
                  @JsonProperty("nodes") List<NodeInfo> nodeInfos,
                  @JsonProperty("nodesExt") List<PortInfo> portInfos,
                  @JsonProperty("bucketCapabilities") List<BucketCapabilities> bucketCapabilities,
                  @JacksonInject("origin") String origin) {
              super(uuid, name, BucketNodeLocator.KETAMA, uri, streamingUri, nodeInfos, portInfos, bucketCapabilities, origin);
              this.env = env;

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

alex1 · November 15, 2016, 12:59pm

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.

avsej · November 15, 2016, 1:22pm

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?

alex1 · November 24, 2016, 5:18pm

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:

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,
Replication of Memcached buckets within the cluster will provide shared cache.

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