NuoDB is a distributed database management system, which supports SQL. It is designed for hybrid cloud application. It offers scale-out performance, continuous availability, region distribution, multi-tenancy and no knobs administration, which most cloud application requires. And it also provides transactional consistency and durability, which normal databases demand. NuoDB can scale out without sharding. It distributes tasks over multiple processors to avoid bottlenecks. Unlike traditional shared-disk or shared-nothing architecture, NuoDB provides a new peer-to-peer messaging to route tasks to nodes. NuoDB splits its architecture into two layers: a transactional tier and a storage tier. These two layers help to scale the data out in the cloud.
NuoDB was started in 2008 as NimbusDB. It changed its name to NuoDB in 2011. The company was founded by Barry S. Morris and Jim Starkey. In 2012, NuoDB added platform support for Solaris. In May 2013, NuoDB presented a migration assistant to migrate databases from Windows SQL Server onto NuoDB. In 2017, NuoDB added more functional supports for AWS.
In order to provide ACID semantics, NuoDB chooses to use MVCC to deal with conflicts. MVCC considers all data as versioned. It treats a update or a delete as an operation that creates a new version of data. In NuoDB, MVCC is implemented in the TE(Transaction Engine). TEs are actually caches, and these caches hold different versions of data. These versions of data include all the versions that may be needed by the current transaction. A version is said to be pending until the related transaction commits successfully. In NuoDB, when two transaction wants to make updates on the same object, the database will choose the TE where the atom (the place the object is stored) of the object is located as the newest version. MVCC also helps NuoDB to provide Snapshot Isolation model.
NuoDB is a distributed relational SQL database, where developers can give structure to data by defining schema.
NuoDB supports foreign key constraints. The foreign key constraints are stored in the FOREIGNKEYS system table. And a table cannot be dropped if it is referenced in the definition of another table.
NuoDB uses the B-tree method to index.
The default isolation level in NuoDB is snapshot isolation. In NuoDB, it defines the visibility of records into 2 domains. One is the most recent committed version of a record (MOST RECENT). The other one is the snapshot version (SNAPSHOT VERSION), which means that this version was the most recent committed at some point in time. Snapshot Isolation is achieved by the visibility of SNAPSHOT VERSION, and Read Committed is achieved by MOST RECENT. MOST RECENT can be achieved by having the updates in other nodes immediately visible to the transactions in the current node. While in SNAPSHOT VERSION, when a transaction starts, the transactions that is committed before determines the visibility of the data. So you will never see any updates from other transactions while the database is executing your transaction. These two visibility are all supported by the MVCC in NuoDB.
NuoDB uses the nested loop join algorithms to join two or more tables based on the types and the predicate conditions of the join.
The durability of NuoDB is maintained by the SM (storage manager). In order to track the database state, SM maintains a journal of all the updates. The journal is simply an append-only set of diffs. Since the SM does not know anything about the transaction, the journal should be using physical logging.
NuoDB uses Durable Distributed Cache for elastic scale out. NuoDB is split into two parts. One is the Transaction Engines. The other one is the Storage Managers. Transaction Engines give Cache, which are in-memory databases for fast transaction processing. Storage Managers give durability which provides durable storage management with scale-out storage. So NuoDB can be considered as a hybrid database.
In NuoDB, tables are partitioned by storage groups. Storage groups let users to decide where to store the data and how many copies of data should be stored. These policies will be established according to the user requirement for redundancy, continuous availability, and separate processing purposes. NuoDB uses two level mapping between a verison of a tuple and physical storage to define the policy. The first mapping maps a table, which is horizontally partitioned, partition to a storage group. The second mapping maps the storage to one or more storage managers, which represent physical storage units in the database.
NuoDB provides a SQL procedural language for users to create stored procedure, user-defined functions and triggers. Also, NuoDB supports stored procedure, user-defined functions and triggers written in Java.
NuoDB is a distributed database management system. Different from traditional databases, it separate transaction processing from storage management. It has two layers: the transactional layer and the storage management layer. The transactional layer is responsible for atomicity, consistency and isolation, while the storage management layer ensures the durability. The transactional tier is a in-memory tier, which can be seen as a on-demand cache. The storage management tier provides access to data when there is a cache-miss. The processes in transactional tier are called transaction Engines (TEs). The processes in storage management tier are called storage managers (SMs). All the processes in the transactional layer and the storage management layer are linked by a simple peer-to-peer communication protocol. When there is a cache miss in a TE, it can fetch data from any peers (other TEs have cached data or SMs have durable data). This model enables NuoDB to do on demand scale-out and live migration easily.
NuoDB supports view. Views in NuoDB are not physically materialized. The view will be run when the view is referenced by another query.
Linux, OS X, Windows