janusgraph-users@lists.lfaidata.foundation

Re: using In-Memory in JanusGraph Verison 0.5.2 Throws Exception

Boxuan Li <libo...@...>

#5442

Make sure you have included janusgraph-inmemory in your dependency.

Cheers,

Boxuan

Show quoted text

On Friday, December 18, 2020 at 4:07:10 PM UTC+8 kri...@... wrote:

Hi folks

i have updated janusgraph version from 0.4.1 to 0.5.2. all my previous unit testcases with inmemory config throws expection below. should i want to add any more particular dependency to my project for running inmemory graph?
can you please help me regarding this issue.

using below config for inmemory janusgraph instance.
graph = JanusGraphFactory.build().set("storage.backend", "inmemory")
.set("graph.timestamps",TimestampProviders.NANO) .open();

java.lang.IllegalArgumentException: Could not find implementation class: org.janusgraph.diskstorage.inmemory.InMemoryStoreManager
at org.janusgraph.util.system.ConfigurationUtil.instantiate(ConfigurationUtil.java:60)
at org.janusgraph.diskstorage.Backend.getImplementationClass(Backend.java:440)
at org.janusgraph.diskstorage.Backend.getStorageManager(Backend.java:411)
at org.janusgraph.graphdb.configuration.builder.GraphDatabaseConfigurationBuilder.build(GraphDatabaseConfigurationBuilder.java:50)
at org.janusgraph.core.JanusGraphFactory.open(JanusGraphFactory.java:161)
at org.janusgraph.core.JanusGraphFactory.open(JanusGraphFactory.java:132)
at org.janusgraph.core.JanusGraphFactory.open(JanusGraphFactory.java:122)
at org.janusgraph.core.JanusGraphFactory$Builder.open(JanusGraphFactory.java:261)

Thanks & Regards
Krishna Sailesh

Re: using In-Memory in JanusGraph Verison 0.5.2 Throws Exception

Nicolas Trangosi <nicolas...@...>

#5443

Hi,

Have you added the janusgraph-inmemory dependency in your pom.xml file?

<dependency>
<groupId>org.janusgraph</groupId>
<artifactId>janusgraph-inmemory</artifactId>
<version>${janusgraph.version}</version>

Regards,
Nicolas

Show quoted text

Le ven. 18 déc. 2020 à 09:07, kri...@... <krishna...@...> a écrit :

Hi folks

i have updated janusgraph version from 0.4.1 to 0.5.2. all my previous unit testcases with inmemory config throws expection below. should i want to add any more particular dependency to my project for running inmemory graph?
can you please help me regarding this issue.

using below config for inmemory janusgraph instance.
graph = JanusGraphFactory.build().set("storage.backend", "inmemory")
.set("graph.timestamps",TimestampProviders.NANO) .open();

java.lang.IllegalArgumentException: Could not find implementation class: org.janusgraph.diskstorage.inmemory.InMemoryStoreManager
at org.janusgraph.util.system.ConfigurationUtil.instantiate(ConfigurationUtil.java:60)
at org.janusgraph.diskstorage.Backend.getImplementationClass(Backend.java:440)
at org.janusgraph.diskstorage.Backend.getStorageManager(Backend.java:411)
at org.janusgraph.graphdb.configuration.builder.GraphDatabaseConfigurationBuilder.build(GraphDatabaseConfigurationBuilder.java:50)
at org.janusgraph.core.JanusGraphFactory.open(JanusGraphFactory.java:161)
at org.janusgraph.core.JanusGraphFactory.open(JanusGraphFactory.java:132)
at org.janusgraph.core.JanusGraphFactory.open(JanusGraphFactory.java:122)
at org.janusgraph.core.JanusGraphFactory$Builder.open(JanusGraphFactory.java:261)

Thanks & Regards
Krishna Sailesh

--
You received this message because you are subscribed to the Google Groups "JanusGraph users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgra...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-users/d0a46a98-59d5-4895-bf22-a25b0250fec1n%40googlegroups.com.

--

Nicolas Trangosi

Lead back

+33 (0)6 77 86 66 44

Ce message et ses pièces jointes peuvent contenir des informations confidentielles ou privilégiées et ne doivent donc pas être diffusés, exploités ou copiés sans autorisation.

Si vous avez reçu ce message par erreur, veuillez le signaler a l'expéditeur et le détruire ainsi que les pièces jointes.

Les messages électroniques étant susceptibles d'altération, DCbrain décline toute responsabilité si ce message a été altéré, déformé ou falsifié. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, DCbrain is not liable for messages that have been modified, changed or falsified. Thank you.

using In-Memory in JanusGraph Verison 0.5.2 Throws Exception

"kri...@gmail.com" <krishna...@...>

#5441

Hi folks

i have updated janusgraph version from 0.4.1 to 0.5.2. all my previous unit testcases with inmemory config throws expection below. should i want to add any more particular dependency to my project for running inmemory graph?

can you please help me regarding this issue.

using below config for inmemory janusgraph instance.

graph = JanusGraphFactory.build().set("storage.backend", "inmemory")

.set("graph.timestamps",TimestampProviders.NANO) .open();

java.lang.IllegalArgumentException: Could not find implementation class: org.janusgraph.diskstorage.inmemory.InMemoryStoreManager

at org.janusgraph.util.system.ConfigurationUtil.instantiate(ConfigurationUtil.java:60)

at org.janusgraph.diskstorage.Backend.getImplementationClass(Backend.java:440)

at org.janusgraph.diskstorage.Backend.getStorageManager(Backend.java:411)

at org.janusgraph.graphdb.configuration.builder.GraphDatabaseConfigurationBuilder.build(GraphDatabaseConfigurationBuilder.java:50)

at org.janusgraph.core.JanusGraphFactory.open(JanusGraphFactory.java:161)

at org.janusgraph.core.JanusGraphFactory.open(JanusGraphFactory.java:132)

at org.janusgraph.core.JanusGraphFactory.open(JanusGraphFactory.java:122)

at org.janusgraph.core.JanusGraphFactory$Builder.open(JanusGraphFactory.java:261)

Thanks & Regards

Krishna Sailesh

Re: Aggregating edges based on the source & target vertex attributes

Kevin Schmidt <ktsc...@...>

#5439

Thanks for improving it! Always good to learn more.

Show quoted text

On Thu, Dec 17, 2020 at 6:11 AM HadoopMarc <bi...@...> wrote:

And here a small variation without the keys and with some code formatting:

g.V().as('a').outE().as('e').inV().as('b').
    group().by(
        union(select('a').values('organization'), select('b').values('organization')).fold()
    ).by(
        select('e').by('collaborationHours').sum()
    ).unfold()
==>[marketing, engineering]=2
==>[sales, marketing]=2
==>[engineering, sales]=3
==>[engineering, marketing]=2
Marc

Op donderdag 17 december 2020 om 14:50:11 UTC+1 schreef kt...@...:
Vishu,

This may not be optimal, but seems to work:

g.E().hasLabel('collaboration').as('e').outV().values('organization').as('1').select('e').inV().values('organization').as('2').select('e').group().by(select('1', '2')).by(values('collaborationHours').sum()).unfold();

==>{1=engineering, 2=marketing}=2
==>{1=marketing, 2=engineering}=2
==>{1=engineering, 2=sales}=3
==>{1=sales, 2=marketing}=2

Note, you have some leading spaces in your Gremlin on 'collaborationHours' I had to remove, and with the data you provided the engineering/sales total is 3, not 4.

Kevin

On Wed, Dec 16, 2020 at 11:57 PM vishnu gajendran <gg...@...> wrote:
Hello,

I request your help regarding the janus graph query which I am trying to construct. Let's consider the following graph where each vertex denotes a person and the edge between any two vertex denotes collaboration between them.

Vertices:
p1 = graph.addVertex('person')
p1.property('personId', 1)
p1.property('organization', "engineering")

p2 = graph.addVertex('person')
p2.property('personId', 2)
p2.property('organization', "sales")

p3 = graph.addVertex('person')
p3.property('personId', 3)
p3.property('organization', "marketing")

p4 = graph.addVertex('person')
p4.property('personId', 4)
p4.property('organization', "engineering")

Edges:
p1.addEdge('collaboration', p2, 'collaborationHours', 1)
p1.addEdge('collaboration', p3, 'collaborationHours', 2)

p2.addEdge('collaboration', p3, 'collaborationHours', 2)

p3.addEdge('collaboration', p4, ' collaborationHours', 2)

p4.addEdge('collaboration', p2, ' collaborationHours', 2)

Expected Result is the following table:

Organization1 Organization2 Total Collaboration Hours
Engineering Sales 4
Engineering Marketing 2
Sales Marketing 2
Marketing Engineering 2

Here, I am trying to aggregate the "person to person" graph into "organization to organization" graph. Does JanusGraph support such aggregation queries? If yes, can you please help me with the query for the same?

Thanks

--
You received this message because you are subscribed to the Google Groups "JanusGraph users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-users/5fb20cf1-0aeb-4128-91da-857ec6295587n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "JanusGraph users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgra...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-users/16a43300-59ae-4727-920c-b5d4cdb96820n%40googlegroups.com.

Re: Aggregating edges based on the source & target vertex attributes

HadoopMarc <bi...@...>

#5438

And here a small variation without the keys and with some code formatting:

g.V().as('a').outE().as('e').inV().as('b').
    group().by(
        union(select('a').values('organization'), select('b').values('organization')).fold()
    ).by(
        select('e').by('collaborationHours').sum()
    ).unfold()

==>[marketing, engineering]=2
==>[sales, marketing]=2
==>[engineering, sales]=3
==>[engineering, marketing]=2

Marc

Op donderdag 17 december 2020 om 14:50:11 UTC+1 schreef kt...@...:

Show quoted text

Vishu,

This may not be optimal, but seems to work:

g.E().hasLabel('collaboration').as('e').outV().values('organization').as('1').select('e').inV().values('organization').as('2').select('e').group().by(select('1', '2')).by(values('collaborationHours').sum()).unfold();

==>{1=engineering, 2=marketing}=2
==>{1=marketing, 2=engineering}=2
==>{1=engineering, 2=sales}=3
==>{1=sales, 2=marketing}=2

Note, you have some leading spaces in your Gremlin on 'collaborationHours' I had to remove, and with the data you provided the engineering/sales total is 3, not 4.

Kevin

On Wed, Dec 16, 2020 at 11:57 PM vishnu gajendran <gg...@...> wrote:
Hello,

I request your help regarding the janus graph query which I am trying to construct. Let's consider the following graph where each vertex denotes a person and the edge between any two vertex denotes collaboration between them.

Vertices:
p1 = graph.addVertex('person')
p1.property('personId', 1)
p1.property('organization', "engineering")

p2 = graph.addVertex('person')
p2.property('personId', 2)
p2.property('organization', "sales")

p3 = graph.addVertex('person')
p3.property('personId', 3)
p3.property('organization', "marketing")

p4 = graph.addVertex('person')
p4.property('personId', 4)
p4.property('organization', "engineering")

Edges:
p1.addEdge('collaboration', p2, 'collaborationHours', 1)
p1.addEdge('collaboration', p3, 'collaborationHours', 2)

p2.addEdge('collaboration', p3, 'collaborationHours', 2)

p3.addEdge('collaboration', p4, ' collaborationHours', 2)

p4.addEdge('collaboration', p2, ' collaborationHours', 2)

Expected Result is the following table:

Organization1 Organization2 Total Collaboration Hours
Engineering Sales 4
Engineering Marketing 2
Sales Marketing 2
Marketing Engineering 2

Here, I am trying to aggregate the "person to person" graph into "organization to organization" graph. Does JanusGraph support such aggregation queries? If yes, can you please help me with the query for the same?

Thanks

--
You received this message because you are subscribed to the Google Groups "JanusGraph users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-users/5fb20cf1-0aeb-4128-91da-857ec6295587n%40googlegroups.com.

Re: Aggregating edges based on the source & target vertex attributes

Kevin Schmidt <ktsc...@...>

#5437

Vishu,

This may not be optimal, but seems to work:

g.E().hasLabel('collaboration').as('e').outV().values('organization').as('1').select('e').inV().values('organization').as('2').select('e').group().by(select('1', '2')).by(values('collaborationHours').sum()).unfold();

==>{1=engineering, 2=marketing}=2
==>{1=marketing, 2=engineering}=2
==>{1=engineering, 2=sales}=3
==>{1=sales, 2=marketing}=2

Note, you have some leading spaces in your Gremlin on 'collaborationHours' I had to remove, and with the data you provided the engineering/sales total is 3, not 4.

Kevin

Show quoted text

On Wed, Dec 16, 2020 at 11:57 PM vishnu gajendran <ggvis...@...> wrote:

Hello,

I request your help regarding the janus graph query which I am trying to construct. Let's consider the following graph where each vertex denotes a person and the edge between any two vertex denotes collaboration between them.

Vertices:
p1 = graph.addVertex('person')
p1.property('personId', 1)
p1.property('organization', "engineering")

p2 = graph.addVertex('person')
p2.property('personId', 2)
p2.property('organization', "sales")

p3 = graph.addVertex('person')
p3.property('personId', 3)
p3.property('organization', "marketing")

p4 = graph.addVertex('person')
p4.property('personId', 4)
p4.property('organization', "engineering")

Edges:
p1.addEdge('collaboration', p2, 'collaborationHours', 1)
p1.addEdge('collaboration', p3, 'collaborationHours', 2)

p2.addEdge('collaboration', p3, 'collaborationHours', 2)

p3.addEdge('collaboration', p4, ' collaborationHours', 2)

p4.addEdge('collaboration', p2, ' collaborationHours', 2)

Expected Result is the following table:

Organization1 Organization2 Total Collaboration Hours
Engineering Sales 4
Engineering Marketing 2
Sales Marketing 2
Marketing Engineering 2

Here, I am trying to aggregate the "person to person" graph into "organization to organization" graph. Does JanusGraph support such aggregation queries? If yes, can you please help me with the query for the same?

Thanks

--
You received this message because you are subscribed to the Google Groups "JanusGraph users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgra...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-users/5fb20cf1-0aeb-4128-91da-857ec6295587n%40googlegroups.com.

Re: JanusGraph 0.5.2 and BigTable

BO XUAN LI <libo...@...>

#5440

Hi Assaf,

I am not familiar with GKE but I can try to answer some of your questions:

> how does a traversal behave when looking up based on an index key when the key is not yet indexed

Assuming the index has been enabled. If a particular key is still in the indexing process (e.g. you are in the middle of a committing process) in one thread, then another thread will not be able to find any data because it finds nothing in the index key lookup. Note that when you are using mixed index, the data is written to your primary backend (e.g. hbase) first, and then mixed index backend (e.g. Elasticsearch). If the data has already been written into hbase but not into Elasticsearch yet, the querying thread cannot find any data (if JanusGraph decides your query can be satisfied by a mixed index).

> org.janusgraph.diskstorage.locking.PermanentLockingException: Local lock contention at org.janusgraph.diskstorage.locking.AbstractLocker.writeLock(AbstractLocker.java:327)

This usually happens when you have multiple local threads (running on the same JVM instance) contending for the same lock. You might want to check your application logic.

Best regards,

Boxuan

Show quoted text

On Dec 17, 2020, at 6:16 PM, Assaf Schwartz <schw...@...> wrote:

Could this be related to delays in indexing? I don't know how to figure out of such exists, but assuming this happens -
how does a traversal behave when looking up based on an index key when the key is not yet indexed?

On Thursday, December 17, 2020 at 10:54:32 AM UTC+2 Assaf Schwartz wrote:
Hi All,

I'm experiencing an issues with running JanusGraph (on top of GKE) against BigTable.
This is the general setup description:
We are using a single node BigTable cluster (for development / integration purposes) with the vanilla 0.5.2 docker.
Indexing is configured to be done with ES (also running on GKE)
JanusGraph is configured through environment variables:
janusgraph.storage.backend=hbase
janusgraph.storage.hbase.ext.hbase.client.connection.impl=com.google.cloud.bigtable.hbase2_x.BigtableConnection
janusgraph.storage.hbase.ext.google.bigtable.project.id=<project_id>
janusgraph.storage.hbase.ext.google.bigtable.instance.id=<bt>
Interaction with JanusGraph are done only through a single gRPC server that is running gremlin-python, let's call it DB-SERVER.
Last time we've done testing against BT was with version 0.4.1 of JanusGraph, precompiled to support HBase1.
All of our components communicate via gRPC.
Description of the problem:
The DB-SERVER creates a Vertex i, generate some XML to represent work to be done, and sends it to another service for processing, let's call in ORCHESTRATOR.
The ORCHESTRATOR generates two properties, w and r (local identifiers) and sends them back to the DB-SERVER, so they will be set as properties on Vertex i. These two properties are also mixed String indexes.
After setting the properties, DB-SERVER will ack ORCHESTRATOR, which will start processing. As part of the processing, ORCHESTRATOR will send updates back to the DB-SERVER using w and r.
On getting these updates DB-SERVER, it will try looking up Vertex i based on w and r, like so:
g.V().has("r", <some_r>).has("w", <some_w>).next()
At that point, a null / None is returned as the traversal fails to find Vertex i.
Trying the same traversal in a separate console (python and gremlin) does fetch the vertex. Since it's a single instance cluster, I ruled out any eventual consistency issues.
I'm not sure if it's a regression introduced after 0.4.1.
I've also validated that db-caching is turned off.

Help! :)
Many thanks in advance,
Assaf

--
You received this message because you are subscribed to the Google Groups "JanusGraph users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgra...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-users/d4373c5a-ab97-4aa4-a143-f26c3ce50677n%40googlegroups.com.

Re: JanusGraph 0.5.2 and BigTable

"ow...@gmail.com" <owner...@...>

#5436

You can try to use composite index for checking mixedindex delay

четверг, 17 декабря 2020 г. в 13:16:43 UTC+3, Assaf Schwartz:

Show quoted text

Could this be related to delays in indexing? I don't know how to figure out of such exists, but assuming this happens -
how does a traversal behave when looking up based on an index key when the key is not yet indexed?

On Thursday, December 17, 2020 at 10:54:32 AM UTC+2 Assaf Schwartz wrote:
Hi All,

I'm experiencing an issues with running JanusGraph (on top of GKE) against BigTable.
This is the general setup description:
We are using a single node BigTable cluster (for development / integration purposes) with the vanilla 0.5.2 docker.
Indexing is configured to be done with ES (also running on GKE)
JanusGraph is configured through environment variables:
janusgraph.storage.backend=hbase
janusgraph.storage.hbase.ext.hbase.client.connection.impl=com.google.cloud.bigtable.hbase2_x.BigtableConnection
janusgraph.storage.hbase.ext.google.bigtable.project.id=<project_id>
janusgraph.storage.hbase.ext.google.bigtable.instance.id=<bt>
Interaction with JanusGraph are done only through a single gRPC server that is running gremlin-python, let's call it DB-SERVER.
Last time we've done testing against BT was with version 0.4.1 of JanusGraph, precompiled to support HBase1.
All of our components communicate via gRPC.
Description of the problem:
The DB-SERVER creates a Vertex i, generate some XML to represent work to be done, and sends it to another service for processing, let's call in ORCHESTRATOR.
The ORCHESTRATOR generates two properties, w and r (local identifiers) and sends them back to the DB-SERVER, so they will be set as properties on Vertex i. These two properties are also mixed String indexes.
After setting the properties, DB-SERVER will ack ORCHESTRATOR, which will start processing. As part of the processing, ORCHESTRATOR will send updates back to the DB-SERVER using w and r.
On getting these updates DB-SERVER, it will try looking up Vertex i based on w and r, like so:
g.V().has("r", <some_r>).has("w", <some_w>).next()
At that point, a null / None is returned as the traversal fails to find Vertex i.
Trying the same traversal in a separate console (python and gremlin) does fetch the vertex. Since it's a single instance cluster, I ruled out any eventual consistency issues.
I'm not sure if it's a regression introduced after 0.4.1.
I've also validated that db-caching is turned off.

Help! :)
Many thanks in advance,
Assaf

Re: JanusGraph 0.5.2 and BigTable

Assaf Schwartz <schw...@...>

#5435

Could this be related to delays in indexing? I don't know how to figure out of such exists, but assuming this happens -

how does a traversal behave when looking up based on an index key when the key is not yet indexed?

Show quoted text

On Thursday, December 17, 2020 at 10:54:32 AM UTC+2 Assaf Schwartz wrote:

Hi All,

I'm experiencing an issues with running JanusGraph (on top of GKE) against BigTable.
This is the general setup description:
We are using a single node BigTable cluster (for development / integration purposes) with the vanilla 0.5.2 docker.
Indexing is configured to be done with ES (also running on GKE)
JanusGraph is configured through environment variables:
janusgraph.storage.backend=hbase
janusgraph.storage.hbase.ext.hbase.client.connection.impl=com.google.cloud.bigtable.hbase2_x.BigtableConnection
janusgraph.storage.hbase.ext.google.bigtable.project.id=<project_id>
janusgraph.storage.hbase.ext.google.bigtable.instance.id=<bt>
Interaction with JanusGraph are done only through a single gRPC server that is running gremlin-python, let's call it DB-SERVER.
Last time we've done testing against BT was with version 0.4.1 of JanusGraph, precompiled to support HBase1.
All of our components communicate via gRPC.
Description of the problem:
The DB-SERVER creates a Vertex i, generate some XML to represent work to be done, and sends it to another service for processing, let's call in ORCHESTRATOR.
The ORCHESTRATOR generates two properties, w and r (local identifiers) and sends them back to the DB-SERVER, so they will be set as properties on Vertex i. These two properties are also mixed String indexes.
After setting the properties, DB-SERVER will ack ORCHESTRATOR, which will start processing. As part of the processing, ORCHESTRATOR will send updates back to the DB-SERVER using w and r.
On getting these updates DB-SERVER, it will try looking up Vertex i based on w and r, like so:
g.V().has("r", <some_r>).has("w", <some_w>).next()
At that point, a null / None is returned as the traversal fails to find Vertex i.
Trying the same traversal in a separate console (python and gremlin) does fetch the vertex. Since it's a single instance cluster, I ruled out any eventual consistency issues.
I'm not sure if it's a regression introduced after 0.4.1.
I've also validated that db-caching is turned off.

Help! :)
Many thanks in advance,
Assaf

Re: JanusGraph 0.5.2 and BigTable

Assaf Schwartz <schw...@...>

#5434

From time to time, usually after setting up a fresh copy of the BT and Janus, I'll encounter errors relating to locking. However this doesn't happen every time.

Sorry, I can't see to be able copy the logs nicely from the GCP Cloud logging.

org.janusgraph.diskstorage.locking.PermanentLockingException: Local lock contention at org.janusgraph.diskstorage.locking.AbstractLocker.writeLock(AbstractLocker.java:327) at org.janusgraph.diskstorage.locking.consistentkey.ExpectedValueCheckingStore.acquireLock(ExpectedValueCheckingStore.java:103) at org.janusgraph.diskstorage.keycolumnvalue.KCVSProxy.acquireLock(KCVSProxy.java:51) at org.janusgraph.diskstorage.BackendTransaction.acquireIndexLock(BackendTransaction.java:255) at org.janusgraph.graphdb.database.StandardJanusGraph.prepareCommit(StandardJanusGraph.java:591) at org.janusgraph.graphdb.database.StandardJanusGraph.commit(StandardJanusGraph.java:712) at org.janusgraph.graphdb.transaction.StandardJanusGraphTx.commit(StandardJanusGraphTx.java:1425) at org.janusgraph.graphdb.tinkerpop.JanusGraphBlueprintsGraph$GraphTransaction.doCommit(JanusGraphBlueprintsGraph.java:297) at org.apache.tinkerpop.gremlin.structure.util.AbstractTransaction.commit(AbstractTransaction.java:104) at org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor.onTraversalSuccess(TraversalOpProcessor.java:471) at org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor.handleIterator(TraversalOpProcessor.java:603) at org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor.lambda$iterateBytecodeTraversal$4(TraversalOpProcessor.java:411) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)

Show quoted text

On Thursday, December 17, 2020 at 10:54:32 AM UTC+2 Assaf Schwartz wrote:

Hi All,

I'm experiencing an issues with running JanusGraph (on top of GKE) against BigTable.
This is the general setup description:
We are using a single node BigTable cluster (for development / integration purposes) with the vanilla 0.5.2 docker.
Indexing is configured to be done with ES (also running on GKE)
JanusGraph is configured through environment variables:
janusgraph.storage.backend=hbase
janusgraph.storage.hbase.ext.hbase.client.connection.impl=com.google.cloud.bigtable.hbase2_x.BigtableConnection
janusgraph.storage.hbase.ext.google.bigtable.project.id=<project_id>
janusgraph.storage.hbase.ext.google.bigtable.instance.id=<bt>
Interaction with JanusGraph are done only through a single gRPC server that is running gremlin-python, let's call it DB-SERVER.
Last time we've done testing against BT was with version 0.4.1 of JanusGraph, precompiled to support HBase1.
All of our components communicate via gRPC.
Description of the problem:
The DB-SERVER creates a Vertex i, generate some XML to represent work to be done, and sends it to another service for processing, let's call in ORCHESTRATOR.
The ORCHESTRATOR generates two properties, w and r (local identifiers) and sends them back to the DB-SERVER, so they will be set as properties on Vertex i. These two properties are also mixed String indexes.
After setting the properties, DB-SERVER will ack ORCHESTRATOR, which will start processing. As part of the processing, ORCHESTRATOR will send updates back to the DB-SERVER using w and r.
On getting these updates DB-SERVER, it will try looking up Vertex i based on w and r, like so:
g.V().has("r", <some_r>).has("w", <some_w>).next()
At that point, a null / None is returned as the traversal fails to find Vertex i.
Trying the same traversal in a separate console (python and gremlin) does fetch the vertex. Since it's a single instance cluster, I ruled out any eventual consistency issues.
I'm not sure if it's a regression introduced after 0.4.1.
I've also validated that db-caching is turned off.

Help! :)
Many thanks in advance,
Assaf

JanusGraph 0.5.2 and BigTable

Assaf Schwartz <schw...@...>

#5433

Hi All,

I'm experiencing an issues with running JanusGraph (on top of GKE) against BigTable.

This is the general setup description:

We are using a single node BigTable cluster (for development / integration purposes) with the vanilla 0.5.2 docker.
Indexing is configured to be done with ES (also running on GKE)
JanusGraph is configured through environment variables:
- janusgraph.storage.backend=hbase
- janusgraph.storage.hbase.ext.hbase.client.connection.impl=com.google.cloud.bigtable.hbase2_x.BigtableConnection
- janusgraph.storage.hbase.ext.google.bigtable.project.id=<project_id>
- janusgraph.storage.hbase.ext.google.bigtable.instance.id=<bt>
Interaction with JanusGraph are done only through a single gRPC server that is running gremlin-python, let's call it DB-SERVER.
Last time we've done testing against BT was with version 0.4.1 of JanusGraph, precompiled to support HBase1.
All of our components communicate via gRPC.

Description of the problem:

The DB-SERVER creates a Vertex i, generate some XML to represent work to be done, and sends it to another service for processing, let's call in ORCHESTRATOR.
The ORCHESTRATOR generates two properties, w and r (local identifiers) and sends them back to the DB-SERVER, so they will be set as properties on Vertex i. These two properties are also mixed String indexes.
After setting the properties, DB-SERVER will ack ORCHESTRATOR, which will start processing. As part of the processing, ORCHESTRATOR will send updates back to the DB-SERVER using w and r.
On getting these updates DB-SERVER, it will try looking up Vertex i based on w and r, like so:
g.V().has("r", <some_r>).has("w", <some_w>).next()
At that point, a null / None is returned as the traversal fails to find Vertex i.
Trying the same traversal in a separate console (python and gremlin) does fetch the vertex. Since it's a single instance cluster, I ruled out any eventual consistency issues.

I'm not sure if it's a regression introduced after 0.4.1.

I've also validated that db-caching is turned off.

Help! :)

Many thanks in advance,

Assaf

Re: Use index for sorting

toom <to...@...>

#5432

Thank you very much, I'll try that.

Toom.

Show quoted text

On Thursday, December 17, 2020 at 8:28:52 AM UTC+1 ow...@... wrote:

We use special strategy that rewrite order comparator for supporting missing values https://gist.github.com/mad/6bef960d51d7a0d89a8c310851023303

пятница, 4 декабря 2020 г. в 09:59:13 UTC+3, t...@...:
The problem of using custom value for null is that we need to choose a value for each data type, and hope that nobody will try to use this particular value. I suppose it is feasible for data type like string, date or double but not for boolean.

Toom.
On Friday, December 4, 2020 at 2:22:02 AM UTC+1 li...@... wrote:
No, null support is an optional feature for graph providers. JanusGraph does not allow null value and I don’t think it will be supported (in near future).

Apart from the solution suggested by Marc, is it possible for you to come up with some custom value to represent null?

Best regards,
Boxuan

「toom <t...@...>」在 2020年12月4日週五，上午3:17 寫道：

Hi Marc,

Thank you for your response.
If I understand correctly, with TinkerPop 3.5 I will be able to sort on property with missing values. It is a good news.
Do you know it JanusGraph 0.6.0 will be release with that version ?

Regarding the impact of the step order on index use, I wrote a strategy [1] that put HasStep and OrderStep before FilterStep if they follow a GraphStep.

Best regards,

Toom.

[1] https://gist.github.com/To-om/e7e406d85dcdd65bc2a533960b50a1d2
On Thursday, December 3, 2020 at 8:17:27 AM UTC+1 HadoopMarc wrote:
Hi Toom,

No solution, but the exception that you mention comes from TinkerPop:
https://github.com/apache/tinkerpop/blob/b4928e1262174a68c3dc1f3234d4340e266f8d98/docs/src/upgrade/release-3.5.x.asciidoc (not released yet)

Apparently, you want all selected vertices, including the ones with null properties, so I would wait for TinkerPop 3.5 and in the mean time use your own workaround for a single filter criterion and do the ordering outside gremlin for more complex sets of filtering criteria.

Best wishes, Marc

Op woensdag 2 december 2020 om 08:13:05 UTC+1 schreef t...@...:
Hello,

I'm using JanusGraph with Cassandra (0.5.2) and ElasticSearch.

I try to optimize my queries and use the mixed indexes as much as possible, in particular for sortings, but I have some difficulties:

It is not possible to sort by properties that can have missing values (or I get a "The property does not exist as the key has no associated value for the provided element"). Therefore I used ".order().by(coalesce(values('closingDate'), new Date()))" but in this case, the index is not used.

If there is only one sorting criterion, I probably can do something like:

g.inject(1).union(
g.V().hasLabel('Case').has('closingDate').order().by('closingDate'),
g.V().hasLabel('Case').hasNot('closingDate'))

But what is my best option if I want to use several criteria?

I also note that the FilterRankingStrategy strategy can have negative effect on performance when there are filters that don't use index. For example, the following query is faster without step reordering.

g.V().hasLabel('Case').has('closingDate').order().by('closingDate').filter(out('attachment').has('file'))

FilterRanking swaps order() and filter() steps and then index is not used for sorting.

Any help will be much appreciated.

Toom.

--
You received this message because you are subscribed to the Google Groups "JanusGraph users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-users/c6bcb878-bfc2-4d8f-a3ee-38cc214382bcn%40googlegroups.com.

Re: Use index for sorting

"ow...@gmail.com" <owner...@...>

#5431

We use special strategy that rewrite order comparator for supporting missing values https://gist.github.com/mad/6bef960d51d7a0d89a8c310851023303

пятница, 4 декабря 2020 г. в 09:59:13 UTC+3, t...@...:

Show quoted text

The problem of using custom value for null is that we need to choose a value for each data type, and hope that nobody will try to use this particular value. I suppose it is feasible for data type like string, date or double but not for boolean.

Toom.
On Friday, December 4, 2020 at 2:22:02 AM UTC+1 li...@... wrote:
No, null support is an optional feature for graph providers. JanusGraph does not allow null value and I don’t think it will be supported (in near future).

Apart from the solution suggested by Marc, is it possible for you to come up with some custom value to represent null?

Best regards,
Boxuan

「toom <t...@...>」在 2020年12月4日週五，上午3:17 寫道：

Hi Marc,

Thank you for your response.
If I understand correctly, with TinkerPop 3.5 I will be able to sort on property with missing values. It is a good news.
Do you know it JanusGraph 0.6.0 will be release with that version ?

Regarding the impact of the step order on index use, I wrote a strategy [1] that put HasStep and OrderStep before FilterStep if they follow a GraphStep.

Best regards,

Toom.

[1] https://gist.github.com/To-om/e7e406d85dcdd65bc2a533960b50a1d2
On Thursday, December 3, 2020 at 8:17:27 AM UTC+1 HadoopMarc wrote:
Hi Toom,

No solution, but the exception that you mention comes from TinkerPop:
https://github.com/apache/tinkerpop/blob/b4928e1262174a68c3dc1f3234d4340e266f8d98/docs/src/upgrade/release-3.5.x.asciidoc (not released yet)

Apparently, you want all selected vertices, including the ones with null properties, so I would wait for TinkerPop 3.5 and in the mean time use your own workaround for a single filter criterion and do the ordering outside gremlin for more complex sets of filtering criteria.

Best wishes, Marc

Op woensdag 2 december 2020 om 08:13:05 UTC+1 schreef t...@...:
Hello,

I'm using JanusGraph with Cassandra (0.5.2) and ElasticSearch.

I try to optimize my queries and use the mixed indexes as much as possible, in particular for sortings, but I have some difficulties:

It is not possible to sort by properties that can have missing values (or I get a "The property does not exist as the key has no associated value for the provided element"). Therefore I used ".order().by(coalesce(values('closingDate'), new Date()))" but in this case, the index is not used.

If there is only one sorting criterion, I probably can do something like:

g.inject(1).union(
g.V().hasLabel('Case').has('closingDate').order().by('closingDate'),
g.V().hasLabel('Case').hasNot('closingDate'))

But what is my best option if I want to use several criteria?

I also note that the FilterRankingStrategy strategy can have negative effect on performance when there are filters that don't use index. For example, the following query is faster without step reordering.

g.V().hasLabel('Case').has('closingDate').order().by('closingDate').filter(out('attachment').has('file'))

FilterRanking swaps order() and filter() steps and then index is not used for sorting.

Any help will be much appreciated.

Toom.

--
You received this message because you are subscribed to the Google Groups "JanusGraph users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-users/c6bcb878-bfc2-4d8f-a3ee-38cc214382bcn%40googlegroups.com.

Aggregating edges based on the source & target vertex attributes

vishnu gajendran <ggvis...@...>

#5430

Hello,

I request your help regarding the janus graph query which I am trying to construct. Let's consider the following graph where each vertex denotes a person and the edge between any two vertex denotes collaboration between them.

Vertices:

p1 = graph.addVertex('person')

p1.property('personId', 1)

p1.property('organization', "engineering")

p2 = graph.addVertex('person')

p2.property('personId', 2)

p2.property('organization', "sales")

p3 = graph.addVertex('person')

p3.property('personId', 3)

p3.property('organization', "marketing")

p4 = graph.addVertex('person')

p4.property('personId', 4)

p4.property('organization', "engineering")

Edges:

p1.addEdge('collaboration', p2, 'collaborationHours', 1)

p1.addEdge('collaboration', p3, 'collaborationHours', 2)

p2.addEdge('collaboration', p3, 'collaborationHours', 2)

p3.addEdge('collaboration', p4, ' collaborationHours', 2)

p4.addEdge('collaboration', p2, ' collaborationHours', 2)

Expected Result is the following table:

Organization1 Organization2 Total Collaboration Hours
Engineering Sales 4
Engineering Marketing 2
Sales Marketing 2
Marketing Engineering 2

Here, I am trying to aggregate the "person to person" graph into "organization to organization" graph. Does JanusGraph support such aggregation queries? If yes, can you please help me with the query for the same?

Thanks

Re: Condition where-inV-is does not work

HadoopMarc <bi...@...>

#5429

Hi Anton,

To compare objects you need the eq() predicate, not the is() step (see https://tinkerpop.apache.org/docs/current/reference/#a-note-on-predicates). Also note that JanusGraph uses RelationIdentifier objects as id's.

So, give the following a try (not tested):

g.V(110792).as('a').V(41099392).outE('LINK').where(inV().eq('a'))

Best wishes, Marc

Op woensdag 16 december 2020 om 10:03:33 UTC+1 schreef Anton Eroshenko:

Show quoted text

Thanks for reply.
In real query I don't have an ID, that's why I use traversal in where clause. Tried this one, but it does not work either:
g.V(41099392).outE('LINK').where(inV().hasId(V(110792).id()))

On Wednesday, December 16, 2020 at 1:45:50 AM UTC+7 Amiya wrote:

Try g.V(41099392).outE('LINK').where(inV().hasId(110792))

On Tuesday, 15 December 2020 at 20:45:40 UTC+5:30 Anton Eroshenko wrote:

Hi, JanusGraph users.
I try a simple query from TinkerPop docs with my JanusGraph installation, but it does not work as expected. How is it possible:
gremlin> g.V(41099392).outE('LINK').inV()
==>v[110792]
==>v[81993864]
gremlin> g.V(41099392).outE('LINK').where(inV().is(V(110792)))
gremlin>

The last query returns nothing...
How to filter out vertices by traversal? Appreciate any help

Re: addE doesn't create more than 1 edge

Anton Eroshenko <erosh...@...>

#5428

Thanks for your explanation. I got the idea, that "many" side of "one-to-many" relationship should go first when adding edges.

Show quoted text

On Wednesday, December 16, 2020 at 2:03:31 AM UTC+7 Amiya wrote:

Marc is correct about "It is not a bug: the addE() step only adds one edge per traverser".
I think query by Mark will create a self link.

Below query might work (not tested)

g.V().hasLabel('Activity').as('a').
V().has('person', 'id', within('p1', 'p2')).addE('LINK').from('a')
On Tuesday, 15 December 2020 at 20:36:56 UTC+5:30 HadoopMarc wrote:
Hi Anton,

It is not a bug: the addE() step only adds one edge per traverser. Also, using g.V() twice is an anti-pattern. Try it the other way around, something like (not tested):
g.V().hasLabel('person').has('id', within('p1', 'p2')).as('a').addE('LINK').from('a')

Now the addE() step runs on two traversers.

HTH, Marc

Op dinsdag 15 december 2020 om 12:22:56 UTC+1 schreef Anton Eroshenko:

I'm trying to link one vertex (let's say Activity) with two others (person), I expect to have two
edges in result, the request below creates only one.

gremlin> g.V().hasLabel('Activity')
==>v[40984624]
gremlin> g.V().hasLabel('person').has('id', within('p1', 'p2'))
==>v[40996896]
==>v[41037952]
gremlin> g.V().hasLabel('Activity').addE('LINK').to(g.V().hasLabel('person').has('id', within('p1', 'p2')))
==>e[oe5mu-oefxs-b0np-oepeo][40984624-RESP->40996896]

Is it a bug or I'm missing something?

Re: Condition where-inV-is does not work

Anton Eroshenko <erosh...@...>

#5427

Thanks for reply.

In real query I don't have an ID, that's why I use traversal in where clause. Tried this one, but it does not work either:

g.V(41099392).outE('LINK').where(inV().hasId(V(110792).id()))

Show quoted text

On Wednesday, December 16, 2020 at 1:45:50 AM UTC+7 Amiya wrote:

Try g.V(41099392).outE('LINK').where(inV().hasId(110792))

On Tuesday, 15 December 2020 at 20:45:40 UTC+5:30 Anton Eroshenko wrote:

Hi, JanusGraph users.
I try a simple query from TinkerPop docs with my JanusGraph installation, but it does not work as expected. How is it possible:
gremlin> g.V(41099392).outE('LINK').inV()
==>v[110792]
==>v[81993864]
gremlin> g.V(41099392).outE('LINK').where(inV().is(V(110792)))
gremlin>

The last query returns nothing...
How to filter out vertices by traversal? Appreciate any help

Re: How to improve traversal query performance

Manabu Kotani <smallcany...@...>

#5426

Hi Marc,

Thank you for your too much advice.

I will keep learning about Gremlin query for better performance.

Thanks a lot!

Manabu.

2020年12月11日金曜日 22:40:21 UTC+9 HadoopMarc:

Show quoted text

Hi Manabu,

Yes, providing an example graph works much better in exploring the problem space. I am afraid, though, that I did not find much that will help you out.
on a single machine with cassandra and using gremlin console with embedded janusgraph, the total query times stated by profile() deviated significantly from the experienced wall clock times even when everything had a cold start:
                                                                total profile (ms)               System.currentTimeMillis(ms)
repeat query, no query-batch             1113                                      1775
repeat query             622             1096
repeat query (warm caches)                 40                                         360
Did you do any wall clock query performance tests on your production system with warmed caches? Results might be better - or worse - than suggested by profile().
the values 5, 161, 9, 8,... under the repeat step add up to the number of touched edges (2828) in the graph. For this generated graph the number of traversers (2925) is dominated by this number of edges. Trying to bulk any intermediate results using sack will have little effect (in contrary to what I suggested earlier). From another perspective, you can check that the following query without any path references still results in the same number of 2925 traversers:
g.V().has('serial', within(startIds)).repeat(inE('assembled').outV()).emit().profile()
other people wanting to play with this graph should use the following line in Manabu's code:

columns = line.split(' ', -1)
So, concluding, there does not seem to be much you can do about the query: you simply want a large resultset from a traversal with multiple steps. Depending on the size of you graph, you could hod the graph in memory using the inmemory backend, or you could replace cassandra with cql and put on it on infrastructure with SSD storage. Of course, you could also precompute and store results, or split up the query with repeat().times(1), repeat().times(2), etc. for faster intermediate results.

Best wishes,    Marc

Op dinsdag 8 december 2020 om 08:56:03 UTC+1 schreef Manabu Kotani:
Hi Marc,

Profile outputs I tried.

1. g.V().has('serial',within('XXXXXX','YYYYYY')).inE('assembled').outV()
----------------------------------------------------------------------
gremlin> g.V().has('serial', within('1654145144','1648418968','1652445288','1654952168','1653379120','1654325440','1653383216','1658298568','1649680536','1649819672','1654964456','1649729552','1656103144','1655460032','1656111336','1654669360')).inE('assembled').outV().profile()
==>Traversal Metrics
Step Count Traversers Time (ms) % Dur
=============================================================================================================
JanusGraphStep([],[serial.within([1654145144, 1... 16 16 18.860 63.13
\_condition=((serial = 1654145144 OR serial = 1648418968 OR serial = 1652445288 OR serial = 1654952168 OR
serial = 1653379120 OR serial = 1654325440 OR serial = 1653383216 OR serial = 1658298568 OR se
rial = 1649680536 OR serial = 1649819672 OR serial = 1654964456 OR serial = 1649729552 OR seri
al = 1656103144 OR serial = 1655460032 OR serial = 1656111336 OR serial = 1654669360))
\_orders=[]
\_isFitted=true
\_isOrdered=true
\_query=multiKSQ[16]@2000
\_index=bySerial
optimization 0.058
optimization 0.694
backend-query 16 17.823
\_query=bySerial:multiKSQ[16]@2000
\_limit=2000
JanusGraphVertexStep(IN,[assembled],vertex) 73 73 11.016 36.87
\_condition=type[assembled]
\_orders=[]
\_isFitted=true
\_isOrdered=true
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
\_multi=true
\_vertices=16
optimization 0.205
backend-query 73 9.332
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
>TOTAL - - 29.877 -

2. g.V().has('serial',within('XXXXXX','YYYYYY')).as('a').in('assembled').inE('assembled').where(outV(), neq('a')).outV()            // query not tested
----------------------------------------------------------------------
gremlin> g.V().has('serial', within('1654145144','1648418968','1652445288','1654952168','1653379120','1654325440','1653383216','1658298568','1649680536','1649819672','1654964456','1649729552','1656103144','1655460032','1656111336','1654669360')).as('a').in('assembled').inE('assembled').where(outV().is(neq('a'))).outV().profile()
==>Traversal Metrics
Step Count Traversers Time (ms) % Dur
=============================================================================================================
JanusGraphStep([],[serial.within([1654145144, 1... 16 16 19.980 26.52
\_condition=((serial = 1654145144 OR serial = 1648418968 OR serial = 1652445288 OR serial = 1654952168 OR
serial = 1653379120 OR serial = 1654325440 OR serial = 1653383216 OR serial = 1658298568 OR se
rial = 1649680536 OR serial = 1649819672 OR serial = 1654964456 OR serial = 1649729552 OR seri
al = 1656103144 OR serial = 1655460032 OR serial = 1656111336 OR serial = 1654669360))
\_orders=[]
\_isFitted=true
\_isOrdered=true
\_query=multiKSQ[16]@2000
\_index=bySerial
optimization 0.026
optimization 0.588
backend-query 16 18.813
\_query=bySerial:multiKSQ[16]@2000
\_limit=2000
JanusGraphVertexStep(IN,[assembled],vertex) 73 73 6.521 8.66
\_condition=type[assembled]
\_orders=[]
\_isFitted=true
\_isOrdered=true
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
\_multi=true
\_vertices=16
optimization 0.154
backend-query 73 5.310
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
JanusGraphVertexStep(IN,[assembled],edge) 2578 2578 20.170 26.77
\_condition=type[assembled]
\_orders=[]
\_isFitted=true
\_isOrdered=true
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
\_multi=true
\_vertices=59
optimization 0.032
backend-query 2578 10.266
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
TraversalFilterStep([EdgeVertexStep(OUT), Profi... 2578 2578 21.824 28.97
EdgeVertexStep(OUT) 2578 2578 4.776
IsStep(neq(a)) 6.172
EdgeVertexStep(OUT) 2578 2578 6.842 9.08
>TOTAL - - 75.338 -

3. Results I want to get.
----------------------------------------------------------------------
g.V().has('serial', within('1654145144','1648418968','1652445288','1654952168','1653379120','1654325440','1653383216','1658298568','1649680536','1649819672','1654964456','1649729552','1656103144','1655460032','1656111336','1654669360')).as('a').repeat(inE('assembled').as('b').outV().as('c').simplePath()).emit().select('a').id().as('parent').select('b').values('work_date').as('work_date').select('c').values('serial').as('child').select('parent','child','work_date').order().by('parent').by('child').by('work_date').profile()
==>Traversal Metrics
Step Count Traversers Time (ms) % Dur
=============================================================================================================
JanusGraphStep([],[serial.within([1654145144, 1... 16 16 24.028 4.95
\_condition=((serial = 1654145144 OR serial = 1648418968 OR serial = 1652445288 OR serial = 1654952168 OR
serial = 1653379120 OR serial = 1654325440 OR serial = 1653383216 OR serial = 1658298568 OR se
rial = 1649680536 OR serial = 1649819672 OR serial = 1654964456 OR serial = 1649729552 OR seri
al = 1656103144 OR serial = 1655460032 OR serial = 1656111336 OR serial = 1654669360))
\_orders=[]
\_isFitted=true
\_isOrdered=true
\_query=multiKSQ[16]@2000
\_index=bySerial
optimization 0.074
optimization 1.256
backend-query 16 312.583
\_query=bySerial:multiKSQ[16]@2000
\_limit=2000
RepeatStep([JanusGraphVertexStep(IN,[assembled]... 2925 2925 272.924 56.26
JanusGraphVertexStep(IN,[assembled],edge)@[b] 2925 2925 223.728
\_condition=type[assembled]
\_orders=[]
\_isFitted=true
\_isOrdered=true
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
\_multi=true
\_vertices=9
optimization 0.203
backend-query 5 1.557
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.020
backend-query 161 2.356
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.125
backend-query 9 25.853
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.023
backend-query 8 2.168
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.024
backend-query 0 1.808
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.026
backend-query 5 1.354
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.024
backend-query 161 1.989
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.040
backend-query 9 3.490
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.026
backend-query 0 2.231
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.061
backend-query 5 1.877
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.027
backend-query 161 4.645
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.056
backend-query 10 2.554
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.073
backend-query 9 4.274
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.026
backend-query 0 1.199
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.026
backend-query 5 1.165
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.025
backend-query 161 8.010
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.032
backend-query 9 1.542
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.032
backend-query 4 5.402
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.038
backend-query 5 4.173
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.029
backend-query 161 4.113
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.056
backend-query 9 1.617
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.035
backend-query 0 1.517
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.044
backend-query 5 1.522
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.045
backend-query 161 1.985
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.029
backend-query 9 1.435
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.028
backend-query 0 1.034
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.021
backend-query 3 1.108
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.024
backend-query 161 1.785
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.036
backend-query 9 7.190
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.032
backend-query 8 12.321
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.044
backend-query 0 1.926
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.032
backend-query 5 1.782
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.028
backend-query 161 3.398
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.031
backend-query 9 1.412
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.026
backend-query 0 1.212
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.035
backend-query 5 1.283
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.028
backend-query 161 2.149
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.035
backend-query 9 1.415
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.025
backend-query 1 1.214
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.025
backend-query 3 1.313
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.027
backend-query 161 2.004
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.038
backend-query 9 8.265
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.031
backend-query 0 1.718
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.028
backend-query 5 1.489
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.029
backend-query 161 2.066
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.029
backend-query 9 1.361
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.024
backend-query 2 1.454
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.026
backend-query 5 1.234
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.025
backend-query 161 1.819
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.027
backend-query 9 1.361
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.026
backend-query 0 1.136
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.028
backend-query 5 1.265
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.029
backend-query 161 10.425
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.040
backend-query 9 2.437
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.050
backend-query 0 1.462
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.049
backend-query 5 2.208
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.028
backend-query 163 2.415
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.035
backend-query 9 1.252
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.027
backend-query 0 1.164
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.032
backend-query 4 1.335
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.028
backend-query 161 1.944
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.028
backend-query 9 1.473
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.026
backend-query 0 1.114
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.025
backend-query 3 1.279
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.025
backend-query 161 1.867
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.033
backend-query 9 1.463
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.027
backend-query 0 1.169
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
EdgeVertexStep(OUT)@[c] 2925 2925 7.733
PathFilterStep(simple) 2925 2925 10.508
JanusGraphMultiQueryStep(RepeatEndStep) 2925 2925 14.827
RepeatEndStep 2925 2925 9.754
SelectOneStep(last,a) 2925 2925 8.340 1.72
IdStep@[parent] 2925 2925 7.347 1.51
SelectOneStep(last,b) 2925 2925 8.690 1.79
JanusGraphPropertiesStep([work_date],value)@[wo... 2925 2925 35.051 7.22
SelectOneStep(last,c) 2925 2925 9.512 1.96
JanusGraphPropertiesStep([serial],value)@[child] 2925 2925 79.337 16.35
\_condition=type[serial]
\_orders=[]
\_isFitted=true
\_isOrdered=true
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@811c505d
\_multi=true
\_vertices=302
optimization 0.044
backend-query 302 53.962
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@811c505d
SelectStep(last,[parent, child, work_date]) 2925 2925 10.705 2.21
OrderGlobalStep([[value(parent), asc], [value(c... 2925 2925 29.210 6.02
>TOTAL - - 485.149 -

Best regards,
Manabu

2020年11月26日木曜日 16:07:27 UTC+9 HadoopMarc:
Hi Manabu,

OK, I think for this graph structure your initial query is fine for getting the right output results. Still, to better understand the impact on the performance of using sack() you might want to split up your query during experimentation:
g.V().has('serial',within('XXXXXX','YYYYYY')).inE('assembled').outV()
g.V().has('serial',within('XXXXXX','YYYYYY')).as('a').in('assembled').inE('assembled').where(outV(), neq('a')).outV()            // query not tested

Note that I did not use the SimplePath() step, but because it probably precludes the bulking after adding appropriate sack() steps.
If you want others to step in for getting the sack() steps right, please provide the gremlin steps to create your sample graph and the query you have already tried with query output and profile() output.

Best wishes,      Marc

Op donderdag 26 november 2020 om 00:29:33 UTC+1 schreef Manabu Kotani:
Hi Marc,

Sorry, I forgot an attachment (Image of tree structure).

Relationships between vertices and edges are like below.
(Label:item, serial:A)<--[Label:assembled, work_date:2020-11-24]--(Label:item, serial:B)
(Label:item, serial:A)<--[Label:assembled, work_date:2020-11-25]--(Label:item, serial:C)
(Label:item, serial:B)<--[Label:assembled, work_date:2020-11-23]--(Label:item, serial:D)
(Label:item, serial:B)<--[Label:assembled, work_date:2020-11-22]--(Label:item, serial:E)
(Label:item, serial:C)<--[Label:assembled, work_date:2020-11-21]--(Label:item, serial:E)
(Label:item, serial:C)<--[Label:assembled, work_date:2020-11-20]--(Label:item, serial:F)

Best regards,
Manabu

2020年11月25日水曜日 19:55:54 UTC+9 HadoopMarc:
Hi Manabu,

What edge are present between vertices A,B,C,D,E,F?

If there are only edges A-B, A-C, A-D, A-E, A-F, you do not need repeat().

Best wishes,    Marc

Op woensdag 25 november 2020 om 09:22:34 UTC+1 schreef Manabu Kotani:
Hi Marc,

Thank you for your quick reply.

Sorry for the lack of my explanation.
I have a graph like below. (There are 3 levels in this figure, but not necessarily 3 levels.)

When query by "A" for property "serial", then I would like to get results like these.
1. A, B, 2020-11-24
2. A, C, 2020-11-25
3. A, D, 2020-11-23
4. A, E, 2020-11-21
5. A, E, 2020-11-22
6. A, F, 2020-11-20

In this situation, how shoud I use until() step?

Sorry for my low comprehension, I've just started to learn Gremlin.

Best regards,
Manabu

2020年11月25日水曜日 15:46:35 UTC+9 HadoopMarc:
Hi Manabu,

repeat()/simplePath()/emit() can have valid uses, although normally you combine it with the times() or until() step to limit the number of repeats. The profile from your query suggests that the repeat step never takes effect, that is, each traversal takes only a single step from parent to child. The repeat step is not wrong in itself, but if it is not necessary you do not want it to be there if you do not know its impact on performance.

Best wishes,    Marc

Op dinsdag 24 november 2020 om 08:43:36 UTC+1 schreef Manabu Kotani:
Hi Marc,

Thank you for your reply.

I'm reading ref docs that you referred about sack()/barrier(). But, I've not able to understand yet.

One question.
What means this you advised? repeat()/simplePath()/emit() steps should not be used?

in the current traversal the repeat(), simplePath() and emit() steps have no effect if the children do not assemble children themselves. So you can leave these steps out for clarity and to be sure that they do not influence the janusgraph execution plan
Best regards,
Manabu

2020年11月21日土曜日 20:13:28 UTC+9 HadoopMarc:
Hi Manabu,

Without knowing if the considerations below will really help, you may try the following:
in the current traversal the repeat(), simplePath() and emit() steps have no effect if the children do not assemble children themselves. So you can leave these steps out for clarity and to be sure that they do not influence the janusgraph execution plan
you may want to study the profile(), sack() and barrier() steps in the TinkerPop ref docs:
https://tinkerpop.apache.org/docs/3.4.8/reference/#profile-step
https://tinkerpop.apache.org/docs/3.4.8/reference/#sack-step
https://tinkerpop.apache.org/docs/3.4.8/reference/#barrier-step
https://kelvinlawrence.net/book/Gremlin-Graph-Guide.html#lambdasack
https://groups.google.com/g/gremlin-users/c/yGs1rv8YXRw/m/Y_iKg15KAwAJ
https://groups.google.com/g/gremlin-users/c/Z7WqhtHvhRc/m/SAbRRMvNBQAJ
Because of your use of the as()/select() mechanism the traversers cannot be bulked and the number of traversers (20669) equals the path count (20669). I am not sure how bulking would affect the JanusGraph execution plan, but with some luck the number of backend calls decreases from 20669 to 1392 (the number of child vertices).
You can influence the bulking by using the sack() step instead of the as()/select() mechanism. You presently get 20669 (a,b,c) items out of your query. You have to rewrite that to get 1392 child vertices out of your query that each have a sack with (a, b) items. Not well covered in the TinkerPop docs is that the sack can be initialized with a Collection object and that the split and merge operators can take closures to act on such a Collection. E.g. you could structure the Sack as an ArrayList that gets (b, a) tuples or "b|a" strings appended during the traversal of a path.
Finally, note that the barrier() step and LazyBarrierStrategy also influence the bulking process.
Best wishes,    Marc

Op donderdag 19 november 2020 om 02:37:48 UTC+1 schreef Manabu Kotani:
Hi All,

I'm testing traversal query performance.
My query (please see below) takes about 1.8sec.

Is there solution for improve performance (faster than 1.8sec)?
I hope that takes less than 500ms.

1.Environment:
JanusGraph (0.5.2) + Cassandra (3.11.0) on Docker Desktop (Windows)

2.Schema:
------------------------------------------------------------------------------------------------
Vertex Label Name | Partitioned | Static |
---------------------------------------------------------------------------------------------------
item | false | false |
---------------------------------------------------------------------------------------------------
Edge Label Name | Directed | Unidirected | Multiplicity |
---------------------------------------------------------------------------------------------------
assembled | true | false | MULTI |
---------------------------------------------------------------------------------------------------
Property Key Name | Cardinality | Data Type |
---------------------------------------------------------------------------------------------------
serial | SINGLE | class java.lang.String |
work_date | SINGLE | class java.util.Date |
---------------------------------------------------------------------------------------------------
Vertex Index Name | Type | Unique | Backing | Key: Status |
---------------------------------------------------------------------------------------------------
bySerial | Composite | false | internalindex | serial: ENABLED |
---------------------------------------------------------------------------------------------------
Edge Index (VCI) Name | Type | Unique | Backing | Key: Status |
---------------------------------------------------------------------------------------------------
byWorkDate | Composite | false | internalindex | work_date: ENABLED |
---------------------------------------------------------------------------------------------------
Relation Index | Type | Direction | Sort Key | Order | Status |
---------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------

3.Query:
g.V().has('serial',within('XXXXXX','YYYYYY',....<- 100 search keys).as('a')
.repeat(inE('assembled').as('b').outV().as('c').simplePath())
.emit()
.select('a').values('serial').as('parent')
.select('b').values('work_date').as('work_date')
.select('c').values('serial').as('child')
.select('parent','child','work_date')
.order().by('parent').by('child').by('work_date')
-----------------------------------------------------------------------------------------------------------

4.Query Profile:
==>Traversal Metrics
Step Count Traversers Time (ms) % Dur
=============================================================================================================
JanusGraphStep([],[serial.within([XXXXXX... 100 100 159.582 8.89
\_condition=((serial = XXXXXX OR serial = YYYYYY OR .... <- 100 search keys))
\_orders=[]
\_isFitted=true
\_isOrdered=true
\_query=multiKSQ[100]@2000
\_index=bySerial
optimization 0.018
optimization 6.744
backend-query 100 1074.225
\_query=bySerial:multiKSQ[100]@2000
\_limit=2000
RepeatStep([JanusGraphVertexStep(IN,[assembled]... 20669 20669 857.001 47.74
JanusGraphVertexStep(IN,[assembled],edge)@[b] 20669 20669 633.529
\_condition=type[assembled]
\_orders=[]
\_isFitted=true
\_isOrdered=true
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
\_multi=true
\_vertices=204
optimization 0.477
backend-query 228 2.076
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.150
backend-query 0 43.366
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.093
backend-query 229 1.978
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.107
backend-query 0 32.738
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.111
backend-query 229 1.577
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.107
backend-query 0 17.827
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.085
backend-query 229 1.517
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.108
backend-query 0 5.729
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.071
backend-query 228 1.993
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.083
backend-query 0 3.335
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.150
backend-query 229 1.890
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.137
backend-query 0 32.593
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.110
backend-query 229 2.253
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.069
backend-query 230 1.624
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.070
backend-query 0 12.797
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.116
backend-query 229 1.579
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.090
backend-query 0 5.764
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.107
backend-query 229 1.651
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.134
backend-query 0 22.327
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.074
backend-query 229 1.756
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.075
backend-query 0 11.145
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.069
backend-query 229 1.947
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.086
backend-query 0 3.727
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.100
backend-query 116 1.492
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.085
backend-query 0 27.159
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.132
backend-query 229 1.524
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.100
backend-query 0 7.173
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.075
backend-query 230 1.880
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.114
backend-query 0 3.696
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.085
backend-query 228 1.645
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.143
backend-query 0 2.924
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.105
backend-query 229 2.010
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.316
backend-query 0 3.806
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.095
backend-query 230 1.854
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.185
backend-query 229 1.936
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.099
backend-query 0 2.135
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.070
backend-query 231 1.479
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.067
backend-query 0 5.907
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.069
backend-query 1 1.129
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.109
backend-query 0 1.069
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.082
backend-query 231 1.245
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.072
backend-query 0 1.175
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.064
backend-query 229 1.308
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.078
backend-query 0 7.058
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.145
backend-query 231 1.655
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.115
backend-query 0 3.946
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.067
backend-query 117 1.231
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.063
backend-query 0 11.856
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.065
backend-query 230 1.606
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.072
backend-query 0 6.973
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.070
backend-query 229 1.445
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.088
backend-query 230 1.836
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.098
backend-query 0 2.552
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.088
backend-query 116 1.450
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.060
backend-query 0 4.072
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.062
backend-query 229 1.421
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.058
backend-query 0 2.342
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.058
backend-query 229 0.999
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.070
backend-query 0 1.847
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.063
backend-query 229 1.171
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.064
backend-query 0 0.999
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.051
backend-query 228 0.991
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.070
backend-query 0 2.107
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.215
backend-query 116 1.678
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.069
backend-query 229 1.578
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.081
backend-query 0 3.649
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.096
backend-query 229 1.619
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.066
backend-query 228 1.549
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.070
backend-query 116 1.610
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.154
backend-query 228 1.746
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.092
backend-query 0 2.958
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.093
backend-query 232 1.698
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.143
backend-query 229 1.719
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.081
backend-query 0 2.809
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.065
backend-query 229 1.410
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.082
backend-query 229 1.458
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.109
backend-query 228 1.651
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.066
backend-query 228 1.417
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.111
backend-query 117 1.536
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.188
backend-query 0 1.660
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.132
backend-query 229 2.361
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.110
backend-query 0 2.384
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.140
backend-query 229 1.680
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.067
backend-query 230 1.342
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.070
backend-query 0 3.129
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.118
backend-query 231 1.397
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.169
backend-query 0 5.665
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.114
backend-query 116 1.780
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.128
backend-query 0 2.316
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.108
backend-query 229 1.521
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.083
backend-query 231 1.508
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.074
backend-query 0 2.327
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.092
backend-query 116 1.509
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.285
backend-query 0 2.007
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.079
backend-query 116 1.245
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.134
backend-query 230 1.521
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.092
backend-query 1 1.278
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.064
backend-query 0 1.104
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.076
backend-query 231 1.287
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.079
backend-query 229 1.768
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.098
backend-query 0 2.570
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.110
backend-query 116 1.489
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.061
backend-query 0 1.756
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.055
backend-query 229 1.133
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.060
backend-query 116 1.241
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.056
backend-query 0 2.435
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.056
backend-query 228 1.099
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.061
backend-query 0 1.017
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.080
backend-query 229 1.217
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.065
backend-query 230 1.448
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.065
backend-query 229 1.546
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.079
backend-query 230 1.955
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.165
backend-query 0 3.284
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.102
backend-query 229 1.936
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.081
backend-query 0 4.640
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.072
backend-query 229 1.384
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.062
backend-query 0 2.224
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.088
backend-query 116 1.419
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.069
backend-query 0 2.289
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.070
backend-query 231 1.474
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.071
backend-query 229 1.646
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.072
backend-query 0 1.408
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.068
backend-query 230 1.974
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.090
backend-query 229 1.923
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.151
backend-query 230 2.211
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.074
backend-query 230 1.234
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.059
backend-query 0 1.695
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.125
backend-query 230 1.199
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.064
backend-query 0 1.089
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.057
backend-query 116 1.807
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.085
backend-query 0 1.299
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.074
backend-query 228 1.397
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.081
backend-query 228 1.776
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.079
backend-query 0 1.980
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.101
backend-query 229 1.571
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.070
backend-query 231 1.483
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.064
backend-query 0 2.260
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.060
backend-query 230 1.471
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.070
backend-query 232 1.305
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.060
backend-query 229 1.246
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.063
backend-query 229 1.093
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.053
backend-query 229 1.420
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.062
backend-query 226 1.596
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.145
backend-query 0 2.730
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.059
backend-query 229 1.550
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.076
backend-query 231 1.622
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.058
backend-query 117 1.224
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.108
backend-query 0 2.025
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.062
backend-query 230 1.251
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.058
backend-query 230 1.223
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.068
backend-query 116 1.224
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.051
backend-query 0 0.937
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.045
backend-query 116 1.597
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.058
backend-query 228 1.595
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.063
backend-query 0 3.238
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.058
backend-query 229 1.573
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.078
backend-query 231 1.894
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.092
backend-query 230 1.717
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
optimization 0.061
backend-query 231 1.302
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812bd43d
EdgeVertexStep(OUT)@[c] 20669 20669 39.223
PathFilterStep(simple) 20669 20669 44.905
JanusGraphMultiQueryStep(RepeatEndStep) 20669 20669 65.528
RepeatEndStep 20669 20669 39.443
SelectOneStep(last,a) 20669 20669 44.574 2.48
JanusGraphPropertiesStep([serial],value)@[parent] 20669 20669 92.515 5.15
\_condition=type[serial]
\_orders=[]
\_isFitted=true
\_isOrdered=true
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@811c505d
\_multi=true
\_vertices=100
optimization 0.090
backend-query 100 12.807
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@811c505d
SelectOneStep(last,b) 20669 20669 41.753 2.33
JanusGraphPropertiesStep([work_date],value)@[wo... 20669 20669 98.648 5.50
SelectOneStep(last,c) 20669 20669 41.674 2.32
JanusGraphPropertiesStep([serial],value)@[child] 20669 20669 246.094 13.71
\_condition=type[serial]
\_orders=[]
\_isFitted=true
\_isOrdered=true
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@811c505d
\_multi=true
\_vertices=1392
optimization 0.060
backend-query 1392 136.281
\_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@811c505d
SelectStep(last,[parent, child, work_date]) 20669 20669 49.139 2.74
OrderGlobalStep([[value(parent), asc], [value(c... 20669 20669 164.034 9.14
>TOTAL - - 1795.018 -
-----------------------------------------------------------------------------------------------------------

Sorry for my poor English.
Thanks,
Manabu

Re: addE doesn't create more than 1 edge

Amiya <amiyakr...@...>

#5424

Marc is correct about "It is not a bug: the addE() step only adds one edge per traverser".

I think query by Mark will create a self link.

Below query might work (not tested)

g.V().hasLabel('Activity').as('a').

V().has('person', 'id', within('p1', 'p2')).addE('LINK').from('a')

Show quoted text

On Tuesday, 15 December 2020 at 20:36:56 UTC+5:30 HadoopMarc wrote:

Hi Anton,

It is not a bug: the addE() step only adds one edge per traverser. Also, using g.V() twice is an anti-pattern. Try it the other way around, something like (not tested):
g.V().hasLabel('person').has('id', within('p1', 'p2')).as('a').addE('LINK').from('a')

Now the addE() step runs on two traversers.

HTH, Marc

Op dinsdag 15 december 2020 om 12:22:56 UTC+1 schreef Anton Eroshenko:

I'm trying to link one vertex (let's say Activity) with two others (person), I expect to have two
edges in result, the request below creates only one.

gremlin> g.V().hasLabel('Activity')
==>v[40984624]
gremlin> g.V().hasLabel('person').has('id', within('p1', 'p2'))
==>v[40996896]
==>v[41037952]
gremlin> g.V().hasLabel('Activity').addE('LINK').to(g.V().hasLabel('person').has('id', within('p1', 'p2')))
==>e[oe5mu-oefxs-b0np-oepeo][40984624-RESP->40996896]

Is it a bug or I'm missing something?

Re: Condition where-inV-is does not work

Amiya <amiyakr...@...>

#5423

Try g.V(41099392).outE('LINK').where(inV().hasId(110792))

Show quoted text

On Tuesday, 15 December 2020 at 20:45:40 UTC+5:30 Anton Eroshenko wrote:

Hi, JanusGraph users.
I try a simple query from TinkerPop docs with my JanusGraph installation, but it does not work as expected. How is it possible:
gremlin> g.V(41099392).outE('LINK').inV()
==>v[110792]
==>v[81993864]
gremlin> g.V(41099392).outE('LINK').where(inV().is(V(110792)))
gremlin>

The last query returns nothing...
How to filter out vertices by traversal? Appreciate any help