2

I have the following scenario implemented in sitecore 9.2 and which uses azure search:

  • index1 is configured to index around 100k items under /sitecore/content/shared/data
  • index2 is indexing around 50k items under /sitecore/content/siteroot/data and has 3 computed fields which are doing queries against index1 to calculate different types of data. Each of these fields are used for filtering and there is no possibility to merge them into one.

Is there any customization that can be applied so that when doing a rebuild of the indexes index1 will be rebuilt first and only afterwards index2? Or would it be a better way of modifying the 3 computed fields to use caching instead of being dependent on index1 when getting data? All indexing is done on the CM instance only.

1

I think this is more of an architectural problem. You shouldn't build indexes based on what's in your indexes. (Even though it's different indexes in this case.) Make sure you can build both indexes based on what's in your item structure instead. Otherwise you'll face tons of issues, such as "what items in index2 needs to be re-index when an item in index1 is updated/re-indexed".

Using short-lived caches during indexing can be quite beneficial. I've used it with great success in other scenarios. For example, Sitecore performs the indexing of every language and version of an item. The computation result of a shared field may be the same, so it doesn't have to be re-computed over and over again. A cache worked great for that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.