Set_settings delay in affecting ranking results

Hey everyone! Just started using Algolia and it’s been a total blast to work with so far.

Wanted to ask a quick question on the speed of which using “set_settings” on an index affects the ranking of search results.

For some context, we allow our users to switch how they rank search results – one of the ranking criteria is a number that each record has (an average rating), the other is by the distance search results are from them.

Using python, the call for changing ranking criteria looks like this:

index.set_settings({
    'ranking': [
        ranking_priority,
    ]}) 

The variable ranking_priority is either ‘geo’, ‘desc(number_of_reviews)’, or ‘desc(average_rating)’, as determined by the user.

Once the settings are updated, we then make a search call:

results = index.search('', structured_parameters)

The issue we’re noticing is that in order for the new ranking setting to kick in, Algolia needs a second or two to update – If we do the search call immediately after using “set_settings”, it doesn’t update soon enough to return results that reflect the new ranking parameter.

What’s interesting is that if we keep on making the same search call exactly without attempting to use set_settings again, it eventually “flips”, and the new ranking criteria is reflected in the results.

Now, I understand that algolia advises to have multiple indexes for different ranking criteria, which would work in theory – but being a startup, to do this we’d be doubling a required records amount from ~1 mil to a few mil, which pushes us into a tier we can’t afford at the moment.

Is there a way to use the set_settings feature to quickly change the ranking criteria for a given index when a search call is made, and avoid the delay in the ranking criteria updating?

Hi @natefox,

Thank you for taking the time to write such a detailed post!

Indexing time
Every time settings of an index are changed, the index needs to be re-built.
That process can take from a few seconds to a minute depending on the load of the machine.

You could use wait_task to ensure the index has been re-built, but we recommend you avoid using wait task because it can become a bottleneck in your application.

Switch ranking
If you know the different type of ranking you need to provide for an index, you could create replicas.
Each replica would have different settings, and you can then at query time choose to target the master index or a replica without needing to change settings.

Like you said, this approach will create more records, but you will not be billed for the synchronization operations.

Conclusion
Unless you go to a dedicated server or make use of replicas, there is no real solution for reducing the indexing time.

Maybe someone else has additional inputs?

1 Like

Awesome – this is super helpful. Thank you!

Out of curiosity, what’s happening with the geo ranking that allows it to rank in realtime?

Asking because every time new longitude and latitude coordinates are given, the search results come back super quickly (which is awesome!).

Each time I pass new geo coordinates, I figure it must be recalculating a new ordered ranking each time, since the relative distance for all the records change in relation to the new position?