orientada - graph database
¿Cuáles son los casos de uso de las bases de datos basadas en gráficos(http://neo4j.org/)? (7)
Utilicé mucho el Relational DB''s y decidí aventurarme en 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?
¿Los ha usado en un entorno de producción? ¿Cuál fue el requerimiento que te impulsó a usarlos?
Aquí hay un buen artículo que habla sobre las necesidades que llenan 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 las personas están empezando a procesar cada vez más datos en el software convencional y sitios web, y que las bases de datos relacionales simplemente no escalan para estas necesidades
Dos puntos:
En primer lugar, en los datos que he estado trabajando con los últimos 5 años en SQL Server, recientemente he llegado al muro de escalabilidad con SQL para el tipo de consultas que necesitamos ejecutar (relationhsips anidados ... 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.
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 gráficos y redes. 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 buena para datos semiestructurados, pero no tan buena para datos densos estructurados. Entonces, este tipo de IBM llamado Codd estaba investigando maneras 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 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 para decir que los modelos de base de datos de gráficos están desactualizados y que usar uno renuncia a 40 años de progreso. Es como decir que usar C es renunciar a todo el progreso tecnológico que hemos tenido para obtener cosas como Java y C #. Eso no es verdad sin embargo. C es una herramienta que se necesita para ciertas tareas. Y Java es una herramienta para otras tareas.
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 necesitas superponer varias tablas distintas, el modelo de 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 una jerarquía BOM (lista de materiales) en una columna a la izquierda y luego varias columnas de notas y verificaciones hechas por individuos quien hizo estas hojas
De modo que uno de los problemas es fusionar todas estas notas en una sola "vista" para que alguien pueda ver todos los problemas que deben abordarse en una parte en particular.
El segundo problema es que una hoja de cálculo de Excel no es buena para representar una lista de materiales jerárquica cuando se usa 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 compañía, quiero poder buscar cualquier cosa fácilmente. Tales como datos relacionados con un número de parte, una estructura de 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 ampliar 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 hacer interesantes recorridos, como "Quiero escribir un correo electrónico a todos los que trabajan en el proyecto XYZ". Se habrá asociado a las personas con el proyecto porque se etiquetarán como creación y modificación de los datos dentro del proyecto XYZ. Entonces, al usar el proyecto XYZ como una 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, al participar en el proyecto XYZ, se incluirán en mi correo electrónico. Esto está en marcado contraste con algún secretario que intenta mantener una lista de personas trabajando 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 cruce interesante podría informar todas las computadoras que tienen un determinado 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.
He estado usando MySQL durante años para administrar datos de ingeniería, y funcionó bien, pero uno de los problemas que tuvimos (pero que no nos dimos cuenta) fue que siempre tuvimos que planificar el esquema por adelantado. Otro problema que sabíamos que teníamos era mapear los datos hasta los objetos de dominio y viceversa.
Ahora acabamos de comenzar a probar neo4j y parece que está solucionando ambos problemas para nosotros. La capacidad de agregar diferentes propiedades a cada nodo (y relación) nos ha permitido volver a pensar todo nuestro enfoque de los datos. Es como los lenguajes dinámicos frente a 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 eso simplifica enormemente nuestro código.
Y dado que el modelo de objeto en el código es generalmente una estructura de gráfico, la asignación desde 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 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 asigna mejor a tablas o gráficos? Decida haciendo algunos prototipos, cargue los datos y juegue con ellos. Use neoclipse para ver las diferentes vistas de los datos. Una vez que hayas hecho eso, con suerte sabrás si te está yendo bien o no.
Hemos estado trabajando con el equipo de Neo durante más de un año y hemos sido muy felices. Modelamos los artefactos académicos y sus relaciones, que son muy útiles 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 el modelado con Neo4j es muy directo y tiene el rendimiento más plano / más rápido para R / W de cualquier otra solución que probamos.
Para ser sincero, me cuesta mucho no pensar en términos de Graph / Network porque es mucho más fácil que diseñar estructuras de tabla complicadas para contener propiedades y relaciones de objeto.
Dicho esto, almacenamos cierta información en MySQL simplemente porque es más fácil para el lado de negocios ejecutar consultas SQL rápidas. Para realizar las mismas funciones con Neo, necesitaríamos escribir código que simplemente no tenemos el ancho de banda por ahora. ¡Tan pronto como lo hagamos, moveré todos esos datos a Neo!
Buena suerte.
Usé una base de datos de gráficos 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 utilizamos una base de datos de gráficos fue que los datos almacenados por el sistema 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 unidos por relaciones. Para razonar acerca de los datos, el sistema necesitaba hacer muchas operaciones que serían un par de recorridos en una base de datos de gráficos, pero eso sería consultas bastante complejas en SQL.
Las principales ventajas del modelo de gráfico fueron el rápido tiempo de 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 injertarlos en la parte superior de nuestro modelo, normalmente el representante de ventas podría hacerlo en el sitio. La flexibilidad también ayudó cuando estábamos diseñando una nueva característica, evitándonos tratar de incorporar 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 raras, brindándonos muchas secretas salsas 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, que puede ser un problema cuando sus clientes son empresariales. Nuestros clientes preguntaban por qué no podí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 realmente 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 empresa grande incluso tenía una política exclusiva de Oracle, pero afortunadamente Oracle compró Berkeley DB. También tuvimos que escribir muchas herramientas adicionales, no pudimos usar Crystal Reports por ejemplo.
La otra desventaja de nuestra base de datos de gráficos fue que la construimos nosotros mismos, lo que significaba que cuando nos topamos con un problema (generalmente con escalabilidad) teníamos 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 se ajusta al modelo de gráfico, use una base de datos de gráficos. Si solo se ajusta a otra cosa, úsalo.
Si su aplicación no necesita ajustarse a la arquitectura blub actual, use una base de datos de gráficos, o CouchDB, o BigTable, o lo que sea que se ajuste a su aplicación y que piense que es genial. Puede darte una ventaja, y es divertido probar cosas nuevas.
Lo que sea que elija, intente no construir el motor de base de datos usted mismo a menos que realmente le guste construir motores de base de datos.
podría ser un poco tarde, pero hay un número creciente de proyectos que utilizan Neo4j, los más conocidos que figuran 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