Graph databases, a little connected tour
•
2 recomendaciones•733 vistas
Este documento proporciona una introducción a las bases de datos de grafos. Explica el origen de las bases de datos de grafos a través del problema de los puentes de Königsberg. Define los componentes básicos de un grafo como nodos, relaciones y propiedades. Describe las ventajas de las bases de datos de grafos sobre las relacionales como su capacidad para modelar datos conectados de forma natural y su mejor escalabilidad. Finalmente, presenta ejemplos de uso como redes sociales y sistemas de recomendación.
Denunciar
Compartir
Presentaciones relacionadas
Graph databases, a little connected tour
- 1. Graph Databases A little connected tour ! @fcofdezc
- 2. El origen
- 4. Dado el mapa de Königsberg, con el río Pregolya dividiendo el plano en cuatro regiones distintas, que están unidas a través de los siete puentes, ¿es posible dar un paseo comenzando desde cualquiera de estas regiones, pasando por todos los puentes, recorriendo sólo una vez cada uno, y regresando al mismo punto de partida?
- 5. = (V, E) ElG origen
- 6. ¿Qué es?
- 9. Escrita en java ACID Interfaz REST Cypher
- 10. ¿Por qué NOSQL?
- 12. Ventajas de BD Relacionales Concurrencia Persistencia Persistencia Integración Estándar
- 13. Ventajas de BD Relacionales Concurrencia Persistencia Concurrencia Integración Estándar
- 14. Ventajas de BD Relacionales Concurrencia Persistencia Integración Integración Estándar
- 15. Ventajas de BD Relacionales Concurrencia Persistencia Estándar Integración Estándar
- 18. class Client < ActiveRecord::Base has_one :address has_many :orders has_and_belongs_to_many :roles end
- 19. DesVentajas de BD Relacionales Fricción! Interoperabilidad Adaptación al cambio Interoperabilidad Escalabilidad No está destinada para ciertos escenarios
- 21. !Escalabilidad
- 22. MySQL vs Neo4j Profundidad Tiempo MySQL(s) Tiempo Neo4j (s) Nº Resultados 2 3 0.016 30.267 0.01 0.168 ~2500 ~110,000 4 1543.505 1.359 ~600,000 5 No Acaba 2.132 ~800,000 * Neo4J in Action
- 23. El enfoque tradicional en el contexto de datos conectados es artificial
- 24. Podemos trasladar el modelo del dominio que estamos tratando de forma natural
- 26. Casos de uso
- 28. Problemas Geoespaciales Detección de fraude Gestión de permisos Gestión de redes
- 29. Cypher Lenguaje declarativo ASCII oriented Pattern matching
- 37. Cypher MATCH (a)-[t:TOCA_EN]—>(g), (g)<-[:ETIQUETADO]-(e) RETURN a.nombre, t.fecha, e.nombre;
- 38. Cypher START c=node:node_auto_index(nombre=‘clapton’) MATCH (c)-[t:TOCA_EN]—>(g), (g)<-[:ETIQUETADO]-(e) RETURN c.nombre, t.fecha, e.nombre;
- 39. Cypher START c=node:node_auto_index(nombre=‘clapton’) e=node:node_auto_index(nombre=‘blues’) MATCH (c)-[t:TOCA_EN]—>(g), (g)<-[:ETIQUETADO]-(e) RETURN c.nombre, e.nombre ORDER BY t.fecha
- 40. Cypher START c=node:node_auto_index(nombre=‘clapton’) e=node:node_auto_index(nombre=‘blues’) MATCH (c)-[t:TOCA_EN | PRODUCE]—>(g), (g)<-[:ETIQUETADO]-(e) WHERE t.fecha > 1968 RETURN c.nombre, e.nombre
- 42. START startNode=node:node_auto_index(name = ‘Sol'), endNode=node:node_auto_index(name = ‘Cuzco') MATCH p = (startNode)-[rels:CONNECTED_TO]->(endNode) RETURN p AS shortestPath, reduce(weight=0, r in rels: weight + r.weight) as tWeight ORDER BY tWeight ASC LIMIT 1
- 44. Red social de cine
- 45. Red social de cine Usuarios puntúan películas Personas actúan en películas Personas dirigen películas Usuarios siguen a otros usuarios
- 46. Red social de cine ¿Cómo lo modelamos?
- 47. Red social de cine Sigue User User Puntúa {nota} Actua en Film Actor Dirige Director
- 48. Red social de cine START fran=node:Persona(name='Fran'), film=node:Peliculas(title=‘Pulp Fiction') MATCH fran-[or:PUNTUA]->film<-[:PUNTUA]-otro_user-[r:PUNTUA]->otras_pelis RETURN distinct otras_pelis.title;
- 49. Red social de cine Puntúa {nota} Puntúa {nota} Film Film User 1 Fran User 2 Puntúa {nota} Film PF Puntúa {nota} Puntúa {nota}
- 50. Red social de cine START fran=node:Persona(name='Fran'), film=node:Peliculas(title=‘Pulp Fiction') MATCH fran-[or:PUNTUA]->film<-[:PUNTUA]-otro_user-[r:PUNTUA]->otras_pelis WHERE or.stars = r.stars RETURN distinct otras_pelis.title;
- 51. Red social de cine START fran=node:Persona(name='Fran'), film=node:Peliculas(title=‘Pulp Fiction') MATCH fran-[or:PUNTUA]->film<-[:PUNTUA]-otro_user-[r:PUNTUA]->otras_pelis, otro_user-[:SIGUE]-fran WHERE or.stars = r.stars RETURN distinct otras_pelis.title;
- 52. Red social de cine Puntúa {nota} Sigue User 1 Puntúa {nota} Fran Puntúa {nota} Film PF Film
- 53. Red social de cine START tarantino=node:Persona(name='Quentin Tarantino') MATCH tarantino-[:DIRIGE]->peli<-[:ACTUA_EN]-tarantino RETURN movie.title; !
- 54. Red social de cine Actua en Film Actor Dirige Director
- 55. Red social de cine Ahora se deben poder categorizar las películas
- 56. Red social de cine Genero Genero Pertenece_a Pertenece_a SubGenero SubGenero Pertenece_a Pertenece_a Film
- 57. Red social de cine START fran=node:Persona(name='Fran'), film=node:Peliculas(title=‘Pulp Fiction') MATCH fran-[or:PUNTUA]->film<-[:PUNTUA]-otro_user-[r:PUNTUA]->otras_pelis, film-[:PERTENECE:*3]->genero<-[:PERTENECE]-otras_pelis WHERE or.stars = r.stars RETURN distinct otras_pelis.title;
- 58. Instead of just picking a relational database because everyone does, we need to understand the nature of the data we’re storing and how we want to manipulate it. Martin Fowler
- 59. Referencias
- 60. Neo4J as a service http://www.graphenedb.com
- 63. Gracias