3 ms·

With an embedded graph database, you can treat your data as if it were all in memory. If things are not in memory, they will be loaded from disk on demand, and

With an embedded graph database, you can treat your data as if it were all in memory. If things are not in memory, they will be loaded from disk on demand, and then kept in a cache, just like virtual memory. This enables you to create persistent representations of real data structures, such as linked lists, trees, etc. You can traverse over the data, executing code in a full programming language, with your real domain model objects. You simply can't work the same way once network latency is involved. This is doubly true when you get automatic generated queries, such as with an Active Record pattern. Let's say that you want to traverse a linked list and apply a complex logical filter dependent on related data. You have to... (A) Craft a very precise query -- This can be difficult if the query depends on business rules which you'd need to implement in both your main language and in your query language. (B) Query for too much and throw away what you don't want -- In the SQL world, this is the 'OMG JOIN EVERYTHING' approach. It can work when datasets are small and infrequent, but does not scale well at all. It also requires you to do extra work upfront of declaring all the information you might possibly ever need in a particular situation. (C) Query for too little and issue additional queries as you realize you need more info -- This is sort of the default for rich client libraries. Naive ORMs routinely produce N+1 nightmare perf bugs in many web applications. With an embedded graph database, you just do (A) in your standard programming language, using your real domain models, without duplicating any effort, using algorithms taught to freshman year college students in their first C++ class. And everything just kinda works.

espeed 15y ago
If you don't require a server environment, having direct access to data that resides in memory or on your local machine will obviously be faster. But, whether this is an option depends on your use case -- if Neo4j is backing your load-balanced Web servers, this isn't really an option, but you could create a local mirror of the database for running queries (similar to OLTP vs OLAP systems). Gremlin is really just Groovy with domain-specific constructs. You can write multi-line Gremlin/Groovy scripts that apply complex filters and send them to the external server. You can also use any JVM langauge to create the equivalent of stored procedures on the server to pull data from multiple sources. Another approach would be to query the external server and use TinkerGraph to keep a local in-memory cache, lazy-loading it as needed.

espeed 15y ago

If you don't require a server environment, having direct access to data that resides in memory or on your local machine will obviously be faster. But, whether this is an option depends on your use case -- if Neo4j is backing your load-balanced Web servers, this isn't really an option, but you could create a local mirror of the database for running queries (similar to OLTP vs OLAP systems). Gremlin is really just Groovy with domain-specific constructs. You can write multi-line Gremlin/Groovy scripts that apply complex filters and send them to the external server. You can also use any JVM langauge to create the equivalent of stored procedures on the server to pull data from multiple sources. Another approach would be to query the external server and use TinkerGraph to keep a local in-memory cache, lazy-loading it as needed.