I am pretty new to NoSQL, but I always liked the idea of it. I took a look at Redis, and got a few questions about the best ways of storing and recieving multiple hashes
.
Assuming the following scenario:
Store a list of objects (redis 'Hashes') and select them by their timestamp.
To archive this in SQL
, it would require one table and two simple queries (INSERT & SELECT).
Trying to do this in Redis
, I ended up creating the following structure:
- Key
object:$id
(hash) containing the object
- Key
index:timestamp:$id
(sorted set)
score
equals timestamp
and value
includes id
While I can live with the additional maintenance work of two keys instead of one table (SQL), I am curious about the process of selecting multiple objects:
ZRANGEBYSCORE index:timestamp:$id timestampStart timestampEnd
This returns an array
of all IDs which got created between timestampStart
and timestampEnd
. To get the object itself I am requesting every single one by:
GET object:$id
- Is this the right way of doing it?
- In comparison with an SQL Database: Is it still appreciably faster or might it even become slower caused by the high number of
GET
s?
A ZRANGEBYSCORE
costs O(log(N) + M)
where N=|items in your set|
and M=|items you're selecting|
. So, doing the ZRANGEBYSCORE
and then M GET
operations is just O(long(N)+M+M)
= O(log(N)+M)
and would at most be twice as slow. The network back and forth could have been a major slow down, but since each of your gets is an independent operation, you can just pipeline them. You can also put the whole thing in a Lua script and just have one back and forth, which would be the most optimal. I'd say with 99% certainty this would be faster than doing the same thing in SQL.
Also, if this is a very frequent operation for you, you can get even more speed up by just storing the entire object in your sorted set instead of just the id. You'd have key = object encoded as json
, score = timestamp
. This would save you O(M)
on your operation in terms of not needing to do any GET
s.
Whether or not this is a good way of doing things really depends on your use case. How much speed do you really need, and how important are other features of a traditional database to you? Remember, Redis is much more just datastructures accessible by clients than a traditional database, and it must store everything in RAM. To know whether it's the right thing for you, we'd need more information.