DynamoDB Consistency Models
Overview
Consistency is essential in the data world. Amazon DynamoDB is the serverless NoSQL database launched in 2012. To achieve consistency, it offers three types of Amazon DynamoDB consistency read models and two consistency write models. Customers can choose the DynamoDB Consistency Model in AWS as per their application and business use-case requirements. Since Amazon DynamoDB is serverless, AWS will manage the durability and availability of the table.
What is a Consistency Model?
There are many types of databases available in the real world. They are hierarchical databases, network databases, object-oriented databases, relational databases, and NoSQL databases.
Relational and NoSQL databases are the most commonly used databases in the IT industry. Relational databases use SQL, whereas NoSQL databases use NoSQL.
The main difference between those databases is how the data is stored and retrieved. This property is determined by a consistency model.
A relational database typically adheres to the ACID properties, which serve as the RDBMS consistency model. NoSQL databases use BASE properties to determine their consistency model.
What is the BASE property?
The BASE is abbreviated as
-
Basic Availability
-
Soft State
-
Eventually Consistent
Basic Availability
The database is expected to work, and the data within it should be available most of the time.
Soft State
Soft state means that data in the database can change without application interaction to become eventually consistent.
Eventually Consistent
The data sometimes returns inaccurate data. If a request is sent after a few seconds, they will get consistent data.
How Does Amazon DynamoDB Achieve Consistency?
Amazon DynamoDB is the NoSQL serverless database provided by AWS to customers.
The data will be declared in key-value store format.
What is an Amazon DynamoDB?
Amazon Dynamodb is the NoSQL database. It will use computing resources to maintain the scalability and reliability of the stored data, but AWS is taking care of that, so customers can focus on application logic to request and retrieve the data from Amazon DynamoDB.
Going back to the DynamoDB Consistency Models in AWS, consistency helps customers achieve data integrity.
If the customer requests data that has yet to be updated, but it returns stale data (not the latest data), then the data will be considered inaccurate or inconsistent.
DynamoDB Consistency Models in AWS will seamlessly scale based on the requirement for data durability. The data will be stored on multiple storage devices across the availability zones within the region.
Getitem and putitem are the two common usages of DynamoDB. Those two actions demonstrate the strong DynamoDB Consistency Models in AWS.
Getitem
-
When a customer sends an API call request to DynamoDB. DynamoDB forwards the customer request to the Request router for authentication and authorization.
-
Once the request is validated, it will return the data from the DynamoDB node, which is nothing but the SSD device where the actual customer data is stored.
PutItem
- When a customer puts an item into DynamoDB via an API call, the request will pass through the request router in any of the availability zones, and then the request router will store the data in the same availability zone storage node.The storage node will copy the data and send it to the next available node within the same region.
- To store the data across storage nodes with the Paxos algorithm, DynamoDB will ensure the customer's high availability and consistency.
What Are The Types Of Consistency Models That Amazon DynamoDB Supports?
There are three types of DynamoDB Consistency Models in AWS supported by Amazon DynamoDB:
- Eventually consistent read
- Strongly consistent read
- Transactional consistent read
Eventually Consistent Reads
- Eventually consistent read will be the default setting in the DynamoDB table read.
- Here, database reads will be fast, but there might be a chance that the customer receives inconsistent data.
- Usually, Eventually consistent reads will make the data generally available across all the storage nodes within a second.
- If the recurrent API call is made in a millisecond interval, this eventually consistent read might return data that is not the latest one.
Strongly Consistent Reads
- Customers need to choose this strongly consistent read while creating the table itself.
- Here, the data will be copied across the storage node, then only the result data will be returned. The data returned guarantees consistency.
- Since this model is consistent, this mode will take extra time, which results in higher latency because more compute capacity will be used to achieve strong consistency.
Conclusion
- DynamoDB Consistency Models in AWS support eventually consistent and strongly consistent reads.
- Eventually consistent model has the possibility of returning inconsistent data.
- A strongly consistent read model guarantees consistent data but may result in higher latency.
- Eventually consistent reads will be the default model in DynamoDB Consistency Models in AWS; if a customer decides to go with strong consistent reads, they should choose that option while creating the table.
- There is no pricing difference for choosing between the eventually consistent read and the strongly consistent read.