Index Best Practices
A guide on managing your indexes, and keeping them up to date with your database. This article also includes tips on keeping indexes organized and optimized for the best possible performance.
As we discussed in multi-tenancy, it's recommended to use a per-user index for production applications. This means that each user of your application will be associated with an Operand index, and will only see data belonging to them.
In this example, we'll discuss approaches on how you can sync data with Operand, to ensure that your users are always getting up-to-date search results.
We're going to build a notes app, which allows users to index the contents of the notes they've written.
On User Creation
When a user signs up for your application, you'll want to create an index for them.
On User Deletion
When a user deletes their account, you'll want to delete their index.
Saving a new Note
When a user creates a new note, you'll want to index the contents of that note inside their index.
Updating an existing Note
When a user updates an existing note, you'll want to update the contents of that note inside their index. This means updating the existing object.
Deleting an existing Note
When a user deletes an existing note, you'll want to delete the contents of that note inside their index. This means deleting the existing object.
(Optional) Backfilling Existing Notes
If you're integrating Operand into an existing application, here are some considerations:
- Each user may not have an index associated with them. When the user is fetching their profile, add a check to see if they have an index associated with them. If not, create one and update their profile before returning it.
- Each note may not have been indexed. When the user is fetching their notes, add a check to see if the note has been indexed. If not, index it and store the corresponding object id before returning it.