Date   

Re: Duplicate vertex issue with Uniqueness constraints | Janusgraph CQL

hadoopmarc@...
 

Hi Pawan,

Your code mirrors the example at https://docs.janusgraph.org/advanced-topics/eventual-consistency/#data-consistency for the greatest part. Are you sure the changes on graphMgmt get committed?

Also, how do you know about "duplicate vertex creation" when "it returns only 1 record"?

Best wishes,   Marc

PS. Most of the software community reserves names starting with a verb to functions and class methods. Violating this convention (e.g. PropertyKey makePropertyKey) makes your code almost unreadable to others.


Re: jvm.options broken

hadoopmarc@...
 

Hi Matthias,

Thanks for taking the trouble to report this. It took a while, but your report did not go unnoticed:

https://github.com/JanusGraph/janusgraph/issues/2857

Best wishes,    Marc


Duplicate vertex issue with Uniqueness constraints | Janusgraph CQL

Pawan Shriwas
 

Hi Everyone,

I am facing a duplicate vertex creation issue even though the unique index is present in that property and when i retrive the data with the same index it returns only 1 record.

Please see below information for the same.

Storage Backend - Cassandra CQL
Janusgraph version - 0.5.2
index - Composite 
Uniqueness -  True
Consistency - yes
Index Status - ENABLED

Below are the code snippet - 

0-02-08-f4ca12e27990b7b27cd9a92fd2028024e13f5784cf7afa26f54da58cce631438_1c6da93e7293a7.png

Index Status : 

2021_11_18_0y5_Kleki.png
 
Thanks,
Pawan


Re: Diagnosing slow write speeds to BigTable

AC
 

I have a follow-up question in addition to my reply above: Is there any guide for understanding the JanusGraph metrics available? I have written a basic metrics integration but I'm finding it quite hard to interpret the metrics that are being produced.


On Tue, Nov 16, 2021 at 12:35 PM AC via lists.lfaidata.foundation <acrane=twitter.com@...> wrote:
Hey again Boxuan, thanks for your help in this thread!

1) Read speed is quite fast, at least as fast as I would expect for using a remote database like BigTable.
2) That is a good idea, I will try making some writes to BigTable outside of JanusGraph in this container. However, considering that the BigTable client stats and BigTable server stats both report low latencies from within the JanusGraph application, this is looking like a JanusGraph-related issue. I will report back with results today.

On Tue, Nov 16, 2021 at 11:48 AM Boxuan Li <liboxuan@...> wrote:
I am not an expert on this and I've never used BigTable or GCP before, but here are my two cents:

1) Did you test the read speed? Is it also very slow compared to writing?

2) Did you try using an HBase/Bigtable client (in the same GCP container as your JanusGraph instance) to write to your BigTable cluster? If it's also very slow then the problem might be with your network or other setups.

Best,
Boxuan


Re: Diagnosing slow write speeds to BigTable

AC
 

Hey again Boxuan, thanks for your help in this thread!

1) Read speed is quite fast, at least as fast as I would expect for using a remote database like BigTable.
2) That is a good idea, I will try making some writes to BigTable outside of JanusGraph in this container. However, considering that the BigTable client stats and BigTable server stats both report low latencies from within the JanusGraph application, this is looking like a JanusGraph-related issue. I will report back with results today.

On Tue, Nov 16, 2021 at 11:48 AM Boxuan Li <liboxuan@...> wrote:
I am not an expert on this and I've never used BigTable or GCP before, but here are my two cents:

1) Did you test the read speed? Is it also very slow compared to writing?

2) Did you try using an HBase/Bigtable client (in the same GCP container as your JanusGraph instance) to write to your BigTable cluster? If it's also very slow then the problem might be with your network or other setups.

Best,
Boxuan


Re: Diagnosing slow write speeds to BigTable

Boxuan Li
 

I am not an expert on this and I've never used BigTable or GCP before, but here are my two cents:

1) Did you test the read speed? Is it also very slow compared to writing?

2) Did you try using an HBase/Bigtable client (in the same GCP container as your JanusGraph instance) to write to your BigTable cluster? If it's also very slow then the problem might be with your network or other setups.

Best,
Boxuan


Diagnosing slow write speeds to BigTable

AC
 

Hey there, folks. Firstly I want to say thanks for your help with the previous bug we uncovered.

I'm evaluating JanusGraph performance on BigTable and observing very slow write speeds when writing even a single vertex and committing a transaction. Starting a new transaction, writing a single vertex, and committing the transaction takes at minimum 5-6 seconds.

BigTable metrics indicate that the backend is never taking more than 100ms (max) to perform a write. It's hard to imagine that any amount of overhead on the BigTable side would bring this up to 5-6 seconds. The basic BigTable stats inside our application also look reasonable.

Here is the current configuration:

"storage.backend": "hbase"
"metrics.enabled": true
"cache.db-cache": false
"query.batch": true
"storage.page-size": 1000
"storage.hbase.ext.hbase.client.connection.impl": "com.google.cloud.bigtable.hbase2_x.BigtableConnection"
"storage.hbase.ext.google.bigtable.grpc.retry.deadlineexceeded.enable": true
"storage.hbase.ext.google.bigtable.grpc.channel.count": 50
"storage.lock.retries": 5
"storage.lock.wait-time": 50.millis

This is running in a GCP container that is rather beefy and not doing anything else, and is located in the same region as the BigTable cluster. Other traffic to/from the container seems fine.

I'm currently using hbase-shaded-client rev 2.1.5 since that's aligned to JanusGraph 0.5.3 which we are currently using. I experimented with up to 2.4.8 and saw no difference. I'm also using bigtable-hbase-2.x-shaded 1.25.1, the latest stable revision.

I'm at a loss how to progress further with my diagnosis, as all evidence indicates that the latency is originating with JanusGraph's operation. How can I better find and eliminate the source of this latency?

Thanks!


Re: How to change GLOBAL_OFFLINE configuration when graph can't be instantiated

toom@...
 

Hi Marc,

Your solution works if the configuration hasn't been changed yet. If you change the index backend and set a wrong hostname, you cannot access your data anymore:
mgmt = graph.openManagement()
mgmt.set("index.search.backend", "elasticsearch")
mgmt.set("index.search.hostname", "non-existant.hostname")
mgmt.commit()

Then the database cannot be open.

Regards,

Toom.


Re: Potential transaction issue (JG 0.6.0)

Boxuan Li
 

I agree with Sergey that "this problem was just hidden in the previous version as resources were not released properly".

I tried to reproduce in Java (not remote graph) but failed. @Charles, are you able to release the complete recipe of your code, or spot anything that I am missing?

My code is as follows (you can put it in JanusGraphTest.java and run):

@Test
public void testTransactionIssue() {
JanusGraphVertex v1 = tx.addVertex(T.label, "company", "companyId", 44507);
JanusGraphVertex v2 = tx.addVertex("status", "APPROVED", "workerId", 123, "lastName", "A", "firstName", "aa");
JanusGraphVertex v3 = tx.addVertex("status", "APPROVED", "workerId", 124, "lastName", "C", "firstName", "a");
JanusGraphVertex v4 = tx.addVertex("status", "APPROVED", "workerId", 125, "lastName", "aa", "firstName", "C");
v1.addEdge("EMPLOYS", v2);
v1.addEdge("EMPLOYS", v3);
v1.addEdge("EMPLOYS", v4);
tx.commit();
newTx();
List list = tx.traversal().V().has("company", "companyId", 44507).out("EMPLOYS").has("status", "APPROVED").skip(0).limit(1).elementMap("workerId").toList();
tx.traversal().V().has("company", "companyId", 44507).out("EMPLOYS").has("status", "APPROVED").skip(1).limit(1).elementMap("workerId").toList();
tx.traversal().V().has("company", "companyId", 44507).out("EMPLOYS").has("status", "APPROVED").skip(0).limit(2).elementMap("workerId").toList();
tx.rollback();
tx = graph.newTransaction();
tx.traversal().V().has("companyId", 44507).out("EMPLOYS").has("status", "APPROVED").skip(0).limit(1).elementMap("workerId").toList();
tx.traversal().V().has("companyId", 44507).out("EMPLOYS").has("status", "APPROVED").order().by("lastName").by("firstName").skip(1).limit(1).elementMap("workerId").toList();


graph.traversal().V().has("companyId", 44507).out("EMPLOYS").has("status", "APPROVED").skip(0).limit(1).elementMap("workerId").toList();
graph.traversal().V().has("companyId", 44507).out("EMPLOYS").has("status", "APPROVED").order().by("lastName").by("firstName").skip(1).limit(1).elementMap("workerId").toList();
}


Re: Cassandra 4

hadoopmarc@...
 

Hi,

There is an issue tracking this, but no PR's yet, see: https://github.com/JanusGraph/janusgraph/issues/2325

Best wishes,     Marc


Cassandra 4

Kusnierz.Krzysztof@...
 

Hi, has anyone tried JG with Cassandra 4 ? Does it work ?


Re: How to Merge Two Vertices in JanusGraph into single vertex

hadoopmarc@...
 

Hi Krishna,

Nope. However, you are not the first to ask, see:
https://stackoverflow.com/questions/46363737/tinkerpop-gremlin-merge-vertices-and-edges/46435070#46435070

Best wishes,   Marc


How to Merge Two Vertices in JanusGraph into single vertex

krishna.sailesh2@...
 

Hi Folks

can you please help me to know how to merge 2 vertices in Janus Graph into a single vertex?

 I am using Cassandra DB as a backend for JanusGraph and unique vertex constraint with id+name vertex properties. I have two vertices B (id:234 and name: orange)  and C (id:345 and name: orange). I want to merge Vertex C to Vertex B so that all the edges connected to Vertex C should connect to Vertex B. and now Vertex B has both edges of vertex B and C. Apart from Adding all the Edges of Vertex C to Vertex B and deleting vertex C is there any way to do it?



Thanks
Krishna Sailesh



Re: Usage of CustomID on Vertexes

hadoopmarc@...
 

Hi Hazal,

Your comment is correct: the graph.set-vertex-id feature is not documented further than this, so using it is not advised.

You are also right that lookups in the index require additional processing. However, depending on the ordering of inserts and their distribution across JanusGraph instances,  many lookups can be avoided if vertices are still in the JanusGraph cache. Also, using storage backend ids assigned by JanusGraph will be more efficient for vertex reads later on because of the id partitioning applied.

So I support your presumption that using an indexed property is to be preferred.

Best wishes,    Marc


Re: JanusGraph server clustering with NodeJS

hadoopmarc@...
 

I read some conceptual confusion, so let me try:
  • a single query is handled by a single janusgraph instance (In this case JanusGraph Server)
  • you can handle many queries from many nodejs clients in parallel by configuring multiple JanusGraph Servers and make these accessible via a load balancer
Best wishes,   Marc


Re: JanusGraph server clustering with NodeJS

sppriyaindu@...
 

We are also facing similar issue .. Could you please direct us how do we handle Janus cluster using node js 


Usage of CustomID on Vertexes

hazalkecoglu@...
 

Hi everyone,

I have a confusion about the topic i mentioned below,  could anyone give any suggestion about it? or does the problem familiar with you?  what was your solution?

I need to load data from a relational database to JanusGraph. I want to use CustomID while I am loading vertexes.The main reason behind to use CustomID is that I want perform faster to be able to load related Vertexes on that ID while creating edges between vertexes.

So, document says that if I activated graph.set-vertex-id attribute some of other attributes will be disabled. What are those attributes? Isn't it an approved solution?
Or instead of using ID to reach a vertex is it a good solution to reach it by an indexed property? Which will perform better? 

Thanks a lot,
Hazal 


Re: Edge traveresal .hasId() not returning expected results

AC
 

Thanks Boxuan! I look forward to that release. In the meantime, I was able to work around this issue now that I know it is not producing the expected results, in a way that should be compatible with this change once it is rolled out. I really appreciate your thorough answer and explanation.


On Sat, Nov 6, 2021 at 5:12 PM Boxuan Li <liboxuan@...> wrote:
Fixed by https://github.com/JanusGraph/janusgraph/pull/2849 and will be included in the next release (0.6.1).


JanusGraph server clustering with NodeJS

51kumarakhil@...
 

Hello!
I'm new to JanusGraph and implemented "single janus server- single nodejs client" setup successfully. Able to create multiple dynamic graphs within the same janusServer instance (if anyone need helps here, I'm happy to help) with Google BigTable as storage backend.

The thing I'm stuck with is this clustering of Janus graph. The idea is to scale up the current architecture with multiple JanusGraph servers to speed up the execution.
I've three google VM instances where I've have configured the same JanusGraph server setup. Now, how can I distribute the data to these three JanusGraph Servers.
I'm using "gremlin" npm module, but it doesn't have the option to connect with three servers at the same time. 

Its been a week I'm looking for solutions, but not able to find any. 
Is there anything I'm missing? If there's any better approach? Or any solution to my problem?

Any help would be Great! Thank You!
Happy Coding!


jvm.options broken

m.leinweber@...
 

Hello Janusgraphers,

seems that janusgraph-server.sh line 116 is broken. Only the last entry of the jvm options file is used.

br,
Matthias

421 - 440 of 6666