¿Cómo particionas una única tabla con miles de millones de filas?

Question

IT Interview Practice · Accepted Answer

**Divide la tabla gigante en tablas hijas físicas más pequeñas por una partition key, para que cada query toque solo las particiones que necesita (partition pruning) en lugar de escanear miles de millones de filas.** Una tabla con 5B de filas de pedidos aún se comporta como una única tabla lógica, pero el motor se salta el 99% de ella cuando tu `WHERE` filtra por la partition key.

## La forma de una tabla particionada

```text
                 orders (logical parent)
                        │  partition key = created_at
       ┌────────────────┼────────────────┬───────────────┐
       ▼                ▼                ▼               ▼
 orders_2024_q1   orders_2024_q2   orders_2024_q3   orders_2025_q1
  (child table)    (child table)    (child table)    (child, active)
       │                                                  │
   local index                                        local index
   (per child)                                        (per child)
```

## Elegir una estrategia de particionado

- **Range** — por rangos de fecha/id. La mejor para series temporales (pedidos, logs, eventos); los datos recientes se mantienen calientes y los rangos viejos son fáciles de eliminar.
- **Hash** — reparto uniforme entre N particiones por `hash(key) % N`. Úsalo cuando no hay un rango natural y quieres carga balanceada (p. ej. `user_id`).
- **List** — buckets explícitos (`region IN ('EU','US')`). Bueno para aislamiento por tenant o región.

```sql
-- Postgres: particionar por rango por mes, prune sobre created_at
CREATE TABLE orders (id bigint, created_at date, amount numeric)
  PARTITION BY RANGE (created_at);

CREATE TABLE orders_2025_01 PARTITION OF orders
  FOR VALUES FROM ('2025-01-01') TO ('2025-02-01');

-- Esto escanea SOLO orders_2025_01, no la tabla entera
SELECT sum(amount) FROM orders
 WHERE created_at >= '2025-01-01' AND created_at < '2025-02-01';
```

## Pruning, índices, mantenimiento

- **El partition pruning** solo funciona si la query filtra por la **partition key**. Filtra por otra cosa y escaneas cada partición — el error #1.
- **Local index** = un índice por hijo (por defecto en Postgres); barato de construir y eliminar junto con la partición. **Global index** (Oracle) abarca todas las particiones — ayuda a los lookups únicos entre particiones pero debe reconstruirse cuando eliminas una.
- **El mantenimiento** se vuelve O(partición): archiva datos viejos con `DROP TABLE orders_2019` (instantáneo, sin `DELETE` gigante), y `ATTACH`/`DETACH` para ventanas rodantes.

## Perspectiva de la entrevista

El entrevistador sondea si entiendes que el **particionado no es indexado** — reduce los datos escaneados, un índice reduce las filas examinadas dentro de un scan; a menudo necesitas ambos. Una buena respuesta nombra range/hash/list; una excelente recalca que **la partition key debe coincidir con tu filtro de query dominante**, advierte que una clave equivocada mata el pruning, y menciona el archival barato vía `DROP`.

**Compensación:** las queries cross-partition (sin filtro de clave, o constraints únicos entre particiones) se vuelven más lentas y la imposición de unicidad es más difícil. No particiones una tabla de 10M de filas — añades complejidad operativa sin ganancia. Particiona cuando la tabla es enorme **y** las queries están naturalmente acotadas por la clave.

La forma de una tabla particionada

Elegir una estrategia de particionado

Pruning, índices, mantenimiento

Perspectiva de la entrevista

Preguntas relacionadas