History[01][05]

Paul Mikesell after working on EMC Isilon and Sergei Tsarev after working on a time-series database for AOL, came together to work on their common idea of a database that could handle transactions and also scale which led to Clustrix. Both of them started to build the database from scratch and decided to make the system MySQL compatible but add better ways of distributing and replicating data in the cluster. They worked with various SSD manufacturers to profile their devices and eventually started shipping a Clustrix Database Appliance in 2010. With cloud computing in the picture and commodity hardware quality improving, they released the first software version, ClustrixDB 5.0 in 2014 and discontinued the appliance.

The Clustrix company was acquired by MariaDB in 2018. The product was renamed to MariaDB Xpand in 2022.

Checkpoints[06]

Every 500 milliseconds, a global periodic process running on one of the nodes(chosen when a new group is created) selects the minimum of commit IDs across all nodes to be the globc value. Then, a global checkpoint transaction with the selected globc value is executed marking all prior commits durable and establishing a point in the transaction timeline to which all nodes are able to revert, while still remaining consistent with respect to each other.

Concurrency Control[07]

It uses the two phase locking protocol for writer-writer conflict resolution. It has a distributed lock manager to scale write accesses on hot tables, the lock information is spread across all nodes. The database also has a concept of row level locks which locks only a subset of rows(size is configurable at runtime) instead of the whole table. If a transaction uses most of the rows on the table, the query optimizer promotes it to a table lock.

Data Model[08]

The founders wanted to keep the interface as close to MySQL so that people won't have to change their application code to move from MySQL to ClustrixDB and hence, ClustrixDB follows a relational model.

Foreign Keys[09]

It supports foreign keys just like MySQL but has one more restriction unlike MySQL. It disallows creation of foreign keys with non-unique parents with referential actions CASCADE or SET NULL and throws an error to the user if encountered in DDL statement.

Isolation Levels[07]

The default isolation level is a modified version of ANSI Repeatable Reads, allows a per-transaction consistent snapshot read. The other levels supported are serializable and read committed.

Joins[10]

Since joins are distributed, hash_join etc. don't fit in with the streaming model of ClustrixDB.

Query Interface[11]

Similar to MySQL but there are restrictions on stored procedures like the following: altering a stored procedure, creating a view which calls a stored procedure, creating a prepared statement that calls a stored procedure and savepoints are not allowed.

Storage Architecture[12]

Support for both in-memory as well as persisted tables.

Stored Procedures[11]

Supported but with the following restrictions: altering a stored procedure, creating a view which calls a stored procedure, creating a prepared statement that calls a stored procedure and savepoints are not allowed.

System Architecture[08]

Shared-nothing architecture was chosen so that the database can scale. Each node can perform any read or write. The architecture has three main parts to it:
1. The global transaction manager(GTM): A node in the cluster which coordinates the processing of the transaction in the cluster. On this node, the database engine parses and compiles the SQL statements into query fragments and comes up with an optimal distributed query plan. The fragments are distributed according to the plan and the GTM is responsible for collecting the results and returning it back to the user.
2. The Rebalancer: This is patented technology used by ClustrixDB to distribute data throughout the cluster. The system uses consistent hashing and splices the tables based on multiple indexes into different shards and distributes it across the cluster.
3. The Sierra Database Engine: This handles query planning and execution. It has two parts: the planner comes up with an optimal distributed query plan and the execution engine compiles the query into small executable query fragments and is responsible for executing those queries.

Views[13]

Materialized views are not supported just like MySQL. There is only one major difference from views for MySQL and that is that the DEFINER and SQL SECURITY arguments for views are ignored.