YugaByte DB is a transactional database management system that can scale up and down across multiple regions for planet-scale and geo-distributed applications. According to the CAP theorem, YugaByte DB is consistent and partition tolerant. Combining SQL and NoSQL in one platform, 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. Built on a customized version of RocksDB, YugaByte DB's 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. Companies with lots of experts are able to offer complex DBaaS platforms which hide internal details of the data layer and benefit their app developers. However, for traditional enterprises and small startups, the data layers are mostly coupled within the applications. This is where YugaByte DB targets to rescue.
Since YugaByte DB's storage engine (DocDB) relies on RocksDB, it 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 performed in YugaByte DB depends on how it is done in RocksDB, which uses Dictionary Compression.
YugaByte DB offers the following three query APIs:
Multi-version Concurrency Control (MVCC) Optimistic Concurrency Control (OCC)
YugaByte DB uses MVCC for concurrency control. Although not clearly stated, it uses a variant of OCC to ensure atomicity. 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 to the target tablet storing the row. These records will not be seen by the client unless the transaction commits. If conflicts occur when writing these records, the transaction will restart and abort. In this case, the client will see a certain number of retries (restarts are transparent to clients). If no conflicts occur, the transaction will commit and notify success to client. After that, the "provisional" records are applied and cleaned asynchronously.
https://github.com/yugabyte/yugabyte-db
https://docs.yugabyte.com/latest/
YugaByte, Inc.
2016
C, C#, C++, Go, Java, JavaScript, Python