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 provide different sorting options for the same data (e.g., ascending and descending price), you need to create replicas with different ranking settings.
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.
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 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.
Replicas take up the same disk space as their primary index. To keep your application at a reasonable size, make sure to remove unused replicas.
Indices and analytics
We store analytics data on a dedicated server, separate from the indices. We collect all search and click 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.