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.

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

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

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

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

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.

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

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

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

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

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

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

A pull request has been submitted for this work: https://github.com/JanusGraph/janusgraph/pull/106. --Ted

interesting. I followed the example from the 'getting start' section. The HBase table contains quick a few (9 to be exact) column families, and the columnfamily name is from 'e' to 't', which I guess

Jerry, thanks for the pointer. Since they are stored in different CFs, it is a bit similar as Neo4j. I have the janusGraph up and running on my mac on top of HBase 1.2, thanks for the effort to make

The edges, vertices, properties and indexes are stored in a fixed table and a fixed set of column families within the table in HBase. i.e. edges are in one CF, properties are in another CF. They are

Irving, thanks for the pointers. Neo4j is still running on single server, though there are efforts with data distribution/partition to support true cluster. maybe Neo4j doesn't worry about

This is a good video that I would recommend -> https://youtu.be/tLR-I53Gl9g I would keep your vertex, edges, and properties together. Thank You, Irving Duran

hi, Guys new to this form and looking for a few pointers. I am fairly familiar with HBase, hence plan to use it as the backend. I went through the 'getting-started' tutorial, and have the example up

I created the following issue to get Sonatype Nexus setup so we can publish artifacts to maven central. https://github.com/JanusGraph/janusgraph/issues/97 Any committers interested in having the