Database Reference
In-Depth Information
Consistency
Before discussing the eighth parameter used to configure a query, we must learn about Dy-
namoDB's consistency model. There are two kinds of consistency models in DynamoDB,
which are listed as follows:
• Eventually consistent
• Strongly consistent
These two consistency models are there in almost all the databases that comply with the
ACID properties. As far as DynamoDB is concerned, it obeys the laws of the ACID prop-
erties. It gives the user the option to choose which property we want and which we don't
want. DynamoDB is a distributed and redundant database. So the data is stored in multiple
servers (remember sharding and partitioning) for faster access, and the same data is stored
in multiple servers for a redundant purpose.
Even if one of the servers is down due to some failure, our applications (using the Dy-
namoDB database) are still backed up by backup servers. Consistency is a measure that
tells us how the update is propagated to each server holding the redundant copy of the same
data.
In the case of strong consistency, the read request followed (within a very short duration)
by the write request must (and will) give the updated items. The update (or insertion or de-
letion of an item) is propagated to each server and only then are the read operations given
access to this data. No implicit locking is involved in DynamoDB. However, the user can
decide on this, which we will discuss in
Chapter 7
,
Distributed Locking with DynamoDB
.
In the case of eventual consistency, the data returned by the query operation will be the
data that was consistent in the past. So a read request followed (within a very short dura-
tion) by the write request might not give the updated items, it might still give the old data
that was consistent in the past. It will take a little time for the update to propagate to every
server, but eventual consistency consumes less units than strong consistency.
To be exact, strong consistency will eat up twice the number of units compared to eventual
consistency. So in the case of low priority applications, where the data consistency can be
compromised (to some extent), the usage of eventual consistency is economical and effi-
cient.
