Isolation Levels

Read Committed Snapshot Isolation

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.

Foreign Keys

Supported

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.

System Architecture

Shared-Nothing

Logging

Physical Logging

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.

Data Model

Relational

NuoDB is a distributed relational SQL database, where developers can give structure to data by defining schema.

Stored Procedures

Supported

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.

Storage Architecture

Hybrid

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.

Query Compilation

Not Supported

Joins

Nested Loop Join

NuoDB uses the nested loop join algorithms to join two or more tables based on the types and the predicate conditions of the join.

Concurrency Control

Multi-version Concurrency Control (MVCC)

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.

Storage Model

Custom

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.

Views

Virtual Views

NuoDB supports view. Views in NuoDB is not physically materialized. The view will be run when the view is referenced by another query.