Primary index queries

The digest of every record in the Aerospike database is indexed in the primary index (PI) of its namespace. This enables query access to all the records in a namespace, and with the assistance of a set index, fast query access to all the records in a set.

Foreground queries

Similar to the SELECT statement in a relational database, a foreground PI query is read-only, and has the query features of being partitioned and partition-tolerant, supporting pagination and filtering.

As the query iterates through the namespace data partitions it returns the current version of each record to the client.

Foreground primary index queries have the ability to:

Filter records by set name. This automatically leverages a set index built on the same set.
Filter records with filter expressions such as last_update() > X. The filter acts as a WHERE clause.
Return only record digests and metadata (generation and TTL).
Return specified bins (projection).
Return a specified number of records with the ability to continue the query from that point (pagination).
Query by data partition (partitioning).

Queries against a set with an established set index may be able to leverage the short query runtime optimization.

Limiting query speed

Each individual query can be capped to run at a specified records per-second limit.

SREs can enforce that the totality of a user’s commands, including queries, are limited to a record per-second rate quota.

Background queries

A client application can issue an asynchronous background query to modify records in place on the server. This is similar to an UPDATE statement in a relational database.

Background queries apply either multiple native bin operations or a user-defined function (UDF) written in Lua to the records matched by the query. Using bin operations (AKA background ops) is often more efficient and higher performing than using a Lua UDF (AKA background UDF).

Background queries have the following features:

Filter records by set name. Will automatically leverage set indexes.
Filter records with filter expressions such as last_update() > X.
Clients can poll for progress and completion of a background query.

Background queries are not partition-tolerant and might miss records when a partition is migrating.