Servidor Neo4j contra incrustado

Question

Estoy un poco confundido acerca de cuál es la mejor solución para mi aplicación. Como he visto hasta ahora, tengo que elegir entre neo4j independiente (RestGraphDatabase) y una EmbeddedGraphDatabase (la RemoteGraphDatabase aún no es para uso de producción).

Pros RESTO:

-> Los distintos servicios pueden acceder a la base de datos Neo4j (muestra: tengo un servicio que se encarga de nodos de tipo A, B y C. El segundo servicio es responsable de los nodos D y H y puede conectar nodos D a A-nodes). De esa manera tengo estructuras de dominio limpio. Cada servicio solo es responsable de sus propios nodos de dominio. Puedo actualizar cada servicio y no tengo que cerrar toda mi aplicación.

-> Puedo acceder al DB Neo4j de diferentes lenguajes (PHP)

Contras: - El rendimiento no es tan bueno como un EmbeddedGraphDatabase (ya que el servidor Neo4j y los servicios están en la misma máquina que la latencia es no tan grande). - Sin transacciones

Mis preguntas: ¿Es una buena decisión ir con el servidor independiente? ¿O debería usar el embebido y mezclar los servicios en uno grande? ¿Es posible ejecutar una aplicación grande (compleja) sin soporte de transacciones?

Answer 1

Tiene la razón de que el rendimiento con el servidor REST será menor. Sin embargo, puede tener algo así como transacciones con el servidor REST usando operaciones por lotes; ver http://docs.neo4j.org/chunked/milestone/rest-api-batch-ops.html. También puede crear complementos de servidor específicos del dominio que realicen su lógica transaccional en el lado del servidor: http://docs.neo4j.org/chunked/milestone/server-extending.html.

Si su arquitectura requiere que pueda acceder a la base de datos desde varias máquinas cliente, sus únicas opciones son el servidor REST o Neo4j HA (alta disponibilidad). HA solo está disponible con una licencia de Neo4j Enterprise.

Deje que la arquitectura de la aplicación informe qué herramientas se utilizan, y no al revés. Si ya ha decidido que su aplicación es mejor como servicios separados, no los combine en uno solo para respaldar el modelo de persistencia subyacente. No sé nada sobre su aplicación, pero a partir de su descripción, elegiría el servidor REST y utilizaría lotes o complementos de servidor.

Answer 2

Todo depende de su caso de uso. Ya enumeró algunos de los pros y contras.

Otro pro para el servidor es la administración/visualización web.

Tiene más opciones. Puede tener un graphdb incorporado para un alto rendimiento y tener solo algunos servicios ejecutados incrustados, y usar una API remota centrada en el dominio (REST o de otro modo) para exponer la base de datos de gráficos para otros servicios.

Lo mismo se puede lograr utilizando el servidor Neo4j y agregue algunos de los servicios más críticos para el rendimiento como Server-Plugins o Extensions que también pueden exponer una API remota personalizada que se adapte mejor a sus casos de uso.

Comenzaría a utilizar el gráfico incrustado db para desarrollar sus servicios, si desea exponer ciertos puntos finales a otros servicios más adelante, es bastante fácil cambiar al servidor Neo4j.

En REST-API hay una transacción por solicitud, para operaciones más grandes hay un batch operation en la API.