Glossary

ACID is the acronym for the database transaction properties of atomicity, consistency, isolation, and durability.

The admin domain is one or more Admin Processes (APs) that are used to manage one or more databases. All databases in a domain are managed using the same APs. See also Admin Process (AP).

An AP is the process that manages database Transaction Engine (TE) and Storage Manager (SM) process lifecycle and is a member of a single admin domain. The AP also tracks the state of all database processes in the distributed system, replicates state information to other APs in the admin domain, and provides client load balancing to TEs. An admin domain must contain at least one AP. Any additional APs join the domain by securely connecting (peering) into the domain using another AP. See also NuoDB Admin.

The admin server is the server associated with an Admin Process (AP). See also Admin Process (AP).

The archive is the directory on a Storage Manager (SM) that is used to store a copy of the entire database or part of the database (if storage groups are used) on disk. The archive directory contains individual atom files. See also atom and Storage Manager (SM).

When a Storage Manager (SM) joins a running database, or when a storage group is added to it, that SM must perform archive synchronization to ensure that its archive is up-to-date and consistent with the running database. During archive synchronization, the SM requests a copy of each out-of-date atom in its archive from another running SM.

Atom is the internal object structure representing all data and metadata in a NuoDB database. Atoms are self-coordinating objects that represent specific types of information (such as data, indexes, or schemas). Atoms are stored in memory on both Transaction Engines (TEs) and Storage Managers (SMs) or serialized over the network and stored to disk by SMs. See also Storage Manager (SM).

Atomicity is a database transaction property that requires that either all processing done in a transaction is completed successfully or none of the processing in the transaction is done. In other words, if a transaction is unable to complete all its processing, then the database state is returned to what it was before the transaction started.

The chairman is an engine process handling concurrent access to an atom. The chairman is the first Transaction Engine (TE) in the node list unless there are no TEs in the node list, then it is the first Storage Manager (SM) in the node list. The node list is the list of SMs and TEs caching the atom. The node list is typically in the temporal order in which the engines cached the atom.

Cold restart is the process of shutting down all processes on a given database before restarting the database.

Consistency is a database transaction property that ensures that the database is in a valid state after a transaction. For example, consider a transaction that moves money from account A to account B. The total of both accounts must be the same before the transaction and after the transaction.

Continuous availability is the ability of a NuoDB database to continue working if one or more hosts shut down. Active transactions on failed hosts are aborted, and errors are reported to clients. Active transactions on surviving hosts are not disrupted.

Saving and storing database snapshots provides continuous data protection because each snapshot provides a virtual copy of the entire database. A snapshot shows what the database looks like at that point in time.

A NuoDB database is a variable number of Transaction Engine processes and Storage Manager processes running on a variable number of hosts. Each process can be referred to as a node. A database is a set of nodes. A database can be served by any number of Transaction Engines (TEs) and Storage Managers (SMs). Each TE and each SM serves one database. For example, a database could run on Amazon Web Services (AWS) and on machines at the customer site, each with separate administration of the physical machines.

A Database Administrator (DBA) is responsible for creating and managing database schemas, creating and managing indexes, monitoring database performance by using the Automation Console and NuoDB system tables, resolving performance issues by adjusting application behavior, adjusting indexes, or working with the domain administrator to deploy additional resources for a database.

A database object is any defined object used to store or reference data in a database. Some examples of database objects include tables, views, sequences, and indexes.

A distributed database is a database that is composed of multiple processes which can be deployed across multiple shared-nothing servers within a single location or across multiple locations.

A domain is a collection of machines or cloud instances that have been provisioned to work together to support NuoDB databases. It contains many databases and each database can run on one or more hosts.

A NuoDB domain set of peers.

A DBA is a user responsible for provisioning a set of hosts where NuoDB runs and monitoring the overall health of the domain.

The domain configuration provides domain configuration information that is stored consistently on each NuoDB Admin Process (AP) in the domain using a Raft log.

Durability is a database transaction property that ensures that changes made during a transaction are persistent and can be re-created in case of a system failure. NuoDB ensures durability using the Storage Manager processes, the archive directory, and the journal directory.

The Enterprise License has no restrictions.

Hot copy is a mechanism for copying a database’s archive and journal from one of the database’s running Storage Managers (SM). The advantage of a hot copy is that it is an online procedure. Your database remains running and available during the hot copy operation. See also Storage Manager (SM).

The journal is NuoDB’s write-ahead log, which is used by databases to recover data in case of an SM failure. It stores all transactions that change the state of any atom. These changes are subsequently applied to the archive and then purged from the journal.

The leader Admin Process (AP) is elected by the Raft Consensus Algorithm to determine the AP majority. The leader AP performs the liveliness checks for the domain and determines if another AP is no longer responding. All safe operations require acknowledgments from an AP majority. See also Admin Process (AP).

The Limited Use License is limited to three Transaction Engines (TEs) and one Storage Manager (SM). It is free of charge and allows you to self-evaluate NuoDB through a series of quick-start guides and/or build and run your applications on your laptop, desktop, or in the cloud.

Load balancing is the act of distributing the workload among multiple processes. In NuoDB, the AP manages the load balancing of SQL connections to the Transaction Engine (TE). See also Transaction Engine (TE).

The management tier is the architectural tier managed using NuoDB Admin.

The membership is the list of Admin Processes (APs) that have been provisioned and are part of the NuoDB domain. This list is stored on disk and its content is agreed on by consensus. It is important to note that an AP can be shut down but remain in the durable membership while it is unconnected.

A multi Host is a NuoDB template that can be selected when creating a database. The default behavior is that it starts two Storage Managers (SMs) and as many Transaction Engines (TEs) as possible. Each host will have at most one SM and one TE so this template can be used for any number of hosts. A process is restarted on a new host if a host goes offline and another host is available.

Multi-Version Concurrency (MVCC) is a form of concurrency control that uses multiple versions of records to provide a consistent view of the data to each transaction and to prevent concurrent transactions from overwriting each other’s changes. Under MVCC, readers do not block writers, and vice-versa.

Multi-tenancy is the ability of one NuoDB domain to host more than one database.

The NuoDB Admin layer is used to manage domain and database configuration. See also Admin Process (AP).

NuoDB Archive (nuoarchive) is a command line utility that can do the following:

NuoDB Command (nuocmd) is a command line tool that enables you to control, monitor, and analyze a NuoDB domain.

NuoDB Durable Distributed Cache (DDC) is the architecture that scales dynamically, has no single point of failure, and delivers ACID transaction properties.

NuoDB Loader is a command line tool for importing and exporting data.

NuoDB Migrator is a command-line Java program that helps Database Administrators (DBAs) migrate schemas and existing data to a NuoDB database. It interfaces with a source database over a JDBC-compliant driver and is designed to support all major RDBMSs. It also interfaces with the NuoDB target database using the NuoDB JDBC driver. NuoDB Migrator can be used as a NuoDB backup/restore utility where both the source and target databases are NuoDB.

NuoDB SQL (nuosql) is a command line tool for exploring NuoDB databases. It enables you to execute SQL statements interactively, run batch scripts, access database metadata information, and perform Database Administrator (DBA) functions.

A domain must contain at least one Admin Process (AP). Any additional APs join the domain by securely connecting (peering) into the domain using another AP. The APs communicate with each other to make sure they are still accessible and available. Peering is configured using the nuoadmin.conf file on each host. On each host, the value of the peering property value used is the hostname and port of the host machine running the initial AP.

Pseudo system tables contain data that is generated by NuoDB processes every time you query it. This data does not exist in this form in persistent storage but is presented as a SQL table. For example, SYSTEM.QUERYSTATS and SYSTEM.NODES are pseudo system tables. A pseudo system table is not a database table object. You cannot create one nor can you use DML to operate on one. You can only select from and read the data in a pseudo system table. Not to be confused with a temporary table.

In a domain, a quorum is a minimum number of Admin Processes (APs) that must acknowledge a change to the durable domain configuration for that change to be made. Usually, this is a simple majority. Many operations in the management tier require acknowledgment from a majority of APs in the domain to ensure safety (never returning an incorrect result) in case of failure.

A Raft log file is created when a NuoDB Admin Process (AP) is started. This file contains information on the state of the domain lifecycle and the database lifecycle.

Redundancy zones are physically separated data centers that are in close proximity (low latency) to each other, within a region. A virtual network is provided to allow an IP subnet to span redundancy zones. To create a fault-tolerant database system, it is common to deploy one or more of each NuoDB process type (AP, TE, or SM) within each redundancy zone. Similar functionality is also available in containerized deployments of NuoDB using AWS Availability Zones or Kubernetes Fault Zones.

Reserved Keywords are the keywords reserved by the NuoDB SQL (nuosql) dialect. For more details, see SQL Keywords.

Never returning an incorrect result.

In contrast to scale-up performance, which increases performance capacity by adding resources to a single server, scale-out increases performance capacity by adding new independent servers or Virtual Machines (VMs).

Service Level Agreement (SLA) is a contract between two or more parties that defines services to be delivered. NuoDB templates are an example of an SLA.

A single host is a NuoDB template that can be selected when creating a database. The default behavior is that it starts one Transaction Engine (TE) and Storage Manager (SM) on a host that you specify. These processes are fixed to the host and are not moved if the host goes offline.

A storage group represents a logical storage unit that can be managed by one or more Storage Managers in a database. Full tables or table partitions can be assigned to a storage group.

A Storage Manager (SM) is a database process responsible for persisting data for a given database to disk. SMs can maintain a full copy or one or more partitions of the data. SMs process SQL data change or insert requests from Transaction Engines (TEs) which send asynchronous messages to the other SMs to commit data to disk and to maintain copies of data in memory. A database can have more than one SM and each SM is associated with exactly one database. A minimally viable deployment of NuoDB must have at least one SM running.

The user must configure a storage password to enable Transparent Data Encryption(TDE) in a database. This password must be given to NuoDB Admin before the database can be started, and it must be given to NuoDB Archive to check an archive or restore a backup set.

The storage tier is the architectural tier where data is stored and managed through objects called atoms. Storage Managers are part of the storage tier in NuoDB’s architecture. See also Storage Manager (SM).

In every NuoDB database, system tables are persistent tables that are stored in the SYSTEM schema. System tables contain important data shared across all processes in the NuoDB domain and available to all connections to the database. This includes information about database objects such as tables, indexes, schemas, triggers, users, roles, and privileges.

A temporary table is a database object that resides in memory for only the current connection. You can define a temporary table with a CREATE TABLE statement and you can operate on it with DML. A temporary table can be dropped during a session. Not to be confused with Pseudo System Table.

A tiebreaker TE is used to help maintain Admin Process (AP) quorum. It is possible to set up one or more Transaction Engines (TEs) so that they no longer service SQL clients but exist solely to make up a quorum. See also Quorum and Transaction Engine (TE).

TEs provide your application with access to a specific NuoDB database. Client connections are established on a specific TE after being load balanced by the Admin Process (AP). TEs execute client application SQL requests, serving as an in-memory data cache, and coordinate transaction execution with other TEs and Storage Managers (SMs). TE processes can be added or removed dynamically without impacting application access to the database. A minimally viable deployment of NuoDB must have at least one TE running. A TE only manages data associated with a single database. However, a database can have more than one TE.

A transaction tier is the architecture tier where transactions are managed to preserve database atomicity, consistency, and isolation. Transaction Engines (TEs) are part of the transaction tier in NuoDB’s architecture. See also Transaction Engine (TE).

Enabling TDE for a database ensures that all user data is encrypted before being written to disk. This includes user data in the archive, as well as data in the journal and spill-to-disk files.

Wasted bytes is the size of disk space consumed by Log Structured Archive (LSA) that does not contain any useful information currently. It is created due to the tradeoff where additional disk space is consumed in return for increased write speed.