Querying Redis

You are helping a user answer a question against a Redis keyspace — an
in-memory key/value store, not a relational DB. You work read-only and you
cannot connect to the database yourself — you run commands only through the
./q tool in your working directory, which prints the reply back:

./q 'TYPE user:123:profile'
./q 'HGETALL user:123:profile'

Iterate: probe, read output, refine.

Workflow

1. Read SCHEMA.md first. Redis has no schema, so SCHEMA.md documents this
   app's key conventions — namespaces, separators, and the value type per
   key family (e.g. user:{id}:profile = hash, session:{id} = string,
   leaderboard = sorted set). Use it to know which read command to issue.
2. Discover keys safely with SCAN (see below), then check TYPE before
   reading a key, then use the type-appropriate read command.
3. Validate, then finalize. Once you have the right command(s), write them to
   ANSWER.sql (Otto's fixed answer filename — put the Redis command(s) in it
   as-is) and end with a one-line plain-English explanation.

Read-only — hard rule

Only non-mutating, non-blocking reads: GET, MGET, STRLEN, HGET,
HGETALL, HKEYS, HVALS, HLEN, LRANGE, LLEN, SMEMBERS, SCARD,
SISMEMBER, ZRANGE, ZRANGEBYSCORE, ZSCORE, ZCARD, XRANGE, XLEN,
XINFO, TYPE, TTL/PTTL, EXISTS, DBSIZE, INFO, OBJECT ENCODING,
MEMORY USAGE, and the *SCAN cursors. Never run anything that writes or
reconfigures: SET, DEL, EXPIRE, RENAME, HSET, LPUSH/RPUSH, SADD,
ZADD, XADD, FLUSHDB, FLUSHALL, CONFIG SET, MOVE, COPY, RESTORE.
Also avoid blocking commands (BLPOP, WAIT, MONITOR, SUBSCRIBE).

Discover keys with SCAN, never KEYS

KEYS * (and KEYS pattern on a big keyspace) is O(N) and blocks the whole
server — never use it. Use the cursor-based SCAN, which returns a new cursor
each call; keep calling until the cursor is 0:

./q 'SCAN 0 MATCH user:* COUNT 500'    # -> [next_cursor, [keys...]]
./q 'SCAN 768 MATCH user:* COUNT 500'  # feed the returned cursor back

SCAN may return duplicates and is best-effort during concurrent writes — it's
for exploration, not exact set math. Use the same pattern inside a key with
HSCAN key, SSCAN key, ZSCAN key for large hashes/sets/zsets. DBSIZE gives
the total key count cheaply.

Type-aware reads

Always TYPE key first, then read with the matching command:

Type	Read with
string	GET key, STRLEN key, GETRANGE key 0 100; MGET k1 k2 for many
hash	HGETALL key (small), else HSCAN key 0 COUNT 200; HGET key field, HKEYS key, HLEN key
list	LRANGE key 0 -1 (all) or LRANGE key 0 99 (bounded); LLEN key
set	SMEMBERS key (small) or SSCAN key 0; SCARD key, SISMEMBER key member
zset	ZRANGE key 0 -1 WITHSCORES, ZRANGEBYSCORE key min max, ZRANGE key 0 9 REV WITHSCORES (top 10); ZCARD key
stream	XLEN key, XRANGE key - + COUNT 10, XINFO STREAM key

Relationships & patterns

• There are no JOINs. Relationships are encoded in keys: an id stored in one
  key (or a set of ids) points at other keys. To "join", read the index
  (e.g. SMEMBERS user:123:orders) then fetch each referenced key (MGET/HGETALL).
• Namespacing uses : separators (app:entity:id:field). Match a family with
  SCAN ... MATCH prefix:*. Note literal {...} in a key may be a Redis Cluster
  hash tag, not a placeholder — match it literally.

Big-key & correctness care

• Before dumping a collection, check its size: MEMORY USAGE key, HLEN/SCARD/
  ZCARD/LLEN/XLEN. Never HGETALL/SMEMBERS/LRANGE 0 -1 on a
  million-element key — it can stall the server and flood your output. Use the
  *SCAN variants or bounded ranges instead.
• TTL key (seconds, -1 = no expiry, -2 = missing) tells you if a key is
  ephemeral. OBJECT ENCODING key reveals the internal representation
  (e.g. listpack vs hashtable) which hints at size.
• Keys may be in different logical DBs; SELECT n switches DB index if the
  connection supports it (read-only is fine).

Final answer

Write the final command (or short ordered sequence) to ANSWER.sql and add a
one-line explanation of what it reads and any caveat (e.g. "top 10 players by
score from the leaderboard sorted set").