Checkpoints

Non-Blocking

Scylla supports non-blocking checkpoints through per-node backup procedures, which include full backup/snapshots and incremental backup. Snapshots are taken by the snapshot operation provided by the nodetool utility, while the incremental backup option can be configured in the configuration file. Automatic unnecessary backup cleaning is not implemented.

Compression

Dictionary Encoding

Scylla uses Apache Cassandra chunked compression on SSTable files. Three dictionary-based compression algorithms are provided: LZ4 (default), Snappy, and DEFLATE. Data needs to be decompressed before being processed during query execution.

Concurrency Control

Multi-version Concurrency Control (MVCC)

Scylla does not support ACID transactions as in RDBMS. However, CQL has a BATCH statement that allows multiple update statements belonging to a given partition key be applied in isolation (note that batches are not a full analogue for SQL transactions). Besides, in UPDATE, INSERT, and DELETE statements, modifications belonging to the same partition key are performed atomically and in isolation. Scylla implements Multi-Version Concurrency Control (MVCC) for partition mutation. Internally, versions are represented by an ordered list of states, where each state is a delta of current mutation.

Data Model

Column Family / Wide-Column Key/Value

Scylla uses the same data model as Apache Cassandra, which represents data in key-value pairs (like row in RDBMS), and organizes a collection of rows as a column family (like table in RDBMS). One or more column families are contained in a keyspace (like database in RDBMS). It is encouraged that one application should use one keyspace.

Foreign Keys

Not Supported

Indexes

Hash Table

Scylla supports both primary key and secondary key indexes. For primary index, Scylla hashes the key and finds the corresponding partition in the consistent hashing ring; within the partition, Scylla finds the row in a sorted data structure (SSTable). For secondary indexes, Scylla maintains an index table for the secondary index keys, where the value for each key is the (primary) partition keys associated with the secondary key. Whenever a secondary index is queried, Scylla first retrieves the partition keys using the secondary index, then retrieves the records with those partition keys returned by the first step.

Isolation Levels

Serializable

Scylla does not support ACID transactions as in RDBMS. However, CQL has a BATCH statement that allows multiple update statements belonging to a given partition key be applied in isolation (note that batches are not a full analogue for SQL transactions). Besides, in UPDATE, INSERT, and DELETE statements, modifications belonging to the same partition key are performed atomically and in isolation. Scylla has a roadmap for supporting CQL Light-Weight Transactions (LWT) in 3.x.

Joins

Not Supported

Each SELECT statement only applies on one single table.

Logging

Logical Logging

Scylla writes a commitlog for each write request coming in. Before the mutation is applied to the MemTable, the commitlog that contains the data in the mutation is written to disk to guarantee the durability.

Query Execution

Vectorized Model

Scylla is designed as a shard-per-core architecture, where all shard runs in parallel. Full table scan queries on Scylla can be made parallel by using the partitioner and token function.

Query Interface

Custom API

Scylla uses Cassandra Query Language (CQL) as the Query Interface. Besides, drivers for the following languages are provided: C++, C#, Go, Java, Node.js, PHP, Python, Ruby, and Rust.

Storage Architecture

Hybrid

Scylla is a disk-oriented DBMS, storing data in SSTable file. Scylla also supports in-memory tables, which reduces read latency for mostly read workloads.

Storage Model

N-ary Storage Model (Row/Record)

Scylla stores data in a sequence of rows.

Storage Organization

Sorted Files

Scylla stores data in Sorted-String Tables.

Stored Procedures

Not Supported

System Architecture

Shared-Nothing

Scylla uses a shared-nothing model. Nodes in the cluster are organized in a decentralized consistent hashing ring and data is partitioned into shards by the key across all nodes. Scylla uses a shard-per-core architecture, where each thread for a shard executes on its own CPU core, memory, and multi-queue network interface controller. Cross-core communication is carried out by explicit message passing. Scylla also uses replicas for fault-tolerance.

Views

Materialized Views

Scylla supports Materialized Views in version 2.0 as an experimental feature. Whenever the base table is updated, the materialized view table will be automatically updated. Materialized View tables are distributed as normal tables and scale as well as normal tables. However, there are still limitations in the current experimental release, including but not limited to lack of local locking and local batch log.