Cassandra

Cassandra is a wide column NoSQL database where data is distributed as rows. In cassandra, each row does not have to have the same column

It basically looks like regular RDBS however when storing in the system.
For example a table would look like following:

   ID         Last    First   Bonus
   1          Doe     John    8000
   2          Smith   Jane    4000
   3          Beck    Sam     1000

It will be a bit differently, for example:

{ row1: { "ID":1, "Last":"Doe", "First":"John", "Bonus":8000}, row2: { "ID":2, "Last":"Smith", "Jane":"John", "Bonus":4000} ... }

For example a table would look like this:

Cassandra keys

See: Partition Key vs Primary Key vs Sort Key vs Clustering Key

1. Partition key — where the data live? Later will be consistent-hashed to the right node
2. Clustering key — how data is sorted (similar to Sort key of DynamoDB)

Similarity to SQL

Perform querying

To perform querying or inserting in Cassandra, they use Cassandra Querying Language (CQL) which looks similar to SQL:

For example

insert into "Customers" (id, name) VALUES (3, 'hi');

However you cannot do join query

Database schema

In Cassandra, we can have database schema. For example to create a table we can do the following:

create table "Customers"  
(  
    id   bigint primary key,  
    name text  
);

Difference between Cassandra and SQL

Although it looks the same as SQL, functionality wise it's not the same. For example, in Cassandra, you can overwrite the same primary key.

For example in your database if you have record id: 1, name: Austin with 1 is a primary key and you perform an insert:

insert into "Customers" (id, name) VALUES (1, 'hi');

It will overwrite the value of Austin to hi. SQL however prevents us to do this.

[!note]
The reason for this is because if we want to have uniqueness check, Cassandra will have to do a read for each write, therefore will affect the performance of the query. Doing like this make write very efficient.

Lightweight transaction

To prevent the above, Cassandra introduces a concept of lightweight transaction.

So for the query above, we can do something like

insert into "Customers" (id, name) VALUES (1, 'hi') if not exists;

Prioritise Denormalisation

To fully use cassandra, we prefer Database Denormalisation. For example in a normalised database we have

In cassandra, it's actually better to do this

Cassandra is very fast for write but would be slow for read due to the fact that it's append only.

Tunable consistency

Cassandra allow us to tune our consistency by per write, how many minimum node agree?

1. ONE node: maximum availablilty but maybe stale read
2. QUORUM node: some set number of nodes that need to agree — most balanced
3. ALL: all nodes need to agree — strong consistency

This is the same as Design Key-Value store > Data Consistency, Synchronisation. And this can be tuned per query

When to use Cassandra

Cassandra writes faster than MongoDB, DynamoDB due to its append only write.

If you know how to denormalise your data into a few table, each one is for specific pattern then Cassandra will scale very well (even match or better than mongodb). However you need to know how you will query