Analytic Attribute Reindexing Logic

Reltio has optimized the way in which updates to calculated attributes are processed.

As part of the Data Persist job execution, we determine entities where calculated attributes are changed and then reindex only the calculated attributes of these changed profiles instead of reindexing all of the attributes on the entity.

Every entity has a version and the entity is reindexed only when the entity version changes. The version of an entity does not change when only the calculated attributes of the entity are updated. This results in further performance optimization.

Currently, versioning is not available for calculated attributes. This means that all the calculated attributes of the entity are reindexed even if the change was made to a subset of them. By deafult, this performance optimization is turned on for all tenants

Note: After performing a data persist job, if the reindex task finishes with the COMPLETED_WITH_ERRORS status, then some URIs are considered as invalid. Therefore, those URIs are skipped during reindexing. You can find the list of these URIs in the job output and can verify whether these URIs exist in the system or not. In such cases, we can ignore the errors that are displayed for the reindex task.

Use cases to understand the reindexing logic

The following use cases explain the reindexing logic better:

Table 1. Use cases
Data structure Scenario What gets reindexed?
1 entity with 1 calculated attribute only No changes are made to the entity but the single calculated attribute is changed. Only the calculated attribute gets reindexed.
1 entity with 5 calculated attributes No changes are made to the entity but 2 out of the 5 calculated attributes are changed. All 5 calculated attributes are reindexed.
2 entities, each entity with 5 calculated attributes 1 entity is changed and 1 calculated attribute for the same entity is updated. All 5 calculated attributes of the 1 changed entity are reindexed.