Long keys on Redis

gistfile1.md

The example key you give is for a set, set lookup methods are O(1). The more complex operations on a set (SDIFF, SUNION, SINTER) are O(N). Chances are that populating $userId was a more expensive operation than using a longer key.

Redis comes with a benchmark utility called redis-benchmark, if you modify the "GET" test in src/redis-benchmark.c so that they key is just "foo", you can run the short key test after a make install:

diff --git a/src/redis-benchmark.c b/src/redis-benchmark.c
--- a/src/redis-benchmark.c
+++ b/src/redis-benchmark.c
@@ -475,11 +475,11 @@
         benchmark("MSET (10 keys)",cmd,len);
         free(cmd);
 
-        len = redisFormatCommand(&cmd,"SET foo:rand:000000000000 %s",data);
+        len = redisFormatCommand(&cmd,"SET foo %s",data);
         benchmark("SET",cmd,len);
         free(cmd);
 
-        len = redisFormatCommand(&cmd,"GET foo:rand:000000000000");
+        len = redisFormatCommand(&cmd,"GET foo");
         benchmark("GET",cmd,len);
         free(cmd);

Here's the GET test speed for 3 subsequent runs of the short key "foo":

59880.24 requests per second
58139.53 requests per second
58479.53 requests per second

Here's the GET test speed after modifying the source again and changing the key to "set-allBooksBelongToUser:1234567890":

60240.96 requests per second
60606.06 requests per second
58479.53 requests per second

Changing the key yet again to "ipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumlorem:1234567890" gives this:

58479.53 requests per second
58139.53 requests per second
56179.77 requests per second

So even really really long keys don't have a large impact on the speed of redis. And this is on GET, a O(1) operation. More complex operations would be even less sensitive to this.

I think that having keys that clearly identify what values they hold greatly outweighs any minuscule speed performance you'd get out of abbreviated keys.

If you wanted to take this further, there's also a -r [keyspacelen] parameter on the redis-benchmark utility that lets it create random keys (as long as they have ':rand:' in them), you could just increase the size of the prefix in the testing code to whatever length you wanted.