Grafos y Big Data: Una combinación con enorme futuro

El año del grafo: obtener grafos, volverse nativo, remodelar el paisaje

El año del grafo está aquí. ¿Realmente necesita una base de datos de grafos y, en caso afirmativo, cómo elegir una?

 George Anadiotis  ||  ZDNet



Video: ¿Qué hay de nuevo en el mundo de las bases de datos de grafos? Aquí hay un resumen rápido

Es oficial: las bases de datos de grafos son una cosa. Ese es el consenso aquí en Big on Data entre los colaboradores Andrew Brust y Tony Baer. Cuando AWS ingresa a un dominio, señala oficialmente la pendiente ascendente del ciclo de promoción. Es un poco como la tierra recién descubierta: primero es en gran parte desconocida y habitada por nativos, luego los pioneros muestran que hay oportunidades, y luego los pesos pesados ​​intentarán colonizarla.

La reciente presentación de AWS Neptune parece haber convencido incluso a los que se autoproclamaron escépticos de los grafos como Brust y Baer. ¿Por qué ahora, preguntas? Al igual que el Aprendizaje automático, por ejemplo, no es tanto que haya un avance importante en la tecnología, sino que es principalmente una cuestión de maduración.

Las capacidades de hardware y software, como almacenamiento económico y capacidad de procesamiento en la nube y en el local, la comprensión de los desafíos en técnicas de indexación distribuida y consulta de grafos y la realización de conjuntos de datos grandes y conectados han contribuido a la tormenta gráfica perfecta.

Obteniendo grafos

Como siempre, cuando alguna tecnología de nicho se generaliza, existe el riesgo de malentendidos o sobrevaloración hasta el punto en que se convierte en una palabra de moda sin sentido, un martillo aplicado a cada problema independientemente de si se trata de un clavo. Entonces, advertencia justa: si algo no se siente como un grafo, entonces no intente forzarlo.

Es probable que tus videos estén viviendo bastante bien en la tienda de objetos donde los tienes actualmente. Un sistema de contabilidad de ventas construido usando una base de datos relacional probablemente esté funcionando bien, y de la misma manera una tienda de documentos es posiblemente el lugar correcto para almacenar sus documentos. Por lo tanto, "usar la herramienta adecuada para el trabajo" sigue siendo una frase válida aquí y en cualquier otro lugar.

Dicho esto, parte del motivo detrás del atractivo del grafo es que, en muchos casos, es una forma natural de modelar el mundo. ¿Más natural que el viejo modelo relacional? Para ciertos dominios y casos de uso, cuando los datos que está almacenando están intrínsecamente vinculados por su naturaleza, sí. Por un lado, ciertamente se siente más fácil y funciona mejor para consultar una base de datos de grafos que relacional para casos de uso que involucran muchos saltos.



En los conjuntos de datos conectados, como los de los dominios sociales, por ejemplo, el grafo tiene mucho sentido. Imagen: Amazon

Tener que pasar por una serie de uniones en el álgebra relacional para hacer cosas como encontrar amigos de amigos de amigos es engorroso para escribir y mantener y degrada el rendimiento. Un modelo de grafo y un lenguaje de consulta pueden ser más naturales y eficientes, pero la palabra clave allí es "puede". No todo lo que parece un grafo es, de hecho, un grafo, y no todos los grafos vienen con las mismas facilidades de consulta.

Para citar a Tony Baer: "Siempre consideré que el grafo era más adecuada para ser incluida bajo el capó porque era una nueva y extraña base de datos sin estándares de facto ni de otro tipo. Pero estoy empezando a cambiar mi tono: todos los principales proveedores de plataformas de datos ahora tienen ya sea una base de datos de grafos o API / motor ". Esto resalta dos puntos importantes: la diferencia entre un grafo nativo y un API de grafo, y la falta de estándares.

Convertirse en nativo

Diferentes personas usarán diferentes definiciones de motores y API, pero al final todo se trata de estructuras de datos. Si su base de datos se basa en estructuras de datos que no encajan de manera natural en un grafo y no cuenta con la indexación correcta, entonces, aunque sus consultas sean más fáciles de escribir utilizando una API de grafos, su rendimiento solo puede ser tan bueno como tu base de datos.

Para dar un ejemplo del mundo de Microsoft, citando a Andrew Brust: "Las capacidades de procesamiento de grafos en SQL Server 2017 son claramente una capa de abstracción y no nativa. Aunque los tipos de tablas de nodo y borde son reales. ¿Pero qué pasa con Cosmos DB? solo un modo de operación, pero aún lo consideraría nativo ".

Este criterio es importante, pero no el único, y dar sentido a un mercado incipiente que descompensa todo no es algo que se pueda hacer en el contexto de un artículo. Puede esperar un trabajo más extenso de esto en un futuro cercano, pero si todavía desea una versión de 10 minutos del Paisaje de base de datos de grafos, puede ver la escrita por Yu Xu, CEO de TigerGraph, además de nuestra cobertura anterior.

TigerGraph es una de las bases de datos de grafos que cubrimos en 2017, junto con AllegroGraph, GraphDB y Neo4j. GraphDB y Neo4j también figuran entre las bases de datos de grafos que oficialmente se ofrecen en AWS, aunque eso no significa que no se puedan implementar otras bases de datos de grafos en AWS.

Ese es el escenario habitual de cooperación que los proveedores y vendedores de la nube han aprendido a vivir, aunque en este caso complicado puede ser más complicado de lo habitual.

Las otras 2 bases de datos de grafos que reciben el visto bueno oficial de AWS son JanusGraph y OrientDB. JanusGraph solía ser Titan, y después de que la empresa matriz de Titan, Aurelius, fuera adquirida por DataStax Titan, se bifurcó como JanusGraph y ahora cuenta con el respaldo de IBM, también proveedor de la nube. OrientDB también fue adquirido recientemente por el proveedor de software empresarial CallidusCloud.

Desempacando AWS Neptune

En cuanto a AWS Neptune (aún en versión beta privada), aunque no esperamos ver demasiada información en términos de funcionamiento interno, podemos notar un par de cosas.

Como Tony Baer escribió recientemente, el almacenamiento en la nube se convierte en el lago de almacenamiento de facto. En AWS, las personas usan S3, y hasta ahora tienen instalaciones de consulta SQL para ello. ¿Podría AWS haber construido Neptune directamente en S3, y eso tendría sentido?

Realmente no lo sabemos, pero probablemente no. AWS habla de la capacidad de realizar copias de seguridad continuas de Neptune a S3, lo cual es bastante revelador. Si S3 era el almacenamiento utilizado para Neptune, las copias de seguridad S3 no tendrían sentido ya que los datos ya estarían en S3, y todo lo que se necesitaría sería habilitar la replicación. Pero hay otra pista allí.

AWS está vendiendo la opción de usar JanusGraph con Amazon DynamoDB como su back-end de almacenamiento. DynamoDB es una base de datos clave-valor, y una metáfora y estructura de clave-valor, se presta bien para graficar. De hecho, es lo que Titan y ahora JanusGraph están utilizando como una tienda de back-end para sus grafos, por lo que tiene sentido para AWS haber construido Neptune en DynamoDB.

Para volver al grafo del colaborador de Big on Data y citar a Andrew Brust, "en el mundo de la base de datos, todo se reduce a pares clave-valor. Por lo tanto, si tienes una base de datos como construcción central, tienes el potencial de hacer casi cualquier cosa que desee. Aunque, de fábrica, es posible que no pueda hacer mucho ".

Entonces, ¿podría ser que AWS Neptune realmente es una capa elaborada sobre DynamoDB que agrega una metáfora gráfica y una API a una tienda clave de valor subyacente? Eso puede sonar demasiado simplificador, pero parece plausible.



Hacer que las bases de datos de grafos escalen significa ir distribuidas, y hay muchos problemas allí. Imagen: ArangoDB

Se podría argumentar que Titan y sus descendientes, JanusGraph y DSE Graph, son de naturaleza similar, y AWS hace hincapié en cómo la arquitectura enchufable de Titan hace que sea fácil comenzar a usar DynamoDB sin cambiar las aplicaciones. ¿Pero qué tan eficiente es eso?

Realmente no tenemos indicadores del rendimiento de AWS Neptune en este momento, aunque como cabría esperar, AWS se muestra lírico al respecto y otros proveedores señalan rápidamente todos los detalles de hacer que los grafos distribuidos funcionen y que AWS podría equivocarse.

Sin embargo, el hecho es que AWS no está realmente en el negocio de equivocarse, y su gran gravedad lo convierte en una fuerza a tener en cuenta. Esto es lo que dice el CEO de Neo4j, la base de datos de grafos líder en adopción de mercado actualmente. Otros vendedores de grafos también están reconociendo el hecho de que su mercado parece que va a crecer de manera significativa, y preparándose para luchar frente a una mayor competencia.

Estándares, muchos o ninguno

Sin embargo, lo que sí sabemos sobre AWS Neptune, que nos lleva al segundo punto importante (estándares) es este: Neptune admite los populares lenguajes de consulta de grafos Apache TinkerPop Gremlin y SPARQL de W3C, lo que permite a los usuarios crear fácilmente consultas que navegan de manera eficiente altamente conectadas conjuntos de datos.

En un mundo que parece carecer del equivalente de lo que SQL es en el mundo relacional, un estándar de facto para las consultas, esto es bastante importante. Significa que Neptune ofrece la máxima flexibilidad para sus usuarios, y es una acción inteligente y pragmática de AWS.

En el grafo, existen modelos de competencia y lenguajes de consulta, y la posibilidad de consultar Neptune utilizando dos de los más populares amplía la base de usuarios potenciales y los casos de uso de Neptune. AWS no está solo en esto, pero ser elocuente y facilitar su uso podría marcar la diferencia.

Ya hemos cubierto SPARQL y algunas de las cosas para las que se puede usar. En la siguiente parte de esta mini serie en grafo, nos centraremos en Apache TinkerPop, su lenguaje de consulta llamado Gremlin, sus características y el papel que puede desempeñar en el mundo de las bases de datos de grafos y más allá.