When NOT to use Cassandra? [closed]

Answer 1

Let's read some real world cases:

http://planetcassandra.org/apache-cassandra-use-cases/

In this article: http://planetcassandra.org/blog/post/agentis-energy-stores-over-15-billion-records-of-time-series-usage-data-in-apache-cassandra

They elaborated the reason why they didn't choose MySql is because db synchronization is too slow.

(Also due to 2-phrase commit, FK, PK)

---

Cassandra is based on Amazon Dynamo paper

Features:

Stability

High availability

Backup performs well

Read and Write is better than HBase, (BigTable clone in java).

wiki http://en.wikipedia.org/wiki/Apache_Cassandra

Their Conclusion is:

We looked at HBase, Dynamo, Mongo and Cassandra. 

Cassandra was simply the best storage solution for the majority of our data.

As of 2018,

I would recommend using ScyllaDB to replace classic cassandra, if you need back support.

Postgres kv plugin is also quick than cassandra. How ever won't have multi-instance scalability.

Answer 2

When evaluating distributed data systems, you have to consider the CAP theorem - you can pick two of the following: consistency, availability, and partition tolerance.

Cassandra is an available, partition-tolerant system that supports eventual consistency. For more information see this blog post I wrote: Visual Guide to NoSQL Systems.

Answer 3

Heavy single query vs. gazillion light query load is another point to consider, in addition to other answers here. It's inherently harder to automatically optimize a single query in a NoSql-style DB. I've used MongoDB and ran into performance issues when trying to calculate a complex query. I haven't used Cassandra but I expect it to have the same issue.

On the other hand, if your load is expected to be that of very many small queries, and you want to be able to easily scale out, you could take advantage of eventual consistency that is offered by most NoSql DBs. Note that eventual consistency is not really a feature of a non-relational data model, but it is much easier to implement and to set up in a NoSql-based system.

For a single, very heavy query, any modern RDBMS engine can do a decent job parallelizing parts of the query and take advantage of as much CPU and memory you throw at it (on a single machine). NoSql databases don't have enough information about the structure of the data to be able to make assumptions that will allow truly intelligent parallelization of a big query. They do allow you to easily scale out more servers (or cores) but once the query hits a complexity level you are basically forced to split it apart manually to parts that the NoSql engine knows how to deal with intelligently.

In my experience with MongoDB, in the end because of the complexity of the query there wasn't much Mongo could do to optimize it and run parts of it on multiple data. Mongo parallelizes multiple queries but isn't so good at optimizing a single one.

Answer 4

another situation that makes the choice easier is when you want to use aggregate function like sum, min, max, etcetera and complex queries (like in the financial system mentioned above) then a relational database is probably more convenient then a nosql database since both are not possible on a nosql databse unless you use really a lot of Inverted indexes. When you do use nosql you would have to do the aggregate functions in code or store them seperatly in its own columnfamily but this makes it all quite complex and reduces the performance that you gained by using nosql.

Answer 5

You should ask your self the following questions:

1. (Volume, Velocity) Will you be writing and reading TONS of information , so much information that no one computer could handle the writes.
2. (Global) Will you need this writing and reading capability around the world so that the writes in one part of the world are accessible in another part of the world?
3. (Reliability) Do you need this database to be up and running all the time and never go down regardless of which Cloud, which country, whether it's VM , Container, or Bare metal?
4. (Scale-ability) Do you need this database to be able to continue to grow easily and scale linearly
5. (Consistency) Do you need TUNABLE consistency where some writes can happen asynchronously where as others need to be certified?
6. (Skill) Are you willing to do what it takes to learn this technology and the data modeling that goes with creating a globally distributed database that can be fast for everyone, everywhere?

If for any of these questions you thought "maybe" or "no," you should use something else. If you had "hell yes" as an answer to all of them, then you should use Cassandra.

Use RDBMS when you can do everything on one box. It's probably easier than most and anyone can work with it.

Answer 6

Cassandra is a good choice if:

1. You don't require the ACID properties from your DB.

2. There would be massive and huge number of writes on the DB.

3. There is a requirement to integrate with Big Data, Hadoop, Hive and Spark.

4. There is a need of real time data analytics and report generations.

5. There is a requirement of impressive fault tolerant mechanism.

6. There is a requirement of homogenous system.

7. There is a requirement of lots of customisation for tuning.