Use Cases: When and Why to Use Cassandra

What Goes Wrong for Cassandra Users

Cassandra projects frequently fail for one or more of the subsequent reasons:

• We used the wrong Cassandra features.
• The Cassandra use case was completely inappropriate.
• It was not done properly to model the info.

False Features

Since Cassandra incorporates a lot of features that probably should not be there, it doesn’t help much, to be honest. Features that give the impression you’ll perform a number of the tasks that everybody expects a computer database to perform include:

Secondary indexes are useful, but they should not be used as a distinct thanks of accessing a table.

Counters: Although they typically work, they’re very expensive and will not be used frequently.

Lightweight transactions: Neither are they nor are they transactions.

Batches: Sending a variety of requests to the server directly is usually an honest idea because it cuts down on network traffic, right? Well, not really in Cassandra’s case.

Materialized perspectives: I fell for this one. It gave the impression to make perfect sense. In fact, it does, after all. But once you consider how it must operate, you think… Oh no!

CQL: It resembles SQL, which causes confusion because people mistake it for SQL.

Any of the aforementioned features employed in a conventional database will almost certainly result in severe performance issues and, in some cases, a broken database.

Correct Your Data Model

Making a poor decision for partition keys is yet one more significant error developers make when constructing a Cassandra database.

Cassandra is detached. This implies a way of distributing the info among several nodes. Cassandra accomplishes this by hashing the partition key, a component of every table’s primary key, and allocating the hashed values (referred to as tokens) to particular nodes within the cluster. When selecting your partition keys, it is important to stay the subsequent guidelines in mind:

• There must be enough partition key values to distribute each table’s data evenly among all the cluster nodes.
• Keep all of the info you want to retrieve within one partition.
• Keep partitions from growing large. Cassandra isn’t very efficient, but it can handle large partitions >100 Megabytes. Additionally, it’s unlikely that your data distribution is going to be evenly distributed if you get partitions that big.
• All partitions should ideally be about the identical size. It not often occurs.

User id, device id, account number, and other common real-world partition keys are listed below. A time modifier, like year and month or year, is often added to the partition key to regulate partition size.

You will suffer greatly if you are doing this incorrectly. It’s probably important to notice that this is applicable to all or any distributed databases in some capacity. The word “distributed” is crucial here.

Inappropriate Cassandra Use Cases

Cassandra is inappropriate for your use case if your database depends on any of the things listed below. Don’t even give some thought to Cassandra, please. You will be depressed.

• There are various access paths for tables. For example, many secondary indexes.
• Finding rows with sequential values is crucial to apply. Oracle sequences or MySQL auto-increment.
• ACID isn’t handled by Cassandra. LSD, oil of vitriol, or another type. Go someplace else if you are feeling such as you need it. People frequently believe they have something while they do not.
• Aggregates: Cassandra doesn’t support aggregates; if you need to perform numerous aggregates, think about using a unique database.
• Joins: you would possibly be able to use your own data modeling to urge around this one, but take care.
• Locks: Cassandra, all told honesty, doesn’t support locking. This can be in hot water for an honest reason. Avoid attempting to use them yourself. I’ve seen what happens when people try and use Cassandra to try and do locks, and therefore the results don’t seem to be appealing.
• Cassandra is superb at writing updates; she does pleased with the reading. Updates and deletions are implemented as special cases of writes, which have unintended consequences.
• Transactions: The begin/commit transaction syntax is absent from CQL. Cassandra isn’t the simplest option for you if you suspect you would like it. Avoid attempting to mimic it. The outcomes won’t be appealing.

You probably do not have a use case for Cassandra if you’re considering it with any of the aforementioned requirements. Please take under consideration utilizing a special database technology that will better fit your requirements.

When to Contemplate Utilizing Cassandra

Every database server ever created was constructed to stick to a collection of design standards. This criterion outlines which use cases the database will work well in and which of them it won’t.

The following are the look requirements for Cassandra:

• Distributed: Operates across multiple server nodes.
• Scale linearly: Adding nodes instead of upgrading hardware on already-existing nodes
• Globally: A cluster could also be dispersed geographically.
• Writes should be prioritized over reads because they’re much faster.
• No master/slave in an exceedingly democratic peer-to-peer architecture.
• Give preference to availability and partition tolerance over consistency
• Support quick, focused reads using the first key: Alternative routes that do not prioritize primary key reads are very inadequate.
• Support for data with a collection lifetime: All data in a very Cassandra database incorporates a set lifetime; once that life has passed, the info isn’t any longer accessible.

The list contains no information on ACID, relational operations, or aggregates. What’s it visiting be good for, you may be asking yourself at this point? All databases must have ACID, relational, and aggregate data so as to function. Without Atomic operations, you can’t guarantee that anything ever occurs correctly, that is, consistently. Without Atomic operations, there is no ACID. You don’t, is that the answer. Consider other options if you were considering using Cassandra to watch account balances at a bank.

Ideal Cases for Cassandra

It seems that for a few applications, Cassandra is admittedly superb.

The following traits define the perfect Cassandra application:

• By a good margin, writes outnumber reads.
• Data updates are infrequent and idempotent once they do occur.
• There is a known primary key for reading access.
• A key will be wont to partition data, allowing the database to be distributed evenly among several nodes.
• Aggregates and joins don’t seem to be required.

My favorite illustrations of beneficial Cassandra use cases include:

• Transaction logging: Items bought grades on tests, movies watched, and most up-to-date movie location.
• Data storage for statistics (as long as you are doing your own aggregates).
• Tracking just about everything, like packages, orders, and order status.
• Preserving fitness tracker data.
• History of the weather service.
• Status and historical data of the net of things.
• Telematics is IOT for automobiles and trucks.
• Envelopes for emails, not the content.

Conclusion

Executives and developers frequently specialize in a technology’s feature set without understanding the underlying design principles or the techniques employed to implement those features. It’s crucial to grasp how the workload and data are distributed when working with distributed databases. Any try and use a distributed database like Cassandra will fail if the look criteria, implementation, and distribution plan don’t seem to be understood, typically in an exceedingly grand manner.

About Enteros

Enteros offers a patented database performance management SaaS platform. It proactively identifies root causes of complex business-impacting database scalability and performance issues across a growing number of clouds, RDBMS, NoSQL, and machine learning database platforms.