YugabyteDB is a high-performance transactional distributed SQL database for cloud-native and geo-distributed applications. YugabyteDB is consistent and partition tolerant. It supports distributed ACID transactions, auto-sharding, and auto-balancing. Besides PostgreSQL-compatible SQL API, it supports the Apache Cassandra Query Language (CQL).
YugabyteDB uses a customized version of RocksDB, called DocDB, as its underlying distributed storage engine. DocDB is a log-structured merge-tree (LSM) based "key to object/document" store.
YugabyteDB's first public beta release came out in November 2017. It was initially developed by the former team that built and ran Facebook's NoSQL platform that supported a number of Facebook's real-time applications. They left Facebook and founded Yugabyte Inc., aiming to build a distributed SQL database for mission-critical applications.
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.
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.
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 can be created with the CREATE TABLE and ALTER TABLE commands.
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.
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.
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.
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
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.
YugabyteDB's storage model depends on RocksDB, which uses Static Sorted Table (SST) format.
YugabyteDB's storage engine relies on RocksDB, which is implemented as a log-structured merge-tree (LSM).
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.
YugabyteDB supports non-materialized views in its YSQL API.