Aerospike Database is a real-time, high-performance NoSQL database. It is designed for applications that cannot experience any downtime and require high read & write throughput. Aerospike is optimized to run on NVMe SSDs capable of efficiently storing large datasets (gigabytes to petabytes). Aerospike can also be deployed as a fully in-memory cache database. Aerospike offers key-value, JSON document, graph data, and vector-search models. Aerospike is an open-source, distributed, NoSQL database-management system, marketed by the company also named Aerospike.

History

Aerospike was first known as Citrusleaf. In August 2012, the company, which had been providing its database since 2010, rebranded both the company and software name to Aerospike. The name "Aerospike" is derived from the aerospike engine, a type of rocket nozzle that is able to maintain its output efficiency over a large range of altitudes, and is intended to refer to the software's ability to scale up. In 2012, Aerospike acquired AlchemyDB, and integrated the two databases' functions, including the addition of a relational data-management system. On June 24, 2014, Aerospike was open-sourced under the AGPL 3.0 license for the Aerospike database server and the Apache License Version 2.0 for its Aerospike client software development kit.

Release history

VersionFirst Release VersionFirst Release DateLatest versionRelease dateFeaturesRef
Unsupported: 3.13.1.3January 2, 20143.1.14February 25, 2014
Unsupported: 3.23.2.0March 19, 20143.2.9May 12, 2014
Unsupported: 3.33.3.5June 9, 20143.3.26December 3, 2014
Unsupported: 3.43.4.0December 8, 20143.4.1January 12, 2015
Unsupported: 3.53.5.2February 13, 20153.5.15July 15, 2015
Unsupported: 3.63.6.0August 31, 20153.6.4November 10, 2015
Unsupported: 3.73.7.0December 10, 20153.7.5.1March 31, 2016Geospatial queries Native List data type
Unsupported: 3.83.8.1April 15, 20163.8.4June 17, 2016Secondary Index on List, Map & Geospatial
Unsupported: 3.93.9.0July 11, 20163.9.1.1September 2, 2016Rapid Rebalance
Unsupported: 3.103.10.0.3October 21, 20163.10.1.5January 13, 2017Durable Delete Support IPv6
Unsupported: 3.113.11.0January 5, 20173.11.1.1February 15, 2017Transport Layer Security on client-server communications
Unsupported: 3.123.12.0March 15, 20173.12.1.3July 31, 2017Predicate Filters
Unsupported: 3.133.13.0.1May 30, 20173.13.0.11April 26, 2018Clustering Layer refactoring Required "Jump" Release before 3.14
Unsupported: 3.143.14.0June 6, 20173.14.1.10April 26, 2018Clustering Layer refactoring pt. 2
Unsupported: 3.153.15.0.1October 3, 20173.15.1.4January 3, 2018Encryption at rest
Unsupported: 3.163.16.0.1February 21, 20183.16.0.6March 2, 2018
Unsupported: 4.04.0.0.1March 7, 20184.0.0.6September 6, 2018Strong consistency Model
Unsupported: 4.14.1.0.1May 10, 20184.1.0.6September 6, 2018LDAP Support
Unsupported: 4.24.2.0.2May 31, 20184.2.0.10August 10, 2018Increase maximum object size to 8MB
Unsupported: 4.34.3.0.2August 1, 20184.3.1.14April 26, 2019All Flash Namespaces
Unsupported: 4.44.4.0.4November 19, 20184.4.0.15April 26, 2019Change notification Framework - connectors for Apache Kafka and JMS Rack aware reads
Unsupported: 4.54.5.0.1December 12, 20184.5.3.22July 7, 2020Support for Intel Persistent memory for Indexing Record level Data compression
Unsupported: 4.64.6.0.2August 9, 20194.6.0.21September 18, 2020Added bitwise BLOB operations Nested Collection Data Type API support
Unsupported: 4.74.7.0.2September 30, 20194.7.0.26November 25, 2020ADQ Support
Unsupported: 4.84.8.0.1December 12, 20194.8.0.31March 29, 2021Support for client/server compression Support for Intel Persistent Memory for storing data
Supported: 4.94.9.0.3April 8, 20204.9.0.36October 25, 2021Added support for HyperLogLog (HLL) data types Improve Scans for non key value access Modify Eviction/Expiration (TTL) Default behavior Required "Jump" Release before 5.0 (LTS)
Unsupported: 5.05.0.0.3May 14, 20205.0.0.38July 19, 2021Refactor cross datacenter replication (XDR) Strong consistency multi site clustering
Unsupported: 5.15.1.0.3July 31, 20205.1.0.42September 20, 2021Hashicorp Vault integration
Unsupported: 5.25.2.02October 1, 20205.2.0.37October 30, 2021Redesigned predicate expressions
Supported: 5.35.3.0.2December 10, 20205.3.0.27October 30, 2021Added expression filtering for XDR Expanded Multi-Site Clustering
Supported: 5.45.4.0.1January 13, 20215.4.0.22October 30, 2021Added bin level convergence for active-active XDR scenarios
Supported: 5.55.5.0.2February 5, 20215.5.0.20October 30, 2021
Supported: 5.65.6.0.3May 10, 20215.6.0.14October 30, 2021Aerospike Expressions Set Indexes Per-user quotas Boolean datatype
Supported: 5.75.7.0.7September 27, 20215.7.0.9December 10, 2021Improved memory footprint and garbage collection for secondary indices Support for PKI authentication
Latest version: 6.06.0.0.0April 27, 20226.0.0.0April 27, 2022Storing, Indexing and Querying JSON Documents Partitioned Secondary Index Queries
Legend:UnsupportedSupportedLatest versionPreview versionFuture version

Features

Aerospike Database is modeled under the shared-nothing architecture and written in C. It operates in three layers: a data-storage layer, a self-managed distribution layer, and a cluster-aware client layer.

Aerospike uses a hybrid memory architecture: the database indices are stored fully in main random-access memory, while the data is stored on a persistent device using the data layer. The data layer stores the data in a solid-state drive, NVMe, or persistent memory. Reading the data is done using a direct access to the record position on disk using a direct pointer from the primary index, and data writes are optimized through large block writes to reduce latency. This architecture to fetch all records from the persistent device and void the use of data cache. Aerospike also provides the ability to store the data fully in RAM, thus acting as an in-memory database. In that case, data would be persisted to either SSD, NVMe, PMEM, or traditional rotational media.

Aerospike provides single-record ACID transactions. The distribution layer is responsible to replicate the data across nodes to ensure the durability and immediate consistency properties of the transaction. This allows the database to remain operational even when an individual server node fails or is manually removed from the cluster. Since version 4.0 (2018), Aerospike Database can be configured both as Available and Partition-tolerant (AP) or Consistent and Partition-tolerant (CP) under the CAP theorem.

The client cluster-aware layer is used to track the cluster configuration in the database, and manages client direct communications to all the nodes in the cluster. The clustering is done using heartbeats and a Paxos-based gossip protocol algorithm.

The software employs two sub-programs that are codenamed Defragmenter and Evictor. Defragmenter removes data blocks that have been deleted, and Evictor frees RAM space by removing references to expired records.

External links