Skip to main content
Loading

List

Aerospike Lists are an abstract data type with two concrete subtypes - Unordered List and Ordered List. Both types of list share the same API and can be cast between each other with the set_order() operation.

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

List terminologyโ€‹

For the following list,

[ 1, 4, 7, 3, 9, 26, 11 ]
  • The index is the (0 origin) position of an element in the list.
  • The value at index 2 is 7. The value at index -2 is 26.
  • The rank is the value order of the elements in the list. The lowest value element has rank 0.
  • The value of the element with rank 2 is 4. The value of the element with rank -2 is 11.

Element orderingโ€‹

Specify element access through index, rank (value ordering) or element value:

[ 1, 4, 7, 3, 9, 26, 11 ] # Unordered
[ 1, 3, 4, 7, 9, 11, 26 ] # Ordered

Once created, a list's order doesn't change, unless the set_order() API call is used.

Unordered Listsโ€‹

  • An Unordered List maintains insertion order, as long as new elements are appended.
  • In an Unordered List, getting elements by rank will obey the same (just-in-time) ordering.

Ordered Listsโ€‹

  • An Ordered List maintains rank order, and sorts itself every time new elements are added.
  • In an Ordered List, elements of mixed data types are first ordered by type, then by value.
  • By default a new list is Unordered, unless a create policy instructs otherwise.

List APIโ€‹

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

Access the following operations to review detailed descriptions.

note

Operations on nested list or map elements were added in Database 4.6. Relative rank operations were added in Database 4.3.

Development guidelines and tipsโ€‹

  • Multiple operations on list, map and scalar data types can be combined into a single-record transaction.
  • A list bin is created when a list value is written to a bin, or by using list append, insert, set or increment operations.
  • Insertion at either end of the list requires no element walk and is generally fast.
  • If insertions and deletions are mostly at the end of the list, operations are, onโ€“average, fast.
  • For data-in-memory, internal structures are optimized for random-access reads with an offset index.
  • If the namespace saves to disk storage, disk writes may create a bottleneck. For example, if there are not enough nodes or devices or if key use is not evenly distributed. This is especially true for list bins nearing maximum record size.

Performanceโ€‹

For the operational complexity analysis of list operations see List performance.

Known limitationsโ€‹

  • Lists are bound by the maximum record size. For data on SSD, the maximum record size is limited by the max-record-size configuration parameter.
  • List operations are not supported by Lua UDFs.

Language-specific client operationsโ€‹

Language-specific list operation examples: