Amazon - DynamoDB Strong consistent reads, Are they latest and how?

Question

In an attempt to use Dynamodb for one of projects, I have a doubt regarding the strong consistency model of dynamodb. From the FAQs

Strongly Consistent Reads — in addition to eventual consistency, Amazon DynamoDB also gives you the flexibility and control to request a strongly consistent read if your application, or an element of your application, requires it. A strongly consistent read returns a result that reflects all writes that received a successful response prior to the read.

From the definition above, what I get is that a strong consistent read will return the latest write value.

Taking an example: Lets say Client1 issues a write command on Key K1 to update the value from V0 to V1. After few milliseconds Client2 issues a read command for Key K1, then in case of strong consistency V1 will be returned always, however in case of eventual consistency V1 or V0 may be returned. Is my understanding correct?

If it is, What if the write operation returned success but the data is not updated to all replicas and we issue a strongly consistent read, how it will ensure to return the latest write value in this case?

The following link AWS DynamoDB read after write consistency - how does it work theoretically? tries to explain the architecture behind this, but don't know if this is how it actually works? The next question that comes to my mind after going through this link is: Is DynamoDb based on Single Master, multiple slave architecture, where writes and strong consistent reads are through master replica and normal reads are through others.

Answer 1

You can find answer to your question here: http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/APISummary.html

When you issue a strongly consistent read request, Amazon DynamoDB returns a response with the most up-to-date data that reflects updates by all prior related write operations to which Amazon DynamoDB returned a successful response.

In your example, if the updateItem request to update the value from v0 to v1 was successful, the subsequent strongly consistent read request will return v1.

Hope this helps.

Answer 2

Disclaimer: the following cannot be verified based on the public DynamoDB documentation, but they are probably very close to the truth

Starting from the theory, DynamoDB makes use of quorums, where V is the total number of replica nodes, Vr is the number of replica nodes a read operation asks and Vw is the number of replica nodes where each write is performed. The read quorum (Vr) can be leveraged to make sure the client is getting the latest value, while the write quorum (Vw) can be leveraged to make sure that writes do not create conflicts.

Based on the fact that there are no write conflicts in DynamoDB (since these would have to be reconciliated from the client, thus being exposed in the API), we conclude that DynamoDB is using a Vw that respects the second law (Vw > V/2), probably just V/2+1 to reduce write latency.

Now regarding read quorums, DynamoDB provides 2 different kinds of read. The strongly consistent read uses a read quorum that respects the first law (Vr + Vw > V), probably just V/2 if we assume V/2+1 for writes as before. However, an eventually consistent read can use only a single random replica Vr = 1, thus being much quicker but giving zero guarantee around consistency.

Note: There's a possibility that the write quorum used does not respect the second law (Vw > V/2), but that would mean DynamoDB resolves automatically such conflicts (e.g. by selecting the latest one based on local time) without reconciliation from the client. But, I believe that this is really unlikely to be true, since there is no such reference in the DynamoDB documentation. Even in that case though, the rest reasoning stays the same.

Answer 3

Short answer: Writing successfully in strongly consistent mode requires that your write succeed on a majority of servers that can contain the record, therefore any future consistent reads will always see the same data, because a consistent read must read a majority of the servers that can contain the desired record. If you do not perform a strongly consistent read, the system will ask a random server for the record, and it is possible that the data will not be up-to-date.

Imagine three servers. Server 1, server 2 and server 3. To write a strongly consistent record, you pick two servers at minimum, and write the data. Let's pick 1 and 2.

Now you want to read the data consistently. Pick a majority of servers. Let's say we picked 2 and 3.

Server 2 has the new data, and this is what the system returns.

Eventually consistent reads could come from server 1, 2, or 3. This means if server 3 is chosen by random, your new write will not appear yet, until replication occurs.

If a single server fails, your data is still safe, but if two out of three servers fail your new write may be lost until the offline servers are restored.

More explanation: DynamoDB (assuming it is similar to the database described in the Dynamo paper that Amazon released) uses a ring topology, where data is spread to many servers. Strong consistency is guaranteed because you directly query all relevant servers and get the current data from them. There is no master in the ring, there are no slaves in the ring. A given record will map to a number of identical hosts in the ring, and all of those servers will contain that record. There is no slave that could lag behind, and there is no master that can fail.

Feel free to read any of the many papers on the topic. A similar database called Apache Cassandra is available which also uses ring replication.

http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/decandia07dynamo.pdf

Answer 4

Yes, a strongly consistent read is the latest, but only when you are reading from the base table or a local secondary index. Strongly consistent reads always come from the leader node of the partition the data is coming from. To understand this better, you must know how writes work in DynamoDB. When you write an item, in order for the client to get a 200 OK ack, the write must go to the leader node and one follower(replica) for the partition. If that does not happen, you don't get a 200 OK returned to you. So if you request a strongly consistent read, that read comes from the leader for that partition. In this scenario, it is more than likely written to the third node in the partition as well, but that is not required for the acknowledgment back to the client.

If you request an eventually consistent read (the default), then the read can come from any one of the three nodes for that partition. You have a 2/3 chance of getting a node in the partition that has the most up-to-date version of that item and that assumes the write has not happened yet on that third node, which is probably has.

If you are reading from a Global Secondary Index (GSI), as of this writing, those reads are always eventually consistent.

For more information, I recommend Jaso Sorenson's re:Invent talk from 2018.

Disclaimer: I am a former member of the DynamoDB team.