A medida que las empresas introducen nuevas fuentes de datos para mejorar los procesos o trasformar completamente sus modelos de negocio, las aplicaciones son capaces de incorporar diversos tipos de modelos de datos: documento, clave-valor y objeto, etc., además del modelo relacional. El reto fundamental es añadir modelos de datos sin aumentar la complejidad tecnológica.
Mientras las bases de datos NoSQL crecían en popularidad, las empresas adoptaron persistencia políglota. Esto implicaba la adopción de un sistema de almacenamiento de datos único para cada tipo de modelo: datos de documento en una base de datos de documentos, datos clave-valor en una base de datos clave-valor, etc. La incorporación de modelos de datos adicionales en las aplicaciones conlleva mayor complejidad en la gestión de aspectos como la transformación de datos y el linaje de datos. Esto se opone al principio de simplicidad.
A medida que las empresas introducen nuevas fuentes de datos para mejorar los procesos o trasformar completamente sus modelos de negocio, las aplicaciones son capaces de incorporar diversos tipos de modelos de datos
En respuesta a estas necesidades, los proveedores de NoSQL comenzaron a ofrecer la capacidad de almacenar múltiples modelos de datos en una única base de datos back-end, lo que suscitó la introducción del término «base de datos multimodelo». La ventaja de este enfoque es que se dispone de una arquitectura menos compleja que, además, mejora la consistencia de los datos.
Si partimos de la premisa de que una base de datos multimodelo representa una necesidad imprescindible para las aplicaciones actuales, el nuevo requisito es conseguir compatibilidad con cargas de trabajo múltiples. Una base de datos con cargas de trabajo múltiples ofrece la capacidad de procesar transacciones y análisis simultáneamente. Tal y como observamos con la evolución de las bases de datos multimodelo, las organizaciones habían implementado bases de datos específicas para la carga de trabajo: unas especializadas en procesamiento de transacciones online (OLTP) y otras especializadas en análisis o procesamiento analítico online (OLAP).
Sume esta complejidad a su persistencia políglota y, ¿cuál es el resultado? Un caos.
Gartner describe la base de datos con cargas de trabajo múltiples como una base de datos híbrida de procesamiento de transacciones y procesamiento analítico (HTAP). La idea de eliminar la necesidad de una base de datos OLAP y ejecutar análisis en la misma base de datos como transacciones adquiere cada vez mayor popularidad. La propuesta de valor es similar al multimodelo: arquitectura más sencilla, menores costes generales de gestión y mantenimiento, etc.
Avancemos un paso más. Reflexionemos sobre el escenario en el que se requiere procesar transacciones para fuentes de datos de documento y relacionales, mientras se ejecutan análisis estructurados y no estructurados, para facilitar que su aplicación procese la transacción de forma óptima. Podría disponer de múltiples bases de datos para procesar diferentes fuentes de datos y diversas bases de datos analíticas para datos estructurados y no estructurados, o podría contar con una base de datos multimodelo y multi-carga de trabajo.
En lugar de aumentar la complejidad, los esfuerzos deben centrarse en obtener simplicidad elegante mediante el principio KISS, del inglés «Keep It Simple!». Las ventajas incluyen una reducción drástica de los costes, ya que se requiere un número considerablemente inferior de recursos para soportar las aplicaciones. El menor número de partes móviles no solo facilita la gestión, también permite conseguir mayor rendimiento, fiabilidad y escalabilidad.
A medida que aumenta el número de nuevos modelos de datos en el mercado, y la necesidad de nuestros clientes de incorporarlos a sus aplicaciones, planificamos cómo ayudarles a evitar la persistencia políglota, manteniendo la mayor simplicidad posible.
