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

Question

He usado Relational DB's mucho y decidí aventurarme en otros tipos disponibles.

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

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

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

Answer 1

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 producción (todavía lo es).

La razón por la que usamos una base de datos de gráficos fue que los datos almacenados por el sistema y las operaciones que el sistema estaba realizando 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 necesario para 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 gráfica, pero eso sería consultas bastante complejas en SQL.

Las principales ventajas del modelo gráfico fueron el rápido desarrollo y la flexibilidad. Podríamos agregar rápidamente nuevas funcionalidades sin afectar las implementaciones existentes. Si un cliente potencial deseara importar algunos de sus propios datos e incrustarlos en nuestro modelo, el representante de ventas generalmente puede hacerlo en el sitio. La flexibilidad también nos ayudó cuando diseñamos una nueva función, lo que nos impide tratar de incluir datos nuevos 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 usando la tecnología de base de datos relacional estándar, lo que puede ser un problema cuando sus clientes son emprendedores. Nuestros clientes preguntaban por qué no podíamos simplemente alojar nuestros datos en sus clústeres de Oracle gigantes (nuestros clientes generalmente tenían grandes centros de datos). Uno de los miembros del equipo realmente reescribió la capa de la base de datos para usar Oracle (o PostgreSQL o MySQL), pero era un poco más lenta que la original. Al menos una gran empresa 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 era 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 encajan en el 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, usa eso.

Si su aplicación no necesita encajar en la arquitectura de 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 usted cree que es genial. Podría darle una ventaja, y es divertido probar cosas nuevas.

Lo que sea que elijas, intenta no construir el motor de base de datos tú mismo, a menos que realmente te guste crear motores de base de datos.

Answer 2

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

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

Para ser honesto, me cuesta mucho no pensar en términos de un Gráfico / Red porque es mucho más fácil que diseñar estructuras de tablas complicadas para mantener las relaciones y propiedades 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, tendríamos que escribir un código que simplemente no tenemos el ancho de banda por el momento. Sin embargo, tan pronto como lo hagamos, moveré todos esos datos a Neo.

Buena suerte.

Answer 3

Dos puntos:

Primero, en los datos con los que he estado trabajando durante los últimos 5 años en SQL Server, recientemente he golpeado el muro de escalabilidad con SQL para el tipo de consultas que necesitamos ejecutar (información sobre relaciones anidadas ... ya sabe. ..graphs). 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.

Segundo, 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 fue tan buena. Este tipo de estructura de datos era buena para datos semiestructurados, pero no tan buena 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 estaba feliz.

¿Qué tenemos aquí? Dos herramientas para dos propósitos diferentes. Los modelos de base de datos de gráficos son muy buenos para representar datos semiestructurados y las relaciones entre entidades (que pueden o no existir). 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 la base de datos de gráficos están desactualizados y usar uno permite 40 años de progreso. Es como decir que usar C es renunciar a todo el progreso tecnológico que hemos atravesado para obtener cosas como Java y C #. Aunque eso no es cierto. C es una herramienta que se necesita para ciertas tareas. Y Java es una herramienta para otras tareas.

Answer 4

He estado usando MySQL durante años para administrar datos de ingeniería, y funcionó bien, pero uno de los problemas que tuvimos (pero no nos dimos cuenta de que teníamos) era que siempre teníamos 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 empezar a probar neo4j y parece que está resolviendo ambos problemas por nosotros. La capacidad de agregar diferentes propiedades a cada nodo (y relación) nos ha permitido repensar todo nuestro enfoque de los datos. Es como los lenguajes dinámicos versus los estáticos (Ruby versus Java), pero para las 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 esto está simplificando dramáticamente nuestro código.

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

Y como un bono adicional, nuestro código de 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 en 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 mapea mejor a tablas o gráficos? Decide haciendo algunos prototipos, carga los datos y juega con ellos. Utilice neoclipse para ver diferentes vistas de los datos. Una vez que hayas hecho eso, espero que sepas si estás en algo bueno o no.

Answer 5

Estoy construyendo una intranet en mi empresa.

Estoy interesado en comprender cómo cargar datos que se almacenaron 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 necesite 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. Hay un proyecto importante en el que estamos trabajando y debido a la complejidad, cada departamento ha creado una hoja de cálculo de Excel separada que tiene un BOM (Lista de materiales) en una columna a la izquierda y luego varias columnas de notas y comprobaciones realizadas por individuos que hicieron estas hojas.

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 utiliza un componente común en más de un subconjunto. Lo que 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. Por ejemplo, datos relacionados con un número de pieza, una estructura de la lista de materiales, un número de teléfono, una dirección de correo electrónico, una política de la empresa o un procedimiento. Quiero incluso 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, puedes comenzar a hacer 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 se etiquetarán como creando y modificando los datos dentro del proyecto XYZ. Entonces, al utilizar el proyecto XYZ como clave de búsqueda, se creará un conjunto enorme 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, serán incluidos en mi correo electrónico. Esto está en marcado contraste con un secretario que intenta 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. Y la mayor parte no agrega ningún valor a nuestros productos.

Otro recorrido interesante podría informar todas las computadoras que tienen una determinada pieza de software instalada, por versión. Ese informe podría utilizarse 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.

Answer 6

Aquí hay un buen artículo que habla sobre las necesidades que satisfacen 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 erróneas, es solo que en estos días las personas están comenzando a procesar más y más datos en software y sitios web comunes, y que las bases de datos relacionales Simplemente no escalaremos para estas necesidades.

Answer 7

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

_{Nota: Soy parte del equipo de Neo4j}