El Problema Políglota: Resolviendo la Paradoja de la Base de Datos «Correcta»

( Leszek Glasner/)

La persistencia políglota, introducida por primera vez en 2011, ahora es casi derecho canónico en ELLA. Por lo tanto, lo que tengo que decir puede parecer una blasfemia.

La mayoría de las organizaciones de hoy en día han adoptado el concepto de Persistencia políglota: implementan una variedad de tecnologías de almacenamiento de datos diferentes basadas en la variedad de formas en que consultan, analizan e implementan sus datos. Y el crecimiento y la omnipresencia de los almacenes de datos clave/valor, gráficos, series temporales y JSON ha proporcionado a los desarrolladores abundantes opciones para elegir la herramienta de datos adecuada para el trabajo correcto.

Pero las demandas para nosotros como desarrolladores han evolucionado rápidamente y creo que la persistencia políglota luchará rápidamente para mantener el ritmo. O, tal vez, esa ya es la realidad a la que te enfrentas hoy. ¿Por qué? Porque la tarea que tenemos es desalentadora y los equipos de desarrollo ya están agotados.

Diversidad de bases de datos

Necesitamos ser expertos en un amplio espectro de tecnologías de bases de datos, cada una con sus propios lenguajes de consulta. Necesitamos que nuestras aplicaciones ofrezcan resultados eficientes en un número creciente de casos de uso. Y se nos pide que construyamos y gestionemos cientos de aplicaciones basadas en datos, que crecen hasta llegar a miles, y que requieren una variedad de modelos de datos e implementaciones. ¿Te imaginas dominar y mantener otra tecnología o lenguaje de consulta? ¿Cinco? Diez más?

El software se está comiendo el mundo, nuestros esfuerzos de desarrollo solo van a crecer, el tiempo y los costos para integrar múltiples almacenes de datos son insostenibles, y los desarrolladores necesitan desesperadamente centrarse en un conjunto finito de tecnologías de base de datos.

Lo que es más importante, los casos de uso están creciendo en sofisticación y lo que pediremos a nuestros datos requerirá el uso de múltiples modelos de datos, tal vez incluso instantáneamente. Crear soluciones alternativas en el código de la aplicación para calcular consultas no es sostenible ni escalable. Creo que es hora de que las organizaciones busquen enfoques híbridos que les permitan simplificar su cartera de tecnología y tener la flexibilidad de elegir el modelo de datos adecuado para el trabajo adecuado.

Explorar modelos de datos

He descubierto que es útil comprender qué modelos de datos funcionan bien para diferentes usos y cómo se pueden combinar.

Bases de datos de documentos JSON

JSON es muy versátil para datos estructurados y no estructurados. La naturaleza recursiva de JSON permite incrustar subdocumentos y listas de longitud variable. Además, incluso puede almacenar las filas de una tabla como documentos JSON, y los almacenes de datos modernos son tan buenos para comprimir datos que esencialmente no hay sobrecarga de memoria en comparación con las bases de datos relacionales. Para datos estructurados, la validación de esquemas se puede implementar según sea necesario mediante una API HTTP extensible.

Bases de datos de gráficos

Las bases de datos de gráficos son buenos modelos de datos para las relaciones. En muchos casos del mundo real, un gráfico es un modelo de datos muy natural. Captura relaciones y puede contener información de etiquetas con cada arista y con cada vértice. Los documentos JSON son una opción natural para almacenar este tipo de datos de vértices y bordes.

Una base de datos de gráficos es particularmente buena para consultas de» grafía». Lo crucial aquí es que el lenguaje de consulta debe implementar rutinas como «camino más corto» y «recorrido de grafos», la capacidad fundamental para estos es acceder rápidamente a la lista de todos los bordes salientes o entrantes de un vértice.

Bases de datos Multimodelo

Una base de datos multimodelo combina las capacidades de las bases de datos de documentos, claves/valores y gráficos. Le permite elegir diferentes modelos de datos con menos gastos operativos. Tener varios modelos de datos disponibles en un único motor de base de datos alivia algunos de los desafíos de usar diferentes modelos de datos al mismo tiempo, porque significa menos sobrecarga operativa y menos sincronización de datos, y por lo tanto permite un gran salto en la flexibilidad de modelado de datos.

De repente tiene la opción de mantener los datos relacionados juntos en el mismo almacén de datos, incluso si necesita modelos de datos diferentes. La posibilidad de mezclar los diferentes modelos de datos en una sola consulta aumenta las opciones de diseño de aplicaciones y optimizaciones de rendimiento. Y si elige dividir la capa de persistencia en varias instancias de base de datos diferentes (incluso si utilizan el mismo modelo de datos), tendrá la ventaja de tener que implementar una sola tecnología. Además, se evita el bloqueo del modelo de datos.

La Solución Políglota

La persistencia Políglota fue aceptada porque nos permitió evitar comprometer una tecnología de base de datos monolítica. Comprendimos que la persistencia políglota tenía un costo en complejidad, un costo en rendimiento y un costo en consistencia y disponibilidad a medida que los clústeres se hacían más y más grandes. Pero la mayoría, si no todos, sentimos que los beneficios de la flexibilidad del modelo de datos han superado con creces esos costos porque una base de datos monolítica nunca existiría ni existirá para abordar todos o incluso la mayoría de los requisitos y casos de uso.

Hoy en día, está claro que necesitamos los beneficios de la Persistencia Políglota sin el costo. Necesitamos tener la flexibilidad para crear aplicaciones de alto rendimiento que se escalen horizontalmente y utilicen una variedad de modelos de datos. Necesitamos lenguajes de consulta que nos permitan realizar consultas de forma nativa y a través de diferentes modelos de datos. Necesitamos bases de datos que nos den la libertad y flexibilidad para usar diferentes modelos de datos de maneras únicas a medida que nuestros proyectos evolucionan inevitablemente.

Para muchas organizaciones avanzadas, ya es común utilizar una pequeña base de datos de gráficos en una parte de un proyecto, una gran implementación de clave/valor para otra o una combinación de modelos de gráficos, clave/valor y documentos (JSON) para otra.

Versatilidad de datos

Considere un conjunto de datos complejo como el de una flota de aeronaves que consta de varias aeronaves, cada una de las cuales consta de varios millones de partes, que forman subcomponentes, luego componentes más grandes y más pequeños, todos los cuales caen en una jerarquía de «elementos».»

Para un mantenimiento óptimo de la flota, la organización tiene que almacenar una variedad de datos en diferentes niveles de la jerarquía, p. ej. nombres de piezas o componentes, números de serie, información del fabricante, intervalos de mantenimiento, fechas de mantenimiento, información sobre subcontratistas, enlaces a manuales y documentación, personas de contacto, información de contratos de garantía y servicio, etc. Ese tipo de jerarquía de datos es un ajuste natural claro para una base de datos de gráficos porque captura las relaciones entre diferentes puntos de datos, incluida la información de cada borde y vértice. Pero, ¿es una base de datos de gráficos ideal para responder de manera eficiente a las consultas clave del equipo de mantenimiento de la flota?

Una base de datos de gráficos funciona bien para la pregunta: «¿ Cuáles son todas las partes de un componente determinado?»Y podría ayudar a responder la pregunta:» Dada la parte A rota, ¿cuál es el componente más pequeño de la aeronave que contiene la pieza y para el que hay un procedimiento de mantenimiento?»Pero una base de datos de gráficos sería algo inútil con una pregunta común como» ¿Qué partes de este avión necesitan mantenimiento la próxima semana?»porque la estructura del gráfico no se ajusta a la consulta.

Sin embargo, si los datos del gráfico se pueden almacenar como documentos JSON, asociando datos arbitrarios con vértices y aristas, esa pregunta podría responderse fácilmente a través de una consulta de documento.

El punto es que para realizar todas las consultas en ese sistema rápidamente, necesita una base de datos que pueda almacenar información como una variedad de modelos de datos, a menudo llamada base de datos multimodelo. ¿No sería bueno si esa base de datos de gráficos pudiera implementar índices secundarios en sus datos de vértices?

Pero entonces se convertiría esencialmente en una base de datos multimodelo. Es un buen primer paso. El escenario ideal es usar un gráfico, un documento y un modelo de datos clave/valor al mismo tiempo para encontrar primero piezas con mantenimiento pendiente, ejecutar el cálculo de ruta más corta anterior para cada una de ellas y luego realizar una operación de unión con la colección de contactos para agregar información de contacto concreta. Acceder a un modelo de datos diferente solo debería ser cambiar una consulta, no su base de datos. Ahí es donde tenemos que ir, y pronto.

Este ejemplo de mantenimiento de flota no es único ni especial. Al hablar con los desarrolladores, descubrí que es simplemente un buen análogo para el creciente número y diversidad de casos de uso que los desarrolladores están viendo. Desde mi perspectiva, el aprendizaje fundamental de la Persistencia Políglota es la necesidad de usar el modelo de datos correcto para el trabajo correcto. Y con las innovaciones en tecnología de bases de datos podemos tener más de uno en el mismo motor de bases de datos. De lo contrario, debemos reconocer que la persistencia políglota es su propio compromiso que nos limita y que eventualmente nos pondrá por detrás de nuestros competidores.

Sobre el autor: Max Neunhoeffer es desarrollador senior y arquitecto en ArangoDB. En su carrera académica, trabajó durante 16 años en el desarrollo e implementación de nuevos algoritmos en álgebra computacional. Hace varios años, cambió su enfoque a las bases de datos NoSQL. En ArangoDB, es responsable de «todo lo distribuido», incluida la implementación en Kubernetes, pero también de la resiliencia, la conmutación por error y la escalabilidad. Sus intereses particulares incluyen transacciones distribuidas, sistemas distribuidos de autocuración y ajuste de rendimiento. Si sus días tuvieran 48 horas, jugaría al golf, navegaría, tocaría el piano e inventaría un nuevo lenguaje de programación.

Etiquetas: ArangoDB, gráfico, json, clave-valor, base de datos multimodelo, políglota, persistencia políglota, relacional

Deja una respuesta

Tu dirección de correo electrónico no será publicada.