Building with Aerospike

Aerospike provides full support for key-value store and document store models. In fact, its operations provide much broader support than the textbook definitions of those models. Aerospike is a row-oriented database, where every record (equivalent to a row in a relational database) is uniquely identified by a key. The record’s key and its other metadata live in the primary index. The record’s data lives in the pre-defined storage device of the Namespace it occupies. For detailed descriptions of an Aerospike Record, Namespace, Set, Key, Bins, and Data Types, read the Data Model section of the architecture overview.

Data models

Aerospike supports both key-value store and document store models:

Key-value store model

Records are uniquely identified by a Key composed of the name of the Set and the user key. The user key is the primary identifier for a record from the app you are building on top of Aerospike. Although a value in a K-V store model is traditionally one opaque and schemaless blob of data, Aerospike records consist of one or more Bins of typed data or untyped blob data.

Document store model

A variant of the key-value store model, where a single record is single document of data, encoded in XML, YAML, JSON, BSON. Aerospike customers commonly store a document of data in a Map data type. An Aerospike Map is a superset of JSON that can contain different data types, including nested Map and List structures. Maps transparently use MessagePack compaction for efficient storage. Whereas a traditional document store model stores one document of data per record, an Aerospike record can contain multiple bins, and therefore multiple scalar and collection data types per record. Path expressions provide a powerful mechanism to traversing and querying documents modeled as maps.

Command types

A read or write command is either a CRUD (create, read, update, delete) record operation that executes against an entire record, or a series of bin operations using the operate command. Commands can be executed against one record (single-key) or in a batch against multiple records identified by a list of keys in parallel. Queries leverage indexes to match records across the namespace or set against specified criteria.

Implementation considerations

Application developers should use the following best practices for implementing a data model.

• Aerospike is schemaless. Prior to putting data in the database, you define namespaces to associate data with hardware storage media types. By comparison, sets (equivalent to tables in a relational database) and bins (equivalent to columns in a relational database) are created in real time by the application as it performs write operations into Aerospike.
• Aerospike modifies individual records atomically in Strong Consistency (SC) mode.  Multiple operations on one or more of a record’s bins are combined into one command, which executes under a record lock providing isolation and durability. Multiple commands on one or more records can be combined as a transaction in Aerospike 8.0.0 and later.
• Aerospike data types each have their own APIs of atomic write operations and server-side read operations, such as the Map data type’s get_by_rank_range() operation.