Although the non-relational databases in the market today provide different features and benefits, a database like Cassandra differs from a typical relational database in the following ways:

Cassandra provides a number of key features and benefits for those looking to use it as the underlying database for modern online applications:

While Cassandra is a general purpose non-relational database that can be used for a variety of different applications, there are a number of use cases where the database excels over most any other option. These include:

Cassandra is well known for its impressive performance in both reading and writing data.

Data is written to Cassandra in a way that provides both full data durability and high performance. Data written to a Cassandra node is first recorded in an on-disk commit log and then written to a memory-based structure called a memtable. When a memtable’s size exceeds a configurable threshold, the data is written to an immutable file on disk called an SSTable. Buffering writes in memory in this way allows writes always to be a fully sequential operation, with many megabytes of disk I/O happening at the same time, rather than one at a time over a long period. This architecture gives Cassandra its legendary write performance.

Because of the way Cassandra writes data, many SSTables can exist for a single Cassandra logical data table. A process called compaction occurs on a periodic basis, coalescesing multiple SSTables into one for faster read access.

Reading data from Cassandra involves a number of processes that can include various memory caches and other mechanisms designed to produce fast read response times.

For a read request, Cassandra consults an in-memory data structure called a Bloom filter that checks the probability of an SSTable having the needed data. The Bloom filter can tell very quickly whether the file probably has the needed data, or certainly does not have it. If answer is a tenative yes, Cassandra consults another layer of in-memory caches, then fetches the compressed data on disk. If the answer is no, Cassandra doesn’t trouble with reading that SSTable at all, and moves on to the next.

While the prior section provides a general overview of read and write operations in Cassandra in the context of a single node, the cluster-wide I/O activity that occurs is somewhat more sophisticated due to the database’s distributed, masterless architecture. Two concepts that impact read and write activity are the data distribution and replication models.

A popular aspect of Cassandra’s replication is its support for multiple data centers and cloud availability zones. Many users deploy Cassandra in this manner to ensure constant uptime for their applications and to supply fast read/write data access in localized regions.

You can easily set up replication so that data is replicated across geographically diverse data centers, with users being able to read and write to any data center they choose and the data being automatically synchronized across all locations.

You can also choose how many copies of your data exist in each data center (e.g. two copies in data center one; three copies in data center two, etc). Hybrid deployments of part on-premise data centers and part cloud are also supported.

Cassandra is a wide-row-store database that uses a highly denormalized model designed to capture and query data performantly. Although Cassandra has objects that resemble a relational database (e.g., tables, primary keys, indexes, etc.), Cassandra data modeling techniques necessarily depart from the relational tradition. For example, the legacy entity-relationship-attribute data modeling paradigm is not appropriate in Cassandra the way it is with a relational database.

Success with Cassandra almost always comes down to getting two things right: the data model and the selected hardware—especially the storage subsystem. The topic of data modeling is of prime importance.

Unlike a relational database that penalizes the use of many columns in a table, Cassandra is highly performant with tables that have thousands or even tens of thousands of columns. Cassandra provides helpful data modeling abstractions to make this paradigm approachable for the developer.

The basic objects you will use in Cassandra include:

Early versions of Cassandra exclusively used the programmatic Thrift interface to create database objects and manipulate data. While Thrift is still supported and maintained in Cassandra, the Cassandra Query Language (CQL) has become the primary API used for interacting with a Cassandra cluster today. This represents a substantial improvement in Cassandra’s usability.

CQL resembles the standard SQL used by all relational databases. Because of that similarity, the learning curve for those coming from the relational world is reduced. DDL (CREATE, ALTER, DROP), DML (INSERT, UPDATE, DELETE, TRUNCATE), and query (SELECT) operations are all supported.

CQL datatypes also reflect RDBMS syntax with numerical (int, bigint, decimal, etc.), character (ascii, varchar, etc.), date (timestamp, etc.), unstructured (blob, etc.), and specialized datatypes (set, list, map, etc.) being supported.

Various CQL command line utilities like cqlsh and graphical tools like DataStax DevCenter can be used to interact with a Cassandra cluster, and client drivers for Cassandra (Java, C#, etc.) also support CQL for developing applications.

While Cassandra does not support ACID transactions like most legacy relational databases, it does offer the “AID” portion of ACID. Writes to Cassandra are atomic, isolated, and durable. The “C” of ACID—​consistency—​does not apply to Cassandra, as there is no concept of referential integrity or foreign keys.

Cassandra offers tunable data consistency across a database cluster. This means you can decide whether you want strong or eventual consistency for a particular transaction. You might want a particular request to complete if just one node responds, or you might want to wait until all nodes respond. Tunable data consistency is supported across single or multiple data centers, and you have a number of different consistency options from which to choose.

Consistency is configurable on a per-query basis, meaning you can decide how strong or eventual consistency should be per SELECT, INSERT, UPDATE, and DELETE operation. For example, if you need a particular transaction to be available on all nodes throughout the world, you can specify that all nodes must respond before a transaction is marked complete. On the other hand, a less critical piece of data (e.g., a social media update) may only need to be propagated eventually, so in that case, the consistency requirement can be greatly relaxed.

Cassandra also supplies lightweight transactions, or a compare-and-set mechanism. Using and extending the Paxos consensus protocol (which allows a distributed system to agree on proposed data modifications with a quorum-based algorithm, and without the need for any one "master" database or two-phase commit), Cassandra offers a way to ensure a transaction isolation level similar to the serializable level offered by relational database.

Moving data from an RDBMS or other database to Cassandra is fairly easy depending on the state of the existing data. The following options currently exist for migrating data to Cassandra:

Cassandra provides a familiar security paradigm for anyone coming from a relational database. Cassandra defaults to having no security enabled. You can enable security and create standard login accounts with passwords, and handle operational and data permission management via the familiar GRANT/REVOKE method of assigning and removing permissions.

Cassandra also provides encryption options for data being sent over the wire from a client to a database cluster as well as encryption for node-to-node communications.

Advanced security is available in DataStax Enterprise and includes external authentication capabilities (e.g. Kerberos), transparent data encryption for tables, and data auditing.

Cassandra provides a number of backup options to ensure data protection and restoration should data loss occur. While some users of Cassandra rely on the database’s replication feature to supply a form of data backup to other locations, this plan does not protect against accidental deletion of data or dropping of database objects. Those actions will be replicated to any remote sites that participate in the cluster, so a regular backup plan remains an important part of any Cassandra deployment.

DataStax OpsCenter (a graphical management and monitoring tool for Cassandra and DataStax Enterprise) provides a visual way of scheduling and maintaining backups for a Cassandra database as well as doing graphical restores for a cluster, down to object level restores if desired. Standard command-line tools also provide the ability to do scripted snapshots of node data across a cluster.

Because of Cassandra’s shared-nothing distributed architecture, there are occasions when data inconsistencies occur in a cluster due to incidents like nodes becoming unavailable or disruptions in network connectivity. Cassandra takes steps automatically to reduce the impact of cluster "entropy" of this kind, but administrators must also periodically run maintenance operations to ensure that data is consistent across all nodes in the cluster.

Cassandra provides a scriptable operation called repair that you can run as needed to ensure that all nodes are consistent with respect to the data they contain. For production environments, DataStax Enterprise supplies an automated repair service that transparently handles this administration task for you.