¿Cómo consultas 10B de registros en menos de 100ms?

Question

IT Interview Practice · Accepted Answer

Diseña **primero para el patrón de acceso**, luego elige el particionado + el índice/PK correcto para que cualquier query individual toque una porción pequeña y acotada — nunca escanees 10B de filas. Sub-100ms sobre 10 mil millones de registros no va de un disco más rápido; va de hacer que el working set sea diminuto.

```text
Query ─▶ Router ──▶ Partition (by tenant/time) ──▶ Index/PK lookup ─▶ ~thousands of rows
   │                    (prune 99.9% of data)         (B-tree / sort key)
   └─▶ Cache (Redis) ─▶ hit? return in <5ms
                        miss ▼
                   Columnar store (ClickHouse) for aggregates / scans
```

## Los patrones de acceso lo determinan todo

Antes de elegir la tecnología, pregunta: **¿point lookup o range/aggregate?** "Obtén los últimos 20 pedidos del usuario X" es una query point/range — quieres que la partition y la sort key coincidan exactamente con ella. "Suma los ingresos por región este mes" es un scan analítico — un row store es la herramienta equivocada. Modelar la query primero es lo que separa un diseño que funciona de uno que parece razonable pero hace full-scan.

## El particionado poda el espacio de búsqueda

Divide la tabla por una clave que aparezca en cada query — normalmente **tenant_id + time**. Con particiones temporales, una query de "últimos 7 días" lee 7 particiones e ignora los otros 3 años. Esto es *partition pruning*: el router elimina el 99,9% de los datos antes de consultar ningún índice.

## Diseño correcto de índice / PK

Dentro de una partición, la **primary key debe anteponer las columnas de filtro de la query**. En DynamoDB: partition key = `tenant`, sort key = `timestamp` → las range queries son O(log n) + lectura secuencial. En un columnar store como **ClickHouse**, la sorting key (`ORDER BY (tenant, ts)`) permite al motor saltar granules y leer solo los bloques que coinciden. Un covering index evita por completo el fetch extra de la fila.

## Elección del store

- **Point lookups, alta escritura:** NoSQL key-value (DynamoDB, Cassandra) — O(1)-ish por clave, escala horizontalmente.
- **Analítica/agregados:** columnar (ClickHouse, BigQuery) — lee solo las columnas necesarias, vectorizado.
- **Cachea el 1% caliente:** Redis por delante absorbe las lecturas repetidas a <5ms; 10B de filas pero unos pocos millones de claves calientes.

## Perspectiva de la entrevista

El entrevistador quiere verte decir **"¿cuáles son las queries?" antes de "¿qué base de datos?"**. Los buenos candidatos recurren a índices; los excelentes notan que un índice sobre 10B de filas es en sí mismo enorme — así que *particionas primero para encoger lo que cubre el índice*. Nombrar la división row-vs-columnar y la capa de cache señala experiencia real a escala.

**Trampa común:** proponer un único índice B-tree gigante como respuesta. Ayuda a los point lookups pero no hace nada por los scans analíticos, y sus escrituras cuellan la ingesta.

## Compensaciones y modos de fallo

- **Partition key equivocada** = scatter-gather cross-partition, la latencia se dispara. Elige una clave presente en las queries.
- **Partición caliente:** un tenant celebridad satura un shard — añade un sufijo de salting.
- **Staleness de cache:** invalida al escribir o acepta el retraso del TTL.
- **Coste de la desnormalización:** a menudo duplicas datos por patrón de acceso; el almacenamiento es barato, una query de 10 segundos no.

Los patrones de acceso lo determinan todo

El particionado poda el espacio de búsqueda

Diseño correcto de índice / PK

Elección del store

Perspectiva de la entrevista

Compensaciones y modos de fallo

Preguntas relacionadas