Redis: The Map (SET / GET / DEL)

Follows Redis 02: RESP, The Wire Protocol, which turned raw bytes into a parsed command, and hands off to Redis: One Thread, Many Clients.

Before you start. You already have a command in hand - SET name garv - because the wire-protocol stage parsed it out of the raw bytes for you. This lesson answers the question that parsing left open: once you have SET, GET or DEL, where does the data actually live?

The idea in 30 seconds

A database that looks things up instantly is just a machine that computes where the answer lives, instead of searching for it - Luhn’s 1953 trick, run by a computer.
The number is a hash, the shelf it names is a bucket, and SET/GET/DEL are three thin calls onto that shelf.
Two keys landing on the same bucket is a collision; the bucket copes by chaining, one coat hooked behind another.
The load factor, entries per bucket, is the average length of chain a lookup walks, and a high one makes the table slow with no error to warn you.
Growing the table means recomputing every key’s bucket, and doing that all at once is a multi-second stall on the one thread that answers everyone.
Redis avoids the stall by keeping two racks and moving one coat across on every ordinary operation, so the move is invisible and never blocks anyone.

Read the story · Skip to the numbers