DEV Community: SEBASTIAN ALEJANDRO CORTEZ APAZA

Una tabla por pregunta: modelar y desplegar sobre Cassandra sin tocar un panel

SEBASTIAN ALEJANDRO CORTEZ APAZA — Sat, 24 Oct 2026 07:41:21 +0000

Cuando llevas años escribiendo SQL, lo primero que haces frente a una base
de datos nueva es buscar dónde está el JOIN. En Apache Cassandra no está,
y ese hueco no es una carencia: es la decisión de diseño de la que cuelga
todo lo demás.

Para entenderlo de verdad construí algo pequeño y lo llevé hasta producción:
un acortador de URLs con analítica de clics, sobre Cassandra gestionado en
Astra DB, desplegado en Render mediante GitHub Actions. El código completo
está en el repositorio, pero lo que quiero contar aquí es el cambio mental
que exige el modelado, porque es la parte que ningún tutorial de "hola
mundo" te obliga a atravesar.

Repositorio: https://github.com/SEBACOR-13/astra-shortener
Aplicación en vivo: https://astra-shortener.onrender.com

Por qué un acortador es el caso perfecto

No lo elegí por original. Lo elegí porque su patrón de acceso es casi una
caricatura de aquello en lo que Cassandra es buena:

La lectura dominante es una sola. Dado un código de siete caracteres, devolver una URL. No hay filtros, no hay agregaciones, no hay relaciones que recorrer. Es un acceso por clave.
La escritura dominante es append-only y masiva. Cada visita genera un registro de clic que nunca se actualiza ni se borra.
El crecimiento es horizontal. Más enlaces significa más particiones, y más particiones se reparten entre más nodos sin que nadie reescriba una consulta.

Si tu carga de trabajo se parece a esto, Cassandra te da escalado lineal y
alta disponibilidad. Si no se parece —si necesitas consultas analíticas
flexibles sobre columnas arbitrarias— te va a hacer la vida miserable. Esa
es la parte honesta que conviene decir antes de empezar.

El giro: no modelas entidades, modelas preguntas

En el modelo relacional diseñas las tablas una vez, normalizas, y después
escribes las consultas que necesites. El motor se encarga de resolverlas.

En Cassandra el orden está invertido. Primero escribes la lista de preguntas
que tu aplicación va a hacer, y después creas una tabla por pregunta.

Para el acortador, las preguntas eran cuatro:

¿A qué URL redirijo este código corto?
¿Qué enlaces creó este usuario, del más nuevo al más viejo?
¿Cuáles fueron los últimos clics de este enlace?
¿Cuántos clics lleva en total?

Cuatro preguntas, cuatro tablas. Veámoslas, porque cada una enseña algo
distinto.

Pregunta 1: acceso por clave

CREATE TABLE links_by_code (
    code        text PRIMARY KEY,
    target_url  text,
    owner       text,
    created_at  timestamp
);

La más simple. code es la partition key: Cassandra calcula su hash,
ese hash determina qué nodo del anillo guarda la fila, y la lectura va
directo a ese nodo. Una partición, un salto de red.

Pregunta 2: desnormalización deliberada

CREATE TABLE links_by_owner (
    owner       text,
    created_at  timestamp,
    code        text,
    target_url  text,
    PRIMARY KEY ((owner), created_at, code)
) WITH CLUSTERING ORDER BY (created_at DESC, code ASC);

Aquí es donde un desarrollador de SQL hace una mueca: es la misma
información que la tabla anterior, duplicada.

Y es exactamente lo correcto. En Cassandra escribir es barato: la escritura
va a un commit log secuencial y a una estructura en memoria, sin leer nada
antes. Leer mal modelado, en cambio, es carísimo, porque obliga al nodo
coordinador a preguntarle a todos los demás. Así que la regla se invierte
respecto a lo que enseñan en Bases de Datos I: duplicas al escribir para
que cada lectura toque una sola partición.

Fíjate en la forma de la clave primaria: ((owner), created_at, code). El
primer paréntesis interno es la partition key —todos los enlaces de un
usuario viven juntos en el mismo nodo— y lo que sigue son las clustering
keys, que determinan el orden físico de las filas dentro de esa
partición.

Lo cual lleva al detalle que más me gustó.

El orden no se pide, se diseña

Esta es la consulta que alimenta la lista de "mis enlaces":

SELECT owner, created_at, code, target_url
FROM links_by_owner
WHERE owner = ? LIMIT ?

No hay ORDER BY. Y aun así las filas llegan de la más nueva a la más
vieja, siempre.

El orden sale del CLUSTERING ORDER BY (created_at DESC) declarado al
crear la tabla. Las filas están físicamente escritas en ese orden dentro
del SSTable. Ordenar en tiempo de consulta es trabajo que Cassandra
simplemente no hace; lo trasladó al momento de la escritura, donde cuesta
menos.

La tabla de clics usa la misma idea:

CREATE TABLE clicks_by_code (
    code        text,
    clicked_at  timestamp,
    click_id    uuid,
    referrer    text,
    user_agent  text,
    PRIMARY KEY ((code), clicked_at, click_id)
) WITH CLUSTERING ORDER BY (clicked_at DESC, click_id ASC);

El click_id uuid al final de la clave no es decorativo: si dos clics
caen en el mismo milisegundo, sin él la segunda fila sobrescribiría a la
primera, porque en Cassandra un INSERT sobre una clave existente es un
upsert silencioso. Es un error fácil de cometer y difícil de notar: no
falla nada, simplemente pierdes datos.

Pregunta 4: por qué `COUNT(*)` no es la respuesta

Para el total de clics, el reflejo relacional sería:

SELECT COUNT(*) FROM clicks_by_code WHERE code = ?;

Funciona. Y es una mala idea: recorre la partición entera cada vez. Con un
enlace que acumule cien mil clics, estás leyendo cien mil filas para
devolver un número.

Cassandra tiene un tipo específico para esto:

CREATE TABLE click_counts (
    code   text PRIMARY KEY,
    total  counter
);

UPDATE click_counts SET total = total + 1 WHERE code = ?;

El tipo counter resuelve incrementos concurrentes de forma distribuida,
sin el ciclo leer-modificar-escribir que provocaría condiciones de carrera.
Tiene una restricción que lo delata: una tabla con columnas counter no
admite ninguna otra columna fuera de la clave primaria. Por eso vive
separada en lugar de ser un campo más de links_by_code.

La escritura doble, en código

Crear un enlace significa escribir en dos tablas:

def create_link(self, code: str, target_url: str, owner: str) -> Link:
    created_at = datetime.now(UTC)
    self._session.execute(
        self._insert_link_by_code, (code, target_url, owner, created_at)
    )
    self._session.execute(
        self._insert_link_by_owner, (owner, created_at, code, target_url)
    )
    return Link(code, target_url, owner, created_at)

No hay transacción que las envuelva, porque Cassandra no ofrece
transacciones multi-partición. Lo que sí ofrece es que ambos INSERT son
idempotentes: si el segundo falla y se reintenta, el resultado es el
mismo. Diseñar para la idempotencia reemplaza aquí al ROLLBACK.

Un detalle de rendimiento: todas las sentencias son prepared statements.
Se compilan una vez y después viajan por la red como un identificador más
los parámetros. Además, el driver sabe qué nodo es dueño de cada partición
y enruta la petición directamente, sin coordinador intermedio.

La segunda mitad: que el deploy no lo haga un humano

El enunciado pedía despliegue automatizado, y vale la pena tomárselo en
serio, porque "lo subí a la nube" y "tengo un pipeline" son cosas muy
distintas.

La regla que me puse: el único gesto manual es git push.

push a main
   ├─ ruff check        estilo
   ├─ pytest            10 pruebas
   ├─ docker build      la imagen compila
   ├─ POST al deploy hook de Render
   └─ polling a /health hasta que responda

Si cualquier paso falla, el deploy no se ejecuta. Un pull request pasa por
lint y pruebas, pero nunca publica.

El problema del bundle binario

Astra DB no se conecta con una cadena de conexión: exige un Secure Connect
Bundle, un .zip con los certificados TLS y los metadatos del clúster.

cluster = Cluster(
    cloud={"secure_connect_bundle": ruta_del_bundle},
    auth_provider=PlainTextAuthProvider("token", astra_token),
)

En local es un archivo en disco. Pero los secrets de GitHub y de Render
solo guardan texto, no binarios. La solución es codificarlo en base64:

base64 -w0 secure-connect-shortener-db.zip > bundle.b64

y reconstruirlo en memoria al arrancar:

raw = base64.b64decode(settings.astra_scb_b64, validate=True)
handle = tempfile.NamedTemporaryFile(suffix=".zip", delete=False)
handle.write(raw)
handle.close()
return handle.name

El bundle nunca entra al repositorio. El .gitignore incluye
secure-connect-*.zip por si acaso.

Probar sin credenciales

Un pipeline que necesita secretos de producción para correr sus pruebas es
un pipeline frágil: no funciona en forks y empuja a poner credenciales
reales en CI.

Definí el acceso a datos como un contrato con dos implementaciones: una
contra Cassandra y otra en memoria. Si faltan las credenciales, la
aplicación arranca igual con la segunda y lo declara en /health:

{"status": "ok", "backend": "memoria", "keyspace": "shortener"}

La implementación en memoria respeta el mismo orden de resultados que
imponen las clustering keys, así que las pruebas verifican el contrato real.
En producción /health responde "backend": "astra", y el último paso del
pipeline comprueba justamente eso: no basta con que el servicio esté vivo,
tiene que estar hablando con la base de datos correcta.

- name: Esperar a que el servicio quede sano
  run: |
    for intento in $(seq 1 30); do
      respuesta=$(curl -fsS "$APP_URL/health" || true)
      if echo "$respuesta" | grep -q '"status":"ok"'; then
        echo "Servicio sano: $respuesta"
        exit 0
      fi
      sleep 10
    done
    exit 1

Ese bucle existe por una razón práctica: Render tarda entre uno y tres
minutos en construir la imagen y arrancar el contenedor. Un deploy que
"termina" en cuanto el webhook responde 200 no ha verificado nada.

Lo que me llevo

La desnormalización deja de ser un pecado. Tres semestres enseñando
formas normales y aquí la respuesta correcta es duplicar. No es relajar el
rigor: es que el criterio cambió. En un sistema distribuido el costo
dominante es el salto de red, no el espacio en disco.

La consulta se diseña antes que la tabla. Es incómodo al principio,
porque obliga a conocer los patrones de acceso antes de escribir una sola
línea. Y es brutalmente honesto: te fuerza a admitir que no sabías cómo se
iba a usar tu aplicación.

Cassandra no tiene una red de seguridad. Sin JOIN, sin transacciones
multi-partición, sin ORDER BY arbitrario, sin secuencias
autoincrementales. Cada una de esas ausencias es un mecanismo de
coordinación que un sistema distribuido no puede pagar barato. Lo que
recibes a cambio es escalado lineal.

Un despliegue automatizado se nota cuando falla. El valor del pipeline
no está en el día que todo sale bien: está el día que una prueba se rompe y
el deploy se detiene solo, antes de que la aplicación caída llegue a
producción.

Si quieres mirar el código, el esquema CQL está comentado línea por línea
en app/schema.cql, que es probablemente el archivo más útil del
repositorio para alguien que esté empezando con Cassandra.

Repositorio: https://github.com/SEBACOR-13/astra-shortener
Aplicación: https://astra-shortener.onrender.com

Trabajo del curso de Base de Datos II — Universidad Privada de Tacna.

Completo, diferencial o incremental: cómo elegir tu estrategia de respaldo (y probarla bloque a bloque con SQLite)

SEBASTIAN ALEJANDRO CORTEZ APAZA — Sun, 04 Oct 2026 03:45:02 +0000

Autor: Sebastian Alejandro Cortez Apaza, estudiante de Ingeniería de Sistemas de la Universidad Privada de Tacna, curso Base de Datos II.

🔗 Demo en vivo: https://sebacor-13.github.io/backup-strategies-sqlite/

💻 Repositorio público: https://github.com/SEBACOR-13/backup-strategies-sqlite

1. Los atacantes también buscan tus respaldos

Según el estudio de Sophos de 2024, aplicado a casi 3 000 organizaciones, en el 94 % de los ataques de ransomware los delincuentes intentaron comprometer también los respaldos, y lo lograron en el 57 % de esos casos. Cuando lo consiguieron, las víctimas tuvieron casi el doble de probabilidad de pagar el rescate, y el costo de recuperación fue unas ocho veces mayor (Adam, 2024).

Por eso la pregunta ya no es solo “¿tengo respaldo?”, sino también:

¿qué tipo de respaldo tengo?
¿cuántas piezas necesito para restaurarlo?
¿está cifrado y separado del sistema atacado?
¿lo he probado alguna vez?

En este artículo comparo las tres políticas clásicas (completa, diferencial e incremental) con datos medidos, gracias a BlockBackupLab, una aplicación que respalda un archivo SQLite real página por página.

2. Las tres políticas, en una frase cada una

La literatura clásica de respaldos distingue entre copiar todo y copiar solo lo modificado (Chervenak et al., 1998):

Política	Qué copia	Para restaurar necesito	Ventaja	Riesgo
Completa	Todo, cada vez	1 pieza	Simplicidad y restauración rápida	Mucho espacio y ventanas largas
Diferencial	Lo que cambió desde el último completo	2 piezas: completo + último diferencial	Restauración sencilla	Crece cada día hasta el siguiente completo
Incremental	Lo que cambió desde el respaldo anterior	Completo + todos los incrementales	Mínimo espacio y ventanas cortas	La cadena es frágil: si falta un eslabón, se pierde lo posterior

Un esquema típico es un completo el domingo y diferenciales o incrementales de lunes a sábado.

3. ¿Qué significa “lo que cambió”? Respaldos por bloques

Las herramientas modernas no comparan filas ni archivos enteros: comparan bloques. SQLite es un caso ideal para entenderlo, porque toda la base vive en un único archivo dividido en páginas de tamaño fijo. El tamaño de página se guarda en la cabecera, en el desplazamiento 16 (SQLite, s.f.-a).

La idea es simple:

Divido el archivo en páginas de 4 KB.
Calculo el SHA-256 de cada página.
Comparo esas huellas con las del respaldo de referencia y copio solo las páginas distintas.

Así funciona también sqlite3_rsync, la herramienta oficial de SQLite para copiar una base viva: la réplica envía hashes de sus páginas y el origen devuelve solo las que difieren. En bases parecidas, el tráfico puede ser del orden del 0,01 % del tamaño (SQLite, s.f.-c). PostgreSQL 17 aplica la misma idea en su respaldo incremental nativo.

// Tamaño de página: bytes 16-17 de la cabecera, big-endian (1 significa 65 536)
export function tamanoPagina(bytes) {
  const v = (bytes[16] << 8) | bytes[17]
  return v === 1 ? 65536 : v
}

export async function crearRespaldo(bytes, tipo, catalogo) {
  const hashes = await hashesDePaginas(bytes)          // SHA-256 de cada página
  const base = tipo === 'diferencial'
    ? [...catalogo].reverse().find((b) => b.tipo === 'completo')   // último completo
    : tipo === 'incremental' ? catalogo.at(-1) : null              // respaldo anterior
  const cambiadas = hashes.flatMap((h, i) => (!base || base.hashes[i] !== h ? [i] : []))
  return { tipo, padre: base?.id ?? null, hashes, paginas: cambiadas.map((i) => copiaPagina(bytes, i)) }
}

Para restaurar, se aplica la cadena en orden: primero el completo y luego cada respaldo posterior, sobrescribiendo sus páginas. Al final se verifica el SHA-256 del archivo reconstruido contra el original.

Ojo en SQLite real: nunca copies el archivo .db con cp mientras está en uso. Usa la Online Backup API, VACUUM INTO 'respaldo.db' o sqlite3_rsync, que garantizan una copia consistente (SQLite, s.f.-b). Para respaldos continuos existe Litestream, que replica el WAL de SQLite hacia almacenamiento S3.

4. BlockBackupLab: medir en lugar de suponer

La aplicación simula un inventario con 4 almacenes, 300 productos y 6 000 movimientos sobre SQLite real, ejecutado en el navegador con sql.js (WebAssembly). Cada vez que avanzas un día simulado:

Se registran unos 120 movimientos nuevos y se actualiza el stock.
Se ejecuta el respaldo que indique la política.
El respaldo se comprime con gzip y se cifra con AES-256-GCM.

4.1 Resultados de dos semanas simuladas

Con los mismos datos, al final la base pesa 584 KB (146 páginas). Estos son los resultados medidos, sin comprimir:

Política	Almacenamiento total	Páginas copiadas por día (lun → sáb, semana 1)	Piezas para restaurar el día 13
Completo diario	7,27 MB	122 → 132 (todo)	1
Completo dominical + diferencial	2,45 MB	25 → 35 (crece)	2
Completo dominical + incremental	2,23 MB	25 → 26 (estable)	7

Lectura de los resultados:

El completo diario ocupa unas 3 veces más que las otras dos políticas.
El diferencial crece cada día: el sábado vuelve a copiar todo lo del lunes. Aun así, restaurar solo necesita dos piezas.
El incremental copia siempre lo mínimo, pero restaurar un sábado exige leer y aplicar siete archivos, sin que falte ninguno.

En la app hay un botón 🗑 que simula “perder” un respaldo, por un disco dañado o un borrado accidental. Si se pierde un incremental intermedio, la cadena de restauración de los días siguientes se rompe y la aplicación lo indica en rojo.

5. Cifrar y verificar: el respaldo como objetivo

Si el atacante puede leer o borrar tus respaldos, no tienes respaldos. BlockBackupLab empaqueta cada uno así:

Serializa las páginas con una cabecera JSON de metadatos.
Comprime con gzip: un completo de 480 KB queda en unos 186 KB.
Cifra con AES-256-GCM, un modo autenticado: cualquier byte alterado hace fallar el descifrado (Dworkin, 2007).
Deriva la clave desde una frase con PBKDF2-HMAC-SHA256 y 600 000 iteraciones, el valor que recomienda OWASP (OWASP Foundation, s.f.).

const clave = await crypto.subtle.deriveKey(
  { name: 'PBKDF2', salt, iterations: 600000, hash: 'SHA-256' },
  material, { name: 'AES-GCM', length: 256 }, false, ['encrypt', 'decrypt'])
const cifrado = await crypto.subtle.encrypt({ name: 'AES-GCM', iv }, clave, comprimido)

En la demostración, un ransomware simulado cifra el archivo de la base y lo vuelve ilegible. La restauración trabaja solo con los paquetes cifrados y hace lo siguiente:

Los descifra y reconstruye el archivo página por página.
Comprueba que el SHA-256 sea idéntico al original.
Ejecuta PRAGMA integrity_check, que devuelve ok.
Compara el número de filas de cada tabla.

6. De 3-2-1 a 3-2-1-1-0

La regla clásica pide 3 copias, en 2 medios distintos y 1 fuera del sitio (Ruggiero & Heckathorn, 2012). Frente al ransomware, la industria la amplió a 3-2-1-1-0:

1 copia inmutable o desconectada (offline o air-gapped), que el atacante no pueda cifrar ni borrar.
0 errores al verificar las restauraciones.

Es lo mismo que pide la guía #StopRansomware de CISA, la NSA y el FBI: mantener respaldos desconectados y cifrados, y probar con regularidad su disponibilidad e integridad (CISA et al., 2023).

A esto se suma una política de retención. La aplicación aplica el esquema GFS (abuelo-padre-hijo): conserva 7 respaldos diarios, 4 semanales y 6 mensuales, y marca el resto como “expira”.

7. Despliegue automatizado

El repositorio público se despliega solo, sin pasos manuales:

deploy.yml: en cada push a main ejecuta 11 pruebas con Vitest. Cubren cadenas completas, diferenciales e incrementales, la ruptura de la cadena, el ransomware, el cifrado con frase incorrecta o paquete alterado, la comparación de políticas y la retención GFS. Después construye con Vite, publica en GitHub Pages y hace una prueba de humo.
simulacro.yml: cada lunes repite el simulacro de restauración, porque un respaldo que nunca se restaura no está probado.

8. ¿Cuál elijo?

Base pequeña o RTO muy exigente → completo frecuente, porque se restaura en un solo paso.
Equilibrio entre espacio y simplicidad → completo semanal + diferencial diario.
Base grande con pocos cambios diarios, o ancho de banda limitado → completo semanal + incremental, con verificación automática de la cadena y copias redundantes de cada eslabón.
RPO de minutos → ninguna de las tres basta por sí sola. Hay que sumar replicación o archivado continuo del log de transacciones (WAL en SQLite o PostgreSQL, binlog en MySQL).

Y siempre: cifra, separa al menos una copia del sistema principal y ensaya la restauración.

Referencias

Adam, S. (2024). The impact of compromised backups on ransomware outcomes. Sophos. https://www.sophos.com/en-us/blog/the-impact-of-compromised-backups-on-ransomware-outcomes

Chervenak, A., Vellanki, V., & Kurmas, Z. (1998). Protecting file systems: A survey of backup techniques. En Proceedings of the Joint NASA and IEEE Mass Storage Conference. https://www.researchgate.net/publication/2431989_Protecting_File_Systems_A_Survey_of_Backup_Techniques

CISA, MS-ISAC, NSA & FBI. (2023). #StopRansomware guide. Cybersecurity and Infrastructure Security Agency. https://www.cisa.gov/stopransomware/ransomware-guide

Dworkin, M. (2007). Recommendation for block cipher modes of operation: Galois/Counter Mode (GCM) and GMAC (NIST Special Publication 800-38D). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-38D

OWASP Foundation. (s.f.). Password storage cheat sheet. OWASP Cheat Sheet Series. Recuperado el 3 de octubre de 2026, de https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

Ruggiero, P., & Heckathorn, M. A. (2012). Data backup options. United States Computer Emergency Readiness Team (US-CERT). https://www.cisa.gov/sites/default/files/publications/data_backup_options.pdf

SQLite. (s.f.-a). Database file format. Recuperado el 3 de octubre de 2026, de https://www.sqlite.org/fileformat.html

SQLite. (s.f.-b). SQLite backup API. Recuperado el 3 de octubre de 2026, de https://www.sqlite.org/backup.html

SQLite. (s.f.-c). Database remote-copy tool for SQLite (sqlite3_rsync). Recuperado el 3 de octubre de 2026, de https://www.sqlite.org/rsync.html