Bases de datos: tablas, SQL y llave-valor

Imagina que el backend de C01, el programa del marketplace que recibe las publicaciones, las guardara en un CSV, una línea por publicación. Funcionaría el primer día. Después, tres problemas:

• Buscar es lento. Para encontrar la publicación 4,242,424 hay que leer el archivo desde el principio. Con ≈ 2.5 M publicaciones nuevas al día, en un año son ≈ 900 millones de líneas.
• Cambiar es peligroso. Para cambiar un precio hay que reescribir el archivo. Si el servidor se apaga a la mitad, queda un archivo roto.
• Compartir no se puede. Si dos programas escriben el mismo archivo a la vez, uno pisa lo que escribió el otro.

Una base de datos (database) resuelve justo eso. Es un programa que guarda datos de forma ordenada (cada dato en su lugar y con su tipo), durable (lo que te confirmó como guardado sobrevive a un apagón) y compartida (muchos programas leen y escriben a la vez sin pisarse), y que deja consultarlos: pides «las publicaciones de Ana que cuestan menos de 1,000 pesos» y recibes solo esas.

Casi siempre corre como un servidor aparte: un proceso que se queda escuchando en la red, con sus datos en su propio disco. El backend se conecta, manda una pregunta y recibe la respuesta. Abrir una conexión cuesta varias idas y vueltas por la red, así que el backend mantiene un pool de conexiones abiertas, como el de la lección de HTTP: cada request toma una, la usa y la devuelve.

Tablas, filas y columnas

La forma más común de ordenar los datos es la tabla (table): una cuadrícula, como una hoja de cálculo. Cada fila (row) es una cosa: una publicación. Cada columna (column) es un dato de todas las cosas: el precio.

A diferencia de una hoja de cálculo, cada columna tiene un tipo fijo, declarado al crear la tabla: precio es un entero, titulo es texto. Esa lista de columnas con sus tipos es el esquema de la tabla, como el de un Parquet. Si alguien quiere guardar «novecientos» en precio, PostgreSQL, una de las bases más usadas (la verás en la sección siguiente), lo rechaza. SQLite, la base que vamos a usar en el código, es más tolerante y lo guarda como texto, salvo que la tabla se declare STRICT (una opción que existe desde SQLite 3.37, de 2021).

C01 tiene varias tablas: usuarios, publicaciones y fotos. Ojo con la última: guarda dónde está cada foto y de qué publicación es, no la foto. Los ≈ 200 KB de cada foto viven en el object storage, un almacén de archivos de la nube que es tema de la lección siguiente. Una base de datos guarda bien millones de filas chicas; los archivos grandes, no.

La llave primaria

¿Cómo dice la app «esta publicación y no otra»? Con la llave primaria (primary key): una columna, o varias juntas, cuyo valor es distinto en cada fila y nunca falta. En la figura es id. La base la hace cumplir: si alguien intenta guardar otra fila con id = 1, la rechaza con un error.

¿Por qué no usar el título? Porque se repite (hay miles de «Tenis blancos») y porque cambia (Ana lo puede corregir). Una buena llave primaria es única, siempre presente y estable: no cambia en toda la vida de la fila. Por eso casi siempre es un número que asigna la base (1, 2, 3…) o un identificador al azar, como un UUID. El correo de un usuario parece buena llave, pero la gente lo cambia.

Otras tablas apuntan a una fila guardando su llave. La tabla fotos tiene una columna publicacion_id que dice de qué publicación es cada foto. Esa columna es una llave foránea (foreign key), y la base puede revisar que apunte a una publicación que exista. Gracias a ella se pueden unir tablas, como vas a ver en el JOIN.

Una base relacional (relational database) guarda todo en tablas que se relacionan por sus llaves. La idea la publicó Edgar F. Codd, de IBM, en 1970, y sigue siendo la forma más común de guardar los datos de una app. Las más conocidas:

• PostgreSQL (o Postgres): un servidor de código abierto. En las encuestas de Stack Overflow de 2023, 2024 y 2025 fue la base que más programadores dijeron usar. La Ronda lo nombra seguido como la «base operacional»: la que guarda publicaciones, usuarios y pagos.
• MySQL: otro servidor de código abierto, muy usado.
• SQLite: no es un servidor, sino una biblioteca. La base vive dentro del programa que la usa, en un solo archivo. Viene en los teléfonos, en los navegadores y en Python.

A todas se les habla en el mismo idioma: SQL (Structured Query Language, «lenguaje de consultas estructurado»). SQL es declarativo: dices qué quieres, no cómo buscarlo. No escribes «recorre las filas una por una y quédate con las baratas»: escribes la condición, y la base elige el camino más rápido. Ese «elegir el camino» es la razón de ser de los índices, dos secciones adelante.

Leer: SELECT

Una consulta (query) de lectura tiene esta forma:

SELECT titulo, precio          -- qué columnas
FROM publicaciones             -- de qué tabla
WHERE categoria = 'tenis'      -- qué filas
ORDER BY precio DESC           -- en qué orden (DESC: de mayor a menor)
LIMIT 10;                      -- cuántas, como máximo

Las palabras en mayúsculas son de SQL; lo demás son nombres de tus tablas y columnas. Lo que va después de -- es un comentario. Se lee casi como español: «selecciona título y precio de publicaciones, donde la categoría sea tenis, de la más cara a la más barata, máximo 10». SELECT * pide todas las columnas.

Filtrar con varias condiciones

El WHERE acepta comparaciones: = (igual), <> (distinto), <, >, <= y >=. Se juntan con AND (las dos se cumplen) y OR (basta una), con paréntesis cuando se mezclan:

SELECT titulo, precio
FROM publicaciones
WHERE (categoria = 'tenis' OR categoria = 'botas')
  AND precio < 1000;

Eso pide los tenis y las botas de menos de 1,000 pesos. Sin los paréntesis, la base leería «tenis de cualquier precio, o botas baratas», porque AND se aplica antes que OR, como la multiplicación antes que la suma. Dos más que vas a ver seguido: titulo LIKE 'Tenis%' busca los títulos que empiezan con «Tenis» (el % vale por cualquier texto), y precio IS NULL busca las filas sin precio (NULL es el valor de SQL para «no hay dato»). Para el NULL no sirve = NULL: «no hay dato» no es igual a nada, ni siquiera a otro «no hay dato», y esa comparación nunca da cierto.

Contar: GROUP BY

GROUP BY junta las filas que tienen el mismo valor en una columna y calcula algo por grupo: cuántas son (COUNT(*)), su promedio (AVG), su suma (SUM), su mínimo (MIN) o su máximo (MAX).

SELECT categoria, COUNT(*), AVG(precio)
FROM publicaciones
GROUP BY categoria;

Es la pregunta de todos los días de un equipo de datos: cuántas publicaciones hubo por categoría ayer, cuál es el precio promedio, qué categoría crece. Para un modelo, GROUP BY es la forma de ver el desbalance del dataset: cuántas fotos hay de cada una de las 500 categorías.

Escribir: INSERT, UPDATE y DELETE

• INSERT INTO publicaciones VALUES (7, 'ana', 'Gorra', 'gorras', 200); agrega una fila.
• UPDATE publicaciones SET precio = 850 WHERE id = 1; cambia las filas que cumplen la condición.
• DELETE FROM publicaciones WHERE id = 5; borra las filas que la cumplen.

Con Python lo puedes probar sin instalar nada: el módulo sqlite3 viene incluido, y ":memory:" crea una base que vive solo en la RAM y desaparece al terminar el programa.

import sqlite3

db = sqlite3.connect(":memory:")       # una base de datos que vive solo en la RAM
db.execute("""CREATE TABLE publicaciones (
    id INTEGER PRIMARY KEY, vendedor TEXT, titulo TEXT, categoria TEXT, precio INTEGER)""")
db.executemany("INSERT INTO publicaciones VALUES (?, ?, ?, ?, ?)", [
    (1, "ana", "Tenis naranjas", "tenis", 900),
    (2, "beto", "Botas de piel", "botas", 1500),
    (3, "ana", "Bolsa de mano", "bolsas", 650),
    (4, "carla", "Tenis blancos", "tenis", 1200),
    (5, "beto", "Sandalias", "sandalias", 300),
    (6, "carla", "Botas de lluvia", "botas", 450)])

for fila in db.execute("SELECT titulo, precio FROM publicaciones "
                       "WHERE categoria = 'tenis' ORDER BY precio DESC"):
    print(fila)
for fila in db.execute("SELECT categoria, COUNT(*), AVG(precio) FROM publicaciones "
                       "GROUP BY categoria ORDER BY COUNT(*) DESC, categoria"):
    print(fila)

cambio = db.execute("UPDATE publicaciones SET precio = 850 WHERE id = 1")
print("filas cambiadas:", cambio.rowcount)
try:
    db.execute("INSERT INTO publicaciones VALUES (1, 'dani', 'Gorra', 'gorras', 200)")
except sqlite3.IntegrityError as error:
    print("rechazado:", error)

('Tenis blancos', 1200)
('Tenis naranjas', 900)
('botas', 2, 975.0)
('tenis', 2, 1050.0)
('bolsas', 1, 650.0)
('sandalias', 1, 300.0)
filas cambiadas: 1
rechazado: UNIQUE constraint failed: publicaciones.id

La última línea es la llave primaria trabajando: ya había una fila con id = 1.

Fíjate en los ? del INSERT. Son huecos que la biblioteca llena con cada valor, por separado del texto de la consulta. Nunca se arma el SQL pegando textos que mandó alguien: si un título trajera una comilla seguida de un comando de SQL, la base lo ejecutaría. Ese ataque se llama inyección de SQL (SQL injection), y los huecos lo evitan.

Las preguntas interesantes casi siempre cruzan dos tablas. C01 quiere saber qué tan seguido acierta el modelo: comparar la categoría que sugirió con la que Ana dejó al final. La sugerencia (la categoría top-1, la primera de la lista del modelo) vive en un lugar, el registro de predicciones, y la publicación en otro. Las une el request_id: el identificador de cada request que el backend guarda junto con la foto (es el header X-Request-ID de la lección de HTTP; su tarjeta es request id). En C01 las predicciones viven en un log, un archivo al que se le agrega una línea por predicción, y no en una tabla; pero la unión es la misma.

Un JOIN («unir») combina las filas de dos tablas cuyas llaves coinciden:

SELECT p.titulo, p.categoria, r.top1
FROM publicaciones AS p
JOIN predicciones AS r ON p.request_id = r.request_id;

AS p le pone un apodo a la tabla, para escribir p.categoria en vez de publicaciones.categoria. ON dice qué columnas tienen que coincidir. Hay dos JOIN que vas a usar casi siempre:

• INNER JOIN (o solo JOIN): solo las filas que tienen pareja en las dos tablas.
• LEFT JOIN: todas las filas de la tabla de la izquierda, la del FROM. Si alguna no tiene pareja, las columnas de la otra tabla llegan vacías, con NULL, el valor de SQL para «no hay dato».

import sqlite3

db = sqlite3.connect(":memory:")
db.execute("CREATE TABLE publicaciones (id INTEGER PRIMARY KEY, titulo TEXT, categoria TEXT, request_id TEXT)")
db.execute("CREATE TABLE predicciones (request_id TEXT PRIMARY KEY, top1 TEXT, confianza REAL)")   # REAL: con decimales
db.executemany("INSERT INTO publicaciones VALUES (?, ?, ?, ?)", [
    (1, "Tenis naranjas", "tenis", "r-101"), (2, "Botas de piel", "botas", "r-102"),
    (3, "Bolsa de mano", "bolsas", "r-103"), (4, "Tenis blancos", "tenis", "r-104")])
db.executemany("INSERT INTO predicciones VALUES (?, ?, ?)", [
    ("r-101", "tenis", 0.91), ("r-102", "tenis", 0.48), ("r-103", "bolsas", 0.88)])   # r-104 no llegó

unir = """SELECT p.titulo, p.categoria, r.top1 FROM publicaciones AS p
          {} JOIN predicciones AS r ON p.request_id = r.request_id ORDER BY p.id"""
print("INNER JOIN:")
for fila in db.execute(unir.format("INNER")):
    print(" ", fila)
print("LEFT JOIN:")
for fila in db.execute(unir.format("LEFT")):
    print(" ", fila)

aciertos, total = db.execute("""SELECT SUM(p.categoria = r.top1), COUNT(*) FROM publicaciones AS p
                                JOIN predicciones AS r ON p.request_id = r.request_id""").fetchone()
print(f"el top-1 acertó {aciertos} de {total}: {aciertos / total:.0%}")

INNER JOIN:
  ('Tenis naranjas', 'tenis', 'tenis')
  ('Botas de piel', 'botas', 'tenis')
  ('Bolsa de mano', 'bolsas', 'bolsas')
LEFT JOIN:
  ('Tenis naranjas', 'tenis', 'tenis')
  ('Botas de piel', 'botas', 'tenis')
  ('Bolsa de mano', 'bolsas', 'bolsas')
  ('Tenis blancos', 'tenis', None)
el top-1 acertó 2 de 3: 67%

En SQLite, p.categoria = r.top1 vale 1 si es cierto y 0 si no, así que SUM cuenta los aciertos. PostgreSQL tiene un tipo aparte para «cierto o falso» y no lo deja sumar; ahí se escribe COUNT(*) FILTER (WHERE p.categoria = r.top1). Python muestra el NULL como None.

¿Cuál JOIN usar? Depende de la pregunta. Para medir aciertos, INNER: sin predicción no hay qué comparar. Pero para saber cuántas publicaciones se quedaron sin sugerencia (el modelo no respondió a tiempo y la app mostró su fallback), hace falta el LEFT: las filas con NULL son justo esas. Un INNER JOIN las quita en silencio y todo se ve mejor de lo que es.

Para quedarte solo con las que faltan, se agrega un filtro después del LEFT JOIN: WHERE r.request_id IS NULL. Esa consulta da las publicaciones que no encontraron pareja; en el ejemplo, solo los tenis blancos. Es la forma de preguntar «¿qué hay aquí que no esté allá?», y sirve igual para buscar fotos sin etiqueta o etiquetas sin foto.

Ana abre su publicación y la app pide SELECT * FROM publicaciones WHERE id = 4242424. Supón una tabla de 10 millones de filas: cuatro días de C01. ¿Cómo encuentra la base esa fila?

La forma tonta es leerlas todas y quedarse con la que coincide: un recorrido completo (full scan). Los datos de una tabla viven en el disco en páginas (pages), bloques de tamaño fijo: 4 KiB (4,096 bytes) por omisión en SQLite (desde su versión 3.12, de 2016) y 8 KiB en PostgreSQL. La base siempre lee páginas completas, nunca una fila suelta.

El árbol B

Con una lista ordenada ya se podría hacer una búsqueda binaria: ver la mitad, descartar la mitad que no sirve y repetir. Para 10 millones son hasta 24 pasos, porque 2²⁴ ≈ 16.8 millones es la primera potencia de 2 que pasa de 10 millones. Pero si cada paso cae en una página distinta del disco, son 24 lecturas al azar.

En computación, un árbol es una estructura de cajas, llamadas nodos, donde cada una apunta a varias de abajo: la de hasta arriba es la raíz, y las de hasta abajo, que ya no apuntan a otros nodos, son las hojas. Buscar es bajar de la raíz a una hoja, eligiendo en cada nodo por cuál camino seguir.

El árbol B (B-tree), que usan casi todas las bases relacionales, hace cada paso mucho más ancho. Cada nodo es una página entera, con cientos de llaves en orden, y entre cada dos llaves sale un camino (una rama) a una página de abajo. Cada rama ocupa una llave y la dirección de la página de abajo, unos 10 a 15 bytes, así que en 4,096 bytes caben, en números redondos, ≈ 300. Leer una página no descarta la mitad: descarta todo menos 1 de cada ≈ 300 caminos. Las hojas guardan cada llave con la dirección de su fila.

Lo mejor es que el árbol crece muy despacio. Cada nivel multiplica por ≈ 300 lo que cabe: con 4 niveles caben 300⁴ = 8,100 millones de llaves. Un año de C01, ≈ 900 millones de publicaciones, cabe en 4 niveles. Pasar de 10 millones a 900 millones de filas cuesta una lectura más.

Lo que cuesta un índice

Un índice no es gratis:

• Hace más lentas las escrituras. Cada INSERT o DELETE, y cada UPDATE de una columna indexada, tiene que poner al día también cada índice. Una tabla con 5 índices escribe en 6 lugares por cada fila nueva.
• Ocupa espacio. Es otra copia de la columna, con sus direcciones. En la medición de abajo, con 1 M de filas chicas, el índice ocupa 11.7 MB, casi lo mismo que la tabla entera (14.7 MB).
• Solo sirve para lo que indexa. Un índice por vendedor no ayuda a buscar por precio.

La regla: indexa las columnas por las que de verdad buscas, unes u ordenas seguido (WHERE, JOIN, ORDER BY), no todas. La llave primaria siempre tiene su índice: la base lo crea sola.

Ver el plan: EXPLAIN QUERY PLAN

¿Cómo sabes si una consulta usa un índice? Se lo preguntas a la base. En SQLite, EXPLAIN QUERY PLAN antes de la consulta dice qué camino eligió, sin correrla: SCAN es recorrer toda la tabla y SEARCH … USING INDEX es bajar por el árbol. Las frases exactas cambian con la versión (antes de SQLite 3.36, de 2021, decía SCAN TABLE publicaciones); la salida del bloque de abajo es de SQLite 3.53, la que trae la Python 3.14 donde se corrió. En PostgreSQL el comando es EXPLAIN, y EXPLAIN ANALYZE además la corre y mide.

import sqlite3

db = sqlite3.connect(":memory:")
db.execute("CREATE TABLE publicaciones (id INTEGER PRIMARY KEY, vendedor_id INTEGER, precio INTEGER)")
db.executemany("INSERT INTO publicaciones VALUES (?, ?, ?)",
               ((i, i % 100_000, 100 + i % 2_000) for i in range(1_000_000)))   # 10 por vendedor

pasos = 0
def contar():                      # SQLite la llama en cada paso interno (cada instrucción)
    global pasos
    pasos += 1
db.set_progress_handler(contar, 1)

def buscar(sql):
    global pasos
    plan = db.execute("EXPLAIN QUERY PLAN " + sql).fetchone()[3]
    pasos = 0
    filas = len(db.execute(sql).fetchall())
    print(f"encontró {filas:>3} · {pasos:>9,} pasos · {plan}")

def megabytes():
    paginas, tamano = (db.execute(f"PRAGMA {p}").fetchone()[0] for p in ("page_count", "page_size"))
    return paginas * tamano / 1e6

buscar("SELECT * FROM publicaciones WHERE vendedor_id = 4242")
antes = megabytes()
db.execute("CREATE INDEX idx_vendedor ON publicaciones (vendedor_id)")
print(f"la tabla ocupa {antes:.1f} MB y el índice, {megabytes() - antes:.1f} MB")
buscar("SELECT * FROM publicaciones WHERE vendedor_id = 4242")
buscar("SELECT * FROM publicaciones WHERE id = 4242")
buscar("SELECT * FROM publicaciones WHERE precio = 777")

encontró  10 · 3,000,048 pasos · SCAN publicaciones
la tabla ocupa 14.7 MB y el índice, 11.7 MB
encontró  10 ·        79 pasos · SEARCH publicaciones USING INDEX idx_vendedor (vendedor_id=?)
encontró   1 ·        11 pasos · SEARCH publicaciones USING INTEGER PRIMARY KEY (rowid=?)
encontró 500 · 3,002,008 pasos · SCAN publicaciones

Publicar, en el ejemplo de esta lección, son dos escrituras: la fila de la publicación y la fila de la predicción que se le sugirió, para poder medir después. ¿Qué pasa si el servidor se cae justo entre las dos?

La transacción

Una transacción (transaction) es un grupo de lecturas y escrituras que la base trata como una sola operación: o pasan todas, o no pasa ninguna. Empieza con BEGIN y termina con COMMIT («confírmalo»). Si algo falla antes, ROLLBACK («échalo para atrás») deja la base exactamente como estaba.

BEGIN;
INSERT INTO publicaciones VALUES (2, 'Tenis naranjas', 'r-105');
INSERT INTO predicciones VALUES ('r-105', 'tenis');
COMMIT;

Si el servidor se apaga después del primer INSERT, al volver la base no encuentra el COMMIT y deshace lo que quedó a medias. Nadie, nunca, ve la publicación sin su predicción. Las bases relacionales prometen cuatro cosas, que se recuerdan con la sigla ACID:

• Atomicidad (atomicity): todo o nada. Es lo de arriba.
• Consistencia (consistency): al terminar, se cumplen todas las reglas de la base: llaves primarias sin repetir, columnas marcadas NOT NULL (que no aceptan quedar vacías) con dato, llaves foráneas que apuntan a algo. Si una regla no se cumple, la transacción entera se rechaza.
• Aislamiento (isolation): dos transacciones al mismo tiempo no ven lo que la otra dejó a medias. El ideal es que el resultado sea como si hubieran corrido una tras otra; cuánto se acerca cada base a ese ideal está en el bloque de abajo.
• Durabilidad (durability): lo que recibió COMMIT sobrevive a un apagón, porque la base lo escribió en el disco antes de confirmar.

En Python, el módulo sqlite3 abre la transacción solo, justo antes de la primera escritura, y with db: la cierra (with es la forma de Python de decir «al terminar este bloque, pase lo que pase, haz el cierre»): al salir del bloque hace COMMIT, y si hubo un error, ROLLBACK. El programa publica una vez bien y luego dos veces con la predicción vacía, que la columna NOT NULL rechaza: una con transacción y otra sin ella.

import sqlite3

db = sqlite3.connect(":memory:")
db.execute("CREATE TABLE publicaciones (id INTEGER PRIMARY KEY, titulo TEXT, request_id TEXT)")
db.execute("CREATE TABLE predicciones (request_id TEXT PRIMARY KEY, top1 TEXT NOT NULL)")

def publicar(id_, titulo, request_id, top1):
    with db:                       # cierra la transacción: al salir, COMMIT; con un error, ROLLBACK
        db.execute("INSERT INTO publicaciones VALUES (?, ?, ?)", (id_, titulo, request_id))
        db.execute("INSERT INTO predicciones VALUES (?, ?)", (request_id, top1))

def a_medias(id_, titulo, request_id, top1):
    db.execute("INSERT INTO publicaciones VALUES (?, ?, ?)", (id_, titulo, request_id))
    db.commit()                    # sin transacción: cada escritura se guarda sola
    db.execute("INSERT INTO predicciones VALUES (?, ?)", (request_id, top1))
    db.commit()

def contar():
    p = db.execute("SELECT COUNT(*) FROM publicaciones").fetchone()[0]
    r = db.execute("SELECT COUNT(*) FROM predicciones").fetchone()[0]
    return f"{p} publicaciones, {r} predicciones"

publicar(1, "Tenis blancos", "r-104", "tenis")
print("bien:", contar())
for funcion, id_ in ((publicar, 2), (a_medias, 3)):
    try:
        funcion(id_, "Tenis naranjas", f"r-10{id_ + 3}", None)   # la segunda escritura falla
    except sqlite3.IntegrityError as error:
        print(f"{funcion.__name__} falló ({error}):", contar())

bien: 1 publicaciones, 1 predicciones
publicar falló (NOT NULL constraint failed: predicciones.top1): 1 publicaciones, 1 predicciones
a_medias falló (NOT NULL constraint failed: predicciones.top1): 2 publicaciones, 1 predicciones

Con transacción, el error deshizo también la publicación: la base quedó igual que antes. Sin ella, quedó una publicación huérfana.

Upsert: escribir dos veces deja lo mismo

En la lección de fallas de red viste que un reintento puede repetir una escritura, y que lo que se repite sin daño es idempotente. Un INSERT no lo es: la segunda vez, o falla porque la llave ya existe, o (si la tabla no tiene llave) mete una fila repetida.

Lo que se quiere casi siempre es «si la fila ya existe, ponle este valor; si no, créala con él». Eso es un upsert (de update + insert). Con una tabla ventas que guarda, por vendedor (su llave primaria), cuántas ventas lleva en los últimos 7 días (ventas_7d):

INSERT INTO ventas VALUES ('ana', 12)
ON CONFLICT (vendedor) DO UPDATE SET ventas_7d = excluded.ventas_7d;

excluded es la fila que se quiso insertar. El «conflicto» lo detecta la llave primaria (o una columna UNIQUE): sin llave no hay upsert. PostgreSQL (desde la versión 9.5, de 2016) y SQLite (desde la 3.24, de 2018) lo escriben así; MySQL usa ON DUPLICATE KEY UPDATE.

Hay dos detalles que deciden si de verdad es idempotente:

• Escribir el valor, no el cambio. «Ana lleva 12 ventas» se puede escribir diez veces. «Súmale 3 a Ana» no: cada repetición suma otra vez. La Ronda (C08) lo dice así: si escribes con INCR (el comando de Redis que suma 1, dos secciones adelante), un reproceso, volver a procesar los mismos datos, cuenta dos veces.
• DO NOTHING para lo que solo debe pasar una vez. ON CONFLICT DO NOTHING guarda la primera y descarta las demás. Así se guarda una llave de idempotencia: la base no acepta la misma llave dos veces, y el segundo intento se entera de que ya se hizo.

import sqlite3

db = sqlite3.connect(":memory:")
db.execute("CREATE TABLE ventas (vendedor TEXT PRIMARY KEY, ventas_7d INTEGER)")

def upsert(vendedor, ventas):      # deja el valor así: si la fila ya existe, la sobrescribe
    db.execute("""INSERT INTO ventas VALUES (?, ?)
                  ON CONFLICT (vendedor) DO UPDATE SET ventas_7d = excluded.ventas_7d""",
               (vendedor, ventas))

def sumar(vendedor, ventas):       # suma lo que llega: como un INCR
    db.execute("""INSERT INTO ventas VALUES (?, ?)
                  ON CONFLICT (vendedor) DO UPDATE SET ventas_7d = ventas_7d + excluded.ventas_7d""",
               (vendedor, ventas))

for intento in (1, 2):             # el mismo mensaje llega dos veces: un reintento
    upsert("ana", 12)
    sumar("beto", 3)
print(db.execute("SELECT * FROM ventas ORDER BY vendedor").fetchall())

db.execute("INSERT INTO ventas VALUES ('carla', 5) ON CONFLICT DO NOTHING")
db.execute("INSERT INTO ventas VALUES ('carla', 9) ON CONFLICT DO NOTHING")   # ya existe: no hace nada
print(db.execute("SELECT ventas_7d FROM ventas WHERE vendedor = 'carla'").fetchone())

[('ana', 12), ('beto', 6)]
(5,)

Ana quedó en 12 aunque el mensaje llegó dos veces. Beto quedó en 6, cuando solo vendió 3.

Las bases relacionales responden casi cualquier pregunta: filtran, cuentan y unen como quieras. Esa libertad cuesta. Una consulta nueva puede recorrer millones de filas, y repartir una base relacional entre muchas máquinas es difícil: un JOIN o una transacción pueden tocar filas que quedaron en máquinas distintas, y entonces las máquinas tienen que coordinarse por la red.

NoSQL es el nombre de las bases que no se organizan en tablas relacionadas. Se suele leer not only SQL, «no solo SQL». Hay varias familias:

• De documentos (MongoDB): cada registro es un documento tipo JSON, con campos que pueden cambiar de uno a otro.
• De columnas anchas (Cassandra, Bigtable): enormes, repartidas en cientos de máquinas, buenas para escribir muchísimo.
• Llave-valor (Redis, DynamoDB): las más simples. Vienen a continuación.
• Vectoriales: guardan embeddings y buscan los más parecidos. Por dentro son un índice vectorial, el de la lección de embeddings.

Lo que casi todas cambian es lo mismo: renuncian a las consultas libres y a los JOIN a cambio de repartirse fácil entre muchas máquinas y de responder siempre igual de rápido.

Llave-valor: pedir por la llave

Una base base llave-valor (key-value store) guarda cada valor bajo una llave, como un diccionario de Python, pero compartido entre programas. Casi todo se reduce a dos operaciones: SET llave valor guarda y GET llave lee.

Por eso, en una base llave-valor, la llave es la consulta, y se diseña antes de escribir el primer dato. Se arman con un prefijo que dice qué es y el id: user:123 para las recomendaciones de un usuario en M02, o f:card:<token> para las features de una tarjeta en C09.

¿Para qué sirve algo tan limitado? Para el camino online del modelo. Cuando llega una request, el modelo necesita las features de una entidad: las de la tarjeta 42, las del vendedor de Ana. Siempre por su llave, siempre en milisegundos. Esa es la parte online de un feature store, el sistema que guarda las features para entrenar y para servir, de la lección siguiente: Redis, DynamoDB o Bigtable con el valor más reciente de cada entidad.

DynamoDB es la base llave-valor administrada de AWS: no manejas servidores, en su modo por demanda pagas por cada lectura y escritura, y AWS promete respuestas de unos pocos milisegundos (de un solo dígito), con los datos en SSD repartidos entre muchas máquinas y copiados en varias zonas (una zona es un grupo de centros de datos de la nube con su propia luz y su propia red, para que una falla no tumbe a las demás).

Redis: llave-valor en la memoria

Redis (de Remote Dictionary Server) es una base llave-valor que guarda todo en la RAM. Leer de la RAM toma ≈ 100 ns; de un SSD, ≈ 0.1 ms. Por eso lo que tarda una lectura de Redis es casi pura red: dentro de la misma zona, un GET toma ≈ 0.3 ms contando la ida y la vuelta, según la Ronda (C08).

Sus valores no son solo texto: también pueden ser un diccionario de campos (Redis lo llama hash, aunque no tiene que ver con la función hash de la lección «Tiempo, hashes e identificadores»), una lista, un conjunto o un conjunto ordenado, cada uno con sus comandos.

Tres cosas más hacen a Redis tan común:

• Vencimiento. Cada llave puede llevar un TTL: SET llave valor EX 3600 la borra sola en una hora. Es la misma idea del TTL del DNS: cuánto tiempo vale una copia.
• Un comando a la vez. Redis ejecuta los comandos de uno en uno, en un solo hilo (desde Redis 6 puede usar otros hilos para leer y escribir en la red, pero los comandos siguen en uno), así que dos INCR al mismo tiempo nunca pierden una cuenta. Por eso guarda el balde del rate limit que comparten las 4 copias del gateway de C10, como viste en la lección de balanceo.
• Persistencia opcional. Si Redis se reinicia, la RAM se borra. Puede guardar copias en el disco, pero aun así puede perder desde un segundo hasta varios minutos de escrituras (el bloque de abajo dice cuánto). Por eso suele guardar cosas que se pueden reconstruir, no el único registro de un pago.

La lección de su velocidad es que lo caro es el viaje, no la lectura. C07, el buscador de un marketplace, junta en cada búsqueda ≈ 400 publicaciones candidatas y revisa en Redis si alguna ya se vendió. C08, la página de inicio (home) de una app de recomendaciones, lee 800 llaves:

import redis                                  # no viene con Python: pip install redis

r = redis.Redis(host="localhost", port=6379)  # el servidor de Redis
r.set("pred:3f9a:v12", "tenis", ex=86_400)    # la predicción de una foto, que vence en 1 día
r.get("pred:3f9a:v12")                        # b'tenis'
r.incr("cuota:equipo-7")                      # suma 1 y devuelve la cuenta nueva
r.hset("f:card:42", mapping={"compras_1h": 3, "monto_24h": 1850})   # un hash con features
r.mget(["tomb:101", "tomb:102", "tomb:103"])  # tres llaves en un solo viaje (las lápidas de la sección extra)

¿Relacional o llave-valor? No compiten: casi todos los sistemas usan las dos. La relacional guarda la verdad del negocio y responde preguntas que nadie previó. La llave-valor sirve lo que el camino online pide por llave, rápido y a gran escala.

Un caché (cache) es una copia de un resultado guardada en un lugar rápido y cercano, para no repetir el trabajo de calcularlo o de traerlo. Ya conoces tres: la caché de la CPU, que guarda en el chip lo que se leyó de la RAM; la page cache, que guarda en la RAM lo que se leyó del disco; y el caché del DNS, que guarda direcciones durante su TTL. En una app es lo mismo, un piso más arriba: una copia de lo que costó una consulta a la base o una inferencia, casi siempre en Redis.

Cada vez que pides algo, pasa una de dos:

• Acierto (hit): la copia está y se usa. Rápido.
• Fallo (miss): no está. Se hace el trabajo completo y, de paso, se guarda la copia para la próxima.

La tasa de aciertos (hit rate) es la fracción de pedidos que fueron aciertos. Con ella se calcula lo que el caché ahorra.

Los 30 ms son la parte del presupuesto que la Ronda (M03) le da a la GPU.

Cómo se usa: primero el caché

La forma más común se llama cache-aside («el caché a un lado»), porque la app lo maneja por su cuenta:

1. 1

   Busca en el caché

   La app arma la llave y hace un GET a Redis.

2. 2

   Si está, úsala

   Es un acierto: responde con la copia.

3. 3

   Si no está, haz el trabajo

   Consulta la base o corre el modelo.

4. 4

   Guarda la copia con un TTL

   Un SET con vencimiento, para que el siguiente pedido sea un acierto.

La llave tiene que incluir todo lo que cambia la respuesta. La Ronda (M02) propone que C01 guarde cada predicción bajo el hash de los bytes de la foto (un resumen corto que cambia si cambia un solo byte) más la versión del modelo. Si solo usara el hash, al salir un modelo nuevo el caché seguiría dando las respuestas del viejo.

Invalidar: cuando la copia queda vieja

El problema de toda copia es que el original cambia. Si Ana baja el precio y el caché sigue con el viejo, la página muestra 900 cuando ya cuesta 850. Hay dos herramientas, y casi siempre se usan las dos:

• El TTL: la copia caduca sola, como la respuesta del DNS de la lección de red. Un TTL de 5 minutos promete que nadie ve algo más viejo que 5 minutos. Es lo que hace el caché de consultas de C07.
• Borrar al escribir (invalidar): quien cambia el dato borra su llave del caché, y el siguiente pedido trae el valor nuevo.

import random
from functools import lru_cache

random.seed(7)
fotos = range(5_000)                               # 5,000 fotos distintas
peso = [1 / (k + 1) for k in fotos]                # unas pocas se piden muchísimo; casi todas, poco
pedidos = random.choices(fotos, weights=peso, k=20_000)

for tamano in (50, 500, None):                     # None: un caché sin límite
    @lru_cache(maxsize=tamano)
    def clasificar(foto):                          # el trabajo caro: aquí sería el modelo
        return foto % 500                          # una «categoría» de mentira
    for foto in pedidos:
        clasificar(foto)
    info = clasificar.cache_info()
    tasa = info.hits / (info.hits + info.misses)
    print(f"caché de {str(tamano):>4}: {info.hits:>6,} aciertos, {info.misses:>5,} fallos, tasa {tasa:.0%}")

caché de   50:  7,000 aciertos, 13,000 fallos, tasa 35%
caché de  500: 13,011 aciertos, 6,989 fallos, tasa 65%
caché de None: 16,804 aciertos, 3,196 fallos, tasa 84%

Para C01, la Ronda (M02) concluye algo que vale para cualquier caché: lo que importa no es la tasa de aciertos, sino cuánta capacidad te deja quitar. Las dos GPUs T4 de C01 (una en cada zona) están ahí por si se cae una zona, y en promedio trabajan al ≈ 5 %; con 20 % de aciertos, al ≈ 4 %. No se puede quitar ninguna, y el caché agrega una pieza más que puede fallar.

1. Filtrar por una columna sin índice

La consulta vuela en la computadora de quien la escribió, con 1,000 filas, y en producción, con 100 millones, tarda segundos y satura la base.

Cómo evitarlo: correr EXPLAIN antes de mandarla y buscar SCAN (o Seq Scan en PostgreSQL) sobre una tabla grande. Probar con datos del tamaño real.

2. Un índice para cada columna

«Si los índices aceleran, pongamos uno en todo.» Cada escritura se vuelve más lenta y el espacio se dispara, para índices que nadie usa.

Cómo evitarlo: indexar lo que de verdad aparece en WHERE, JOIN y ORDER BY de las consultas frecuentes, y revisar de vez en cuando qué índices no se usan.

3. Escribir varias cosas sin transacción

La publicación se guarda y su predicción no; el pago se registra y la orden no. Ningún error lo avisa.

Cómo evitarlo: todo lo que debe pasar junto va en una transacción. Y si una parte vive fuera de la base (mandar un mensaje, llamar a otro servicio), se escribe la intención en la misma transacción y otro proceso la ejecuta después: es el patrón outbox de la Ronda (M02).

4. Reintentar escrituras que no son idempotentes

Un INSERT sin llave o un INCR dentro de un job que se reintenta: cada reintento duplica filas o infla contadores.

Cómo evitarlo: una llave primaria en cada tabla, upsert con el valor absoluto («lleva 12», no «suma 3») y ON CONFLICT DO NOTHING para lo que solo debe pasar una vez.

5. Leer de una réplica lo que acabas de escribir

Ana cambia el precio, la página lee de una réplica atrasada y le muestra el viejo. Un job escribe y, enseguida, otro paso del mismo job lee de la réplica y no encuentra nada.

Cómo evitarlo: lo recién escrito por el mismo usuario o el mismo proceso se lee de la primaria; las réplicas, para lo que tolera unos segundos de atraso.

6. Un caché sin TTL o con la llave incompleta

El caché sigue dando el precio viejo o, peor, las predicciones del modelo anterior, porque la llave no incluía la versión del modelo.

Cómo evitarlo: que la llave incluya todo lo que cambia la respuesta, borrar la llave al escribir, ponerle siempre un TTL y medir la tasa de aciertos antes de decidir que el caché vale la pena.

Resuélvelos con lápiz antes de abrir la solución. Los de índices y caché se pueden comprobar con las calculadoras.

1. 1Fácil

   La tabla usuarios tiene las columnas correo, nombre, ciudad y fecha_alta. ¿Cuál sirve como llave primaria? Si ninguna, ¿qué agregarías?

   Ver la solución paso a paso

   • nombre y ciudad se repiten. fecha_alta también: miles de usuarios se dan de alta el mismo día.
   • correo es único y siempre está, pero no es estable: la gente lo cambia, y cada tabla que apunta al usuario tendría que cambiar también.
   • Agregaría una columna id, un número que asigna la base o un UUID, que nunca cambia. El correo puede llevar su propia regla UNIQUE para que no se repita, sin ser la llave.
2. 2Fácil

   Escribe la consulta que da el título y el precio de las botas que cuestan menos de 1,000 pesos, de la más barata a la más cara. Con la tabla de la sección de SQL, ¿qué filas salen?

   Ver la solución paso a paso

   • SELECT titulo, precio FROM publicaciones WHERE categoria = 'botas' AND precio < 1000 ORDER BY precio;
   • ORDER BY va de menor a mayor si no dices DESC.
   • Sale una sola fila: ('Botas de lluvia', 450). Las de piel cuestan 1,500.
3. 3Fácil

   Un caché recibió 1,000 pedidos y acertó 850. Un acierto tarda 1 ms; un fallo, 1 ms de revisar más 20 ms de ir a la base. ¿Cuál es la tasa de aciertos y la latencia promedio?

   Ver la solución paso a paso

   • Tasa: 850 ÷ 1,000 = 85 %.
   • Promedio: 0.85 × 1 + 0.15 × 21 = 0.85 + 3.15 = 4 ms, contra 20 ms sin caché.
   • La base recibe solo 150 de cada 1,000 pedidos.
4. 4Fácil

   ¿Cuáles de estas preguntas puede responder bien una base llave-valor, con llaves f:card:<token>? (a) Las features de la tarjeta 42. (b) Todas las tarjetas con más de 3 compras en la última hora. (c) Las features de 300 tarjetas a la vez.

   Ver la solución paso a paso

   • (a) Sí: es un GET (o un HGETALL) de la llave f:card:42.
   • (b) No: no hay índice por valor. Habría que leer las millones de llaves. Esa pregunta es para una base relacional o un almacén de análisis.
   • (c) Sí, con un solo viaje: MGET o pipelining de las 300 llaves.
5. 5Medio

   Con la tabla de la sección de SQL, ya con los tenis de Ana en 850, calcula a mano qué devuelve SELECT vendedor, COUNT(*), SUM(precio) FROM publicaciones GROUP BY vendedor.

   Ver la solución paso a paso

   • ana: tenis (850) y bolsa (650): 2 publicaciones, 1,500.
   • beto: botas de piel (1,500) y sandalias (300): 2, 1,800.
   • carla: tenis blancos (1,200) y botas de lluvia (450): 2, 1,650.
   • Comprueba: 1,500 + 1,800 + 1,650 = 4,950, la suma de los seis precios.
6. 6Medio

   Ayer hubo 1,000 publicaciones; 950 tienen su predicción y en 760 el top-1 fue la categoría final. ¿Cuántas filas da el INNER JOIN y cuántas el LEFT JOIN? ¿Qué tasa de aciertos reportas, y qué más reportas?

   Ver la solución paso a paso

   • INNER: 950 filas. LEFT: 1,000; las 50 de más traen NULL en la predicción.
   • Aciertos: 760 ÷ 950 = 80 % de las que tuvieron sugerencia.
   • Reporta también el 5 % sin sugerencia (50 ÷ 1,000): son las veces que se usó el fallback. Si solo miras el INNER JOIN, esas 50 desaparecen.
7. 7Medio

   Una tabla de 1,000 millones de filas tiene un árbol B con ≈ 400 ramas por página. ¿Cuántos niveles necesita? ¿Cuántas páginas lee una búsqueda por llave, contando la de la tabla?

   Ver la solución paso a paso

   • 400² = 160,000; 400³ = 64 millones; 400⁴ = 25,600 millones. 1,000 millones no caben en 3 niveles, sí en 4.
   • Con logaritmos: log(10⁹) ÷ log(400) ≈ 3.46, y se redondea hacia arriba.
   • Páginas: 4 del árbol + 1 de la tabla = 5. Compruébalo en la calculadora: 1,000 millones de filas y 400 ramas por página.
8. 8Medio

   Un job escribe cada noche las ventas de la semana de cada vendedor con UPDATE ventas SET ventas_7d = ventas_7d + :hoy. Un día falla a la mitad y Airflow (el programa que agenda los jobs) lo reintenta completo. ¿Qué pasa? ¿Cómo lo arreglas?

   Ver la solución paso a paso

   • Los vendedores que ya se habían procesado antes de la falla reciben la suma dos veces: sus ventas quedan infladas, sin ningún error.
   • Arreglo: calcular el valor absoluto de la ventana (las ventas de los últimos 7 días, contadas desde los datos) y escribirlo con upsert: ON CONFLICT (vendedor) DO UPDATE SET ventas_7d = excluded.ventas_7d. Repetirlo deja lo mismo.
   • Mejor aún: todo en una transacción, o escribir una versión nueva de la tabla y, al final, hacer que la app lea esa (M02 lo llama mover el «puntero»).
9. 9Reto

   Ana cambia el precio a las 12:00:00.000. Su página lee de una réplica con 500 ms de retraso, y la app recarga a los 200 ms. ¿Qué ve? Propón dos arreglos y di qué cuesta cada uno.

   Ver la solución paso a paso

   • La réplica aplica el cambio a las 12:00:00.500. A los 200 ms todavía dice el precio viejo.
   • Arreglo 1: durante unos segundos después de que Ana escribe, sus lecturas van a la primaria. Cuesta carga extra en la primaria, aunque es poca: solo las de quien acaba de escribir.
   • Arreglo 2: la app muestra el precio que Ana mandó, sin volver a leerlo. No cuesta nada en la base, pero si la escritura falló, Ana ve algo que no se guardó: hay que avisarle del error.
   • Lo que no arregla nada: esperar 200 ms más. El retraso cambia con la carga.
10. 10Reto

    El sistema de búsqueda de C07 escribe una llave tomb:{id} por cada publicación vendida o retirada, con TTL de 7 días. Si se venden o retiran ≈ 2.5 M al día, ¿cuántas llaves vivas hay? Si ocupan ≈ 2 GB, ¿cuánto pesa cada una? ¿Por qué no un TTL de 1 día, y por qué no sin TTL?

    Ver la solución paso a paso

    • Llaves vivas: 2.5 M × 7 días = 17.5 M.
    • Cada una: 2,000,000,000 B ÷ 17,500,000 ≈ 114 bytes, contando la llave, el valor y lo que Redis ocupa por cada una.
    • 1 día no alcanza: el TTL tiene que durar más que la copia más vieja del índice que pueda estar sirviendo. Si una copia de hace 3 días trae la publicación vendida y la lápida ya venció, la publicación reaparece.
    • Sin TTL, la lista crece para siempre (≈ 900 M llaves al año, ≈ 100 GB) y casi todas ya no sirven, porque el índice ya se rehízo sin esas publicaciones.

En la Ronda:

• M02 · Patrones de inferencia usa todo esto: el llave-valor donde un job deja las predicciones nocturnas, el caché de predicciones con hash más versión, la tabla de deduplicación con ON CONFLICT DO NOTHING, el estado de cada trabajo con escritura condicional y el patrón outbox.
• M09 · Datos separa la base operacional del lago de datos, explica por qué no se entrena leyendo la base directo, pide que cada job sea idempotente (upsert o sobrescribir la partición, nunca agregar a ciegas) y arma el feature store con su parte online en un llave-valor.
• Los casos. C07 y C08 (tombstones en Redis y MGET), C09 (online store en Redis con réplicas por zona) y C01 (el join por request_id).

En el Dojo: la estación 1, «Datos y etiquetas», ya está abierta y usa SQL en casi cada paso: con DuckDB, una base para análisis que lee archivos Parquet directamente, juntas los logs del gateway con las publicaciones por request_id, cuentas con GROUP BY y cazas duplicados.

En Sensei: la siguiente lección, «Object storage, data lakes y warehouses», guarda lo que no cabe en una base: las fotos, los logs y los datasets, y separa la base de la app de la de análisis. Después, «Colas y streams» lleva los cambios de una base a otros sistemas, y «Tiempo, hashes e identificadores» explica los hashes, los UUID y el join point-in-time.

Estos son los conceptos que presentó esta lección. Cada uno tiene su tarjeta con la definición completa.

Intenta responder en tu cabeza antes de abrir cada respuesta.

1. 1¿Qué tiene una base de datos que no tiene un archivo CSV?Ver respuesta

   Guarda los datos ordenados y con tipo, no pierde lo confirmado aunque se apague, deja que muchos programas escriban a la vez sin pisarse y responde consultas sin que tú recorras los datos.

2. 2¿Por qué un índice encuentra una fila entre 10 millones en unas 4 lecturas?Ver respuesta

   Porque es un árbol B: cada página trae ≈ 300 llaves en orden, y leer una descarta todo menos 1 de cada 300 caminos. Tres niveles alcanzan para 27 millones de llaves, y una lectura más trae la fila.

3. 3¿Qué cuesta un índice?Ver respuesta

   Cada escritura tiene que ponerlo al día, ocupa espacio (casi como la tabla, si las filas son chicas) y solo ayuda a las consultas sobre su columna.

4. 4¿Qué diferencia hay entre INNER JOIN y LEFT JOIN?Ver respuesta

   El INNER deja solo las filas con pareja en las dos tablas. El LEFT deja todas las de la izquierda y pone NULL donde no hubo pareja: así se ven, por ejemplo, las publicaciones sin predicción.

5. 5¿Qué es una transacción y qué pasa si el servidor se cae a la mitad?Ver respuesta

   Un grupo de escrituras que pasa completo o no pasa. Si se cae antes del COMMIT, al volver la base deshace lo que quedó a medias: nadie ve la publicación sin su predicción.

6. 6¿Por qué un upsert es idempotente y un INCR no?Ver respuesta

   El upsert deja la fila con un valor («lleva 12»): repetirlo deja lo mismo. El INCR suma: cada repetición suma otra vez.

7. 7Si Ana cambia el precio y una réplica todavía muestra el viejo, ¿qué está pasando?Ver respuesta

   Retraso de replicación: la réplica aplica los cambios de la primaria un poco después, y eso es consistencia eventual. Arreglo: por unos segundos, las lecturas de Ana van a la primaria.