JanusGraph configuration for LDBC SNB

[andrii0lomakin]

Good day.

I am dev lead of youtrackdb project and we are working now on implementation of LDBC SNB interactive workload implementation on top of TinkerPop.

Our idea is to implement benchmark that can be used virtually any DB provider using Google Guice for DI as both Graph and optimized versions of queries (if default ones need to be replaced) .

We are going to include JanusGraph in this benchmark.

Could you clarify what type of JanusGraph deployment configuration better to use for us in such case ?

P.S. We of course will send code for optional review once integration is done.

[hadoopmarc]

As no more knowledgeable person has shown up, my take on this question. JanusGraph's reference system in most tests is with Cassandra as storage backend and Elasticsearch as indexing backend. The Elasticsearch indexing is necessary because the LDBC SNB benchmark includes filters with ranges (e.g. Interactive/Complex 9 from https://arxiv.org/pdf/2001.02299). If you want the best possible JanusGraph as a benchmark you should probably replace Cassandra by ScyllaDb.
As the benchmark scales to large data and you need optimal/independent scaling of the JanusGraph service, the backend service and the indexing service, you probably want the advanced deployment scenario as described in https://docs.janusgraph.org/operations/deployment/#advanced-scenario (assuming the available resources for the benchmark enable this scenario).

[porunov]

CQL-compatible databases are implemented just a bit better right now as they support parallel key queries better.
Some backends to consider:

• Cassandra (obviously)
• ScyllaDB - C++ Cassandra implementation with better sharding (if used directly with ScyllaDB driver - requires manual JanusGraph compilation with the driver support)
• YugaByte -CQL compatible C++ DB that also uses SSTables, but with strong consistency using Raft protocol (you will need to explicitly enable CQL protocol in YugaByte to work with JanusGraph)

HBase works well as well, but notice that the parallel key queries can work only via the executor service. By default that is a fixed thread pol, but you may try using Java 24 with Virtual Threads enabled to have better parallelism and resources utilisation.

There are also other storage adapters that you may consider checking, but that may vary a lot.