Navegar por la analítica en la era NoSQL

Los sistemas de bases de datos NoSQL han establecido firmemente su presencia durante más de una década, cosechando una cuota de mercado sustancial en el dominio de las bases de datos OLTP. La rápida adopción de las bases de datos NoSQL para casos de uso OLTP puede atribuirse a factores clave como la escalabilidad y la disponibilidad, junto con un sólido soporte para el desarrollo ágil a través de un diseño de esquema flexible y un rendimiento mejorado.

La piedra angular de las prácticas de desarrollo ágil para los desarrolladores de aplicaciones modernas reside en la flexibilidad que ofrece un modelo documental, que permite una rápida adaptación a la evolución de los requisitos empresariales. Esto ha liberado eficazmente a los desarrolladores de la dependencia de los administradores de bases de datos, eliminando los cuellos de botella y la necesidad de adherirse a las ventanas de cambio de las bases de datos empresariales.

Consideremos un ejemplo de aplicación de biblioteca con un esquema JSON

Introducir el género de un libro en nuestra aplicación de biblioteca es una tarea sencilla para el desarrollador de la aplicación. Se trata de un simple ajuste: añadir un nuevo campo de matriz llamado género al documento. Dado que un libro puede pertenecer a múltiples géneros, este enfoque flexible se adapta sin esfuerzo a la naturaleza dinámica de la categorización de libros.

¿Culmina el ciclo de vida de los datos con una aplicación OLTP? La respuesta inequívoca es no.

Muchas aplicaciones OLTP fluyen sin problemas hacia sistemas analíticos posteriores, como análisis en tiempo real, data marts, almacenes de datos o lagos de datos. Sin embargo, surge un reto importante porque la mayoría de los sistemas de bases de datos analíticos del mundo se basan en modelos de bases de datos relacionales, que esperan un formato fijo, tabular y relacional para los datos almacenados. 

En este punto se plantea un problema importante: mientras que los sistemas de bases de datos OLTP NoSQL ascendentes cuentan con un esquema flexible con un modelo de documento -en el que cada documento puede poseer un esquema distinto, y los documentos pueden encapsular documentos o matrices anidados-, la conversión de estos datos diversos de nuevo en el mundo relacional induce considerables desafíos ETL (Extract, Transform, Load). Sin embargo, el problema va más allá de los problemas de ETL. 

La flexibilidad del soporte de esquemas y modelos de documentos en las aplicaciones OLTP significa que los desarrolladores ya no están obligados a coordinar los cambios en las bases de datos con un administrador de bases de datos (DBA), lo que permite una evolución rápida y dinámica del esquema de la aplicación. En cambio, los sistemas descendentes, de naturaleza intrínsecamente relacional, tienen dificultades para seguir el ritmo de la evolución constante del esquema. Para ilustrar este problema, volvamos a nuestro ejemplo de la aplicación de biblioteca.

Suponiendo que esta aplicación de biblioteca tenga una base de datos analítica relacional subyacente, el esquema sería algo parecido a lo siguiente.

Mesa de libros

Tabla de editores

Tabla Book_Publisher

Si necesitamos transmitir la adición directa del género en los documentos de la base de datos OLTP NoSQL al sistema de análisis posterior, el proceso implica lo siguiente.

Introduciríamos 2 nuevas mesas: Género y Libro_Género.

Tabla de géneros

Tabla Libro_Género

Además, la aplicación ETL encargada de suministrar datos al sistema analítico relacional debe acometer la tarea de descomponer los género dentro de cada documento y rellenando la información resultante en las tablas correspondientes a cada documento.

A partir de los ejemplos anteriores, es evidente que la construcción de aplicaciones analíticas en tiempo real y la sincronización con los cambios dinámicos en las bases de datos OLTP NoSQL ascendentes plantean retos para los sistemas analíticos relacionales. A pesar de estos retos, ¿por qué persisten las empresas en construir sistemas analíticos relacionales, especialmente cuando los sistemas OLTP ascendentes se inclinan hacia una naturaleza orientada a documentos NoSQL? Para profundizar en esta cuestión, exploremos los principios fundamentales que sustentan los sistemas de bases de datos diseñados para la analítica.

Las consultas analíticas suelen implicar el manejo de extensos conjuntos de datos con intrincadas uniones, agregaciones y múltiples capas de filtrado. Muchas de estas operaciones pueden agilizarse considerablemente si se ejecutan en paralelo en una red de servidores. Por ello, los sistemas de bases de datos diseñados para el análisis deben ser robustos. Procesamiento paralelo masivo que permite distribuir un plan de consulta entre varios servidores físicos para aumentar la velocidad de ejecución de las consultas.

Las consultas analíticas suelen centrarse en recuperar un subconjunto específico de columnas de todo el conjunto de datos. Por lo tanto, Bases de datos orientadas a columnas son las preferidas en los casos de uso analítico porque optimizan las operaciones de E/S. Al recuperar selectivamente sólo las columnas relevantes para una consulta, estas bases de datos minimizan la necesidad de recuperar toda la información de las columnas del disco, lo que se traduce en un rendimiento más eficiente de las consultas.

Las consultas analíticas son intrínsecamente complejas y pueden dar lugar a múltiples planes de ejecución potenciales. En el ámbito de los sistemas de bases de datos para análisis, es fundamental que estos sistemas vayan más allá de la planificación basada en reglas y empleen una Optimizador de consultas basado en costes. Este optimizador desempeña un papel crucial a la hora de identificar el plan de consulta más eficiente teniendo en cuenta una serie de factores de coste, lo que garantiza la ejecución óptima de consultas analíticas complejas.

Las bases de datos analíticas están diseñadas para la escalabilidad horizontal, lo que permite añadir sin problemas recursos informáticos a un clúster de bases de datos existente. Esta escalabilidad sirve para reducir los tiempos de ejecución de las consultas y dar cabida a consultas adicionales. Especialmente en los entornos en nube, donde es posible añadir y eliminar rápidamente recursos informáticos, resulta imperativo adoptar una arquitectura de base de datos analítica que haga hincapié en lo siguiente Separación almacenamiento-ordenador. Este diseño facilita la rápida ampliación o contracción del clúster de bases de datos, garantizando su adaptabilidad a cargas de trabajo variables.

Históricamente, las bases de datos NoSQL orientadas a documentos no cumplían los cuatro principios esenciales mencionados que requieren los sistemas de bases de datos analíticos. En consecuencia, las empresas persistían en utilizar bases de datos relacionales para los sistemas analíticos, incluso cuando la base de datos OLTP ascendente adoptaba un enfoque NoSQL. Esta decisión estaba motivada por las limitaciones expuestas anteriormente.

¡Couchbase Analytics al rescate!

Couchbase Analytics es un servicio en la nube de base de datos columnar masivamente paralela, orientada a documentos NoSQL y con almacenamiento y computación separados, equipado con un optimizador integrado basado en costos. Couchbase Analytics, que aborda todos los principios fundamentales de una base de datos analítica de alto rendimiento, conserva el apreciado modelo de datos flexible orientado a documentos. Al permitir a las empresas construir sistemas analíticos en tiempo real, reduce significativamente el esfuerzo y el tiempo de ETL necesarios para ingestar datos de bases de datos OLTP NoSQL ascendentes. Además, garantiza que las aplicaciones analíticas se mantengan sincronizadas con los datos empresariales más recientes que llegan de los sistemas transaccionales ascendentes.

Obtenga más información sobre cómo Couchbase Analytics satisface sus necesidades:

• Leer Couchbase Analytics añade un servicio de datos en tiempo real
• Ver Couchbase anuncia un nuevo servicio de análisis