Database Reference
In-Depth Information
Request handling
The
get
and
put
requests in DynamoDB are handled in two ways: first, it can route
through a load balancer, or it can directly select a node using partitioning information. In
the first case, the load balancer decides which way the request would be routed, while in
the second strategy, the client selects the node to contact. Both strategies are beneficial in
their own ways; in the first strategy, the client is unaware of DynamoDB, which is helpful
in terms of scalability and makes your architecture loosely coupled. The second strategy
helps in achieving lower latency. As a DynamoDB user, we don't have any control over re-
quest handling, partitioning, or any other internals.
When a client sends a request to DynamoDB, it can be handled by any node in that cluster.
When a node receives the request, it first checks whether that node has the given range of
keys provided by the client. If it has got the key, it will fulfill the request, or else it will
simply forward the request to the top N nodes in the preferred list.
Read and write operations involve only the top N healthy nodes. The nodes which are not
available, or not reachable, are completely ignored. To maintain the consistency in replicas,
DynamoDB uses a quorum-like technique to decide whether an operation should be de-
clared successful or not in a distributed environment.
In quorum, we have to maintain two keys R (Read) and W (Write); here R is the minimum
number of nodes that should participate in a successful read operation and W is the minim-
um number of nodes that should participate in a successful write operation. Here, we are
expected to set R and W such that R plus W is greater than N, where N is the number of
nodes in the cluster. This ensures the commits are done only in quorum, but there is one
disadvantage of this technique, that this may lead to a lower response time as the latency
would be decided by the slowest node. In order to avoid this, DynamoDB keeps the R plus
W number less than N to get better latency.
When a coordinator node receives the
put()
request, it first generates a new version of
the object in the vector clock and writes the update locally. The coordinator node then
sends the update along with the updated vector clock to the N most reachable nodes. If at
least W minus 1 nodes respond, then the write is supposed to be a successful one.
In the case of the
get()
operation, the coordinator node requests all available versions of
data from the N most reachable nodes. If the coordinator node receives multiple versions of
objects, then the responses are reconciled looking at the vector clock. Once done, the re-
conciled version of the object is returned to the client. Also, the same reconciled version is
