Post

TIL in RediSearch, if you are running an FT.AGGREGATE with a SORTBY, if you apply no MAX, it will only sort the first 10 records. github.com/redis/redis-... One of the really neat things about RediSearch is that it makes you really think about how you're querying your data in #redis.

First, for data modeling, you use FT.CREATE to create a secondary index on top of your data in Redis (either hashes or JSON). You need to consider the documents you want to index (we use prefixes for your keys to determine what you're indexing), then you specify precisely which fields to index.

Then when using FT.SEARCH to query your data you use the RediSearch query syntax to build a filter for your documents. FT.SEARCH forces you to think about how you're going to paginate your data, because by default it only returns the first 10 records matching your filter. Why's that you might ask?

Well, at Redis, we measure execution times in microseconds not milliseconds, by default anything that exceeds 10ms is considered "slow", and we want to be as aggressive as possible in servicing queries. The way indexes are structured in RediSearch, the time complexity of a query is:

O(N) in the size of the Result Set (the documents sent back to you). So, that's why we default to 10, we want some relatively small constant - which in strict time-complexity terms - removes the O(N) (as N is a constant), now you're bound to the access complexity of the index O(1) or O(log(N))