tutorial servidor produccion nodejs node node.js neo4j orientdb arangodb lokijs

node.js - servidor - nodemon



Qué DB(in_memory) gráfico si los datos de modelado están enfocados (2)

Estoy fuera de ideas y espero obtener alguna información útil. Estoy usando esta pregunta para comprimir mis experiencias y compartirlas, con la esperanza de inspirar a algunos distribuidores para que den el siguiente paso con el modelado de bases de datos gráficas como una pregunta / forma de primera clase.

He estado validando algunas soluciones de bases de datos gráficas utilizables por node.js durante algunas semanas. Mi caso de uso es guardar interacciones de diferentes cuentas de redes sociales de usuarios . La necesidad es utilizar la CPU y la memoria de la manera más eficiente .

Mis requisitos más importantes son:

  • en_memoria (al menos para indexación)
  • código abierto (y de uso gratuito)
  • El mismo rendimiento de JavaScript / Node.js como ciudadano de primera clase.
  • Cómodo lenguaje de consulta y modelado.

Neo4J

Realmente me gusta la cypher así que mi mejor elección sería Neo4j. Pero el principal problema de Neo4j es que el acceso a JavaScript no es nativo. Utiliza la API REST, que es aproximadamente diez veces más lenta que el acceso directo a Java. Así que eché un vistazo a node-neo4j-embedded , pero ha estado inactivo durante más de dos años. Parece que su author no está activo en absoluto (mala señal).

ArangoDB

Los desarrolladores principales de ArangoDB realmente agradables respondieron a mi pregunta sobre los aspectos internos. Finalmente, significa que JavaScript es un ciudadano de primera clase porque las consultas nativas se pueden eliminar de JS. En cuanto a los puntos de referencia de código abierto, creo que es justo. Pero me temo que no usaron node-neo4j-embedded para su punto de referencia. Los puntos de referencia comparan las API REST (editadas por el comentario de @weinberger). Me hubiera gustado que comparasen las API nativas (¡tal vez alguien sea lo suficientemente estúpido y pruébalo! ¡Avísanos!). Actualización : Como he notado ahora, OrientDB ha respondido la prueba con un nuevo controlador node.js (usando Command Cache iniciando el servidor con -Dcommand.cache.enabled = true -Dcommand.cache.minExecutionTime = 3 , lo que no es justo , porque no era una consulta caches benchmark! )

Como me gusta usar ArangoDB como una base de datos gráfica, tendría 3 opciones (fuente: FAQ ):

En general no es cómodo como el cypher. Y no estoy seguro de cómo comparar y cuál es la forma correcta de modelar los datos (como lo explica Neo4J muy bien ). Me encantaría tener algo como esto para ArangoDB Graphs. Se siente como si ArangoDB se enfocara en operaciones de gráficos y Neo4J satisface más las necesidades de usar gráficos si tiene más relaciones que filas ( la razón para usar gráficos en lugar de relaciones con combinaciones ).

MongoDB

El documento basado en MongoDB no está optimizado para operaciones de gráficos, pero más tarde ha conseguido un motor de almacenamiento experimental en memoria . También hay algunos proyectos relacionados con la memoria o con el gráfico, pero nada es realmente convincente. Y en esta discusión parece que MongoDB no es lo que me gusta usar.

OrientDB

Debido a que hay una comparación entre OrientDB y MongoDB disponible (de OrientDB), pensé a punto de usar esta. " OrientDB tiene un motor híbrido de documentos y gráficos " que usa SQL. Soy un ex experto en PHP / MySQL. Pero ¿dónde está la parte de modelado? Su capítulo de trabajo con gráficos no es tan simple. Es como usar SQL para gráficos. No hay nada de malo en eso, pero usar la clave antes de que pierda el sentimiento de modelado. Si alguien hiciera un proceso de modelado con OrientDB y Graphs, tal vez podría escribir un tutorial como lo había hecho Neo4J .

Actualización : Acerca del acceso a JavaScript como primer ciudadano, hay noticias : " En la próxima versión, la velocidad de este controlador será comparable a la de Java nativa ".

Actualización : antes de elegir OrientDB, es posible que desee leer un artículo sobre algunos problemas y discusiones vinculadas desde allí. El artículo está tocando un tema delicado y debe abordarse con una mente crítica. Nota del autor de esta actualización: soy nuevo en la edición SO y no tengo la reputación suficiente para poner esto en los comentarios. Creo que esta información es un punto de discusión válido, no estoy seguro de cómo colocarla aquí de acuerdo con las reglas de SO.

LokiJS

Antes de ver Neo4J, ArangoDB y MongoDB, jugué un poco con esa base de datos en memoria llamada LokiJS , que parece seguir la estrategia para ignorar todo lo que ralentiza el rendimiento y la eficiencia. LokiJS está intentando completar el estilo Mongo (RoadMap). El principal problema es la mala capacidad para escalar . No es una base de datos gráfica, pero fue una solución interesante al principio de mi proyecto. Además, no fue una sensación perfecta encontrar toda la documentación distribuida (tal vez deberían reiniciarse con GitBook). Finalmente, LokiJS es un proyecto muy interesante y espero que sigan adelante.

LevelDB

Anteriormente, cuando escribí mi trabajo de grado, estaba buscando en levelDB. Recordando esto mientras escribía esta publicación, busqué LevelDB en memoria y obtuve un resultado prometedor llamado MemDown (vea also ). No he probado este hallazgo, pero tal vez alguien tenga experiencias trabajando y modelando esta solución. Tal vez sería la forma más eficiente si todos los demás no encajaran porque simplemente escribiría un clon de cifrado ligero con el objetivo de seguir siendo lo más ligero posible.

Edición: Debido al comentario, aquí hay un enlace a LevelGraph . Como idea para implementar un analizador CYPHER para LevelGraph / LevelDB, su punto de partida sería comparar

cypher

CREATE (SUBJECT:"a") - [b:PREDICATE] -> (OBJECT:"c") RETURN, subject, predicate, object

LevelGraph :

var RETURN = { SUBJECT: "a", PREDICATE: "b", OBJECT: "c" }; db.put(RETURN, function(err) { // .. });

Conclusión

Como te habrás dado cuenta, no soy el superhéroe de los gráficos. Pero esta es mi primera inmersión en esto y estoy tratando de obtener una visión general. Supongo que hay muchas personas que quieren hacer las mismas preguntas que yo pero que no tienen tiempo. Espero que esta publicación ayude a mucha gente y cambie por comentarios y respuestas para convertirse en una descripción general bien hecha de cómo modelar datos para gráficos.

@editores: de nada .

@commentadores: este es el resultado de mi investigación personal: si también ha realizado un viaje como yo, responda con un breve resumen como el que he hecho para cada DB que he evaluado (no olvide apuntar mis 4 objetivos) .

La idea de combinar el rendimiento de estilo de nodo a través de cualquiera de las funciones nativas (p. Ej., Flujos) y un lenguaje de consulta de alto nivel como CYPHER es en realidad bastante clara.

Lo que probablemente no obtendrá es cualquier tipo de API de bajo nivel, ya que esto es bastante raro en los autores de bases de datos y, supuestamente, no se desea en sus patrones de diseño. Por lo tanto, las conexiones tcp larga ejecución solo servirán bien.

cypher-stream desde que se incorpora todo esto, mientras que (superficialmente juzgado) mantiene un buen estilo.

Como es probable que no consiga más en la búsqueda, le sugeriría que le envíe una solicitud de extracción si necesita alguna otra función :)