14 replies

Usage of _lock_ tables with ConfiguredGraphFactory vs. JanusGraphFactory

Hi everybody,

we are noticing weird behavior of JanusGraph regarding the tables

edgestore_lock_

edgestore_lock_

and

graphindex_lock_

graphindex_lock_

. We are operating two JanusGraph clusters which use the same schema, both running on ScyllaDB. While one instance is managed by

JanusGraphFactory

JanusGraphFactory

, we have configured multiple graphs in the other instance using

ConfiguredGraphFactory

ConfiguredGraphFactory

. Recently, we noticed an unexpected storage usage caused by the table

edgestore_lock_

edgestore_lock_

, so we started comparing the utilization of these tables for both scenarios:

Factory          | JanusGraphFactory | ConfiguredGraphFactory (example keyspace)
-----------------+-------------------+------------------------------------------
edgestore        |          2.20 TiB |                                116.78 GiB
edgestore_lock_  |          1.57 MiB |                                 13.14 GiB
graphindex       |       1010.49 GiB |                                119.94 GiB
graphindex_lock_ |          1.15 MiB |                                     0 B

Factory          | JanusGraphFactory | ConfiguredGraphFactory (example keyspace)
-----------------+-------------------+------------------------------------------
edgestore        |          2.20 TiB |                                116.78 GiB
edgestore_lock_  |          1.57 MiB |                                 13.14 GiB
graphindex       |       1010.49 GiB |                                119.94 GiB
graphindex_lock_ |          1.15 MiB |                                     0 B

As you can see, in the

JanusGraphFactory

JanusGraphFactory

case, both

_lock_

_lock_

tables are hardly used. That is exactly what we expect, since we are not using any uniqueness constraints and only use

MULTI

MULTI

edges. As of our understanding, that should cause JanusGraph to not require locks.
In the

ConfiguredGraphFactory

ConfiguredGraphFactory

case, however, the

edgestore_lock_

edgestore_lock_

table seems to be heavily utilized, while

graphindex_lock_

graphindex_lock_

does not contain a single byte of data. As stated above, that feels weird, because both cases are using the same schema.

Does anybody have a deeper understanding of JanusGraph's usage of

_lock_

_lock_

tables? Sadly, there's little to no documentation on that topic. Is there a way to disable lock usage for

ConfiguredGraphFactory

ConfiguredGraphFactory

Solution

The lock is acquired by

StandardJanusGraph

StandardJanusGraph

when

vp[~T$VertexExists->true]

vp[~T$VertexExists->true]

is deleted. This only affects deletions because on additions, the vertex is always "new" https://github.com/JanusGraph/janusgraph/blob/06526e728f468bf7fca072c3cf2c5d9024830be0/janusgraph-core/src/main/java/org/janusgraph/graphdb/database/StandardJanusGraph.java#L762

GitHub

janusgraph/janusgraph-core/src/main/java/org/janusgraph/graphdb/dat...

JanusGraph: an open-source, distributed graph database - JanusGraph/janusgraph

Jump to solution

JanusGraph•3y ago•

14 replies

rngcntr

Usage of _lock_ tables with ConfiguredGraphFactory vs. JanusGraphFactory

Hi everybody,

we are noticing weird behavior of JanusGraph regarding the tables

edgestore_lock_

edgestore_lock_

and

graphindex_lock_

graphindex_lock_

. We are operating two JanusGraph clusters which use the same schema, both running on ScyllaDB. While one instance is managed by

JanusGraphFactory

JanusGraphFactory

, we have configured multiple graphs in the other instance using

ConfiguredGraphFactory

ConfiguredGraphFactory

. Recently, we noticed an unexpected storage usage caused by the table

edgestore_lock_

edgestore_lock_

, so we started comparing the utilization of these tables for both scenarios:

Factory          | JanusGraphFactory | ConfiguredGraphFactory (example keyspace)
-----------------+-------------------+------------------------------------------
edgestore        |          2.20 TiB |                                116.78 GiB
edgestore_lock_  |          1.57 MiB |                                 13.14 GiB
graphindex       |       1010.49 GiB |                                119.94 GiB
graphindex_lock_ |          1.15 MiB |                                     0 B

Factory          | JanusGraphFactory | ConfiguredGraphFactory (example keyspace)
-----------------+-------------------+------------------------------------------
edgestore        |          2.20 TiB |                                116.78 GiB
edgestore_lock_  |          1.57 MiB |                                 13.14 GiB
graphindex       |       1010.49 GiB |                                119.94 GiB
graphindex_lock_ |          1.15 MiB |                                     0 B

As you can see, in the

JanusGraphFactory

JanusGraphFactory

case, both

_lock_

_lock_

tables are hardly used. That is exactly what we expect, since we are not using any uniqueness constraints and only use

MULTI

MULTI

edges. As of our understanding, that should cause JanusGraph to not require locks.
In the

ConfiguredGraphFactory

ConfiguredGraphFactory

case, however, the

edgestore_lock_

edgestore_lock_

table seems to be heavily utilized, while

graphindex_lock_

graphindex_lock_

does not contain a single byte of data. As stated above, that feels weird, because both cases are using the same schema.

Does anybody have a deeper understanding of JanusGraph's usage of

_lock_

_lock_

tables? Sadly, there's little to no documentation on that topic. Is there a way to disable lock usage for

ConfiguredGraphFactory

ConfiguredGraphFactory

Solution

The lock is acquired by

StandardJanusGraph

StandardJanusGraph

when

vp[~T$VertexExists->true]

vp[~T$VertexExists->true]

GitHub

janusgraph/janusgraph-core/src/main/java/org/janusgraph/graphdb/dat...

JanusGraph: an open-source, distributed graph database - JanusGraph/janusgraph

Jump to solution

Usage of _lock_ tables with ConfiguredGraphFactory vs. JanusGraphFactory

Usage of _lock_ tables with ConfiguredGraphFactory vs. JanusGraphFactory

Similar Threads

Similar Threads

Similar Threads