4 ms·

A Neo4j REST API seems strange to me. I could see, as it evolves, it being pretty useful for some use cases. Especially with these maturing graph query language

A Neo4j REST API seems strange to me. I could see, as it evolves, it being pretty useful for some use cases. Especially with these maturing graph query languages. However, it just seems counter productive in light of the many lost benefits of the embedded approach. I quite like the software transactional domain objects wrapped around nodes and relationships. I think it would make more sense to develop a distinct distributed graph database, rather than force Neo4j to support both embedded and server use cases.

espeed 15y ago
Even though it's over REST, you can still have "transactional domain objects wrapped around nodes and relationships." Neo4j is working on providing RESTful transactions for the Neo4j REST server (http://www.mail-archive.com/user@lists.neo4j.org/msg08253.html http://www.mail-archive.com/user@lists.neo4j.org/msg08253.ht...), and you can already do this with Rexster. Here's a Bulbs (Python) example of what a domain object looks like wrapped around a node: from bulbs.model import Node, Relationship from bulbs.datatype import Property, Integer, String class Person(Node): element_type = "person" name = Property(String, nullable=False) age = Property(Integer) james = Person(name="James", age=34) julie = Person(name="Julie", age=28) Relationship.create(james,"knows",julie) As I said in another thread, Bulbs connects to Neo4j through the Rexster REST server, and binary bindings are in the works. But with Bulbs and Rexster you are not limited to just Neo4j -- you can connect to any Blueprints-enabled graph database (https://github.com/tinkerpop/blueprints/wiki/ https://github.com/tinkerpop/blueprints/wiki/). In addition to Neo4j, this also includes TinkerGraph, Dex, OrientDB, OpenRDF Sail, and others. InfiniteGraph (http://www.infinitegraph.com/ http://www.infinitegraph.com/) has a Blueprints implementation under development (see http://blog.infinitegraph.com/2011/02/04/infinitegraph-announces-release-1-1-with-new-indexing-options-and-improved-performance/ http://blog.infinitegraph.com/2011/02/04/infinitegraph-annou...)
- snprbob86 15y ago
  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

Even though it's over REST, you can still have "transactional domain objects wrapped around nodes and relationships." Neo4j is working on providing RESTful transactions for the Neo4j REST server (http://www.mail-archive.com/user@lists.neo4j.org/msg08253.html http://www.mail-archive.com/user@lists.neo4j.org/msg08253.ht...), and you can already do this with Rexster. Here's a Bulbs (Python) example of what a domain object looks like wrapped around a node: from bulbs.model import Node, Relationship from bulbs.datatype import Property, Integer, String class Person(Node): element_type = "person" name = Property(String, nullable=False) age = Property(Integer) james = Person(name="James", age=34) julie = Person(name="Julie", age=28) Relationship.create(james,"knows",julie) As I said in another thread, Bulbs connects to Neo4j through the Rexster REST server, and binary bindings are in the works. But with Bulbs and Rexster you are not limited to just Neo4j -- you can connect to any Blueprints-enabled graph database (https://github.com/tinkerpop/blueprints/wiki/ https://github.com/tinkerpop/blueprints/wiki/). In addition to Neo4j, this also includes TinkerGraph, Dex, OrientDB, OpenRDF Sail, and others. InfiniteGraph (http://www.infinitegraph.com/ http://www.infinitegraph.com/) has a Blueprints implementation under development (see http://blog.infinitegraph.com/2011/02/04/infinitegraph-announces-release-1-1-with-new-indexing-options-and-improved-performance/ http://blog.infinitegraph.com/2011/02/04/infinitegraph-annou...)

snprbob86 15y ago
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.