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.

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.

Data Model

Relational

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

System Architecture

Shared-Nothing

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.

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.

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.

Query Compilation

Not Supported

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.

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.

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 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.

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.