neo4j - base de datos de gráficos junto con una base de datos relacional?

Question

esta es una pregunta sobre las mejores prácticas, entiendo que hay muchas opciones diferentes para hacer esto, pero me gustaría su opinión sobre cómo abordaría la solución de este problema. Tómelo como si el rendimiento fuera crítico en este sistema, en otras palabras, escalable.

Hace poco encontré las maravillas de la base de datos de gráficos, así que se me ocurrió una situación teórica en la que una empresa quiere gestionar sus relaciones con los clientes, y para hacerlo van a usar neo4j que es genial, y permite para una excelente administración de los clientes, diferentes miembros del personal y sus relaciones, lo que es genial, sin embargo, ahora la compañía desea crear una interfaz basada en web que requiera autenticación, y cualquier persona en la base de datos neo4j debería poder iniciar sesión en el sistema para ver cómo están relacionados con otras personas en la base de datos de la compañía, por lo que cada usuario debe tener una contraseña/correo electrónico/id asociado con su nombre.

Así que mi pregunta es, en este caso, si es mejor almacenar password_hash/password_salt/id/email en una base de datos mysql y luego, en función del nodo, buscarlo en la base de datos mysql. ¿O es mejor almacenar password_hash/password_salt/id/email en las tablas hash dentro de los nodos?

También cada tienda tiene miles de productos, y se pueden almacenar en la base de datos de gráficos o puedo almacenar los productos en la base de datos mysql y luego buscar el producto allí, y hacer los cambios allí, porque los productos no son relacionados entre sí, por lo que no tiene sentido almacenarlos en la base de datos de gráficos, por lo que no deberían almacenarse allí para mejorar el rendimiento?

Así que mi pregunta se reduce a esto: ¿es mejor para los grandes proyectos utilizar una base de datos de gráficos junto con la base de datos de rdms más común como mysql? si no, ¿cuál es el punto en el que comienzas a utilizar estos dos sistemas de bases de datos?

disculpas de antemano por mi falta de conocimiento sobre la terminología de la base de datos.

Answer 1

Gráfico DB se utiliza principalmente para el mantenimiento de las relaciones. Si la aplicación tiene un gráfico DB, eso no significa que la aplicación necesite almacenar todo en Graph DB.

Cada solicitud de nodo en Graph está en la memoria y, por lo tanto, si tiene propiedades innecesarias en su nodo, estará hinchado y puede hacer que las cosas vayan más despacio y requiera más memoria. Por lo general, decido qué debe ir en gráfico y qué necesita en DB por regla muy simple.

La propiedad de alto nivel (que define la relación y otras propiedades importantes que definen el nodo) va en el gráfico, mientras que la información adicional va en RDMS.

Por ejemplo, en FB puede ser FBID, Nombre va en Gráfica ya que define la relación de un nodo con otro.Pero cuando el usuario hace clic en la ID de alguien de Facebook, puede ver a otros usuarios fecha de nacimiento, edad, universidad. Todos estos pueden ir en RDBMS.

PD: RDMS tiene otra ventaja, se puede utilizar para análisis rápidos. Sé que con el gráfico también puedes hacerlo, pero no estoy seguro si es tan escalable y fácil como RDBMS.

La desventaja de este enfoque es: necesita mantener dos DBS.

Answer 2

Debe usar ambos en caso de que existan datos en los que no tiene mucho sentido almacenarlos en un DB de gráficos como neo4j/orientDB (y algunos datos estarían mejor en un DB de gráficos en comparación con un DB relacional) Forzar datos en una plataforma puede causar problemas con el rendimiento/escalabilidad más adelante.

Answer 3

A menos que tenga un caso probado para una solución de dos DB, diría que menos partes móviles lo mantendrían más ágil, más capaz de cambiar las cosas rápidamente. Si luego encuentra un caso de uso que es difícil, pondere el costo/beneficio de introducir un segundo almacenamiento. Una arquitectura de dos DB no es desconocida, pero viene con una sobrecarga.

específica a la seguridad, no hay ninguna razón por la Neo4j o cualquier otra solución razonable NOSQL no podían hacer eso: http://spring.neo4j.org/docs#tutorial_security