Skip to main content
Loading

Map

Aerospike Maps are an abstract data type with three concrete subtypes - Key Ordered Map (K-ordered), Key-Value Ordered Map (KV-ordered), and Unordered Map. All types of Map share the same API and can cast between each other with the set_type() operation.

A Map can store scalar data types or contain nested List or Map elements. Map operations are optimal for manipulating maps directly on the Aerospike database.

Elements in a Map are stored based on the ordering type. Unordered maps do not have a guaranteed order, while K-ordered maps are always stored in key order. When a K-ordered Map is in an in-memory namespace, it will also have a key offset index for faster access.

KV-ordered maps are also stored in key order. When a KV-ordered Map is in an in-memory namespace, it will also have a full index - a key offset index, and a rank offset index.

Map keys can be of type String, Bytes, or Integer. Other map key data types are not recommended and may be explicitly forbidden in future server releases.

Map terminology

  • The key is the identifier of the element in the map.
  • The value is the value of the element identified by a specific map key.
  • The index is the key order of the element in the map.
  • The rank is the value order of the element in the map. If there are multiple elements with the same value, their rank is based on their index order.
{a:1, b:2, c:30, y:30, z:26}

The elements of the map have

a:1b:2c:30y:30z:26
keyabcyz
value12303026
index0 or -51 or -42 or -33 or -24 or -1
rank0 or -51 or -44 or -25 or -12 or -3

Element ordering

In an ordered Map, elements of mixed data types are first ordered by type, then by value. Irrespective of the order type of the map, key, rank, index and value based operations are supported, with a variation in their runtime performance.

Map API

Using the Aerospike client API, an application can retrieve the full map, or operate on individual elements. Atomic map operations work on top level elements, and on nested elements with an additional collection data type (CDT) nested context.

You can click on each of the following operations to see a detailed description of it.

note

Operations on nested list/map elements were added in Aerospike Database version 4.6.

Relative rank operations were added in Aerospike version 4.3.

Map operation flag

get_* or remove_* operations have an opFlags parameter to control what they return back and to modify their search criteria.

OpFlagDescription
INVERTEDInverts the search criteria provided in the op parameters.
  • Remove the 10 map elements with the largest key values: remove_by_index_range(-10, 10, NONE)
  • Remove all but the 10 map elements with the largest key values: remove_by_index_range(-10, 10, INVERTED)
note

Since Aerospike version 3.16.0

Map return types

get_* and remove_* operations have a returnType parameter to control what they return back.

Return TypeDescription
NoneNo results, useful for faster remove operations due to not constructing a reply.
IndexKey order: 0 = smallest key, (N-1) = largest key, where N is the number of key entries in map.
RevIndexReverse key order: 0 = largest key.
RankValue order: 0 = smallest value, (N-1) = largest value.
RevRankReverse value order: 0 = largest value.
CountReturn number of items matching criteria.
KeyKey for single item operations and list of keys for multi-ops.
ValueValue for single item operations, list of values for multi-ops.
KeyValueKey Value pairs. The exact format is client dependent.
  • Keep only the top 10 key elements, return count: remove_by_index_range(-10, 10, INVERTED | COUNT)
note

Since Aerospike version 3.16.0, returnType folded into opFlags.

Development guidelines and tips

  • Multiple operations on List, Map and scalar data types can be combined into a single-record transaction.
  • A map bin is created when a map value is written to a bin, or by using map put, put_items, or increment operations.
  • Use set_type() to convert an unordered map into a K-ordered or KV-ordered map. Alternatively, use a map policy with put or put_items and the map_type in the policy will be used to create the map bin if it did not exist.
  • All map operations work for any map_type. The only difference is performance as detailed in the performance table below.
  • In general, when namespace is data-on-SSD, K-ordered gives the best performance for all map operations at the cost of 4 extra bytes on disk.

Performance

For the operational complexity analysis of map operations, refer to the Map Performance documentation.

Known limitations

  • Maps are bound by the maximum record size. For data-on-SSD, the maximum record size is limited by the write-block-size configuration parameter.
  • Map operations are not supported by Lua UDFs.

Language-specific client operations

Language-specific list operation examples: