On 1/19/17 1:06 PM, Austin Sharp wrote:

4. Handle supernodes better, for instance by streaming - i.e., when
traversing over edges, don't pull all edges in from Cassandra at once.
This is my personal bugbear - we keep having to change our schema and
use indices or properties when edges are by far the best fit for the
model, because Titan can easily blow through the Cassandra frame size
even if you set up vertex partitioning to split adjacency lists, among
other issues.

This is a big one for us as well, and while we have stuck with a schema that allows supernodes we've made all sorts of work arounds in our java code which accesses Titan.

Although in our case we're dealing with HBase underneath, and so the limits are somewhat different. However similar solutions should be applicable to any backend, either by changing the row structure or by having the clients page through the results with multiple calls.

Related to this area, I think the "hands-off-the-backend" approach that the Titan project took should be ditched. For systems like this installing custom HBase filters, co-processors, etc can be hugely beneficial in terms of performance. From talking to the Datastax folks about their new graph product it sounds like they've done a lot to integrate the graph DB with the Casandra nodes themselves, and I think a similar approach will be needed to move JanusGraph forward.

- Adam