Blog > Post
Cassandra keeps climbing the ranks of the DB-Engines Ranking
by Matthias Gelbmann, 3 May 2016
To many database enthusiasts, becoming more popular than Microsoft Access might not sound like a good enough reason to crack open the Champaign at the Datastax headquarter in Santa Clara. However that may be, becoming the 7th most popular database management system in that crowded space of 300+ systems certainly is. An impressive achievement for a DBMS that's only 8 years old.
Cassandra is one of three NoSQL systems in the top 10 of our ranking. MongoDB and Redis are the other ones. However, although we conveniently keep putting these systems into the "NoSQL bucket", Cassandra feels quite different when you start working with it.
Every developer is familiar with nested structures, therefore moving from an RDBMS to a Document Store such as MongoDB feels very natural. Actually, data modeling for a Document Store is in many ways easier than for an RDBMS, even though we have learned in the last 30 years how to squeeze every piece of information into a fixed data scheme, so we can do that now while we are sleeping.
Getting started with a Key-value Store such as Redis is even easier and takes literally only a few lines of code. You may or may not come to the more advanced features offered by Redis later, when you need them. That's all not a big deal, from a conceptual point of view.
Cassandra is different.
The ins and outs of a Wide Column Store are not something you learn without scratching your head now and then. Structuring your data into column spaces, defining optimal row keys and column keys for these column spaces, finding the right balance between data redundancy and query efficiency, all that takes time to familiarize yourself with the peculiarities of the system. Having an SQL-like query language (CQL, Cassandra Query Language) makes things easier, but only on the surface. You still need to understand the profound and fundamental differences, probably to any other system you know, in order to make use of the strengths of the wide-column concepts.
On top of that, one of the reasons why many people consider switching to Cassandra is its beautiful no-single-point-of-failure, tunable-consistency implementation of data replication and data partitioning. That is something you might soon find indispensable. However, if you add the inherent complexities of distributed systems to the data modeling requirements mentioned before, you will see that introducing Cassandra into your organization is not something you should decide on a Friday late afternoon.
If you have a run-of-the-mill application, you are probably better off using a run-of-the-mill DBMS, which is not Cassandra. However, if you have a problem that's more challenging in its data storage requirements, you might want to look at Cassandra.
The fact that Cassandra is different must not be seen as a weakness, because what would be the point of developing yet-another-DBMS? The fact that Cassandra is different is the basis of its success. It is the reason why they moved up to rank #7.
Share this page