Writer & Editor
Sorry, there is no results for this query
Fast indexing ensures that search results contain the most up-to-date information in the most timely manner. The meaning of “timely” depends on every company’s particular business activity. But as mentioned in our previous article on indexing best practices, and repeated below, fast indexing comes out of the box – that is, there’s nothing you need to do to optimize the indexing process, it’s already fast enough for most use cases.
Optimizing an already fast indexing process might seem unnecessary. But in some situations, optimizing adds speed to the standard indexing process. We see this in a handful of advanced use cases where data needs to be updated even faster than usual, sometimes in real-time.
We’ll discuss the following advanced use cases:
*Just a general note on indexing. For all use cases, whether standard or advanced, you’ll always want to perform a “batch indexing process” that updates data in small batches, incrementally, and per attribute.
In this scenario, it’s about how you prioritize some changes over others. We’ll call this “selective updating”. For example, you decide to send some updates now (like price) and others later (like description). This lowers the number of changes in each batch, shortening the frequency of your batching process (e.g., every 5 minutes to every 1 minute).
Another technique is to use “non-delete indexing”, where you set an “is-unavailable” attribute on a record instead of deleting it. Deleting records costs more in terms of performance than merely updating attributes. But it’s a trade-off. While it’s faster to change the value of an attribute, it’s always better to reduce the size of an index via deleting, which makes it faster to index. Thus, the best practice is to do the techniques together: make attribute-changes every 5 minutes and delete those records every 30 minutes.
A crisis situation happens when a factory doesn’t deliver a supply of goods. Or a ship gets stuck in the Suez canal, blocking the world’s supply of goods. In these scenarios, the online business has to immediately remove the unavailable items from its website and replace them with another set of products. They may also have to rethink their promotions.
There’s actually no reason to do anything different from a standard indexing process. However, if the crisis goes on for too long, or requires a lot of changes in a short time, it’s important to avoid overloading the indexing. The best approach then is to categorize the changes:
Black Friday combines the scenarios of high-frequent changes and “crisis”, so you’ll want to follow the suggestions of those scenarios. The difference here is that on Black Friday, the high-activity period could last longer than a crisis, or create sudden spikes of activity – but at least you can plan for the event in advance, which makes it easier to manage.
Users expect search results to have the most up-to-date, accurate information. Technically, this means that they want to see changes in the back office to appear in their search results immediately. Businesses want this as well: outdated information can negatively impact profits and customer trust.
Example: booking a hotel. If a hotel appears available in the search results, users expect that it has the same status and price when they click for more detail. But what if the hotel is booked between the query and the click? You can manage this gracefully with a friendly front-end UX (see below). But you can also mitigate the problem with an additional indexing strategy, often used in real-time systems-level programming that relies on a second, smaller index.
You create a tiny index on the Algolia server that collects updates, up to 1000 records. The front-end code merges this tiny index with your main index on every search, removing results (e.g., out-of-stock items) or updating information (e.g., price) on the fly. Here’s the algorithm:
Here, user expectations and business needs are more stringent: this use case requires that changes in the back-office show up immediately in the search results. We see this in stock market trading or bidding applications, where prices can change every second or even millisecond. If this scenario is yours, contact Algolia and discuss the different advanced settings you can adjust on your application, engine, and data that can maximize your indexing performance. While engine-level changes should rarely be done, in exceptional circumstances, they can shorten indexing times.
One important aspect to performance is perceived performance. We won’t cover UI/UX best practices here, but want to acknowledge the importance of building a front end that gives the feeling of high performance. This is not about creating a false impression, it’s about communicating to the user that there is a (reasonable) waiting time. A friendly progress bar is an example of this: it asks the user nicely to wait, and if it’s not too long, people are ok with that. There are many equally effective ways to manage performance on the UI.
As promised, a word about what we mean by “out-of-the-box high performance”. Our indexing comes with the following technologies:
Our first article on indexing presented a high-level overview of standard and advanced indexing use cases. Our next article walked you through indexing best practices and the implementation details of a standard indexing process. This article discussed how to optimize indexing in advanced use cases.
Now it’s time to help you build solutions. Our remaining articles will provide front & back end code for some of the advanced indexing use cases we discussed, starting with real-time pricing.