ThomasWeiss
ThomasWeiss

Reputation: 1302

Redis key design

I'm wondering if the way we "design" keys in Redis can impact performance and scalability. For example, if I store content related to "users" under keys like "user:<user_id>" and content related to say, groups, under keys like "group:<group_id>", all my keys will start with either "user:" or "group:".

Will this have a negative impact on the way Redis hashes keys internally?

Upvotes: 3

Views: 6964

Answers (2)

Adam Bittlingmayer
Adam Bittlingmayer

Reputation: 1277

There is no negative impact. Precisely the design you mention is recommended in the official Redis docs, which are quite clear on this:

Very long keys are not a good idea, for instance a key of 1024 bytes is a bad idea ...

but, read on:

Very short keys are often not a good idea. There is little point in writing "u1000flw" as a key if you can instead write "user:1000:followers". The latter is more readable and the added space is minor compared to the space used by the key object itself and the value object. While short keys will obviously consume a bit less memory, your job is to find the right balance.

Try to stick with a schema. For instance "object-type:id" is a good idea, as in "user:1000". Dots or dashes are often used for multi-word fields, as in "comment:1234:reply.to" or "comment:1234:reply-to".

(Emphases mine.)

See also: Redis key naming conventions?

As it is basically a hash table under the hood, there is nothing analogous to a SQL-style WHERE. That's where bad design could effect performance.

Upvotes: 7

Jahaja
Jahaja

Reputation: 3302

No, it shouldn't be any issue with prefixing your keys like that. Redis uses a hash table internally which in turn uses a proper hash function (one of the murmur hashes if I recall correctly) that won't budge by prefixes.

Upvotes: 3

Related Questions