I'm not too familiar with redis and this may well help, so thank you.
I see some data-types on the right. It surprises me that redis doesn't have a numeric data type. I understand that at its heart it is just a key-value store and doesn't ever need to do range-based lookup but it still surprises me.
One consequence of "everything is a string" I've run into (although probably a sign I'm "doing it wrong"), is serialisation overhead in the client.
If redis is expecting strings then it's left to the client to choose an appropriate serialisation which can have either performance or other pitfalls.
Comments
I'm not too familiar with redis and this may well help, so thank you.
I see some data-types on the right. It surprises me that redis doesn't have a numeric data type. I understand that at its heart it is just a key-value store and doesn't ever need to do range-based lookup but it still surprises me.
One consequence of "everything is a string" I've run into (although probably a sign I'm "doing it wrong"), is serialisation overhead in the client.
If redis is expecting strings then it's left to the client to choose an appropriate serialisation which can have either performance or other pitfalls.
Numbers in redis can be natively represented using BITFIELDS.
1) (integer) 0
1) (integer) 100
1) (integer) 100
OK, that's helpful thank you.
That said, all the keys themselves are still strings and therefore you can't have a SET of numbers or bitfields.
How would a native number type avoid some serialization overhead that using e.g. 4 byte BE keys yourself must pay?