¿Qué es un sistema de gestión de bases de datos (SGBD o DBMS)?

25min

Un sistema de gestión de bases de datos es la pieza de software que permite convertir una acumulación de información en un recurso organizado, consultable y protegido. Su importancia no se limita a guardar registros: interviene en la forma en que una aplicación localiza los datos, comprueba que sean válidos, coordina los cambios realizados por varios usuarios y responde cuando ocurre un fallo.

Índice

¿Qué es un sistema de gestión de bases de datos?

Un sistema de gestión de bases de datos, conocido en español por las siglas SGBD y en inglés como DBMS (Database Management System), es un software diseñado para crear, estructurar, consultar, modificar, administrar y proteger bases de datos. Actúa como una capa intermedia entre la información almacenada y quienes necesitan utilizarla: aplicaciones, desarrolladores, administradores, analistas o usuarios autorizados.

Esta separación resulta esencial. Una aplicación de comercio electrónico, por ejemplo, no debería tener que localizar manualmente en el disco cada dato de un cliente ni decidir cómo reorganizar los archivos cuando aumenta el catálogo. Envía una petición al gestor (como consultar un producto, registrar un pedido o actualizar el inventario) y este se ocupa de interpretar la operación, encontrar los datos y aplicar las reglas definidas.

Una base de datos y el programa que la administra no son lo mismo. La primera es el conjunto organizado de información; el DBMS es la tecnología que permite trabajar con ese conjunto de forma controlada. Cuando se habla de “la base de datos” en un proyecto, a menudo se utiliza la expresión de manera amplia para referirse también al servidor, al gestor y a los mecanismos que hacen posible el acceso.

Frente al almacenamiento directo en archivos, un gestor aporta capacidades que serían difíciles de desarrollar desde cero: lenguajes de consulta, índices, validaciones, permisos, transacciones, auditoría, copias de seguridad y recuperación. No todos los productos implementan estas funciones del mismo modo ni con el mismo alcance, pero comparten un objetivo: mantener los datos disponibles, coherentes y gobernados durante todo su ciclo de vida.

¿Cómo funciona la arquitectura de un DBMS Database?

La arquitectura de un DBMS puede entenderse como una cadena de componentes que transforma una solicitud lógica en operaciones concretas sobre memoria y almacenamiento. Cuando una aplicación envía una consulta, el sistema no se limita a “buscar” la respuesta. Primero comprueba la sintaxis y los permisos; después analiza distintas formas de ejecutar la petición; finalmente accede a las páginas de datos necesarias, aplica filtros y devuelve el resultado.

Aunque cada tecnología posee una implementación propia, un sistema de gestión de bases de datos suele incorporar un procesador de consultas, un motor de almacenamiento, un catálogo de metadatos, áreas de memoria, registros de transacciones y módulos de seguridad, concurrencia y recuperación. El rendimiento final depende de cómo cooperan estas piezas, no únicamente de la velocidad del disco o de la cantidad de memoria disponible.

El papel del motor de almacenamiento (Storage Engine) y el procesador de consultas

El procesador de consultas recibe instrucciones expresadas mediante SQL, una API o un lenguaje propio. En una consulta SQL, sus tareas suelen incluir el análisis sintáctico, la validación de nombres y tipos, la reescritura de determinadas expresiones y la creación de un plan de ejecución. El optimizador compara alternativas: utilizar un índice, recorrer una tabla completa, cambiar el orden de las uniones o ejecutar partes de la operación en paralelo.

Elegir el plan adecuado puede cambiar radicalmente el tiempo de respuesta. Para localizar diez pedidos dentro de una tabla con millones de filas, un índice bien seleccionado evita revisar todos los registros. Sin embargo, si la consulta recupera la mayor parte de la tabla, una lectura secuencial puede ser más eficiente. El optimizador decide basándose en estadísticas, costes estimados y recursos disponibles, aunque una mala distribución de datos o unas estadísticas desactualizadas pueden llevarlo a escoger una estrategia poco conveniente.

Dentro de un sistema de gestión de bases de datos, el motor de almacenamiento ejecuta la parte física del trabajo. Gestiona páginas, archivos, índices, cachés, escrituras, bloqueos y registros necesarios para conservar los cambios. En algunos gestores, como MySQL, pueden coexistir distintos motores con características diferentes; en otros, el almacenamiento está integrado en el núcleo del producto. Esta capa también trata de minimizar el acceso al disco manteniendo en memoria la información utilizada con mayor frecuencia.

Procesador y motor no trabajan aislados. El primero define qué debe hacerse y en qué orden; el segundo lee o modifica los datos respetando las reglas de transacción, concurrencia y durabilidad. Esta división explica por qué dos consultas equivalentes pueden generar planes distintos y por qué el diseño de índices debe responder al uso real de la aplicación.

¿Qué es un DBMS Schema y por qué define la estructura lógica de los datos?

Un DBMS schema o esquema de base de datos describe cómo se organizan lógicamente los datos. En un modelo relacional establece tablas, columnas, tipos, claves, relaciones, restricciones, vistas y otros objetos. Por ejemplo, puede indicar que cada pedido debe estar asociado a un cliente existente, que el importe no admite valores negativos y que el correo electrónico debe ser único.

El esquema no contiene necesariamente los datos concretos, sino las reglas que determinan su forma y sus relaciones. Se parece más al plano de un edificio que al contenido de sus habitaciones. Un esquema bien diseñado evita ambigüedades y traslada reglas esenciales desde la aplicación hasta la propia base de datos, donde pueden aplicarse de manera uniforme con independencia del programa que acceda a ella.

Esto no significa que todos los gestores exijan una estructura rígida. Las bases documentales pueden permitir que los documentos de una colección tengan campos diferentes y, al mismo tiempo, admitir validaciones para impedir formatos inesperados. Por tanto, hablar de flexibilidad de esquema no equivale a trabajar sin modelo: las decisiones sobre qué datos se guardan juntos, cómo se identifican y cómo se consultan siguen existiendo.

El diseño del esquema afecta a la integridad, pero también al rendimiento y a la capacidad de evolución. Una estructura excesivamente fragmentada puede obligar a realizar muchas uniones; una desnormalización indiscriminada puede introducir duplicidades difíciles de mantener. Por eso, el modelo debe construirse atendiendo tanto a las reglas del negocio como a los patrones reales de lectura y escritura.

Los tres niveles de abstracción de un sistema de gestión de bases de datos DBMS

La arquitectura clásica distingue tres niveles de abstracción: externo, conceptual e interno. Esta separación permite modificar ciertos aspectos del almacenamiento sin obligar a reescribir todas las aplicaciones y evita que cada usuario tenga acceso a la totalidad de la información.

El nivel externo corresponde a las vistas que reciben los distintos perfiles. Un departamento comercial puede consultar clientes y pedidos sin acceder a datos contables; una aplicación pública puede mostrar disponibilidad sin revelar costes internos. Cada vista presenta únicamente la información y la representación necesarias para una tarea concreta.

El nivel conceptual define la estructura lógica global: entidades, relaciones, restricciones y tipos de datos. Describe qué información existe y cómo se conecta, sin entrar todavía en los detalles físicos de los archivos. Es el punto de referencia común para administradores y aplicaciones.

El nivel interno determina cómo se guardan realmente los datos: páginas, bloques, índices, particiones, compresión, distribución de archivos y otras estructuras físicas. Gracias a la independencia entre niveles, un administrador puede añadir un índice o trasladar archivos a otro dispositivo sin cambiar la forma en que una aplicación formula sus consultas. En la práctica, la independencia absoluta no siempre es posible (una decisión física puede afectar al rendimiento), pero el principio reduce el acoplamiento y facilita la evolución del sistema de gestión de bases de datos.

Funciones principales y ventajas de utilizar un DBMS

Implantar un DBMS no consiste solo en disponer de un lugar común para guardar información. Su verdadero valor aparece cuando centraliza reglas que, de otro modo, quedarían repartidas entre aplicaciones, archivos y procedimientos manuales. Un sistema de gestión de bases de datos proporciona una base común para controlar la calidad, la seguridad y la disponibilidad de los datos.

La principal ventaja es reducir la complejidad sin renunciar al control. Los desarrolladores trabajan con operaciones de alto nivel, mientras el gestor se encarga de aspectos físicos y operativos que requieren mecanismos especializados.

Abstracción de los datos y simplificación del acceso para los desarrolladores

La abstracción permite consultar información mediante tablas, documentos, grafos u otros modelos sin conocer la ubicación exacta de cada byte. El desarrollador expresa qué necesita y el gestor resuelve cómo obtenerlo. Esta separación acelera el desarrollo y facilita cambiar índices, particiones o estrategias de almacenamiento sin modificar toda la lógica de negocio.

También proporciona interfaces coherentes para insertar, actualizar, eliminar y consultar. Los controladores, conectores y herramientas de administración reducen la cantidad de código específico que debe escribirse. No obstante, abstraer no significa ignorar el funcionamiento del gestor: comprender planes de ejecución, índices y transacciones sigue siendo necesario para diseñar aplicaciones eficientes.

Garantía de consistencia y cumplimiento de las propiedades ACID en transacciones

Una transacción agrupa una o varias operaciones que deben tratarse como una unidad. En una transferencia bancaria, restar dinero de una cuenta y sumarlo a otra no puede quedar a medias. Si la segunda operación falla, el conjunto debe revertirse.

En un sistema de gestión de bases de datos, las propiedades ACID describen las garantías habituales de las transacciones: atomicidad, para que se ejecuten por completo o no se apliquen; consistencia, para respetar las reglas definidas; aislamiento, para controlar la interferencia entre operaciones simultáneas; y durabilidad, para conservar los cambios confirmados incluso después de un fallo. ACID no convierte automáticamente un modelo de datos incorrecto en uno fiable: el gestor solo puede hacer cumplir las restricciones y transacciones que el proyecto haya definido adecuadamente.

El grado de aislamiento puede configurarse en muchos productos. Un nivel más estricto evita más anomalías, pero también puede aumentar los bloqueos, los reintentos o el consumo de recursos. La decisión debe ajustarse al riesgo de cada operación, en lugar de aplicar la máxima exigencia de manera indiscriminada.

Control de concurrencia para evitar la pérdida de datos en accesos simultáneos

En una aplicación real, varias personas y procesos leen o modifican información al mismo tiempo. Sin coordinación, dos usuarios podrían editar el mismo registro partiendo de un valor antiguo y sobrescribir mutuamente sus cambios. También podrían aparecer lecturas incoherentes mientras una operación todavía no ha terminado.

Los gestores emplean mecanismos como bloqueos, control multiversión, marcas temporales y detección de conflictos. El control multiversión permite, por ejemplo, que una lectura acceda a una versión coherente mientras otra transacción modifica el registro, reduciendo la necesidad de bloquear a los lectores.

La concurrencia exige equilibrar consistencia y rendimiento. Bloquear demasiado disminuye la capacidad del sistema y puede provocar interbloqueos; bloquear poco o escoger un aislamiento insuficiente puede exponer datos que aún no deberían considerarse definitivos. El DBMS aporta los mecanismos, pero el diseño de las transacciones debe mantenerlas breves y acceder a los recursos en un orden previsible.

Centralización de las políticas de seguridad y control de accesos restringidos

Un sistema de gestión de bases de datos permite definir usuarios, roles, privilegios y políticas desde un punto central. Es posible autorizar la lectura de una tabla sin permitir modificaciones, restringir columnas sensibles, controlar el acceso a determinadas vistas o registrar operaciones para su posterior auditoría.

Esta centralización evita depender exclusivamente de la interfaz de una aplicación. Si una segunda herramienta accede a la misma información, las restricciones del gestor continúan vigentes. También favorece el principio de mínimo privilegio: cada cuenta recibe solo los permisos imprescindibles para su función.

La seguridad no termina en una contraseña. Debe combinar autenticación, autorización, cifrado, segmentación de red, actualización del software, gestión de secretos, auditoría y protección de las copias. Además, las cuentas utilizadas por aplicaciones no deberían compartir privilegios administrativos ni utilizar credenciales incrustadas en el código.

Automatización de los procesos de respaldo y mecanismos de recuperación ante fallos

Un sistema de gestión de bases de datos incorpora utilidades para realizar copias físicas o lógicas, registrar cambios y restaurar información después de errores, corrupción o fallos de infraestructura. Algunas estrategias permiten recuperar la base hasta un momento concreto combinando una copia completa con los registros de transacciones posteriores.

Automatizar una copia no garantiza que pueda recuperarse. Es necesario definir objetivos de pérdida de datos y tiempo de recuperación, conservar copias aisladas, supervisar las ejecuciones y realizar restauraciones de prueba. Así, una copia de seguridad que nunca se ha restaurado ofrece una confianza incompleta.

La recuperación también puede incluir replicación y conmutación por error, pero estas técnicas no sustituyen siempre al respaldo. Una eliminación accidental o un cambio corrupto pueden replicarse inmediatamente en todos los nodos. La estrategia correcta combina copias, registros, redundancia y procedimientos documentados para responder a distintos escenarios.

Clasificación de los sistemas de gestión: modelos relacionales frente a no relacionales

No existe un único modelo válido para almacenar cualquier clase de información. La elección depende de la estructura de los datos, las relaciones que deben conservarse, el volumen de operaciones, la necesidad de consistencia y la forma en que crecerá la aplicación. Por eso, un sistema de gestión de bases de datos puede apoyarse en tablas relacionadas, documentos, pares clave-valor, grafos o incluso combinar varios modelos dentro de una misma plataforma.

La distinción entre tecnologías relacionales y no relacionales resulta útil como punto de partida, pero no debe interpretarse como una división absoluta. Los gestores relacionales actuales admiten documentos JSON, búsquedas avanzadas y mecanismos de distribución, mientras que algunas soluciones NoSQL incorporan transacciones, validación de esquemas y lenguajes de consulta cada vez más expresivos. La decisión correcta no consiste en escoger el modelo más moderno, sino el que resuelve mejor las necesidades reales del proyecto.

Sistemas relacionales (RDBMS)

Los sistemas relacionales organizan la información en tablas formadas por filas y columnas. Cada tabla representa normalmente una entidad (clientes, productos, facturas o pedidos) y las relaciones entre ellas se establecen mediante claves primarias y foráneas.

Este modelo resulta especialmente adecuado cuando la información posee una estructura bien definida y existen relaciones que deben mantenerse con rigor. En una plataforma de ventas, por ejemplo, no basta con guardar un pedido: es necesario vincularlo con un cliente, asociarle unas líneas de producto, registrar el pago y actualizar las existencias sin dejar el proceso a medias.

Un RDBMS utiliza habitualmente SQL para definir estructuras, consultar información y modificar registros. SQL permite seleccionar, filtrar, agrupar y relacionar datos sin especificar manualmente cómo deben recorrerse los archivos físicos. El optimizador del gestor analiza cada instrucción y decide qué índices, métodos de unión y rutas de acceso pueden ofrecer una ejecución más eficiente.

La principal fortaleza del modelo relacional es su capacidad para mantener relaciones e invariantes de negocio de forma centralizada. Las restricciones de unicidad, las claves foráneas, los tipos de datos y las transacciones reducen la posibilidad de que distintas aplicaciones introduzcan información contradictoria.

Esto convierte al RDBMS en una opción frecuente para facturación, banca, comercio electrónico, inventarios, recursos humanos y otros entornos transaccionales. Sin embargo, utilizar un sistema de gestión de bases de datos relacional no obliga a normalizar cada elemento hasta el extremo. En proyectos reales puede ser conveniente duplicar determinados datos, crear vistas materializadas o utilizar columnas JSON cuando ello simplifica una consulta concreta sin comprometer la integridad general.

El universo DBMS NoSQL

El término NoSQL agrupa tecnologías que no dependen exclusivamente del modelo relacional tradicional. No significa necesariamente “sin SQL”, sino que suele interpretarse como Not Only SQL: sistemas concebidos para resolver necesidades que pueden resultar incómodas en una estructura estrictamente tabular.

Dentro de esta categoría existen varias familias. Los gestores documentales almacenan objetos semejantes a JSON; los sistemas clave-valor recuperan información mediante una clave única; las bases columnares distribuidas organizan los datos para gestionar grandes volúmenes; y las bases de grafos priorizan las relaciones y los recorridos entre nodos.

NoSQL no es un único modelo ni ofrece las mismas garantías en todos los productos. Una base documental y una plataforma clave-valor pueden compartir la etiqueta, pero su forma de consultar, escalar y mantener la consistencia es muy diferente.

Un gestor documental puede resultar apropiado para catálogos cuyos atributos cambian según el producto. Un televisor puede tener tamaño de pantalla y resolución, mientras que una prenda necesita talla, tejido y color. Guardar cada artículo como documento permite representar esas diferencias sin crear numerosas tablas auxiliares o columnas vacías.

No obstante, la flexibilidad debe administrarse. Si cada aplicación guarda fechas, direcciones o importes con formatos distintos, las consultas y validaciones se complicarán. Aunque el sistema de gestión de bases de datos permita documentos con estructuras variables, el proyecto sigue necesitando criterios de modelado, convenciones y controles de calidad.

Comparativa de escalabilidad: crecimiento vertical clásico frente al horizontal de NoSQL

El escalado vertical consiste en aumentar los recursos de una máquina: más procesadores, memoria, almacenamiento o capacidad de entrada y salida. Ha sido una estrategia habitual en entornos relacionales porque simplifica la coordinación de transacciones y mantiene los datos principales dentro de un mismo servidor.

Su ventaja es la sencillez operativa. Añadir memoria o sustituir un servidor puede requerir menos cambios que dividir los datos entre varios nodos. Sin embargo, existe un límite físico y económico: el hardware de gran capacidad aumenta de precio de forma considerable y una única máquina puede convertirse en un punto crítico.

El escalado horizontal incorpora más servidores y distribuye entre ellos las operaciones o los datos. Las plataformas NoSQL se asociaron desde sus orígenes con este enfoque porque muchas fueron diseñadas para particionar automáticamente grandes conjuntos de información. MongoDB, por ejemplo, utiliza sharding para repartir datos entre varias máquinas y atender volúmenes o cargas que no deberían concentrarse en un único nodo.

Escalar horizontalmente no significa limitarse a añadir servidores sin consecuencias. Es necesario decidir cómo se reparten los registros, cómo se localiza cada partición, qué ocurre cuando un nodo falla y cómo se coordinan las operaciones que afectan a varias particiones.

Además, la frontera se ha difuminado. Los RDBMS pueden utilizar réplicas, particionamiento y arquitecturas distribuidas, mientras que un sistema de gestión de bases de datos NoSQL también puede ejecutarse inicialmente en una sola máquina. La arquitectura debe responder a un crecimiento previsible, no a la expectativa de una escala que quizá nunca llegue a producirse.

Sistemas de gestión de bases de datos distribuidas y consistencia eventual

Una base de datos distribuida mantiene información o capacidad de procesamiento en varios nodos, que pueden encontrarse incluso en centros de datos y regiones diferentes. Esta arquitectura permite aumentar la disponibilidad, acercar las lecturas a los usuarios y reducir la dependencia de una única infraestructura.

La distribución introduce un problema inevitable: la comunicación entre nodos tiene latencia y puede interrumpirse. Cuando un dato se modifica en una ubicación, las demás copias no siempre reciben el cambio de manera instantánea. En un modelo de consistencia eventual, durante un periodo breve pueden obtenerse versiones distintas, pero el sistema converge cuando dejan de producirse actualizaciones.

Este comportamiento puede ser aceptable en un contador de visualizaciones, determinadas recomendaciones o una caché de contenido. En cambio, sería mucho más delicado al comprobar un saldo, reservar la última habitación disponible o impedir que un mismo cupón se utilice dos veces.

La consistencia eventual no equivale a pérdida de control ni a datos permanentemente incorrectos. Es una garantía concreta que debe evaluarse junto con las necesidades de latencia, disponibilidad y tolerancia a fallos.

Tampoco todas las plataformas distribuidas obligan a elegir únicamente entre consistencia fuerte y eventual. Azure Cosmos DB, por ejemplo, ofrece varios niveles intermedios, mientras que Google Spanner proporciona transacciones con consistencia externa sobre una arquitectura distribuida.

Por tanto, al configurar un sistema de gestión de bases de datos distribuido hay que estudiar qué operaciones pueden admitir lecturas desactualizadas, cuáles requieren confirmación inmediata y qué coste de latencia implica cada garantía. La consistencia debe definirse según el proceso de negocio y no mediante una regla general para toda la aplicación.

SGBD multimodelo

Un SGBD multimodelo admite distintas formas de representar y consultar información dentro de una misma plataforma. Puede combinar tablas relacionales, documentos, grafos, datos espaciales, series temporales o pares clave-valor, dependiendo de las capacidades del producto.

Esta posibilidad evita desplegar una herramienta independiente para cada necesidad. Una empresa podría conservar clientes y facturas en tablas, guardar atributos variables en documentos JSON y analizar relaciones mediante funciones de grafo sin trasladar todos los datos a sistemas separados.

La ventaja principal es reducir la fragmentación tecnológica y los movimientos innecesarios de información. También puede simplificar la seguridad, las copias de respaldo y la administración, porque varias cargas comparten una infraestructura común.

Sin embargo, que una plataforma admita varios modelos no significa que destaque por igual en todos ellos. Una función de grafos integrada puede ser suficiente para recomendaciones sencillas, pero quedarse corta ante recorridos extremadamente complejos. Del mismo modo, una columna JSON dentro de un gestor relacional no sustituye automáticamente a una base documental diseñada para distribuir millones de documentos.

El enfoque multimodelo debe valorarse por la profundidad de sus funciones, su rendimiento y su encaje con el equipo. Adoptarlo solo para reducir el número de tecnologías puede trasladar la complejidad hacia configuraciones difíciles de optimizar.

SGBD más utilizados en el mercado

El mercado reúne soluciones de código abierto, productos comerciales, servicios administrados y plataformas creadas directamente para la nube. Su presencia varía según el tipo de empresa, el sector y la carga de trabajo, por lo que no existe un ranking único que determine cuál es mejor.

Al seleccionar un sistema de gestión de bases de datos ampliamente implantado conviene considerar su madurez, la documentación, los controladores disponibles, la comunidad, el soporte profesional y la facilidad para encontrar especialistas. La popularidad reduce ciertos riesgos, pero nunca sustituye al análisis técnico del proyecto.

DBMS PostgreSQL

PostgreSQL es un gestor relacional de código abierto caracterizado por su atención a los estándares, su extensibilidad y su amplia colección de tipos de datos y funciones. Permite crear índices avanzados, vistas, procedimientos, particiones y extensiones capaces de incorporar nuevas funcionalidades.

Su modelo relacional convive con soporte para JSON, búsquedas de texto, datos espaciales mediante extensiones y diferentes mecanismos de replicación. Esto permite utilizarlo tanto en aplicaciones transaccionales convencionales como en proyectos que necesitan manejar información semiestructurada.

La documentación actual de PostgreSQL incluye apartados específicos sobre definición de datos, consultas, índices, control de concurrencia, búsqueda de texto, administración y optimización del rendimiento.

PostgreSQL destaca cuando se necesita combinar integridad transaccional con capacidad de ampliación. No obstante, sus numerosas opciones exigen supervisar consultas, índices, mantenimiento y configuración. Elegir una tecnología potente no elimina la necesidad de administrarla correctamente.

MySQL y Oracle Database

MySQL es uno de los gestores relacionales más extendidos en aplicaciones web. Su integración con numerosos lenguajes, paneles de alojamiento y sistemas de gestión de contenidos ha favorecido su adopción en proyectos de tamaños muy distintos.

Su arquitectura admite motores de almacenamiento, aunque InnoDB es la opción predeterminada y de propósito general en las versiones actuales. Este motor proporciona transacciones, claves foráneas, recuperación y control de concurrencia. MySQL también incorpora replicación, que permite copiar datos desde un servidor de origen hacia una o varias réplicas. Aquí tenemos una explicación detallada sobre qué es MySQL.

Oracle Database está orientado especialmente a entornos empresariales que requieren herramientas avanzadas, soporte comercial, alta disponibilidad, seguridad, gestión de grandes cargas y una amplia integración con productos corporativos. Su plataforma ha evolucionado más allá del almacenamiento puramente tabular e incluye capacidades para datos JSON, espaciales y de grafo.

MySQL y Oracle Database pueden compartir fundamentos relacionales, pero responden a contextos de adopción y costes muy diferentes. Antes de elegirlos hay que revisar las ediciones, las funciones incluidas, las condiciones de licencia, la infraestructura disponible y el nivel de soporte requerido.

MongoDB

MongoDB es una base de datos documental que almacena registros mediante documentos con una estructura similar a JSON. Los documentos pueden contener campos, listas y objetos anidados, lo que permite representar de forma natural información jerárquica o con atributos variables.

El modelo documental suele reducir la necesidad de uniones cuando los datos que se consultan juntos se almacenan dentro del mismo objeto. Esto puede resultar útil en catálogos, perfiles de usuario, sistemas de contenidos y aplicaciones que evolucionan con rapidez.

MongoDB dispone de conjuntos de réplicas para aportar redundancia y alta disponibilidad. También permite distribuir colecciones mediante sharding, repartiendo el conjunto de datos entre varios fragmentos.

La clave no está en trasladar directamente un diseño relacional a documentos. Es necesario modelar según las consultas habituales, decidir qué información debe incrustarse y qué información conviene referenciar. Un documento que crece sin límites o una clave de partición mal elegida puede generar problemas incluso en una infraestructura distribuida.

Redis

Redis se diseñó como un almacén de datos en memoria, aunque sus capacidades actuales abarcan caché, mensajería, procesamiento de flujos, almacenamiento documental y otros escenarios de baja latencia. Trabaja con estructuras como cadenas, hashes, listas, conjuntos y conjuntos ordenados, sobre las que proporciona operaciones atómicas.

Su velocidad lo hace adecuado para sesiones, cachés, clasificaciones, limitación de peticiones, colas y datos temporales que deben consultarse con mucha frecuencia. Sin embargo, no debería elegirse únicamente porque sea rápido: mantener grandes volúmenes en memoria tiene un coste y el patrón de acceso debe justificarlo.

Redis dispone de replicación y diferentes opciones de persistencia en disco. Estas funciones deben configurarse atendiendo a cuánta información puede perderse y cuánto tiempo puede tardar la recuperación. La propia documentación recomienda combinar cuidadosamente replicación y persistencia cuando los datos deben sobrevivir a reinicios o fallos.

Redis suele ofrecer más valor como componente especializado que como sustituto universal de la base principal. En muchas arquitecturas complementa a un gestor relacional o documental, absorbiendo las operaciones que necesitan una respuesta especialmente rápida.

Gestores nativos de la nube

Los gestores nativos de la nube se diseñan para aprovechar servicios distribuidos, escalado automático, infraestructura administrada y despliegues en varias zonas o regiones. El proveedor asume una parte importante de las tareas de mantenimiento, como aprovisionamiento, parches, copias, monitorización y sustitución de nodos.

Amazon Aurora es un motor relacional administrado compatible con MySQL y PostgreSQL. Separa el procesamiento del almacenamiento y mantiene un volumen distribuido entre varias zonas de disponibilidad.

Google Spanner combina una arquitectura distribuida con SQL, transacciones ACID y consistencia fuerte global. Azure Cosmos DB, por su parte, ofrece distribución internacional, particionamiento y varios niveles configurables de consistencia para adaptar el equilibrio entre disponibilidad, latencia y actualidad de las lecturas.

Un servicio administrado reduce trabajo operativo, pero no elimina las decisiones de arquitectura. Todavía es necesario diseñar particiones, índices, consultas, permisos, presupuestos y estrategias de recuperación. Además, deben analizarse la dependencia del proveedor, los costes por transferencia, almacenamiento y operaciones, así como la dificultad de una futura migración.

La ventaja de utilizar un sistema de gestión de bases de datos concebido para la nube aparece cuando el proyecto necesita crecer de manera elástica, operar en varias ubicaciones o reducir la administración directa de servidores. Para aplicaciones pequeñas y estables, una solución convencional bien gestionada puede seguir siendo más sencilla y previsible.

Fernán García de Zúñiga

Artículos relacionados

Productos relacionados: