Neo4j Una guía rápida de Devniel.com Parte I

Transcripción

1 Neo4j Una guía rápida de Devniel.com Parte I Por Daniel Flores Braph 1

2 Esta guía se base principalmente en el libro Graph Databases y otras fuentes presentadas en la bibliografía. 2

3 Introducción La teoría de grafos fue creada y promovida por Euler en el siglo dieciocho, por más de trescientos años se ha investigado y mejorado de forma activa por matemáticos, sociólogos, antropólogos, y otras demás ciencias que han encontrado en los grafos una amplia aplicabilidad a través de una serie de diversos problemas matemáticos. Hoy en día, los grafos están siendo adoptados con éxito por los gigantes de Internet (Google, Facebook, Twitter) a través de su explotación en las tecnologías de la información con un nuevo paradigma de bases de datos orientadas a grafos. Una de las mayores empresas de logística en el mundo utiliza, en tiempo real, una base de datos orientada a grafos para la distribución de diferentes paquetes de envío acorde a su modelo de cadena de suministro, una empresa de citas en línea ha reemplazado toda su infraestructura lógica hacia tecnologías orientadas a grafos, un sistema de empleos por internet ha utilizado bases de datos orientadas a grafos para realizar recomendaciones puntuales a sus usuarios con un incremento de la experiencia del usuario bastante aceptable. Es así que las bases de datos orientadas a grafos ahora se utilizan en industrias tan diversas como la salud, tecnologías geoespaciales, redes sociales, comercio minorista, industrias del petróleo y gas, medios de comunicación y redes, juegos y demás, incluso se prevé acelerar su ritmo hacia otras áreas con un crecimiento del trescientos por ciento de utilización en diversas compañías desde enero del año pasado (2013). Y a qué se debe el éxito de este nuevo paradigma?. Puesto que los datos al estar altamente relacionados y requerir un análisis exhaustivo necesitan de una mejor comprensión de las relaciones entre sus entidades, las bases de datos orientadas a grafos ocupan el primer lugar en cuanto a la mejor manera de representar y consultar datos conectados entre sí. Datos conectados cuya interpretación y valor nos obliga primero a entender las formas en que sus elementos constitutivos se relacionan, entendimiento que además se facilita visual y lógicamente gracias a las bases de datos orientadas a grafos. Las tecnologías de administración de bases de datos orientadas a grafos buscan mantener todas las características probadas de las base de datos relacionales (transacciones, ACID, triggers, etc) pero con el uso de un modelo de datos propicio para el siglo veintiuno: grafos. 3

4 Qué es un grafo? Formalmente, un grafo es sólo una colección de vértices y aristas - o, en lenguaje un poco práctico, un conjunto de nodos y relaciones que los unen. Los grafos, dentro de las tecnologías de la información, representan entidades u objetos como nodos y las formas en que las entidades están relacionadas con el mundo o entre sí, a través de relaciones. Con esa perspectiva general, la estructura expresiva nos permite modelar todo tipo de escenarios, desde la construcción de un automóvil, a un sistema de rutas del servicio metropolitano de transporte, pasando por modelos de cadena de suministro o la procedencia de los productos alimenticios e ingredientes de tu plato favorito, hasta llegar incluso a modelar el historial médico de poblaciones enteras o por qué no la estructura del ADN. En cuanto al tratamiento de la información a través de estas estructuras de datos, podemos clasificar las tecnologías orientadas a grafos en: - Tecnologías usadas principalmente para persistencia transaccional online de datos distribuidos en grafos, comúnmente accedidos en tiempo real desde una aplicación. Estas tecnologías son llamadas bases de datos orientadas a grafos, equivalentes a sistemas OLTP. - Tecnologías usadas para el análisis offline de grafos, típicamente realizados en un proceso batch. También denominadas motores de análisis de grafos o graph compute engines. Caben dentro de la categoría de sistemas OLAP o de minería de datos. Mientras que, en cuanto al modelado de la información previo a su tratamiento y dependiendo de las necesidades del negocio y del desarrollador, podemos clasificar los modelos de tecnologías basadas en grafos en las siguientes: - Grafo de propiedades - RDF (Resource Description Framework). - Hipergrafos. 4

5 Bases de datos orientadas a grafos Un sistema de gestión de base de datos orientada a grafos (de ahora en adelante, una base de datos orientada a grafos) es un sistema de gestión de base de datos en línea que basa su modelo de distribución de datos en grafos consolidando a las relaciones como un elemento crucial y concreto de su estructura, además cuenta con métodos CRUD que expone el modelo de datos del grafo. Las bases de datos orientadas a grafos se despliegan generalmente para el uso en sistemas transaccionales (OLTP). En consecuencia, normalmente son optimizados para el rendimiento transaccional, y fabricados con integridad transaccional y disponibilidad operacional. Hay dos propiedades de las bases de datos orientadas a grafos que usted debe considerar al investigar las tecnologías de base de datos orientadas a grafos. - El almacenamiento de los datos o Algunas bases de datos de gráficos utilizan el almacenamiento de grafos en forma nativa que se ha optimizado y diseñado para el almacenamiento y la gestión de los mismos. Sin embargo, no todas las tecnologías de bases de datos orientadas a grafos utilizan el almacenamiento nativo de grafos. Algunos serializan los datos de un modelo de grafos en una base de datos relacional, una base de datos orientada a objetos, o algún otro almacén de datos de uso general. - El motor de procesamiento o o Las bases de datos orientadas a grafos requieren de un procesamiento de nodos adyacentes sin la necesidad de índices intermedios (index-free adjacency), lo que significa que los nodos deben estar conectados físicamente "punto" a punto en la base de datos. Cualquier base de datos que desde la perspectiva del usuario se comporta como una base de datos orientada a grafos (por ejemplo, expone métodos CRUD) se califica como tal. Sin embargo, es clave la inclusión de las adyacencias libres de índices (index-free adjacency) ya que representan la ventaja frente otros tipos de base de datos. 5

6 El beneficio del almacenamiento nativo de grafos es que la infraestructura de distribución de los datos ha sido diseñada y construida especialmente para un buen rendimiento y una alta escalabilidad en el tratamiento de modelos de grafos. El beneficio del almacenamiento no nativo de grafos, en cambio, es que depende por lo general en una infraestructura con muchos años de experiencia (como MySQL, PostgreSQL u Oracle), cuyas características de producción se conocen bien por los equipos de administración. Mientras tanto, el procesamiento nativo de grafos a través de la adyacencia libre de índices beneficia el rendimiento de consulta de los grafos ya que permite el recorrido de los nodos a través de sus relacionales siempre y cuando a costa de consultas con cierta complejidad o de alto consumo de memoria. Relaciones, elementos concretos Las relaciones son estructuras de datos de primera clase del modelo de datos orientados a grafos, a diferencia de otros sistemas de gestión de bases de datos, que nos obligan a inferir conexiones entre las entidades mediante la utilización de propiedades adicionales tales como claves foráneas, o mediante el procesamiento en un nivel superior con algoritmos Map-Reduce. Al reunir las simples abstracciones de los nodos y las relaciones en las estructuras conectadas, las bases de datos orientadas a grafos nos permiten construir modelos sofisticados de forma arbitraria que se asignan estrechamente al dominio del caso de negocio o problema. Los modelos resultantes son más simples y más expresivas que las producidas utilizando bases de datos relacionales y NoSQL. Motores de procesamiento de grafos Un motor de procesamiento de grafos es una tecnología que permite a los algoritmos basados en grafos, como el de Dijkstra o de caminos mínimos, ejecutarse sobre una gran cantidad de datos independientemente del soporte informático que los almacena. Los GCE están diseñados para hacer cosas como identificar patrones, grupos o clústers en los datos y responder a preguntas tales como, " cuántas relaciones, en promedio, tiene un usuario dentro de la red social?". Debido al énfasis en consultas globales, los motores de procesamiento de grafos son normalmente optimizados para el tratamiento de grandes cantidades de información 6

7 particularmente en lotes, y en ese sentido son similares a otras tecnologías de análisis de datos, como la minería de datos y OLAP, que son muy conocidas en el mundo relacional. Mientras que algunos motores de procesamiento de grafos incluyen una capa de almacenamiento nativa de grafos es decir bases de datos orientadas a grafos como Neo4j, otros (y posiblemente más) se refieren a sí mismos estrictamente como habilitados para solo el procesamiento de datos que provienen de fuente externa, y la devolución de los resultados tales como : - Cassovary - Pegasus - Giraph - Pregel Ventajas de una base de datos orientada a grafos Existe un conjunto de casos de uso cuyos patrones de datos presentan una mejora de rendimiento en consultas cuando se implementan en un modelo orientado a grafos, y cuya latencia es mucho menor en comparación con el procesamiento por lotes de las funciones colectivas de otros tipos de base de datos. A parte de la ventaja de rendimiento, las bases de datos orientadas a grafos ofrecen un modelo de datos muy flexible que se adapta al constante cambio de requerimientos o entregas iterativas que concuerdan con las prácticas actuales de desarrollo de software ágil. Eficiencia y eficacia Existe un aumento transparente o evidenciable de rendimiento cuando se trata de consultas de datos relacionados frente a bases de datos relacionales y soluciones NoSQL. A diferencia de las bases de datos relacionales, donde el rendimiento de consultas a través de operaciones JOIN se deteriora a medida que el conjunto de datos se hace más grande, con una base de datos orientada a grafos el rendimiento 7

8 tiende a permanecer relativamente constante, lineal o directamente proporcional a la magnitud del conjunto de datos. Esto es porque las consultas están localizadas en un segmento del grafo que empieza su recorrido a partir de un nodo y continúa a través de sus vértices sin necesidad de recorrer toda una tabla o lista de índices tal y como lo hacen otras bases de datos. Como resultado, el tiempo de ejecución para cada consulta es proporcional solo al tamaño de la parte del grafo recorrido para satisfacer esa consulta. Flexibilidad Como desarrolladores e ingenieros de datos queremos relacionar los datos como los requeridos por el dominio de algún problema o situación, permitiendo así que la estructura y el modelo de datos que surjan sea paralela a nuestra creciente comprensión del espacio del problema, en lugar de ser inferida totalmente por adelantado, cuando sabemos menos acerca de la forma reales y las complejidades de los datos representativos de la situación atendida. Las bases de datos orientadas a grafos abordan directamente esta necesidad, puesto que permite un modelado iterativo de los datos. El modelo de datos orientado a grafos se expresa y se acomoda a las necesidades del negocio de una manera que permite moverse a la velocidad de la situación. Los grafos son naturalmente aditivos, lo que significa que podemos añadir nuevos tipos de relaciones, nuevos nodos, e incluso nuevos subgrafos a una estructura existente sin alterar las consultas existentes y la funcionalidad de la aplicación. Esto permite reducir las implicaciones que contribuyen a la productividad del desarrollador y reducen los riesgos del proyecto. Debido a la flexibilidad del modelo de grafos, no se tiene que modelar el dominio del problema en detalle antes de tiempo - una práctica que comúnmente se hace pero con temor frente a los constantes cambios de requerimientos del cliente. La naturaleza aditiva de los grafos también significa que tienden a realizar menos migraciones, lo que reduce gastos de mantenimiento y riesgo. Agilidad Queremos ser capaces de evolucionar nuestro modelo de datos, a medida que cambia nuestra aplicación, usando una tecnología en línea con las prácticas ágiles de entrega incremental e iterativa de software de hoy. Las bases de datos orientadas a grafos nos equipan para llevar a cabo el desarrollo y mantenimiento de sistemas de 8

9 sin un esquema rígido de datos. En particular, la naturaleza sin esquema del modelo de datos orientado a grafos, junto con el carácter testable de la interfaz de programación de aplicaciones (API) de una base de datos orientada a grafos y el lenguaje de consulta respectivo, hace posible la evolución correcta de una aplicación de una manera controlada y segura. Al mismo tiempo, precisamente porque son libres de esquema, las bases de datos orientadas a grafos no tienen el tipo de mecanismo de restricción de datos orientado a esquemas con el que estamos familiarizados en el mundo relacional. Lo que no significa un riesgo, sino que llama a una especie de libertad que permite hacer mucho más visible y viable la administración de los datos. Las restricciones se aplican comúnmente en forma programática, en un nivel superior al de las consultas, mediante la prueba de conducir el modelo de datos y las consultas de acuerdo a determinadas reglas de negocio de las cuales depende el grafo. Las bases de datos relacionales cuentan con relaciones abstractas Las relaciones entre diferentes entidades existen en las bases de datos relacionales pero de manera indirecta a través de tablas relacionales. Para agregar significado a una relación se necesita eliminar ambigüedades y calificarlas por su grado o importancia, las bases de datos relacionales no aplican nativamente ninguna de estas características. Peor aún, cuando los datos incrementan, y la estructura general de la base de datos se vuelve más compleja y menos uniforme, el modelo relacional es recargado con largas tablas relacionales (join tables), tablas con filas escasamente pobladas y por lo tanto varias columnas con valores nulos. Es así, que el crecimiento de conexión entre entidades se traslada en el modelo relacional en el incremento de operaciones join, las cuales impiden un buen performance y hacen dificultoso la modificación de una base de datos existente en respuesta a un cambio en las necesidades del negocio. 9

10 Las aplicaciones ejercen una influencia clave sobre el diseño del esquema de datos, haciendo unas consultas fáciles, mientras dificulta algunas otras. - Las tablas relacionales agregan cierta complejidad, mezclan datos del negocio con metadatos concernientes a claves foráneas. - Las restricciones de claves foráneas incrementan la labor de desarrollo y mantenimiento de la base de datos. - Las sparse tables con valores nulos requieren una revisión especial en código, a pesar de la presencia de un esquema. - A veces, se necesita de joins demasiado complejos solo para saber qué ha comprado un cliente. - Las consultas recíprocas son aún más costosas : Qué productos compró un cliente? es relativamente barata comparada a Qué clientes compraron este producto?, la cual es la base de los sistemas de recomendación. Se puede introducir un índice, pero incluso con un índice, las preguntas recursivas como 10

11 Qué clientes compraron este producto que también hayan comprado el otro producto? rápidamente se convierten en más complejas a medida que el grado de reciprocidad aumenta Las bases de datos relacionales se rigen con dominios altamente conectados. Para entender el costo de realizar consultas conectadas en una base de datos relacional, vamos a ver un simple ejemplo y no tan simples consultas en el dominio de una red social. Preguntando por Quiénes son los amigos de Bob? Es fácil, como se muestra en la siguiente consulta: SELECT p1.person FROM Person p1 JOIN PersonFriend ON PersonFriend.FriendID = p1.id JOIN Person p2 ON PersonFriend.PersonID = p2.id WHERE p2.person = 'Bob' 11

12 Basado en nuestros datos de ejemplo, la respuesta sería Alice y Zach. Esto no es particularmente costoso o complejo, ya que restringe el número de filas en evaluación usando el filtro WHERE Person.person= Bob. Friendship no es siempre una relación recíproca, por eso en el siguiente ejemplo, nosotros preguntamos: Quién es amigo de Bob? SELECT p1.person FROM Person p1 JOIN PersonFriend ON PersonFriend.PersonID = p1.id JOIN Person p2 ON PersonFriend.FriendID = p2.id WHERE p2.person = 'Bob' La respuesta a esta consulta sería Alice; lamentablemente Zach no considera a Bob como amigo. Esta consulta recíproca entre entidades es aún fácil de implementar, pero del lado de la base de datos es más costosa ya que la base de datos ahora tienen que considerar todas las filas en la tabla PersonFriend. Nosotros podemos agregar un índice, pero esto aún implica una costosa capa de indirección. Preguntas como Quién es el amigo de mis amigos? se vuelven más costosas con joins recursivos, además de hacer la consulta sintácticamente y computacionalmente más complejas. SELECT p1.person AS PERSON, p2.person AS FRIEND_OF_FRIEND FROM PersonFriend pf1 JOIN Person p1 ON pf1.personid = p1.id JOIN PersonFriend pf2 ON pf2.personid = pf1.friendid JOIN Person p2 ON pf2.friendid = p2.id WHERE p1.person = 'Alice' AND pf2.friendid <> p1.id Esta consulta es computacionalmente más compleja, incluso aunque está sola trate con los amigos de los amigos de Alice, y no tratan más profundamente en la red social de Alice. Las cosas se vuelven más complejas y más caras a medida del grado de relación entre los objetos. Pero preguntas como quién es el amigo, de mis amigos de mis amigos? hacen que las consultas sean más costosas y difíciles de entender. 12

13 El desarrollador se ajusta al esquema de la base de datos con tablas con columnas de valores nulos y código de consulta que captura las excepciones, peor aun cuando se trata de migraciones de un esquema a otro por causas de cambios de la necesidad del negocio. Las bases de datos NoSQL también carecen de relaciones La mayoría de bases de datos NoSQL almacenan conjuntos de documentos, valores o columnas de datos que no guardan relación alguna. Una estrategia muy conocida es la de agregar referencias hacia otros objetos dentro de un campo de cualquier entidad algo parecido a una clave foránea sin embargo, esto necesita de estrategias de relación a través de funciones colectivas en el nivel de aplicación que agrega costo a las operaciones. Con estas referencias, percibimos una relación que a nivel de la base de datos no existe y que por lo tanto para volverlas realidad debemos agregar una lógica adicional a nivel de aplicación que inclusive debe preocuparse por cualquier actualización o eliminación de objetos relacionados para evitar referencias erróneas que puede afectar la calidad de los datos y el desempeño de las consultas, una función propia de las bases de datos relacionales, lógica que muchas veces ya viene incluida con los 13

14 controladores de las diferentes bases de datos NoSQL, dándonos esa falsa percepción de relación entre objetos. Algunas bases de datos no relacionales agregan nativamente capacidades de relación entre entidades a través de metadatos de enlace que apuntan de un valor almacenado hacia otro, permitiendo capturar estas relaciones en las consultas a través de técnicas map-reduce. La técnica MAP-REDUCE consiste en dos fases. MAP, donde la gran cantidad de datos se filtra en pequeñas porciones sobre las cuales se establecerá una determinada lógica. REDUCE, donde el resultado de la lógica aplicada a estos segmentos de datos es coleccionada en un resultado simple Otro punto importante sobre este esquema es que las referencias nativas entre objetos no nos indican el sentido de la relación restringiendo así la capacidad de explotar la base de datos frente a distintas preguntas, que solo podría hacerse agregando más propiedades a las entidades y por lo tanto reduciendo la calidad de la base de datos (se incrementa la latencia de escritura al insertar más bytes de los necesarios y la utilización de discos para almacenar metadatos adicionales) o a través de medios externos, por ejemplo exportando los datos a otro engine como Hadoop para minar los datos. 14

15 Por otro lado el recorrido de estos enlaces o referencias continúan siendo caras por el hecho de requerir la revisión constante de índices, esto debido a que se recorre toda la colección de datos en busca del objeto referenciado, no hay un conocimiento de localidad de la entidad tal y como la tienen las bases de datos orientadas a grafos con la adyacencia de entidades libre de índices a través de relaciones concretas y no abstractas. Las bases de datos orientadas a grafos acogen relaciones Las relaciones en una base de datos forman rutas, así como los vértices en un grafo, es así que la consulta o el recorrido de un grafo implica el seguimiento de estas rutas, a diferencia de una base de datos relacional no se hace un recorrido de toda los datos, es por eso que las operaciones sobre esta base de datos están alineados exactamente al despliegue de las entidades y sus relaciones haciéndolas muy efectivas y eficaces. En el libro Neo4j in Action se hace una comparación entre la ejecución de consultas en una base de datos relacional frente a una base de datos orientadas a grafos, el objetivo es obtener los amigos de los amigos de una determinada persona registrada en la base de datos con una profundidad de hasta 5 grados (amigos de amigos de amigos de amigos) evidenciando la rapidez de Neo4j como representante de las bases de datos orientadas a grafos. Grados Tiempo de ejecución en un RDBMS Tiempo de ejecución en Neo4j Registros retornados ~ ~ ~ Desmesurado ~ Como se puede apreciar en las cifras resultantes, el desempeño de una base de datos relacional decae a medida que la manipulación de elementos conectados se hace más compleja, esto debido a la revisión constante de índices implicados. 15

16 Bibliografía - Robinson, I., Webber, J., & Efrem, E. (2013). Graph databases. Sebastopol, Calif.: O Reilly Media Shades of Graph: How Graph Databases Are Transforming Online Dating. (n.d.). Forbes. Retrieved February 16, 2014, from - Anatomy of an SQL Index. (n.d.). Retrieved February 18, 2014, from Index-Luke.com/sql/anatomy - Neubauer, P. (n.d.). Neo4j Blog: Demining the Join Bomb with graph queries. Retrieved from - OLTP vs. OLAP. (n.d.). Retrieved February 16, 2014, from - Partner, J. (2013). Neo4j in action. [S.l.]: O Reilly Media. 16