“The Main Reason Why You Shouldn’t Use C*” was created by Michael Kjellman, as part of Hakka Labs’ Cassandra Week.
A new class of databases (sometimes referred to as “NoSQL”) has been developed and designed with 18+ years worth of lessons learned from traditional relational databases such as MySQL. Cassandra (and other distributed or “NoSQL” databases) aim to make the “right” tradeoffs to ultimately deliver a database that provides the scalability, redundancy, and performance needed in todays applications. Although MySQL may have performed well for you in the past, new business requirements and/or the need to both scale and improve the reliability of your application might mean that MySQL is no longer the correct fit.
Before committing any further time towards a MySQL to Cassandra (C*) migration, ask yourself:
“Is MySQL currently preventing development of new features or providing acceptable uptime, reliability, and scalability for my users?”
“No”: Not only should you not migrate to Cassandra, but also you most likely should not be considering a migration to any alternative database. Migrating an application to a new database is a very difficult, time consuming, and error-prone process.
“Yes”: Then hopefully you’ve found a helpful resource to help guide and plan your migration from MySQL to Cassandra. There are many databases available, all with their various advantages, disadvantages and tradeoffs. I did not write this article in an attempt to portray Cassandra as a perfect solution; in fact, I’ve tried my best to highlight Cassandra’s tradeoffs, advantages, and disadvantages. Hopefully this will help you make a decision that is both informed and educated; not one motivated by marketing hype or change for the sake of change.
Cassandra is far from perfect, but in my opinion it is currently the best database available today.
Don’t try to shove a square peg in a round hole!
- Cassandra is not a relational database.
- Cassandra is not a 100%/“drop-in” replacement for MySQL.
- Simply migrating existing code to Cassandra without modifying and rethinking your existing data model will not result in perfect uptime or fix performance bottlenecks for your application. In fact, it might make things worse.