Understanding Replicas
On this page
By design, Algolia provides one ranking formula per index. Every index has a unique sorting strategy, which is statically defined at the index level, and can’t be changed at query time. Pre-sorting at indexing time instead of at query time leads to a considerable performance boost.
When you want to provide different rankings for the same data, you need to use replica indices.
Algolia provides primary/replica relationships to let you automatically replicate the content of one index (the primary) onto other indices (the replicas) and synchronize content changes.
Algolia offers two flavors of replicas, standard and virtual replicas. You can choose either one or the other depending on your needs.
What are standard replicas?
Standard replicas are linked to their primary index: a standard replica copies its primary index’s content, but can have different settings. Though linked to its primary, a standard replica is a separate index. This means standard replicas increase the number of records on your application.
Data synchronization and settings in standard replicas
Standard replicas have the exact same data as their primary index, and Algolia handles the data synchronization for you. Every time you add, update, or delete records in your primary index, your replica is automatically modified. You can’t alter this automatic data synchronization.
For example, you can’t directly add, update, or delete records in your replica indices. Standard replicas start with the exact same settings as their primary index. However, you can change a replica’s settings.
The most common modifications to a replica’s settings are to its exhaustive sorting strategy.
What are virtual replicas?
Unlike standard replicas, virtual replicas don’t copy their primary index’s content. While they slightly increase the primary index’s size (less than 10 MB per millions records), they don’t affect the number of records on your application.
Virtual replicas are optimized for the Relevant sort feature.
Data synchronization and settings in virtual replicas
Virtual replicas can be seen as a view of their primary index, meaning that virtual replicas directly access their primary index’s records. Since a virtual replica uses the same data as its primary, every time you add, update, or delete records in your primary index, the modifications are found in your replica. You can’t alter this automatic data synchronization.
For example, you can’t directly add, update, or delete records in your replica indices.
The most common modifications to a virtual replica’s settings are to its relevant sorting strategy.
How do standard and virtual replicas compare?
If it’s not obvious for you to choose between standard and virtual replicas, you can refer to the comparison table below.
One rule of thumb to decide between virtual or standard replicas is your desired sorting strategy. If you need an exhaustive sort, you should pick standard replicas. If you need to use Relevant sort you should pick virtual replicas.
Standard Replicas | Virtual Replicas | |
---|---|---|
Usage | Optimized for exhaustive sorting strategy | Optimized for the Relevant sorting feature |
Data | Automatically synchronized as a copy of the primary | Automatically synchronized, as they use the same data as their primary |
Impact on number of records | Increase the number of records | Don't increase the number of records |
Supported settings | Support all index settings | Support a subset of index settings |
Rules | Support different Rules | Support different Rules |
Synonyms | Support different Synonyms | Support different Synonyms, except placeholders. |
Managing replicas
Creating replicas
Multiple ranking formulas are useful to implement different sorting strategies (for example, sort by price, ascending, or descending, sort by most viewed, etc.)
You can create replicas with the dashboard, or you can use the replicas setting when using the API. Whichever method you choose, these actions replicate all data and settings. You then need to change the sorting strategy of the replica.
Querying replicas
When you want to search a replica index, you need to target the replica index as you would with any primary index.
Changing a replica’s settings
Regarding settings, a standard replica is like any other index: you can change any of its settings.
Virtual replicas supports a subset of the primary’s settings.
For more information on which settings you can change in virtual replicas, refer to the guide on virtual replicas supported settings.
For both standard and virtual replicas you typically want to keep most settings in sync with your primary index. You can ensure setting synchronization by forwarding settings changes made to your primary index to its replicas: to achieve this, set the forwardToReplica
parameter to true when using the setSettings
method.
Deleting or detaching a replica
You can’t edit the contents of a replica index. If you want to edit or delete the replica, you first have to unlink it from its primary index, which turns it into a regular index. Once unlinked, changes to the primary index no longer propagate to the replica index.
Please note that detaching a virtual replicas turns it into an empty index.
Virtual replicas supported parameters subset
Because virtual replicas can be seen as a view of the primary’s index, they support a subset of the available index settings. You can find the supported and unsupported parameters in the list below.
Supported parameters
advancedSyntax
advancedSyntaxFeatures
alternativesAsExact
allowTyposOnNumericTokens
aroundPrecision
attributeCriteriaComputedByMinProximity
attributesToHighlight
attributesToSnippet
attributesToRetrieve
distinct
enablePersonalization
enableRules
exactOnSingleWordQuery
highlightPostTag
highlightPreTag
hitsPerPage
ignorePlurals
maxFacetHits
maxValuesPerFacet
minProximity
minWordSizefor1Typo
minWordSizefor2Typos
paginationLimitedTo
queryLanguages
queryType
removeStopWords
replaceSynonymsInHighlight
responseFields
restrictHighlightAndSnippetArrays
snippetEllipsisText
sortFacetValuesBy
typoTolerance
unretrievableAttributes
Unsupported parameters
attributeForDistinct
attributesForFaceting
camelCaseAttributes
customNormalization
decompoundedAttributes
disableExactOnAttributes
disablePrefixOnAttributes
disableTypoToleranceOnAttributes
disableTypoToleranceOnWords
indexLanguages
keepDiacriticsOnCharacters
numericAttributesForFiltering
optionalWords
searchableAttributes
userData