Key-Value Operations

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.

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

Operation types

Aerospike provides two types of atomic operations, which support broader use cases than the two models described above. Because Aerospike stores data by key and value pair, this document describes its operations as Key-Value Operations:

Record operations

Individual CRUD (create, read, update, delete) record operations.

Transaction operations

Bin-based operations executed in sequence on a record using the operate() client method.

Implementation considerations

The following Aerospike features inform best practices for implementing a data model. Application developers should keep these points in mind:

• 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 supports record-atomic transactions. Multiple operations on one or more of a record's bins can be combined into one transaction. The transaction executes under a record lock with isolation and durability.
• 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.
• Starting with Aerospike version 4.6, Map and List operations can be applied on deeply nested elements.
• For non-atomic operations, the record's generation metadata (data modification count) can be used to ensure that the data being written was not modified since the last read. This optimistic concurrency allows application developers to use a check-and-set (read-modify-write) pattern. For a language-specific example, see Java Read-Modify-Write.