The vBucket mechanism provides a layer of indirection between the hashing algorithm and the server responsible for a given document ID. This indirection is useful in managing the orderly transition from one cluster configuration to another, whether the transition was planned (e.g. adding new servers to a cluster) or unexpected (e.g. a server failure).
The diagram below shows how document ID-Server mapping works
when using the vBucket construct. There are 3 servers in the
cluster. A client wants to look up (get) the value of document
ID. The client first hashes the ID to calculate the vBucket
which owns ID. Assume Hash(ID) = vB8. The client then consults
the vBucket-server mapping table and determines Server C hosts
vB8. The get operation is sent to Server C.
After some period of time, there is a need to add a server to the cluster (e.g. to sustain performance in the face of growing application use). Administrator adds Server D to the cluster and the vBucket Map is updated as follows.
Note
The vBucket-Server map is updated by an internal Couchbase algorithm and that updated table is transmitted by Couchbase to all cluster participants - servers and proxies.
After the addition, a client once again wants to look up (get) the value of document ID. Because the hashing algorithm in this case has not changed 1 Hash(ID) = vB8 as before. The client examines the vBucket-server mapping table and determines Server D now owns vB8. The get operation is sent to Server D.