Checkpoints

Consistent

Compression

Dictionary Encoding

Relying on RocksDB, YugabyteDB's storage engine is responsible for converting every supported data formats (i.e., documents, CQL rows) to key-value pairs and storing them in RocksDB. How data compression is accomplished in YugabyteDB depends on how it is done in RocksDB, which uses Dictionary Compression.

Concurrency Control

Multi-version Concurrency Control (MVCC) Optimistic Concurrency Control (OCC)

YugabyteDB uses MVCC and a variant of OCC for concurrency control (as of March 2022, the pessimistic concurrency control was in active development). Under a distributed environment, it uses Two-Phase Commit with Early Acknowledgement. When a transaction wants to modify a number of rows, it first writes "provisional" records of each modified row into the target tablet storing the row. These records cannot be seen by the client unless the transaction commits. If conflicts occur when writing these records, the transaction will restart and abort. Otherwise, the transaction commits and notifies success to the client. After that, the "provisional" records are applied and cleaned asynchronously.

Data Model

Relational Key/Value

YugabyteDB's storage engine, DocDB, is based on RocksDB. Unlike RocksDB, DocDB is a "key to object/document" store instead of a "key to value" store. Values in DocDB can be primitive types as well as object types (e.g., lists, sorted sets, and sorted maps) with arbitrary nesting.

Foreign Keys

Supported

Foreign keys can be created with the CREATE TABLE and ALTER TABLE commands.

Indexes

Log-Structured Merge Tree

YugabyteDB supports log-structured merge-tree (LSM) and generalized inverted (GIN) indexes. These indexes are based on YugabyteDB's DocDB storage and are similar in functionality to PostgreSQL's btree and gin indexes, respectively.

Isolation Levels

Read Committed Serializable Snapshot Isolation

Joins

Nested Loop Join Hash Join Sort-Merge Join

YugabyteDB SQL API supports the following types of joins: cross join, inner join, right outer join, left outer join, and full outer join.

YugabyteDB uses the following join algorithms: Nested Loop Join, Hash Join, Sort-Merge Join.

Logging

Command Logging

YugabyteDB uses the Raft distributed consensus algorithm for replication, so all the changes to the database will be recorded in Raft logs, which can be used during recovery.

Query Interface

Custom API PL/SQL

YSQL is a PostgreSQL code-compatible API based around v11.2. YSQL is accessed via standard PostgreSQL drivers using native protocols. It exploits the native PostgreSQL code for the query layer and replaces the storage engine with calls to the pluggable query layer.

YCQL is a Cassandra-like API based around v3.10 and re-written in C++. YCQL is accessed via standard Cassandra drivers using the native protocol port of 9042. In addition to the 'vanilla' Cassandra components, YCQL is augmented with the following features: - Transactional consistency - unlike Cassandra, Yugabyte YCQL is transactional. - JSON data types supported natively - Tables can have secondary indexes

Storage Architecture

Disk-oriented

YugabyteDB is a disk-oriented database management system. However, as its storage engine is implemented as a log-structured merge-tree (LSM), some of the data will be stored in memory before flushed out to disk.

Storage Model

Custom

YugabyteDB's storage model depends on RocksDB, which uses Static Sorted Table (SST) format.

Storage Organization

Log-structured

YugabyteDB's storage engine relies on RocksDB, which is implemented as a log-structured merge-tree (LSM).

Stored Procedures

Supported

System Architecture

Shared-Nothing

YugabyteDB uses shared-nothing system architecture. A table will be split into multiple tablets. Depending on the replication factor, each tablet has its corresponding number of replicas (tablet peers) across different nodes.

Views

Virtual Views

YugabyteDB supports non-materialized views in its YSQL API.