1. Janusgraph-Dev
  2. Topics

[Vote] Removal of the Cassandra embedded backend

Jan Jansen <faro...@...>
 

Hi

Porunov raised the question should we remove the Cassandra embedded backend? (During reviewing my Cassandra Thrift removal PR)

Advantage:
  • Quick start to test JanusGraph (Now we have a docker image for this.)
  • Performance improvements (no network calls and no serialization)
Disadvantage:
  • Increased configuration complexity in the production usage
    • GC tuning
    • Apache Hadoop/Apache Spark
    • different configurations
  • Each patch version of Cassandra can lead to breaking changes (We use internal API of Cassandra)
This [VOTE] will open for the next 7 days --- closing Monday, October 7, 2019 at 12:00 PM CEST (UTC+2).
All are welcome to vote on the removal but only votes from committers are binding.

My vote is +1.

Greetings,
Jan
Oleksandr Porunov <alexand...@...>
 

I would like to add some thoughts about performance. I didn't test but most likely using separate ScyllaDB instance and separate JanusGraph server instance will have a better performance because there will be no GC for the database. So, the advantages of embadedcassandra is very questionable but disadvantages are clear.

Maybe someone uses embadedcassandra and can explain a specific usecase where embadedcassandra is better than cql.

Right now my VOTE is +1
Florian Hockmann <f...@...>
 

Maybe someone uses embadedcassandra and can explain a specific usecase where embadedcassandra is better than cql.

I'm personally also in favour of removing the embedded backend, but maybe we should really ask users first whether they use the embedded backend and whether it would be a big problem for them to move to a stand-alone installation of Cassandra. I suggest that we ask this on janusgraph-users first before we make a final decision here, as most users probably won't follow here.


Am Dienstag, 1. Oktober 2019 22:40:34 UTC+2 schrieb Oleksandr Porunov:
I would like to add some thoughts about performance. I didn't test but most likely using separate ScyllaDB instance and separate JanusGraph server instance will have a better performance because there will be no GC for the database. So, the advantages of embadedcassandra is very questionable but disadvantages are clear.

Maybe someone uses embadedcassandra and can explain a specific usecase where embadedcassandra is better than cql.

Right now my VOTE is +1
Jan Jansen <faro...@...>
 

I did ask today on user list, so we should wait a bit long for example two weeks more.
lfie...@...
 

Hi,

I am not sure whether I am supposed to post this here too. But, as I was already saying on Jan's user-post: I am using the embedded cassandra backend all the time and would really miss it! So I am hoping it will not be removed.
Thanks for asking the users!

Lilly

Am Montag, 30. September 2019 11:47:26 UTC+2 schrieb Jan Jansen:

Hi

Porunov raised the question should we remove the Cassandra embedded backend? (During reviewing my Cassandra Thrift removal PR)

Advantage:
  • Quick start to test JanusGraph (Now we have a docker image for this.)
  • Performance improvements (no network calls and no serialization)
Disadvantage:
  • Increased configuration complexity in the production usage
    • GC tuning
    • Apache Hadoop/Apache Spark
    • different configurations
  • Each patch version of Cassandra can lead to breaking changes (We use internal API of Cassandra)
This [VOTE] will open for the next 7 days --- closing Monday, October 7, 2019 at 12:00 PM CEST (UTC+2).
All are welcome to vote on the removal but only votes from committers are binding.

My vote is +1.

Greetings,
Jan
Jan Jansen <faro...@...>
 

I had the idea to make a extra project of this backend, because it so hardly coupled with internals of Cassandra, which prevent us from Cassandra dependencies. I patch could include a breaking change.

1 - 6 of 6