Overview article of ScyllaDB (CassandraDB)

Photo by Tobias Fischer on Unsplash

In this article, I will provide an overview of ScyllaDB, a high-performance NoSQL database that is fully compatible with Apache Cassandra. We will delve into its internal structure of data model, constraints and use cases that it has. We aim to equip Data Engineers with the necessary knowledge to understand and implement ScyllaDB effectively in their data ecosystem.

🏗️ Database components

📍 Key spaces

Base entity in ScyllaDB is key-space which is responsible for organizing table internally. Each key-space contains details of how table will distributed “sharded” over database cluster and whether inserted records to tables enclosed will be durably reflected in commitlog.

📍 Tables

Under each key-space, scylla enclose tables. Idea of tables is the same as with any other relational table. However, for each table we not only define it’s structure, but we also provide respective management configs that could be applied.

📍 Primary key

One of the crucial part in this statement is PRIMARY KEY which is a composition of partition key & clustering keys.

⚠️ Every 1st defined field in primary key section is partition key and all subsequent are clustering keys.

Partition key is key that is used in data partition, the idea is that based on hash value derived by applying hash function against partition key, database determine at which node specific data need to be stored. Partition key can be composed out of multiple fields.

Meanwhile clustering key define how data subsequently need to be ordered on machine. In general, definition of that key affects on internal data organization.

📍 Materialized view

The next important entity is materialized view which is physical table derived from natural. This table is intended to address several constraints associated with database essence, particularly:

• To create indexes over existing tables
• Lack of join statement support

❗ Since materialized view are derived data, they has a lower priority than original data. In cases resource insufficiency data in materialized view might become with some delay “lag”.

https://opensource.docs.scylladb.com/stable/using-scylla/materialized-views.html

📍 Secondary indexes

Like any other database, scylla support tools allowing to boost query performance titled as indexes and there are 2 types of them are supported: global & local.

Global index is materialized view with different partition key, which lead to different distribution of records in cluster in comparison with original table. To define them in create index statement you just need to change the partition key.

Local index is materialized view with different clustering key, which keeps the same data distribution (materialized view partition resides on the same node as with original table). To define them you need to keep partition key and provide different clustering key.

CREATE TABLE buildings (
 name text,
 city text,
 height int,
 PRIMARY KEY (
  name,
  height
));

CREATE INDEX buildings_by_city ON buildings (city);  # Global secondary index
CREATE INDEX buildings_by_name_and_city ON buildings (name, city);  # local secondary index

Both of them under the hood will create a materialized view that will be used for speeding up retrieval process.

[embed]Global Secondary Indexes | ScyllaDB Docs ScyllaDB is an Apache Cassandra-compatible NoSQL data store that can handle 1 million transactions per second on a…opensource.docs.scylladb.com

[embed]Local Secondary Indexes | ScyllaDB Docs ScyllaDB is an Apache Cassandra-compatible NoSQL data store that can handle 1 million transactions per second on a…opensource.docs.scylladb.com

⛓️ Data distribution principle

At this section i would like to highlight a principle of how data distributed across the cluster. In general cluster organized into a ring which itself broken into segments named as ranges. Which actually range of hash values. Each range enclose internally Vnodes, representing a contiguous range of tokens owned by a single Scylla node.

Using partition key hash database place record to specific vnode.

Picture 1. Range based distribution principle

⚠️ Each physical node is represented as a collection of virtual nodes (Vnodes)

Picture 2. How vnodes are enclosed under ring principle

Also right in key space you might define replication factor which reside partition replicas over cluster.

🪐 Scylla DB internally

Picture 3. Writing path highlight

To unpack internals let’s consider example of internal processed performed behind scenes in scyllaDB.

Picture 4. SSTable structure

📥 Writing path

1. Data first are written to memtable, which is memory table stored RAM.
2. At the same time record is written to commit log (Append only log file where each new record is appended only to the tail of the file).
3. Since RAM is limited, the data need to be flushed to disk to achieve that memtable represents itself self-balanced or AVL tree which after reaching a certain size, get’s flushed to disk as segment with ordered keys which in DB world known as SSTable.
4. Now we have many SSTables with data marked as deleted and records that are outdated. In background scyllaDB performs compaction process intended to de-duplicate records by saving latest and fusing small segments together.
5. Now we have multiple SSTables on a disk and constantly arriving a new records. To keep the structure database in background files are organized into levels, where lowest level store the most up-to-date records and higher level of data the more they are compacted.

⚠️ Note, that delete & update operation in log-append DBs are always create a new record, but in the case with delete there will respective additional mark

📤 Internal reading path

Step 1. Determination of required node, since Scylla follows ring cluster organization, using a partition key client determines the physical node with your data.

Step 2. After determining node, db engine starts to scan from up-to-date segments presence of required data. To speed up this process it uses bloom filters indicating whether segment contains required data

Step 3. After finding needed segment hash of partition key helps to pick up an offset and quickly get actual record

❗Constraints

The main constraints that you might to face are bounded to interaction with database. Available query language CQL is pretty restricted in terms of it’s capabilities for example:

• You always need to provide partition key condition after where statement. Moreover since you need to select specific partition you will be allowed to use only equal and IN operators
• Then you need to provide condition sequence after where statement exactly matching to primary key definition sequence if you are using cqlsh. However drivers could automatically handle this constraint by themself like python-cassandra drivers does
• Lack of support OR statement
• In log-append databases updates will create a new record, so there is a CONDITION mechanism for updates statement need to be used.
• Lack of join support (Addressing this issue is done by creating one more denormalized table)
• And so on…

So, i would like to recommend to check your particular use case on small data subset…

Photo by Markus Spiske on Unsplash

💭 Summary

ScyllaDB can be effectively used when dealing with huge amounts of data as it offers high write and read throughput with low latencies. However, due to underlying structure given database is more constrained rather than tradition relational DB.

To use database you need to know in advance the read pattern that will be applied against database. Otherwise you will need to create additional indexes leading to storage overheads, due to creation additional table over source table. So, please carefully plan data models in advance.

Also, using such kind of database might be pretty great for your use case if want to store logs due to log-append essence.

However, if you planning to perform complex query operations, joins, aggregations and subqueries this database might not suitable to you.

Under right plan & usage scylla DB could give you significant boost in read performance and capability to handle tremendous volume of data.

📞 Let’s stay in touch

• Linkedin: https://www.linkedin.com/in/adilrashitov/
• Telegram: @ARashitov
• Email: adil.rashitov.98@gmail.com