Manage Your Indices

Managing your Indices

Once you’ve pushed your data into indices, our API clients offer you methods to rename them, copy them within the same app or across different apps, clear them, and remove them.

Replicating an index

By design, Algolia provides one ranking formula per index. It means that, when you want to provide different rankings for the same data, you need to use the replica indices.

Algolia provides this primary/replica partnership to let you automatically replicate the content of one index (the primary) onto other indices (the replicas).

Replicas have the exact same data as their primary index, and data synchronization is done automatically for you. Every time you add, update, or delete records in your primary index, your replica is simultaneously modified.

Replicas start with the exact same settings as their primary index. However, unlike with data, you can change a replica’s settings.

Replicas for sorting

The primary use case for replicas is to create alternative sorts. For all sorting beyond that of Ranking by Relevance, you’ll need to create secondary indexes called replicas.

Replicas for testing

One additional use case for replicas is testing. You can create a replica solely for the purpose of testing - any kind of testing - like dev, int, uat, or other kinds of pre-production testing, or experimentation, or A/B testing.

Managing Replicas

For purposes of managing indexes, a replica is no different from any other kind of index. This means you can move, copy, or delete an index. When you move or copy a replica, it no longer is attached to the primary; therefore all data and settings synchronization are no longer maintained.

There is one particularity to watch out for: When you delete a primary index, you need to do the same manually with its replicas. Otherwise, they remain on your application as normal indices, no longer having the status of replica. This means that they behave like any normal index: you can change their data and use them as primary indices for other replicas.

Finally, note that replicas take up the same disk space as their primary index. Therefore, to keep space on your application at a reasonable size, you’ll want to remove all unused replicas.

Indices and Analytics

Analytics data is stored on a dedicated server, separate from the one where your indices are.

Additionally, all search and Click Analytics are collected asynchronously, in parallel to the processing of a search. This way, it doesn’t impact the speed of the search.

Keep in mind that there’s no hard link between your indices and their analytics. They’re two different sets of data, stored on separate servers. As a consequence, index management methods like copying, moving, and deleting have no effect on analytics data. For example, deleting an index does not delete its associated analytics.

Let’s look at this in more detail.

How index management methods impact analytics data

Analytics data is referenced by an index’s name. This reference never changes, which can create some confusion (see below).

Renaming an index (move index)

Changing the name of an index doesn’t change the name of the index’s analytics.

This has two consequences:

1. To track the analytics history of the renamed index, you need to keep using the old name.
2. New analytics are referenced by the new name, which means the old and new analytics won’t be merged.

Deleting an index

When you delete an index, it doesn’t delete the associated analytics data. It remains available under the name of the deleted index.

Copying an index

When you copy an index, it has two consequences:

1. It does not copy the associated analytics data. Only one set of analytics data exists, accessible under the original name. Additionally, the new target index has no analytics data.
2. If you use the copyIndex method to overwrite an existing index, the analytics data of the overwritten index will be associated with the copied index (which is incorrect).