node.js - What (in_memory) graph DB if modeling data is focused -

i out of ideas , hope useful input. using question compress experiences , share them, hoping inspire distributors go next step modeling graph databases first class question/way.

i've been validating graph database solutions usable node.js few weeks. my use case save interactions of different social user network accounts. need use cpu , memory in efficient way.

my important requirements are:

• in_memory (at least indexing)
• open source (and free use)
• same javascript/node.js performance first class citizen
• comfortable query , modeling language

neo4j

i cypher best choice neo4j. major issue neo4j javascript access non-native. uses rest-api about ten times (10x) slower direct java access. took @ node-neo4j-embedded, has been inactive more 2 years. looks author isn't active @ (bad sign).

arangodb

the nice core developers of arangodb answered my question internals. means javascript first class citizen because native queries can pushed out of js. looking @ open source benchmarks, think fair. afraid didn't use node-neo4j-embedded benchmark. benchmarks compare rest-apis (edited because of @weinberger comment). wished compare native apis (maybe snoopy enough , give try! - let know!). update: noticed now, orientdb has answered benchmark new node.js driver (using command cache starting server -dcommand.cache.enabled=true -dcommand.cache.minexecutiontime=3, what isn't fair, because wasn't query caches benchmark!)

because use arangodb graph database have 3 choices (source: faq):

• traverse js objects
• using aqls graph functions
• using rest api

in general isn't comfortable cypher. , not sure how compare , right way modeling data (like neo4j explains well). i'd love have arangodb graphs. feels arangodb focused on graph operations , neo4j fits more needs of using graphs if have more relations rows (the reason use graphs instead of relations joins).

mongodb

the document based mongodb isn't optimized graph operations latterly has gotten experimental in_memory storage engine. there projects either in_memory or graph related nothing compelling. , @ this discussion looks mongodb isn't use.

orientdb

because there comparison orientdb vs. mongodb available (from orientdb) though use one. "orientdb has hybrid document-graph engine" using sql. former php/mysql expert. modeling part ? chapter working graphs not cypher like. using sql graphs. there nothing wrong that, using cypher before miss modeling feeling. if did modeling process orientdb , graphs maybe write tutorial neo4j had done.

update: javascript access first citizen there news: "in next release speed of driver comparable native java one" forked node.js driver had bin fixed last days.

update: before choosing orientdb 1 might want read article issues , discussions linked there. article touching sensitive issue , should approached critical mind. note author of update: i'm new editing , don't have enough reputation put comments. believe information valid point discussion, not sure how place here according rules.

lokijs

before looking @ neo4j, arangodb , mongodb, played around javascript based in_memory database called lokijs, seams follow strategy ignore slows down performance , efficiency. lokijs trying complete mongo-style (roadmap). major issue bad ability scale. of cause isn't graph database interesting solution while beginning of project. wasn't perfect feeling find distributed documentation (maybe should reboot gitbook). lokijs interesting project @ , hope go forward!

leveldb

previously when wrote degree paper looking @ leveldb. remembering while writing post, searched leveldb in_memory , got promising result called memdown (see also). haven't tested find, maybe has experiences working , modeling solution. maybe efficient way if others not fit because write lightweight cypher clone goal stay lightweight can do.

edit: due comment, here link levelgraph. idea implement cypher parser levelgraph/leveldb starting point compare

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) {   // .. }); 

conclusion

as noticed not super hero graphs. initial dive , i'm trying overview. assume there lot people out there want ask same questions me haven't time. hope post lot people , change comments , answers become done overview how modeling data graphs.

---

@editors: you welcome.

@commenters: this result of personal research - if have done journey me, please answer short summary have done each db i've evaluated (don't forget target 4 goals).

the idea combine node-style performance through of native features (e.g. streams) , high level query language cypher quite neat.

what won't kind of low level api, since rather rare db authors and, supposedly, not wanted in design patterns. so, long running tcp connections shall serve fine.

cypher-stream since incorporate of this, while (superficially judged) maintaining style.

since won't further search, i'd suggest sending him pull request if other features needed :)