Redis Data Types and Commands

Last update: 2024-01-02 17:43:06 +0800 +0800
Available translations: 日本語 / 中文(简体) / 中文(繁體)

Redis associates each key with one data type. A command issued against a key of the wrong type fails, so key naming and value ownership should make the data model explicit.

Redis executes each command atomically on the server thread. Single commands such as INCR, HSET, SADD, and ZADD are therefore safe for one-key state changes, but multi-step read-modify-write sequences need MULTI/EXEC, WATCH, or Lua if they must behave as one unit.

Key Lifecycle #

DEL synchronously reclaims the value and can block on a large aggregate. UNLINK detaches the key and lets Redis reclaim memory asynchronously. Set and inspect expiry with EXPIRE, PEXPIRE, TTL, and PTTL; TTL returns -1 for a key without an expiry and -2 for an absent key.

Do not use KEYS * against a production-sized keyspace because it scans the entire keyspace in one command. Iterate with SCAN instead:

redis
SCAN 0 MATCH user:* COUNT 1000

Continue until the returned cursor is 0. A scan can return duplicates and can miss keys created or deleted during the iteration; callers that require a unique result must deduplicate it.

Core Types #

  • Strings support GET, SET, atomic INCRBY, and binary-safe values.
  • Lists are ordered, left/right indexed collections used for queues and streams of work. LPUSH and RPUSH add to the head or tail; LPOP and RPOP return nil on an empty list and remove the key when the last element disappears. BLPOP and BRPOP block until one of the listed keys becomes non-empty. LRANGE is inclusive on both ends and accepts negative indexes from the tail; unrestricted ranges can return very large payloads. RPOPLPUSH and BRPOPLPUSH atomically move one tail element to another list.
  • Sets contain unique members with hash-table membership tests. Use SADD, SREM, SCARD, SISMEMBER, SMEMBERS, SPOP, and SRANDMEMBER. Algebra commands such as SINTER, SUNION, and SDIFF read from their inputs without modifying them; the *STORE variants replace the destination set atomically.
  • Sorted sets associate each unique member with a floating-point score. ZADD adds or updates a member atomically, so a repeated member replaces the previous score instead of creating a duplicate. Use ZRANGE, ZREVRANGE, ZRANK, ZREVRANK, and the score-range commands for ordered lookup, and ZREM or ZREMRANGEBYRANK/ZREMRANGEBYSCORE for removal.
  • Hashes group field/value pairs under one key. HSET creates or updates a field atomically; HGET, HMGET, HDEL, HINCRBY, and HGETALL operate on named fields rather than nested objects. HGETALL can be large, so prefer targeted reads when only a few fields are needed.
  • Streams append field/value entries under ordered IDs. XADD writes an entry, XRANGE reads an ID range, and XREAD waits for entries after a cursor. Consumer groups distribute entries with XREADGROUP; consumers must acknowledge completed work with XACK and reclaim abandoned pending entries deliberately. Streams are persistent data structures, not ephemeral Pub/Sub delivery.

HGETALL, SMEMBERS, and unrestricted LRANGE return every element and can create large responses. Use cursor-based hash/set scans or bounded ranges in request paths.

MULTI queues commands and EXEC runs them without interleaving from another client, but Redis transactions do not provide SQL-style rollback. A runtime error in one queued command does not undo successful commands in the same EXEC. WATCH adds optimistic conflict detection. Lua scripts and Redis Functions execute atomically with respect to other commands, so they must remain bounded because long execution blocks server progress.

Probabilistic Counting #

HyperLogLog values accept observations with PFADD and estimate cardinality with PFCOUNT. Redis documents a standard error of less than 1 percent and a dense representation of up to 12 KiB, trading exactness and member enumeration for bounded memory. PFMERGE combines compatible observations. Use a set when an exact member list is required; use HyperLogLog only when an approximate count meets the product contract.

References #

Comments

Read or comment on GitHub (sign-in required to comment)