This page outlines the design goals with which YugaByte DB has been built.
YugaByte DB offers strong consistency guarantees guarantees in the face of a variety of failures. It supports distributed transactions.
In terms of the CAP theorem, YugaByte DB is a CP database (consistent and partition tolerant), but achieves very high availability. The architectural design of YugaByte is similar to Google Cloud Spanner, which is also a CP system. The description about Spanner is just as valid for YugaByte DB. The key takeaway is that no system provides 100% availability, so the pragmatic question is whether or not the system delivers availability that is so high that most users no longer have to be concerned about outages. For example, given there are many sources of outages for an application, if YugaByte DB is an insignificant contributor to its downtime, then users are correct to not worry about it.
YugaByte DB supports single-key lineazible writes. Linearizability is one of the strongest single-key consistency models, and implies that every operation appears to take place atomically and in some total linear order that is consistent with the real-time ordering of those operations. In other words, the following should be true of operations on a single key:
- Operations can execute concurrently, but the state of the database at any point in time must appear to be the result of some totally ordered, sequential execution of operations.
- If operation A completes before operation B begins, then B should logically take effect after A.
Multi-Key ACID Transactions
YugaByte DB supports multi-key transactions with Snapshot Isolation, note that the Serializable Isolation level is nearing completion as of this writing (Feb 2019).
Read More about Consistency
YugaByte DB does not re-invent storage APIs. It is wire-compatible with existing APIs and extends functionality. It supports the following APIs:
- YSQL which is being built to be ANSI-SQL compliant and is wire-compatible with PostgreSQL
- YCQL (or the YugaByte Cloud Query Language) which is a semi-relational API with Cassandra roots
The YSQL API is PostgreSQL compatible as noted before. It re-uses PostgreSQL code base.
New changes do not break existing PostgreSQL functionality
Designed with migrations to newer PostgreSQL versions over time as an explicit goal. This means that new features are implemented in a modular fashion in the YugaByte DB codebase to enable rapidly integrating with new PostgreSQL features in an on-going fashion.
Support wide SQL functionality:
- All data types
- Built-in functions and expressions
- Various kinds of joins
- Constraints (primary key, foreign key, unique, not null, check)
- Secondary indexes (incl. multi-column & covering columns)
- Distributed transactions (Serializable and Snapshot Isolation)
- Stored Procedures
Read MoreUnderstanding the design of the query layer.
Written ground-up in C++ to ensure high performance and the ability to leverage large memory heaps (RAM) as an internal database cache. It is optimized primarily to run on SSDs and NVMe drives. It is designed with the following workloads in mind:
- High write throughput
- High client concurrency
- High data density (total data set size per node)
- Ability to handle ever growing event data use-cases well
Read MoreAchieving high performance in YugaByte DB.
YugaByte DB should work well in deployments where the nodes of the cluster span:
- single zone
- multiple zones
- multiple regions that are geographically replicated
- multiple clouds (both public and private clouds)
In order to achieve this, a number of features would be required. For example, client drivers across the various languages should be:
- Cluster-aware, with ability to handle node failures seamlessly
- Topology-aware, with ability to route traffic seamlessly
YugaByte DB is a cloud-native database. It has been designed with the following cloud-native principles in mind:
Run on Commodity Hardware
Run on any public cloud or on-premise datacenter. This means YugaByte DB should be able to run on commodity hardware on bare metal machines, VMs or containers.
No hard external dependencies. For example, YugaByte DB should not rely on atomic clocks, but should be able to utilize one if available.
The database should work natively in Kubernetes and other containerized environments as a stateful application.
YugaByte DB is open source under the very permissive Apache 2.0 license.
You can now read about the following: