0% completed
The Life of Dynamo’s put() & get() Operations
So far we have covered how Dynamo stores and replicates data. Now let's follow a single get() or put() request through the system, end to end.
Strategies for choosing the coordinator node
Every get() and put() request has to reach a coordinator node. This is the node that owns the key and drives the request. Dynamo clients pick that node one of two ways:
- Route the request through a generic load balancer.
- Use a partition-aware client library that sends the request straight to the right coordinator node, for lower latency.
.....
.....
.....
goobaek
· 3 years ago
`As stated above, put() requests are coordinated by one of the top nodes in the preference list. Although it is always desirable to have the first node among the top to coordinate the writes, thereby serializing all writes at a single location, this approach has led to uneven load distribution for Dynamo. This is because the request load is not uniformly distributed across objects. To counter this, any of the top nodes in the preference list is allowed to coordinate the writes. In particular, since each write operation usually follows a read operation, the coordinator for a write operation is chosen to be the node that replied fastest to the previous read operation, which is stored in the request's context information. This optimization enables Dynamo to pick the node that has the data
Gary
· 4 years ago
In 'put()' process section, why are the numbers N-1 and W-1 instead of N and W?
- Sends the write request to N−1 highest-ranked healthy nodes from the preference list.
- The put() operation is considered successful after receiving W−1 confirmation.
Amey Naik
· 5 years ago
" preference list" - The list of nodes responsible for storing a particular key is called the preference list.
Reading Progress
0%