¿Cuáles son los casos de uso de bases de datos basadas en gráficos (http://neo4j.org/)? [cerrado]

He usado mucho las bases de datos relacionales y decidí aventurarme con otros tipos disponibles.

Este producto en particular se ve bien y prometedor: http://neo4j.org/

¿Alguien ha usado bases de datos basadas en gráficos? ¿Cuáles son los pros y los contras de una perspectiva de usabilidad?

¿Has utilizado estos en un entorno de producción? ¿Cuál fue el requisito que te impulsó a usarlos?

Utilicé una base de datos gráfica en un trabajo anterior. No estábamos usando neo4j, era una cosa interna construida sobre Berkeley DB, pero era similar. Fue utilizado en la producción (todavía lo es).

La razón por la que utilizamos una base de datos de gráficos fue que los datos que el sistema almacenaba y las operaciones que el sistema estaba haciendo con los datos eran exactamente el punto débil de las bases de datos relacionales y eran exactamente el punto fuerte de las bases de datos de gráficos. El sistema necesitaba almacenar colecciones de objetos que carecen de un esquema fijo y están vinculados entre sí por relaciones. Para razonar sobre los datos, el sistema necesitaba realizar muchas operaciones que serían un par de recorridos en una base de datos de gráficos, pero que serían consultas bastante complejas en SQL.

Las principales ventajas del modelo gráfico fueron el rápido tiempo de desarrollo y la flexibilidad. Podríamos agregar rápidamente una nueva funcionalidad sin afectar las implementaciones existentes. Si un cliente potencial quisiera importar algunos de sus propios datos e injertarlos sobre nuestro modelo, el representante de ventas generalmente podría hacerlo en el sitio. La flexibilidad también ayudó cuando estábamos diseñando una nueva característica, lo que nos evitó tratar de comprimir nuevos datos en un modelo de datos rígido.

Tener una base de datos extraña nos permite construir muchas de nuestras otras tecnologías extrañas, dándonos mucha salsa secreta para distinguir nuestro producto de los de nuestros competidores.

La principal desventaja era que no estábamos utilizando la tecnología de base de datos relacional estándar, lo que puede ser un problema cuando sus clientes son empresariales. Nuestros clientes preguntarían por qué no podríamos simplemente alojar nuestros datos en sus clústeres gigantes de Oracle (nuestros clientes generalmente tenían grandes centros de datos). Uno de los miembros del equipo reescribió la capa de la base de datos para usar Oracle (o PostgreSQL o MySQL), pero fue un poco más lento que el original. Al menos una gran empresa incluso tenía una política exclusiva de Oracle, pero afortunadamente Oracle compró Berkeley DB. También tuvimos que escribir muchas herramientas adicionales; no podíamos usar Crystal Reports, por ejemplo.

La otra desventaja de nuestra base de datos de gráficos es que la construimos nosotros mismos, lo que significa que cuando encontramos un problema (generalmente con escalabilidad) tuvimos que resolverlo nosotros mismos. Si hubiéramos usado una base de datos relacional, el proveedor ya habría resuelto el problema hace diez años.

Si está creando un producto para clientes empresariales y sus datos se ajustan al modelo relacional, use una base de datos relacional si puede. Si su aplicación no se ajusta al modelo relacional pero sí al modelo gráfico, use una base de datos gráfica. Si solo se ajusta a otra cosa, úsala.

Si su aplicación no necesita encajar en la arquitectura blub actual, use una base de datos gráfica, o CouchDB, o BigTable, o lo que sea que se ajuste a su aplicación y cree que es genial. Puede darte una ventaja, y es divertido probar cosas nuevas.

Elija lo que elija, intente no construir el motor de la base de datos usted mismo a menos que realmente le guste construir motores de base de datos.

Llevamos más de un año trabajando con el equipo de Neo y estamos muy contentos. Modelamos artefactos académicos y sus relaciones, lo cual es perfecto para un gráfico db, y ejecutamos algoritmos de recomendación a través de la red.

Si ya está trabajando en Java, creo que modelar usando Neo4j es muy sencillo y tiene el rendimiento más plano / rápido para R / W que cualquier otra solución que probamos.

Para ser honesto, me resulta difícil no pensar en términos de un Gráfico / Red porque es mucho más fácil que diseñar estructuras de tabla enrevesadas para mantener las propiedades y relaciones de los objetos.

Dicho esto, almacenamos cierta información en MySQL simplemente porque es más fácil para el lado comercial ejecutar consultas SQL rápidas. Para realizar las mismas funciones con Neo, necesitaríamos escribir código para el que simplemente no tenemos el ancho de banda en este momento. Sin embargo, tan pronto como lo hagamos, moveré todos esos datos a Neo.

Buena suerte.

Dos puntos:

Primero, en los datos con los que he estado trabajando durante los últimos 5 años en SQL Server, recientemente llegué al muro de escalabilidad con SQL para el tipo de consultas que necesitamos ejecutar (relaciones anidadas ... ya sabes ... gráficos ) He estado jugando con neo4j, y mis tiempos de búsqueda son varios órdenes de magnitud más rápidos cuando necesito este tipo de búsqueda.

En segundo lugar, hasta el punto de que las bases de datos de gráficos están desactualizadas. Mmm no. Al principio, cuando las personas intentaban descubrir cómo almacenar y buscar datos de manera eficiente, crearon y jugaron con modelos de bases de datos de estilo gráfico y de red. Estos fueron diseñados para que el modelo físico reflejara el modelo lógico, por lo que su eficiencia no era tan buena. Este tipo de estructura de datos era bueno para datos semiestructurados, pero no tan bueno para datos densos estructurados. Entonces, este tipo de IBM llamado Codd estaba investigando formas eficientes de organizar y almacenar datos estructurados y se le ocurrió la idea del modelo de base de datos relacional. Y fue bueno, y la gente era feliz.

¿Qué tenemos aquí? Dos herramientas para dos propósitos diferentes. Los modelos de bases de datos de gráficos son muy buenos para representar datos semiestructurados y las relaciones entre entidades (que pueden existir o no). Las bases de datos relacionales son buenas para datos estructurados que tienen un esquema muy estático, y donde las profundidades de unión no son muy profundas. Uno es bueno para un tipo de datos, el otro es bueno para otros tipos de datos.

Para acuñar la frase, no hay Silver Bullet. Es muy miope decir que los modelos de bases de datos gráficas están desactualizados y usar uno da 40 años de progreso. Es como decir que usar C es renunciar a todo el progreso tecnológico que hemos experimentado para obtener cosas como Java y C #. Sin embargo, eso no es cierto. C es una herramienta necesaria para ciertas tareas. Y Java es una herramienta para otras tareas.

He estado usando MySQL durante años para administrar los datos de ingeniería, y funcionó bien, pero uno de los problemas que tuvimos (pero no me di cuenta de que teníamos) fue que siempre tuvimos que planificar el esquema por adelantado. Otro problema que sabíamos que teníamos era asignar los datos a objetos de dominio y viceversa.

Ahora acabamos de comenzar a probar neo4j y parece que nos está resolviendo ambos problemas. La capacidad de agregar diferentes propiedades a cada nodo (y relación) nos ha permitido repensar todo nuestro enfoque de los datos. Es como lenguajes dinámicos versus estáticos (Ruby versus Java), pero para bases de datos. La construcción del modelo de datos en la base de datos se puede hacer de una manera mucho más ágil y dinámica, y eso está simplificando drásticamente nuestro código.

Y dado que el modelo de objetos en el código es generalmente una estructura gráfica, la asignación de la base de datos también es más simple, con menos código y, en consecuencia, menos errores.

Y como una ventaja adicional, nuestro código prototipo inicial para cargar nuestros datos en neo4j en realidad está funcionando más rápido que la versión anterior de MySQL. No tengo números sólidos sobre esto (todavía), pero esa fue una buena característica adicional.

Pero al final del día, la elección probablemente debería basarse principalmente en la naturaleza de su modelo de dominio. ¿Se asigna mejor a tablas o gráficos? Decide haciendo algunos prototipos, carga los datos y juega con ellos. Use neoclipse para ver diferentes vistas de los datos. Una vez que hayas hecho eso, espero que sepas si estás haciendo algo bueno o no.

Estoy construyendo una intranet en mi empresa.

Estoy interesado en comprender cómo cargar datos almacenados en tablas (Oracle, MySQL, SQL Server, Excel, Access, varias listas aleatorias) y cargarlos en Neo4J o en alguna otra base de datos de gráficos. Específicamente, qué sucede cuando los datos comunes se superponen a los datos existentes que ya están en el sistema.

Sí, sé que algunos datos se modelan mejor en RDBMS, pero tengo esta idea que me pica, que cuando necesita superponer varias tablas distintas, el modelo gráfico es mejor que la estructura de la tabla.

Por ejemplo, trabajo en un entorno de fabricación. Estamos trabajando en un proyecto importante y, debido a la complejidad, cada departamento ha creado una hoja de cálculo Excel separada que tiene una jerarquía BOM (Lista de materiales) en una columna a la izquierda y luego varias columnas de notas y controles realizados por individuos quien hizo estas sábanas.

Entonces, uno de los problemas es fusionar todas estas notas en una "vista" para que alguien pueda ver todos los problemas que deben abordarse en cualquier parte en particular.

El segundo problema es que una hoja de cálculo de Excel apesta al representar una lista de materiales jerárquica cuando se usa un componente común en más de un subensamblaje. Esto significa que, si alguien escribe una nota sobre el relé P34 en el subconjunto de encendido, el mismo comentario debe asociarse con los relés P34 utilizados en el subconjunto del controlador del motor. Esto no ocurrirá en la hoja de cálculo de Excel.

Para la intranet de la empresa, quiero poder buscar cualquier cosa fácilmente. Tales como datos relacionados con un número de pieza, una estructura BOM, un número de teléfono, una dirección de correo electrónico, una política o procedimiento de la compañía. Incluso quiero extender esto para administrar los activos de hardware de la computadora y el software instalado.

Imagino que una vez que la red de información comience a poblarse, puede comenzar a realizar recorridos geniales como "Quiero escribir un correo electrónico a todos los que trabajan en el proyecto XYZ". Las personas se habrán asociado con el proyecto porque serán etiquetadas como creando y modificando los datos dentro del proyecto XYZ. Entonces, al usar el proyecto XYZ como clave de búsqueda, se creará un gran conjunto con todo lo relacionado con el proyecto XYZ. Incluyendo enlaces a personas que construyeron el proyecto XYZ. Los enlaces de personas se conectarán a sus direcciones de correo electrónico. Entonces, por su participación en el proyecto XYZ, se incluirán en mi correo electrónico. Esto está en marcado contraste con algunas secretarias que intentan mantener una lista de personas que trabajan en el proyecto. Generamos muchas listas. Pasamos mucho tiempo manteniendo listas y asegurándonos de que estén actualizadas.

Otro recorrido interesante podría reportar todas las computadoras que tienen un cierto software instalado, por versión. Ese informe podría usarse para generar tareas para eliminar copias adicionales de software antiguo y para actualizar a las personas que necesitan tener la última copia. También sería útil para el seguimiento de licencias.

Aquí hay un buen artículo que habla sobre las necesidades que cubren las bases de datos no relacionales: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php

Hace un buen trabajo al señalar (aparte del nombre) que las bases de datos relacionales no son defectuosas o incorrectas, es solo que en estos días la gente está comenzando a procesar más y más datos en software y sitios web convencionales, y que las bases de datos relacionales no escalarán para estas necesidades

puede llegar un poco tarde, pero hay un número creciente de proyectos que usan Neo4j, los más conocidos que se enumeran en Neo4j . También NeoTechnology, la compañía detrás de Neo4j, tiene algunas referencias en la página de sus clientes.

_{Nota: soy parte del equipo Neo4j}