Book Image

Cassandra Design Patterns - Second Edition

By : Rajanarayanan Thottuvaikkatumana
Book Image

Cassandra Design Patterns - Second Edition

By: Rajanarayanan Thottuvaikkatumana

Overview of this book

If you are new to Cassandra but well-versed in RDBMS modeling and design, then it is natural to model data in the same way in Cassandra, resulting in poorly performing applications and losing the real purpose of Cassandra. If you want to learn to make the most of Cassandra, this book is for you. This book starts with strategies to integrate Cassandra with other legacy data stores and progresses to the ways in which a migration from RDBMS to Cassandra can be accomplished. The journey continues with ideas to migrate data from cache solutions to Cassandra. With this, the stage is set and the book moves on to some of the most commonly seen problems in applications when dealing with consistency, availability, and partition tolerance guarantees. Cassandra is exceptionally good at dealing with temporal data and patterns such as the time-series pattern and log pattern, which are covered next. Many NoSQL data stores fail miserably when a huge amount of data is read for analytical purposes, but Cassandra is different in this regard. Keeping analytical needs in mind, you’ll walk through different and interesting design patterns. No theoretical discussions are complete without a good set of use cases to which the knowledge gained can be applied, so the book concludes with a set of use cases you can apply the patterns you’ve learned.
Table of Contents (15 chapters)

Chapter 4. CAP Patterns

 

"Your Coffee Shop Doesn't Use Two-Phase Commit"

 
 --Gregor Hohpe

Those who have worked on database applications will be familiar with two-phase commit. Whenever there are multiple application elements or components in a distributed system, there are two phases in order to perform an atomic transaction. In the first phase, all the participating components have to say "yes" for the transaction. If all of them say "yes," then in the second phase the changes have to be committed, which completes the transaction. This is an oversimplified description of the two-phase commit.

Note

A transaction is said to be atomic if it cannot be divided further. There is another way to interpret this: If there are multiple steps in a given transaction, either all the steps complete successfully, or none of them completes.

Even if the systems are distributed, if the number of components is very small, a two-phase commit doesn't affect the response time of the requests. But when it comes to...