Janusgraph: Index by label

[s-nel]

In Janus I can create a composite index for a single property. Why then can I not create a composite index for a vertex label without a property?

My use case is that we're using vertex labels to identify the type of the vertex (as suggested in Janus docs). We have a CRUD UI that allows users to browse objects of a given type, so we now want to show a paged list of people:

g.V().hasLabel("person").range(0, 10)

This results in a 5 second long query, because it's doing a full graph scan. If I introduce a redundant property "mytype"="person", I can place an index on "mytype" only for label "person", write a query like this:

g.V().has(Key[String]("mytype"), "person").hasLabel("person").range(0, 10)

And it no longer performs a full graph scan: ~100ms.

Is it possible to trick Janus into using an existing index I have on property "name" for label "person" by changing the query? Both these queries still result in a full graph scan:

g.V().has(Key[String]("name")).hasLabel("person").range(0, 10)
g.V().has(Key[String]("mytype")).hasLabel("person").range(0, 10)

[amcp]

This proposed feature has the potential to introduce a hot key in graphindex for large graphs that have many vertices of a particular type. To implement this feature correctly, graphindex would also need to be partitioned (with the number of partitions defined by cluster.max-partitions). Otherwise, you will see latency increases in Cassandra/HBase and throttling on DynamoDB while using a vertex label index.

[sharpau]

@amcp The hot key problem already exists in plenty of schemas. Right now we use edges or property indices for types and other high-cardinality indices, and have to wade through all the problems that arise. I would love to see this issue get worked on, if only to spur better support for hot keys.