CODEWITHSUNDEEP
couchbase
Barbadoss
Barbadoss

Reputation: 1156

To store certain keys on the same Couchbase node in a cluster

Is it possible to make sure that certain keys get stored on the same Couchbase node in a cluster? Say there's User and its Preferences (not a real example, just for sake of simplicity here...) and most the time I will get them together to display on a page. Thought it would be natural to place them on the same node so the client does not retrieve it from different nodes.

How should I name the keys to make sure they place on the same node? Is it possible at all? Is it something I should care about ever?

Upvotes: 0

Views: 89

Answers (2)

chongqing xiao
chongqing xiao

Reputation: 11

This question is pretty old but I have the same question with regarding Counchbase so I add some comments.

Redis cluster has the exact feature you asked where part of the key that is wrapped using {} will be used to calculate the hash instead of the whole key.

Below is one case this could be useful.

Let's say a cluster of Couchbase or Redis nodes is used to save session data for 20+ web servers. If one web server's data always goes to the same node, then even part of the cluster is down and can't be recovered, only the web servers the node serves would be impacted. Otherwise, all web servers will be down.

Upvotes: 0

mrkwse
mrkwse

Reputation: 420

While it is technically possible, and there are cases such as your example in which it would seem logical to do so, there is little benefit, particularly when contrasted with the potential drawbacks that ensuring keys do go to the intended nodes.

To justify the 'little benefit' comment, for a typical system in good health, there should be minimal discrepancies between nodes in terms of time taken to access any particular document (be it the time it takes for a node to retrieve a document or the time taken to send that document over a network), and as such any performance gain that would occur due to grouping keys on a node would be marginal.

The other main area of interest, would be availability. Benefit here could be greater, as if one node goes down for whatever reason, there's the chance that the node isn't the one containing all the linked keys and hence one of the remaining nodes will be enough to sustain (a particular part of) a system. There is also, however, the risk that the one node containing all the priority keys will go down, leaving no active keys for the system, and requiring (auto)failover or replica reads. However, even with these keys distributed across a node, the same availability will be afforded with the same (auto)failover and replica read mechanisms, leaving minimal (if any) benefit.

The drawbacks are far greater, however, as the means of ensuring keys get sent to particular nodes will require modification of the hashing algorithm used to shard the keys, which would require thorough testing and design before reliably deploying to a development cluster.

Upvotes: 2

Related Questions