Query features and short and long queries
Starting with the Aerospike Database 6.0 release, both the primary index and secondary indexes are created per-partition. As a result, both primary index (PI) queries (formerly known as scans) and secondary index (SI) queries (formerly known as queries) share these features:
- Queries are partitioned - all the partitions can be targeted, or some of them, or a single partition with a query. This allows for large data sets to be processed in parallel. By default, the query targets all the partitions.
- Queries can be paginated - a query may return a very large number of results (billions of records), which could overwhelm the client. The query can be paginated, with the size of the result, using the max records query policy. The client partition filter object keeps track of the query progress across multiple partitions, and can be used to continue the query each time.
- Queries are rebalancing-tolerant - using the Server 6.0 release, compatible clients ensures that queries are able handle automatic partition migration when the cluster changes size.
The server unifies both PI queries and SI queries in a single query subsystem.
Differences between Short and Long Queries
In the Server 6.0 the concept of short versus long queries was introduced. Developers can specify whether the PI or SI query is short or long (which is the default) from the unified Query class of compatible clients. The following table shows the differences between short and long queries.
| Short Query | Long Query |
|---|---|
| Use the short query when the number of records in the result is small and when the query execution is highly concurrent | Use the long query when the number of records in the result is large |
Short queries are not tracked. Useful when short-lived queries run frequently in order to avoid polluting the active_jobs queue | Long queries are tracked in active_jobs queue when they are active and in finished_jobs queue when they complete |
| Measured by query latency and record count histograms | Do not provide latency and record count histograms |
| Short queries cannot be aborted | Long queries can be aborted |
| Short query execution cannot be throttled | Long query execution can be throttled by setting an RPS (records per second) cap |
| Short queries have a default 1s transaction timeout (on the socket) | Long queries do not time out on the transaction length |
Refer to Java client: Java Client Short Query
The Scan classes are deprecated starting with the Server 6.0 compatible clients, such as Java client 6.0.0.