Predefined routines that traverse your records for maintenance purposes. No downtime, no service interruption nor performance degradation.
Use cases
Enforcing retention policy
Privacy-protecting laws require the deletion of customer data after a certain time of inactivity. For example 2 years after a transaction has been processed, or 5 years after a customer has made a purchase the last time. By programming the maintenance directly into your deployments, you keep your company out of troubles. The datastore changes also automatically trigger and write through to the continuous backup.
Encryption key rotation
The key rotation in the data encryption uses this mechanism.
Data model changes
Re-indexing may be necessary or beneficial after your data model changes, for example extending with new fields.
Technical evolution
Upgrades to search and match logic may ask for an internal re-indexing. This is scheduled and executed in coordination with the customer.
Your own use case
Whatever it may be.
Record evolution
Every record has an evolution version field. When you define a change that requires a bump, such as rotating the encryption key or a change to the data model, all records are traversed and the change is applied one at a time. Each record is committed in a separate transaction, with optimistic locking.
The whole process is running on a distributed cluster, involving multiple machines. It finishes once all records have the new evolution number in the attribute field. It can take anywhere from a few minutes to hours depending on the amount of records stored in your index.
During this process, the application is capable of working with both evolution versions.
<- Back to SearchCluster page.