Does it make sense to have dynamic indexes in RediSearch?

Question

For example: consider that a hash (lets call it Event) has two searchable properties: user_id (num) and name (text).

However, whenever I need to filter events by name I aways have the user_id at hand. So I am wondering if it makes sense to have one index of events per user instead of one big index of events for all users.

From my basic knowledge with Redis and RediSearch:

• One index for all events of all users:
  • Prefix: "events:"
  • Key examples: events:123, events:456
  • Pros: easier.
  • Cons: whenever I need to search for events of name "foo" and user_id 100 RediSearch needs to find a block of events using the user_id and then filter the name. The hash needs to be in the same shard or use the coordinator.
• One index per user for its events:
  • Prefixes: "events:%USER_ID%:", ie "events:789" where 789 is an user id
  • Key examples: events:789:123
  • Pros: Smaller indexes for better performance and can be easily distributed.
  • Cons: harder to maintain. If there are 1mi users we have 1mi indexes, dunno if this is a problem or not.

Answer 1

@jonathan it depends on your performance requirements and available memory.

If memory is not an issue (indexing the same doc twice) and you want to reduce the latency to a minimum then that sounds like an optional option.

With one caveat creating so many indexes has an overhead on the GC therefore you should only consider it if the user level index is pretty static or short live and you can define it as TEMPORARY (can be with endless timeout)

See: https://oss.redis.com/redisearch/Commands/#ftcreate