Why RexsterGraph is not meant for high-performing graph traversals?

Question

Why RexsterGraph in the blueprint stack is not meant for high-performing graph traversals:
https://github.com/tinkerpop/blueprints/wiki/Rexster-Implementation

What are the limitations? And should I then fallback on executing gremlin throw a simple string evaluated?

Answer 1

RexsterGraph uses the Rexster REST API which is a RESTful representation of the Blueprints API. As such, each Blueprints method called in RexsterGraph translates to an HTTP call.

Here's an example of why that's bad for "high performance traversals". Using the toy graph, for an example. Let's say I want to do something simple with RexsterGraph like: g.v(1).out.filter{it.name=='josh'}.name. That will translate to the following HTTP calls:

1. vertices/1 - gets data for v(1)
2. vertices/1/outE - gets the out edges for v(1)
3. vertices/2 - knowing the out edges tells us the other vertex to retrieve
4. vertices/3 - knowing the out edges tells us the other vertex to retrieve
5. vertices/4 - knowing the out edges tells us the other vertex to retrieve
6. vertices/2 - now we are filtering so we need the name property
7. vertices/3 - now we are filtering so we need the name property
8. vertices/4 - now we are filtering so we need the name property
9. vertices/4 - now we are down to "josh" so get the name property

As you can see, it's not efficient. It is a one-to-one mapping of the Blueprints API to the Rexster REST API. That's it. Could it be made to be more efficient? Probably...we might consider caching property values or something, but it will still be really chatty for a "high performance traversal". Other problems with trying to make it more efficient are dealing with mechanisms for serializing closures so that can be executed on the server.

In the end, it was simply decided a long time ago that this was not a good approach and we started to recommend against using RexsterGraph in favor of server-side DSLs and RexPro/REST Gremlin Extension.