Currently, query.fast-property is defaulted to false which means that vertex property retrievals require repeated trips to the storage backend. Issue 104 proposes that this be changed and defaulted

https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-hbase-parent/janusgraph-hbase-core/src/main/java/org/janusgraph/diskstorage/hbase/HBaseStoreManager.java#L246 This tells you the column

Jerry, thanks a lot. that is exactly what I was looking for. Demai

Hey, we already have a tinkerpop-ignite implementation as part of an in-house project. We'd be happy to merge it with Janus, if we can work together. You are right about the convergence of OLTP and

Song, great that you guys already have the implement with ignite. Would you please share some performance numbers, for example comparing to Titan-on-HBase, how much Ignite improve? My team consider

Hi Demai, Preliminary tests showed slower performance than tinkerpop-spark in OLAP (largely due inherent constraints of Ignite) and faster OLTP than titan-cassandra in most cases (largely because we

Hi, Is there some plan about upgrade the ElasticSearch support? Currently, the project is built against ES 1.5.1, and there are a lot of breaking changes in ElasticSearch API in 2.x and 5.x.

Yes, there's ongoing work in https://github.com/JanusGraph/janusgraph/pull/79 to update Elasticsearch.

I started some conversation over at https://github.com/JanusGraph/janusgraph/pull/79#pullrequestreview-24343839, and Jason Plurad suggested I move that over here. I have some code that's been used in

resending because I made a typo: hadoop -> hbase We could do a split for ES much like the split that we do for hbase (098, 10 etc). have a janusgraph-es/janusgraph-es-core that JanusGraph uses, and

In the scheme below if 1.5=transport and 2.x=transport and 5.x=http/jest, then we don't need to pull out protocols in the shim names, so the shims would just

I'm in support of this. I did not see a convincing need for defaulting to false in Titan, and has potential to double the latency of traversals due to lazy loading.

I think JanusGraph should end formal support for 1.x, though it would be great if users could still have the ability to use it (even if unsupported/tested) via your Jest-based implementation. For one

It's also similar to the split that we'll have with Cassandra with cassandra-thrift and cassandra-cql. Since ES is going in the direction of HTTP-only client access (good read here), it might make

I proposed Jest for a few reasons. The ES Rest client is rather low level, as mentioned in #92. Jest is much higher level client that adds a lot of niceties for Java. I think that alone will keep Jest

Regarding the compatibility shim approach I think this should be avoided if at all possible. I don't think using Jest gets away from needing version-specific ES client code to support other

Although the more I think about it I guess this issue is going to be present no matter what until we can go full HTTP. Just to throw it out there, why not drop node/transport and go full HTTP? It's

I don't see a problem with just going full http, it would definitely make things easier for me. But the Jest jars for 1.x vs 2.x + are going to need to be different. I'm not sure what the preferred

I think you said the Jest 2.x jars should work with ES 2.x and 5.x, right? Then I'm back to my suggestion to drop formal support for ES 1.x but documentation could be updated to provide workaround

Yup. Once those PRs are merged in the Jest project. +1 I personally think only supporting http makes sense and going the route @sjudeng mentioned. It allows current titan users some flexibility in