This type of sort is intended for use cases that require strict sorting or where relevance isn’t key, like for an inventory app or other use cases similar to a database. Exhaustive sorting leverages standard replicas.
An alternative to exhaustive sorting is relevant sorting.
Effect on ranking formula
In Algolia, each of your indices has its own ranking formula which is made of up to three parts:
The first part—sort-by attributes—is optional.
If a sort-by attribute is present, the engine first orders results by their sort-by attribute’s value.
For example, suppose you have an index where you’ve set “price (ascending)” as a sort-by attribute. For the query “iphone”, the engine first selects all records that match “iphone” (and alternatives like prefixes, typos, and synonyms) in the
searchableAttributes. Then, it orders the results from lowest to highest price.
If two records have the exact same price, then the engine orders them according to Algolia’s default ranking criteria. If records have the same values for all the textual ranking criteria, then the engine orders them by custom ranking.
In summary, when you sort by attribute, Algolia’s ranking formula isn’t turned off; instead, the tie-breaking relevance criteria comes after your selected sort-by attribute. With exhaustive sorting, if the sort-by attribute is very granular and has high cardinality, the relevance criteria don’t play a large role in ranking.
For example, consider exhaustively sorting on a timestamp attribute that has granularity up to the millisecond. If none of your records have the exact same timestamp value, then timestamp is the only attribute that plays a role in ranking.
Depending on your use case, this may be what you want, or you may want to decrease your timestamp granularity, or Relevant sorting might be a more appropriate choice.
To make search fast, the engine sorts your data at indexing time. Therefore, each of your indices can only be sorted in one way. To allow for multiple sort orders, Algolia uses replica indices.
A replica is a copy of one of your indices, that has the same data, synchronizes data updates, but can have unique settings. The index from which you copy a replica’s data is the replica’s primary index. If you want to configure an exhaustive sort-by, you should use standard replicas.
For each attribute you want to sort by, you need to create a replica index, which contains a copy of all the data in your primary index. Making a replica adds a new index to your application with the same number of records as the primary.
Replica indices manage the back-end of sorting, but you still need to implement the front end. You can do this with either custom logic or InstantSearch. If you plan to use InstantSearch, you should use the SortBy UI widget.