Logging

Not Supported

Logging is not supported for recovery. Instead, after a crash data is restored from cloud storage if running there or is restored from the most recent backup.

Storage Architecture

Disk-oriented

System Architecture

Shared-Nothing

Aerospike uses a consistent hashing method to distribute the storage of data across nodes. Distribution is done at a namespace level (see storage model) with records within sets being distributed across nodes. Records are replicated across nodes using the same consistent hashing method and are not replicated on the same node as their original storage location.

Checkpoints

Non-Blocking

Checkpoints serve to backup nodes and can be invoked from a command line API. Checkpoints can be invoked at either the namespace or set level. These backups are formed by completing a scan of the entire namespace or set and writing the result to disk. This backup is restored during recovery. In the event, the node's content cannot be restored from disk it can be restored from a backup from another node.

Isolation Levels

Serializable

Aerospike supports multiple isolation levels: strong consistency, serializability (which it calls linearizability), and session consistency. In strong consistency, the database ensures that all writes occur in a specific order across all nodes. Strong consistency is only supported on a single record level. Under linearizable consistency, reads and writes appear to be atomic system-wide. However, the additional synchronization costs associated with this can impact performance.

Data Model

Key/Value

Aerospike uses a key-value data model. Keys are mapped on to records. Each record is comprised of its key, its bins, and its metadata. Bins are analogous to fields in a relational database. Records are organized into sets. Sets can be configured to have storage policies. Policies dictate whether records are stored on disk or in-memory and replication factors among other parameters. Sets are organized into namespaces.

Views

Not Supported

Stored Procedures

Supported

Aerospike supports what it calls User-Defined Functions (UDFs) which are limited versions of stored procedures. UDFs are able to be invoked on single records when called from a client or can be invoked on a stream of records. User-Defined Functions can be written in Lua which will have access to APIs for whether the UDF is to be invoked on a single record or on a stream of records. UDFs are deployed to all nodes from the primary (which Aerospike calls a principal) so that the same version of UDF is running on every node.

Joins

Not Supported

Query Interface

SQL

Aerospike uses a custom api that is quite similar to SQL. It supports most statements in the SQL that could be applied to its key-value model. It advertises that it is a NoSQL system however the query language is easily mistakable for SQL.

Foreign Keys

Not Supported

Aerospike does not support foreign keys but instead allows users to embed sub-records within records.

Concurrency Control

Not Supported

Concurrency control is implemented by preventing deadlock from arising and timing out or razing errors when they occur. Keys that are being written to or read from are marked as busy and concurrent transactions cannot read or write on busy keys. Instead, transactions competing for a record are queued for a record in a fixed size queue. If a deadlock occurs between transactions, it is resolved by one of the transactions in the dependency cycle timing out. Timeouts are set by clients on a transaction level. If a transaction overflows the wait queue, it is aborted.

Consistency guarantees are provided by policy options that limit the operations that can occur in a transaction. Transactions are only allowed to read records, insert records--including multiple records in a single transaction, blind writes to records, delete records, and read-modify-write records. Each of these policies can be configured at the transaction level. This resolves the need for a higher level concurrency control mechanism.

Indexes

B+Tree Hash Table Red-Black Tree

Aerospike implements indexes differently for primary and secondary keys. Primary indexes are implemented as an in-memory mix of red-black trees and traditional hash-indexes. Consistent hashing allows records to be located to a particular node. Within a single node, records are indexed by red-black trees that it calls sprigs. Secondary indexes are built using in-memory b-trees.

Storage Organization

Copy-on-Write / Shadow Paging

Aerospike uses copy on write storage organization to increase the number of records that can be fit in memory. This means that during transactions only pages that contain modified data are duplicated reducing the amount of duplicated data that is stored in memory. Because storage policies are configurable at the namespace level, different namespaces can be stored on different storage mediums (memory, flash, disk, etc.).

Query Execution

Tuple-at-a-Time Model

Parallel Execution

Inter-Operator (Vertical)

Aerospike allows users to allocate threads to different types of tasks. Most thread types maintain a priority queue of tasks for that type. Priority is set by either the user through the client or by the DBMS if a retry-able failure occurs. Aerospike supports the usage of multiple threads for large scans.

Storage Model

N-ary Storage Model (Row/Record)

Aerospike uses a hierarchical storage model. The highest level of the storage hierarchy is called a namespace. Namespaces exist both above and below the database level of a traditional relational database. A namespace can exist across multiple databases and multiple namespaces can be contained within a single database. Configuration of data storage is done at the namespace level, including the configuration of where data is stored (Memory or Disk) and replication factor. These controls are done through namespace level policies which can be user-defined. Below namespaces lie sets that are akin to tables in a relational database which are comprised of a number of records. Policies can be defined for sets to override the policy of their namespace. Records are all stored contiguously in memory or on disk.