Modify the hash algorithm so some keys will always end up on the same node

Hey @sri_ram,

Note that just going to a single node doesn’t give you all-or-nothing transaction behavior.

Also note that you need not go through N1QL statements for transactions. Couchbase Transactions has direct access through Java. I think for a bulk add of 5k documents, it likely will be more performant to use that API.

The concept you’re following there, putting the related documents in a single vbucket, is what we call setting a shard key for the doc. Back in the memcached days, it was common for some clients to do this. We did allow for this in the early design of the system.

At some point though, when some of the UI, query, XDCR and replication components were added, we didn’t carry that shard key through the system. So, when you go to the UI, there are a couple of ways it may retrieve the document, and one is through its own calculation of the vbucketid based on the key.

Most of that is background to say that while you could, by modifying your client and working with the KV service, coerce a number of documents into the same vbucket and thus the same node, there are other parts of the system that may not hold.

If what you really need is all-or-nothing, read committed visibility of the docs, try the Java API. We designed in particular features for this particular use case.

1 Like