¿Qué tipos de datos soporta Redis?

Question

Accepted Answer

Redis soporta varias **estructuras de datos** como valores — strings, listas, hashes, conjuntos, conjuntos ordenados, más tipos especializados (streams, bitmaps, HyperLogLog, geoespacial). Elegir el tipo correcto para cada caso de uso es clave para usar Redis de manera efectiva.

## Tipos de datos principales

```bash
# STRING — the simplest (text, numbers, even binary up to 512MB)
SET key "value"
INCR counter            # atomic increment (strings can be counters)

# LIST — ordered list of strings (a linked list — fast push/pop at ends)
LPUSH mylist "a"        # push left
RPUSH mylist "b"        # push right
LRANGE mylist 0 -1      # get all → useful for queues, recent-items

# HASH — a map of field→value (like an object/record)
HSET user:1 name "Ann" age 30
HGET user:1 name        # => "Ann"  → great for storing objects

# SET — unordered unique strings
SADD tags "redis" "cache"
SISMEMBER tags "redis"  # membership test; SINTER/SUNION for set operations

# SORTED SET (ZSET) — unique members each with a SCORE, kept ordered by score
ZADD leaderboard 100 "Ann" 90 "Bob"
ZRANGE leaderboard 0 -1 WITHSCORES   # ranked → leaderboards, priority queues
```

## Tipos especializados

```text
STREAM      → an append-only log (like a message queue/event log with consumer groups)
BITMAP      → bit operations on strings (compact flags, e.g. daily active users)
HYPERLOGLOG → approximate unique counts using tiny memory (cardinality estimation)
GEOSPATIAL  → store/query locations (geo radius queries)
```

## Elegir el tipo correcto

```text
String      → simple values, counters, cached serialized data
List        → queues, stacks, recent-items, activity feeds
Hash        → objects/records (store fields of an entity together)
Set         → unique collections, membership tests, tags, relationships
Sorted Set  → leaderboards, rankings, priority queues, time-ordered data
→ Picking the right structure makes operations efficient and natural.
```

## Por qué es importante

Entender los tipos de datos de Redis es fundamental para usar Redis de manera efectiva, porque el poder de Redis proviene precisamente de sus **estructuras de datos ricas** (no solo almacenamiento simple de clave-valor), así que conocerlas y saber cuándo usar cada una es conocimiento práctico esencial.

Los **tipos principales** se adaptan cada uno a necesidades diferentes: **strings** (valores simples y contadores atómicos), **listas** (colecciones ordenadas para colas, pilas y feeds de elementos recientes), **hashes** (almacenar objetos/registros con múltiples campos juntos — eficiente para entidades), **conjuntos** (colecciones únicas para pruebas de pertenencia, etiquetas y relaciones, con operaciones de conjuntos como intersección), y **conjuntos ordenados** (miembros clasificados por puntuación — el ajuste natural para tablas de clasificación, rankings y colas de prioridad).

Entender los **tipos especializados** — streams (registros de solo anexión con grupos de consumidores, para colas de mensajes y event sourcing), bitmaps (banderas compactas), HyperLogLog (conteos de únicos aproximados en memoria minúscula), y geoespacial (consultas de ubicación) — amplía lo que Redis puede hacer de manera eficiente.

Más importante aún, **elegir el tipo correcto** para cada caso de uso (un conjunto ordenado para una tabla de clasificación, un hash para un objeto, una lista para una cola) es lo que hace que las operaciones de Redis sean eficientes y naturales — usar la estructura incorrecta lleva a soluciones incómodas y lentas.

Ya que el valor de Redis proviene de sus estructuras de datos y usar las apropiadas es la habilidad principal de trabajar con Redis, y ya que la elección de estructura determina directamente si las operaciones son eficientes y el código es limpio, entender los tipos de datos de Redis — los tipos principales y especializados y cuándo usar cada uno — es conocimiento esencial y frecuentemente aplicado para cualquiera que use Redis, el fundamento para aprovechar Redis de manera efectiva más allá del almacenamiento trivial de clave-valor.