modelado - arquitectura del sgbd postgresql
La mejor manera de modelar datos gráficos en postgresql (4)
Creo que la pregunta es demasiado vaga y amplia para dar una respuesta precisa ...
Sin embargo, en esencia, existen algunas técnicas para consultar eficientemente datos de gráficos dentro de una base de datos SQL, que se aplican a escenarios altamente especializados. Podría optar por mantener un índice GRIPP, por ejemplo, si sus intereses se centran en encontrar las rutas más cortas. (Básicamente funciona un poco como un índice de árbol pre-ordenado, aplicado a gráficos). Por lo que yo sé, ninguna de estas técnicas está estandarizada todavía.
Con eso dicho, y viendo su comentario que menciona las redes sociales, lo más probable es que cada uno de ellos sea excesivo. Si su interés radica principalmente en obtener datos relacionados con los amigos de un usuario, o en algo equivalente en el sentido de que se trate de consultar el vecindario de un nodo, la cantidad de nodos que deberá atravesar en uniones es tan pequeña que no hay necesidad de hacerlo. herramientas especializadas, estructuras de datos, etc .: simplemente use CTE recursivos.
http://www.postgresql.org/docs/current/static/queries-with.html
Para obtener un rendimiento óptimo al usar este último, cambie la cantidad de condiciones dentro de la parte with (...) de la consulta, para eliminar los nodos antes de tiempo.
¿Cómo se podría hacer para almacenar y consultar gráficos dispersos dirigidos o no dirigidos en Postgresql? Hay algo como pggraph , pero eso todavía está en la etapa de planificación.
Me doy cuenta de que las bases de datos de gráficos dedicadas como Neo4J son las más adecuadas para esto. Sin embargo, hay una forma de implementar el mismo en Postgresql, mediante el uso de una extensión o un tipo de datos, lo que evitaría agregar otro motor de base de datos.
Dado que la pregunta es genérica, agregaría una solución que pueda funcionar para gráficos en su mayoría planos como redes de calles, PostgreSQL ofrece una solución excelente a través de la topology Postgis. La topología de Postgis almacena geometrías como bordes, nodos y caras y sus relaciones relativas. Esto significa que, desde la geometría de una red de calles, puede seleccionar los bordes y sus nodos de inicio y finalización y, a partir de esto, construir fácilmente un gráfico en el motor de procesamiento que elija (networkx o graph-tool para Pyhton son ejemplos).
Sin embargo, como dije, la topología de Postgresql / Postgis funciona cuando queremos estudiar geometrías como redes de calles desde la perspectiva del análisis de gráficos.
En este punto, recomendaría experimentar con AgensGraph, una distribución multimodelo prometedora de PostgreSQL que ofrece bases de datos de gráficos de primera clase y consultas tanto de SQL como de Cypher. Tenga en cuenta que es un servidor completo, y no una extensión como PostGIS, aunque se le pueden agregar extensiones PostgreSQL.
Use PostgreSQL para el almacenamiento subyacente y use networkX o iGraph a través de PL / Python para el motor de procesamiento.
En su libro " Graph Databases ", Ian Robinson, Jim Webber y Emil Eifrem hacen una distinción entre el almacenamiento subyacente y el motor de procesamiento. Si observa la respuesta que seguí en un problema reciente (vea here ), verá que estoy usando PostgreSQL para el almacenamiento subyacente y networkX como el motor de procesamiento. La ganancia de rendimiento en relación con mi solución original fue enorme (y similar a las descritas en el libro "Bases de datos de gráficos") y su implementación fue muy fácil.