Excellent read on ACID

I was reading AWS white paper on Database migration. The following excerpt covered clean and concise description on Database Atomicity and ACID properties. Worthy read!

Amazon Web Services – Best Practices for Migrating from RDBMS to DynamoDB August 2014

The growth of “internet scale” web applications, such as e-commerce and social media, the explosion of connected devices like smart phones and tablets, and the rise of big data have resulted in new workloads that traditional relational databases are not well suited to handle. As a system designed for transaction processing, the fundamental properties that all RDBMS must support are defined by the acronym ACID: Atomicity,
Consistency, Isolation, and Durability. Atomicity means “all or nothing” – a transaction executes completely or not at all. Consistency means that the execution of a transaction causes a valid state transition. Once the transaction has been committed, the state of the resulting data must conform to the constraints imposed by the database schema. Isolation requires that concurrent transactions execute separately from one another. The isolation property guarantees that if concurrent transactions were executed in serial, the end state of the data would be the same. Durability requires that the state of the data once a transaction executes be preserved. In the event of power or system failure, the database should be able to recover to the last known state. These ACID properties are all desirable, but support for all four requires an architecture that poses some challenges for today’s data intensive workloads. For example, consistency requires a well-defined schema and that all data stored in a database conform to that schema. This is great for ad-hoc queries and read heavy workloads.
For a workload consisting almost entirely of writes, such as the saving of a player’s state in a gaming application, this enforcement of schema is expensive from a storage and compute standpoint. The game developer benefits little by forcing this data into rows and tables that relate to one another through a well-defined set of keys. Consistency also requires locking some portion of the data until the transaction modifying it completes and then making the change immediately visible. For a bank
transaction, which debits one account and credits another, this is required. This type of transaction is called “strongly consistent.” For a social media application, on the other hand, there really is no requirement that all users see an update to a data feed at precisely the same time. In this latter case, the transaction is “eventually consistent.” It is far more important that the social media application scale to handle potentially millions of Simultaneous users even if those users see changes to the data at different times. Scaling an RDBMS to handle this level of concurrency while maintaining strong consistency requires upgrading to more powerful (and often proprietary) hardware. This is called “scaling up” or “vertical scaling” and it usually carries an extremely high cost. The more cost effective way to scale a database to support this level of concurrency is to add server instances running on commodity hardware. This is called “scaling out” or
“horizontal scaling” and it is typically far more cost effective than vertical scaling.

NoSQL databases, like Amazon DynamoDB, address the scaling and performance challenges found with RDBMS. The term “NoSQL” simply means that the database doesn’t follow the relational model espoused by E.F Codd in his 1970 paper A Relational Model of Data for Large Shared Data Banks, 1 which would become the basis for all modern RDBMS. As a result, NoSQL databases vary much more widely in features and
functionality than a traditional RDBMS. There is no common query language analogous to SQL, and query flexibility is generally replaced by high I/O performance and horizontal scalability. NoSQL databases don’t enforce the notion of schema in the same way as an RDBMS. Some may store semi-structured data, like JSON. Others may store related
values as column sets. Still others may simply store key/value pairs.
The net result is that NoSQL databases trade some of the query capabilities and ACID properties of an RDBMS for a much more flexible data model that scales horizontally.
These characteristics make NoSQL databases an excellent choice in situations where use of an RDBMS for non-relational workloads (like the aforementioned game state example) is resulting in some combination of performance bottlenecks, operational complexity, and rising costs. DynamoDB offers solutions to all these problems, and is
an excellent platform for migrating these workloads off of an RDBMS.

https://d0.awsstatic.com/whitepapers/migration-best-practices-rdbms-to-dynamodb.pdf

Print Friendly, PDF & Email

Leave a Reply

Your email address will not be published. Required fields are marked *