Manage Your Indices

Managing your indices

Once you’ve sent your data to Algolia, it resides in indices. You can rename indices, copy them within the same or across different applications, clear them, and delete them, either from the Algolia dashboard or using our API clients.

Replicating an index

By design, Algolia allows one ranking formula per index. If you want to provide different rankings for the same data, you need to use replica indices.

Replica indices let you replicate an index’s data (the primary) into other indices (the replicas). Replicas have the same records as their primary index, and Algolia automatically synchronizes data changes for you. Every time you add, update or delete records in your primary index, it also updates its replicas.

When you create a replica, it starts as an exact copy of its primary index: they have the same data and the same settings. While you can’t change a replica index’s data, you can change its settings. It allows you to provide different sorts for the same data, run A/B tests, experiment with new settings, etc.

Replicas for sorting

The primary use case for replicas is to create alternative sorts. Whenever you want to offer different sorting options for the same data (for example, from lowest to highest price), you need to create replicas with different ranking settings.

Algolia provides two types of sorting:

• Exhaustive or hard sorting
• Relevant sort

Your use case determines which is a better fit.

Exhaustive sorting

Exhaustive sorting is a “strict” sorting strategy because it re-orders all results based on the sorting attributes. It’s intended for use cases that require exhaustivity or where the relevance isn’t key, like for an inventory app or any other use case similar to a database. Exhaustive sorting leverages standard replicas.

Relevant sort

Relevant sorting reorders only relevant results. This behavior is a state of the art sorting experience, especially in e-commerce, marketplace, and media content discovery. Relevant sorting leverages virtual replicas.

Replicas for testing

Another use case for replica indices is testing. You can create a replica for pre-production testing (user acceptance, quality assurance, etc.), to experiment with different settings, or to perform A/B testing. If the parameters you’re testing are supported by virtual replicas, you can use them to save space. If not, or if you want to separate indices for your separate environments, you should use standard replicas.

Managing replicas

A replica is no different from any other kind of index, which means you can rename, copy, or delete it. When you rename or copy a replica, you detach it from its primary index. The replica becomes a primary index itself and is no longer synchronized with its former primary index.

If you want to reattach an index as a replica, you need to follow the same steps as creating a replica for the first time. In other words, you need to declare the index as a replica of the primary, either through the dashboard or API using the replicas setting.

If you delete a primary index, you need to delete its replicas manually. Otherwise, they remain on your application as primary indices: you can change their data, and create replicas from them.

Standard replicas, unlike virtual replicas, take up the same disk space as their primary index. They also add to your record count. To keep your application at a reasonable size, make sure to remove unused replicas.

Indices and analytics

Algolia stores analytics data on dedicated servers, separate from the indices. Algolia collects Search and Click and Conversion Analytics asynchronously, in parallel to search processing. This way, gathering analytics never impacts the speed of search.

There’s no hard link between your indices and their analytics. They’re two different sets of data stored on separate servers. Consequently, index management methods such as copying, moving, and deleting have no effect on analytics data. For example, if you delete an index, it doesn’t remove its associated analytics data.

We reference analytics data by the name of its index. This reference never changes.

Renaming an index

Changing the name of an index doesn’t change the name of the index’s analytics. The new name references new analytics—the old and new analytics aren’t merged. If you want to preserve an index’s analytics history, you need to keep using the old name.

Conversely, this mechanism ensures that you never lose analytics data when you atomically reindex your records.

Deleting an index

When you delete an index, it doesn’t delete the associated analytics data. It remains available under the deleted index’s name, allowing you to export it using our Analytics REST API.

Copying an index

When you copy an index, it doesn’t copy the associated analytics data. The new index starts fresh. However, you need to be careful when using the copyIndex method to overwrite an existing index, as it associates the existing analytics data of the overwritten index with the new one.