Bases de datos

En sistemas del mundo real, las aplicaciones generan y dependen constantemente de datos como cuentas de usuario, transacciones, mensajes y registros. Almacenar estos datos directamente en la memoria de la aplicación no es suficiente, porque la memoria es temporal y desaparece cuando el programa se detiene o falla.

Las bases de datos resuelven esto proporcionando almacenamiento duradero. Los datos se escriben en disco de una manera que sobrevive a reinicios y fallos del sistema. Esto es lo que permite que sistemas como plataformas bancarias, redes sociales y sitios de comercio electrónico mantengan un estado a largo plazo.

Más allá del almacenamiento, las bases de datos proporcionan formas estructuradas de acceder a los datos. En lugar de recorrer archivos manualmente, los desarrolladores pueden usar consultas para recuperar exactamente lo que necesitan. Por ejemplo, obtener un usuario por correo electrónico o recuperar todos los pedidos de la última semana.

Las bases de datos también aplican reglas de consistencia, asegurando que los datos sigan siendo válidos incluso cuando ocurren varias operaciones al mismo tiempo. Sin esto, los sistemas corromperían fácilmente los datos bajo acceso concurrente.

A alto nivel, la base de datos actúa como la fuente de verdad. La aplicación procesa las solicitudes, pero la base de datos es responsable de almacenar y gestionar los datos de los que dependen esas solicitudes.

Las bases de datos SQL siguen el modelo relacional, donde los datos se organizan en tablas. Cada tabla representa una entidad (como usuarios o pedidos), y cada fila representa un registro dentro de esa entidad.

Una característica clave es el esquema. Antes de almacenar datos, defines la estructura, incluidos los tipos de columnas y las restricciones. Esto garantiza que todos los datos sigan un formato consistente, lo que reduce errores y mantiene la integridad.

Las relaciones entre tablas son fundamentales en los sistemas SQL. Por ejemplo, una tabla de usuarios puede vincularse con una tabla de pedidos mediante un user_id, lo que permite al sistema conectar datos relacionados de forma eficiente.

Las bases de datos SQL también admiten potentes capacidades de consulta. Mediante joins, filtros y agregaciones, los desarrolladores pueden recuperar conjuntos de datos complejos de varias tablas en una sola consulta.

Este enfoque estructurado proporciona una gran consistencia y fiabilidad, por eso bases de datos SQL como PostgreSQL y MySQL se usan ampliamente en sistemas donde la corrección y la integridad de los datos son críticas.

A diferencia de las bases de datos SQL, los sistemas NoSQL no requieren un esquema predefinido. Esto significa que cada registro puede tener una estructura diferente, lo que los hace útiles cuando los datos no están estructurados o cambian con frecuencia.

Las distintas bases de datos NoSQL se optimizan para diferentes casos de uso. Las bases de datos de documentos como MongoDB almacenan objetos similares a JSON, los almacenes clave-valor como Redis proporcionan búsquedas extremadamente rápidas, las bases de datos de columna ancha como Cassandra manejan enormes conjuntos de datos distribuidos, y las bases de datos de grafos modelan las relaciones directamente.

Esta flexibilidad hace que los sistemas NoSQL sean más fáciles de escalar horizontalmente en muchos servidores, lo cual es fundamental para aplicaciones a gran escala que manejan mucho tráfico.

La desventaja es que muchos sistemas NoSQL sacrifican la consistencia estricta o las consultas relacionales complejas en favor del rendimiento y la escalabilidad. Elegir entre SQL y NoSQL depende de la estructura de los datos y de los requisitos del sistema.

Cuando una consulta se ejecuta sin un índice, la base de datos debe revisar cada fila una por una para encontrar los resultados coincidentes. Esto se llama full table scan, y se vuelve extremadamente lento a medida que crece el conjunto de datos.

Un índice actúa como una estructura de búsqueda (similar al índice de un libro). En lugar de escanear todo, la base de datos puede ir directamente a la ubicación de los datos. Esto reduce significativamente el tiempo de consulta, especialmente en tablas grandes.

Por ejemplo:

CREATE INDEX idx_users_email
ON users(email);

Esto crea un índice en la columna email, permitiendo que consultas como "find user by email" se ejecuten mucho más rápido.

Sin embargo, los índices no son gratuitos. Cada vez que se insertan, actualizan o eliminan datos, el índice también debe actualizarse. Esto hace que las escrituras sean un poco más lentas y aumenta el uso de almacenamiento.

Un diseño eficaz de bases de datos implica elegir las columnas correctas para indexar, normalmente aquellas que se usan con frecuencia en condiciones de búsqueda, filtros o joins.

En muchos sistemas, las operaciones no están aisladas. Por ejemplo, transferir dinero entre dos cuentas requiere actualizar ambos saldos. Si una actualización tiene éxito y la otra falla, el sistema queda inconsistente.

Las transacciones resuelven esto agrupando las operaciones:

BEGIN
UPDATE account A
UPDATE account B
COMMIT

Si algún paso falla durante la ejecución, la base de datos realiza un rollback, deshaciendo todos los cambios anteriores en la transacción.

Esto garantiza que nunca ocurran actualizaciones parciales. O toda la operación se completa correctamente, o el sistema vuelve a su estado anterior.

Las transacciones son críticas en sistemas donde la corrección importa, como los sistemas financieros, el seguimiento de inventario y los sistemas de reservas. Sin ellas, los fallos o los problemas de concurrencia corromperían fácilmente los datos.

ACID es un conjunto de cuatro propiedades que las bases de datos relacionales aplican para garantizar la corrección durante las transacciones.

Atomicidad significa que una transacción es indivisible. Si falla cualquier paso, toda la transacción se revierte, evitando actualizaciones parciales.

Consistencia garantiza que, después de que una transacción se complete, la base de datos cumpla con todas las reglas, como restricciones, relaciones y validez de los datos. Nunca se permiten estados inválidos.

Aislamiento garantiza que varias transacciones que se ejecutan al mismo tiempo no interfieran entre sí. Cada transacción se comporta como si se ejecutara sola, incluso en un sistema concurrente.

Durabilidad garantiza que, una vez que una transacción se confirma, los datos se almacenan de forma permanente, incluso si el sistema falla inmediatamente después.

En conjunto, estas propiedades permiten que las bases de datos manejen fallos, concurrencia y operaciones complejas sin corromper los datos. Son fundamentales para construir sistemas confiables donde la corrección importa.

Cuando envías una consulta a una base de datos, no la ejecuta ciegamente paso a paso. En su lugar, la base de datos primero analiza la consulta usando un componente llamado planificador de consultas.

El planificador evalúa varias formas posibles de ejecutar la consulta y selecciona la más eficiente. Esto incluye decisiones como si usar un índice, cómo unir tablas y el orden de las operaciones.

Por ejemplo, si una consulta busca un usuario por correo electrónico y existe un índice en esa columna, la base de datos usará el índice en lugar de recorrer cada fila. Esto puede reducir el tiempo de ejecución de segundos a milisegundos en conjuntos de datos grandes.

El resultado de este proceso es un plan de ejecución, que define exactamente cómo se ejecutará internamente la consulta.

La optimización de consultas se vuelve crítica a medida que crecen los datos. Las consultas mal optimizadas pueden causar respuestas lentas, alto uso de CPU y cuellos de botella en el sistema, mientras que las consultas bien optimizadas mantienen los sistemas rápidos y escalables.

La replicación se usa para mantener múltiples copias de los mismos datos en diferentes servidores de bases de datos. La configuración más común es un modelo primaria-réplica.

En este modelo, la base de datos primaria maneja todas las operaciones de escritura. Luego, cualquier cambio realizado se propaga a las bases de datos réplica. Estas réplicas mantienen copias de los datos y pueden atender solicitudes de lectura.

Esta configuración ofrece varios beneficios. Si la base de datos primaria falla, una réplica puede tomar el control, mejorando la disponibilidad del sistema. También permite que los sistemas escalen el tráfico de lectura distribuyendo las consultas entre múltiples réplicas en lugar de sobrecargar una sola base de datos.

Sin embargo, la replicación introduce complejidad. Puede haber pequeños retrasos entre el momento en que los datos se escriben en la primaria y cuando aparecen en las réplicas (replication lag). Esto significa que las réplicas no siempre tendrán los datos más actualizados.

A pesar de esta desventaja, la replicación es una técnica fundamental para construir sistemas backend escalables y tolerantes a fallos.

A medida que los datos crecen, un solo servidor de base de datos eventualmente se convierte en un cuello de botella. La fragmentación resuelve esto dividiendo los datos en partes más pequeñas, con cada fragmento almacenado en un servidor diferente.

Por ejemplo:

Fragmento 1 → usuarios 1–1M
Fragmento 2 → usuarios 1M–2M
Fragmento 3 → usuarios 2M–3M

Las solicitudes se enrutan al fragmento correcto según los datos a los que se accede. Esto permite que los sistemas escalen horizontalmente y manejen cargas de trabajo mucho mayores.

La desventaja es una mayor complejidad, especialmente cuando las consultas necesitan datos de varios fragmentos.