Skip to main content
Loading

Secondary Indexes in Aerospike Cloud

Overview

A secondary index (SI) is a data structure that locates all the records in a set, based on a bin value in the record. When a value is updated in the indexed record, the secondary index automatically updates.

After your Aerospike Cloud database has been deployed and you have written data into it, you can plan how to improve query performance with secondary indexes. For more information see secondary index.

Secondary index considerations

  • In an Aerospike Cloud database, all records must belong to a set. Secondary indexes must be associated with a particular set. Secondary indexes at the namespace level are not allowed in Aerospike Cloud databases.

  • Aerospike Cloud manages the secondary indexes for each deployment. They cannot be updated or changed directly by client applications.

  • New secondary indexes may not be immediately available for use by the database. The cloud console displays new indexes as soon as they are created, but there may be a delay before database starts using them.

  • Each database may use up to 10 secondary indexes.

Create a secondary index

  1. Log in to your Aerospike Cloud console at https://control.aerospike.cloud.

  2. Select an existing database from the dashboard or the Databases link in the left-side navigation.

  3. Select the Configurations tab near the top of the page.

  4. Click Create Secondary Index. A dialog box appears.

    The dialog box has the following fields:

    FieldDescriptionRequired?
    Set NameThe set to be indexed.Yes
    Index NameThe name of the index. Must be unique for this database.Yes
    Bin NameThe bin to be indexed.Yes
    Index TypeData type of the index.Yes
    Index Collection TypeIf the bin to be indexed contains a Collection Data Type (CDT), specify it here.No
    CDT ContextTo index a nested CDT element, provide a context. See details below.No
    1. Click Create Secondary Index to create the index.

Notes on the CDT Context field

To index multiple specific nested fields in a CDT, fill in the CDT Context text box with a comma-separated list of values indicating the fields to be indexed. The values have the following format:

<CDT_CONTEXT_TYPE>:<VALUE_TYPE>:<VALUE>:<CDT_ORDER>:<PADDING>

The <CDT_CONTEXT_TYPE> field is always required. The following CDT context types are available:

TypeDescriptionExample
list_indexList indexlist_index::7::
list_rankList ranklist_rank::2::
list_valueList valuelist_value:integer:2::
list_value:string:two::
list_index_createList index createlist_index_create::2:ordered:true
list_index_create::2:unordered:true
map_indexMap indexmap_index::7::
map_rankMap rankmap_rank::2::
map_keyMap keymap_key:integer:2::
map_key:string:two::
map_valueMap valuemap_value:integer:2::
map_value:string:two::
map_key_createMap key createmap_key_create:string:two:key_value_ordered:
map_key_create:string:two:unordered:
map_key_create:string:two:key_ordered:

Multiple CDT contexts

You can also specify multiple CDT contexts in a comma-separated list to index values that are at multiple nested levels, such as in a JSON document.

Consider a bin named http_requests which stores data in JSON format. One record in the http_requests bin might look like the following:

"http_requests" : {
"request_details" : {
"method" : "POST",
"status" : {
"http_code": 200,
},
"url" : "/register",
},
"request_id" : 227
}

To query records based on the http_code value, you need a secondary index on the http_code field. Use the following CDT context:

map_key:string:request_details::,
map_key:string:status::,
map_key:string:http_code::

See additional examples of CDT Context usage.

Delete a secondary index

All existing secondary indexes are listed on the Configurations tab. To delete a secondary index, click the garbage can icon to the right of each listing.

Additional resources

The following links contain more information about secondary index usage: