YugaByte DB is a transactional database management system that can scale up and down across multiple regions for planet-scale and geo-distributed applications. YugaByte DB is consistent and partition tolerant. It supports distributed ACID transactions, auto-sharding, and auto-balancing. Besides PostgreSQL-compatible SQL API, it provides another two APIs extended from Redis commands and Apache Cassandra Query Language (CQL), respectively.
YugaByte DB uses a customized version of RocksDB, called DocDB, as its underlying storage engine. DocDB is a log-structured merge-tree (LSM) based "key to object/document" store.
YugaByte DB'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 found their own company, YugaByte Inc., aiming to build a database management system to unify the data layer for these mission-critical applications.
YugaByte DB 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.
Nested Loop Join Hash Join Sort-Merge Join
Only YugaByte DB's PostgreSQL-compatible API YSQL supports join operations (i.e., inner, outer, left, and right join). The other two APIs, YEDIS and YCQL, do not support this operation. Currently YSQL is still in beta and is based on part of the open source PostgreSQL 10.4 codebase, so the join algorithms it supports are the same as Postgres, namely Nested Loop Join, Hash Join, and Sort-Merge Join.
YugaByte DB offers the following three query APIs:
Multi-version Concurrency Control (MVCC) Optimistic Concurrency Control (OCC)
YugaByte DB uses MVCC and a variant of OCC for concurrency control. 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 client. After that, the "provisional" records are applied and cleaned asynchronously.
Relying on RocksDB, YugaByte DB's storage engine is responsible for converting every supported data formats (i.e., documents, CQL rows, and Redis data) to key-value pairs and store them in RocksDB. How data compression is accomplished in YugaByte DB depends on how it is done in RocksDB, which uses Dictionary Compression.
https://github.com/yugabyte/yugabyte-db
https://docs.yugabyte.com/latest/
YugaByte, Inc.
2016
C, C#, C++, Go, Java, JavaScript, Python