At what point (number of documents) redisearch should be partitioned for best read (latency) full text search performance? Is there a general rule of thumb e.g. to have 20ms response time one shard should have no more than 1MLN documents etc?
Are you using Redis OSS or Redis Enterprise (by Redis Labs) ?
If you are using Redis Enterprise version then you should see here and reachout Redis Labs team for further guidance:
Hope this helps.
@suyog thank you for the suggestion.
I am on OSS.
I have checked the sizing calculator but it does not have latency input.
I see long delays with short terms when searching: “a”, “ab”, etc … The more characters or tokens the faster response. However I need to keep it fast even for short terms when searching.
Hope that makes sense?
Are you looking autosuggestion functionality with just prefix matches ? https://oss.redislabs.com/redisearch/Commands/#suggestions
LIMIT works on the result set.
Can not use autosuggestion as it only works on document’s (as a whole) prefix and not the term prefix. So for example my document has: “star wars” and I need this document to be found when user types “w”…
As a general thumb, I would recommend to do some doing some estimation by benchmarking the search your document on one shard/process prior to going live. If you need more performance or to scale, you can try to setup a redis cluster instead, which usually required 3 node at minimum (to achieve quorum).
Also, these partitioning maintenance or management can be simplified by using redis enterprise as @suyog suggested.