This week on the New Tech Forum, DataStax CEO Billy Bosworth offers an incisive essay on a key difference in relational and NoSQL mindsets. Bosworth has spent many years in the database and development world, and has become a passionate proponent of NoSQL databases such as Apache's Cassandra, the open source NoSQL database around which his company is built.
Bosworth zeroes in on the misinformation and misunderstanding surrounding NoSQL, particularly in regard to ACID (atomicity, consistency, isolation, durability) compliance. To address that issue, he has compiled a list of common misconceptions about ACID compliance, databases, and modern application development.
Top 5 misconceptions about ACID compliance in a nonrelational world
I graduated college in 1992, fresh computer science degree in hand, about to spend the next 10 years writing client/server applications. Oracle and SQL Server were my tools of choice, and I quickly learned the basics of relational databases. First was 3NF data modeling, originally defined by the legendary E.F. Codd. Next came an understanding of ACID properties, which lie at the heart of predictable relational database behavior.
For over 20 years, DBAs like myself wrote millions of applications according to the unbreakable laws of 3NF and ACID. Without realizing it, we came to believe that only the relational way of thinking made sense.
Then the world changed, and the demands placed on applications shifted. For online applications, two things matter more than just about anything else: performance at extreme scale and applications always staying available in a completely connected world.
I first encountered the new trend while reading an article titled "Your Coffee Shop Doesn't Use Two-Phase Commit." Nonrelational concepts were entering mainstream thinking. Nonetheless, I continued believing that certain use cases were far too taboo when it came to breaking the relational laws, the quintessential example being the "ATM problem." Surely, critical applications still required locks and complex transactions with rollback/commit capabilities? Eric Brewer has since shattered even that belief, and now it seems that virtually any use case is up for grabs.