Bases de datos: Parte 1 — Tipos y finalidad

Una base de datos es un almacenamiento organizado de información al que la aplicación recurre para escribir, buscar, modificar y eliminar datos. El sistema de gestión de bases de datos (SGBD) es un programa que administra ese almacenamiento: recibe peticiones, vigila la integridad de los datos, restringe el acceso y restaura el funcionamiento tras fallos.

¿Para qué un SGBD si existen archivos y hojas de cálculo?

Mientras los datos son pocos y los maneja una sola persona, una hoja de cálculo de Excel basta. Las dificultades aparecen cuando los registros son miles y los usuarios decenas:

• trabajo simultáneo. Dos gestores modifican un mismo pedido al mismo tiempo y uno de los cambios se pierde;
• integridad. Un pedido referencia a un cliente que ya fue eliminado, o se descuenta una suma de una cuenta pero no se abona en otra;
• búsqueda. Buscar el registro necesario entre millones de filas sin índices lleva mucho tiempo;
• acceso. El contable necesita los pagos, pero no las contraseñas de los usuarios;
• fallos. Tras un corte de energía el archivo puede quedar medio escrito.

El SGBD resuelve estas tareas de forma sistemática: dispone de transacciones, índices, permisos de acceso y un registro de cambios mediante el cual se recuperan los datos tras una avería.

Transacciones y ACID en palabras sencillas

Una transacción es un grupo de operaciones que se ejecuta en su totalidad o no se ejecuta en absoluto. El ejemplo clásico es una transferencia de dinero: el cargo en una cuenta y el abono en otra deben realizarse juntos. La fiabilidad de las transacciones se describe con cuatro propiedades ACID:

• atomicidad (Atomicity) — o se ejecutan todas las operaciones de la transacción, o no se ejecuta ninguna;
• consistencia (Consistency) — después de la transacción los datos cumplen todas las reglas establecidas: restricciones, claves externas, comprobaciones;
• aislamiento (Isolation) — las transacciones en paralelo no ven los resultados intermedios de las demás; cuán estricto es esto lo define el nivel de aislamiento;
• durabilidad (Durability) — una transacción confirmada se conserva incluso si ocurre un fallo inmediatamente después de la confirmación.

Muchos sistemas distribuidos NoSQL sacrifican parte de estas garantías en pos de disponibilidad y escalabilidad. Este enfoque se denomina BASE: el sistema sigue estando disponible y la consistencia entre nodos se alcanza no de forma instantánea, sino con el tiempo (eventual consistency). Para el carrito de una tienda online esto puede ser aceptable; para los saldos bancarios, no.

Tipos principales de bases de datos

Relacionales (SQL)

Los datos se almacenan en tablas con un esquema estricto: cada columna tiene su tipo, las relaciones entre tablas se definen mediante claves externas. Las consultas se escriben en SQL, que permite unir tablas (JOIN), agrupar y filtrar datos.

• Cuándo convienen: contabilidad, CRM, tiendas online, facturación — en general donde los datos están relacionados entre sí y su precisión es importante.
• Representantes: PostgreSQL, MySQL y MariaDB, SQLite; entre los comerciales — Oracle Database y Microsoft SQL Server.

Un SGBD relacional es una elección sensata por defecto. Las versiones modernas de PostgreSQL y MySQL pueden almacenar e indexar JSON, por lo que no es necesario extraer campos flexibles a una base separada.

Clave-valor

El modelo más simple: por una clave se almacena un valor, y sólo se puede obtener por la clave. Estos sistemas son muy rápidos porque suelen mantener los datos en memoria.

• Cuándo convienen: caché, sesiones de usuarios, contadores, colas, limitación de tasa.
• Representantes: Redis y su fork libre Valkey, Memcached.

Documentales

Un registro es un documento en formato JSON (o su variante binaria BSON) con estructura anidada arbitraria. Los documentos de una misma colección pueden diferir en el conjunto de campos.

• Cuándo convienen: catálogos de productos con distintas características, contenido, perfiles de usuario, datos cuya estructura cambia con frecuencia.
• Representantes: MongoDB, Couchbase.

Columnas

Bajo este nombre se esconden dos clases distintas de sistemas:

• SGBD columnar analíticos almacenan cada columna por separado y la comprimen. Una consulta como “suma de ventas por regiones en un año” lee sólo dos columnas necesarias de entre cientos y se ejecuta en segundos sobre miles de millones de filas. Representantes: ClickHouse, Apache Druid;
• almacenamientos wide-column (columnas anchas) distribuyen los datos entre muchos servidores y están pensados para flujos de escritura enormes. Representantes: Apache Cassandra, ScyllaDB, HBase.

Series temporales

Optimizadas para datos con marca temporal: métricas de servidores, lecturas de sensores, cotizaciones. Saben comprimir ese tipo de datos, decimar valores antiguos y construir agregados por intervalo con rapidez.

• Representantes: Prometheus y VictoriaMetrics (métricas de monitorización), InfluxDB, la extensión TimescaleDB para PostgreSQL.

Grafos

Almacenan entidades como nodos y las relaciones entre ellas como aristas. Son eficaces donde lo primordial son las conexiones: recomendaciones, búsqueda de cadenas de fraude, grafos sociales.

• Representantes: Neo4j, Memgraph.

Cómo elegir una base de datos

Al elegir conviene comprobar varias cosas:

1. Qué soporta su aplicación. WordPress funciona con MySQL y MariaDB, «1С:Предприятие» — con PostgreSQL (incluida la distribución Postgres Pro) y Microsoft SQL Server. No tiene sentido elegir una base en contra de los requisitos de la aplicación.
2. Si se necesitan transacciones. Si los datos están relacionados con dinero, saldos o documentos, hace falta un SGBD con ACID completo.
3. Cómo crecerá la carga. La mayoría de proyectos viven años en un solo servidor con una réplica para disponibilidad. El escalado horizontal (sharding) complica la operación, y planearlo de antemano sólo vale la pena si es realmente necesario.
4. Licencia. Las condiciones varían entre SGBD populares: PostgreSQL se distribuye bajo una licencia libre, MySQL Community bajo GPL; las licencias de MongoDB y Redis han cambiado en los últimos años. Esto es importante si piensa ofrecer la base como servicio.
5. Quién la administrará. Copias de seguridad, actualizaciones y monitorización son necesarias para cualquier SGBD. Si no dispone de un administrador propio, conviene considerar una base de datos gestionada por un proveedor en la nube.

A menudo en un mismo proyecto conviven varias bases: PostgreSQL guarda los pedidos, Redis las sesiones y el caché, ClickHouse la analítica. Es una práctica normal: cada sistema resuelve su propia tarea.