Official support for FoundationDB?


jackson.ch...@...
 

Hi everyone,

Seems there may be a good deal of interest in having support for FoundationDB as a backend storage for Janusgraph. Ted Wilmes had created a storage adapter https://github.com/experoinc/janusgraph-foundationdb that hasn't seen any updates by Ted for some time, however other teams have picked up where Ted left off with a few forks seeing some activity:

https://github.com/rngcntr/janusgraph-foundationdb
https://github.com/skyrocknroll/janusgraph-foundationdb
https://github.com/blindenvy/janusgraph-foundationdb

I wanted to start a conversation about working towards getting this adapter added as part of the main janusgraph code base and making FDB an officially supported backend.

Personally, I am interested in seeing this happen as I work for IBM and we are planning on using Janusgraph on top of FoundationDB for a few projects. The https://github.com/blindenvy/janusgraph-foundationdb fork is where some of our team members have started to make changes. We originally forked from experoinc repo and only noticed the other forks after the fact. It seems both the rngcntr and skyrocknroll forks have seen a good deal of changes and may be better forks to choose as a starting point to bring in to the official code base.  

If the community decides they want to do this I would like to offer my assistance in helping bring the code in and adding documentation to jump start the process. 

I look forward to hearing everyones thoughts on this topic. 

Regards,
Christopher Jackson


f.gri...@...
 

Hi Christopher,
thanks for offering your support!

I did indeed put a lot of effort into my fork (rngcntr), but I worked alone and rewrote a significant amount of code so it definitely lacks an in-depth review. Other than that, most of what I did was stress testing and finding bugs that need to be fixed. There are stil some open issues but all in all I'm quite happy with the current state of the storage adapter.

What still worries me is the effects of the transaction time limit of FDB. Officially supporting FDB as a storage backend would currently leave the user in charge of handling these problems. Retrying can not solve all problems as some queries will never make it through the 5s limit, even when tried over and over again. This results in the FDB adapter only supporting a subset of all possible queries and this should be stated clearly in case it is officially released.


Christopher Jackson <jackson.ch...@...>
 

I agree we would have to clearly state all limitations the adapter has so everyone is aware of them. 

Would love to hear additional feedback from the community on the topic of making this adapter official. 


On Monday, May 25, 2020 at 3:21:22 AM UTC-4, f....@... wrote:
Hi Christopher,
thanks for offering your support!

I did indeed put a lot of effort into my fork (rngcntr), but I worked alone and rewrote a significant amount of code so it definitely lacks an in-depth review. Other than that, most of what I did was stress testing and finding bugs that need to be fixed. There are stil some open issues but all in all I'm quite happy with the current state of the storage adapter.

What still worries me is the effects of the transaction time limit of FDB. Officially supporting FDB as a storage backend would currently leave the user in charge of handling these problems. Retrying can not solve all problems as some queries will never make it through the 5s limit, even when tried over and over again. This results in the FDB adapter only supporting a subset of all possible queries and this should be stated clearly in case it is officially released.


Jason Plurad <plu...@...>
 

+1. I support having a janusgraph-foundationdb repository under the main JanusGraph org on GitHub. There is precedent for this with janusgraph-docker, language-specific client bindings (janusgraph-dotnet and janusgraph-python), and janusgraph-ambari.

It comes down to whether there is a consensus desire to collaborate together instead of having separate forks. There would be some work from those fork authors to agree on how to merge those forks into the one that will serve as the initial repo. There would be more restrictions on getting code committed since the project would be expected to have a code review and approval process in place, like the other JanusGraph repos. Keep in mind that having a repo under the JanusGraph org doesn't mean that it needs to be production worthy from the start.

Thanks to both of you for getting the ball rolling here with FoundationDB. Happy to hear more feedback/discussion from the community.

-- Jason

On Saturday, May 30, 2020 at 5:57:13 PM UTC-4, Christopher Jackson wrote:
I agree we would have to clearly state all limitations the adapter has so everyone is aware of them. 

Would love to hear additional feedback from the community on the topic of making this adapter official. 

On Monday, May 25, 2020 at 3:21:22 AM UTC-4, f....@... wrote:
Hi Christopher,
thanks for offering your support!

I did indeed put a lot of effort into my fork (rngcntr), but I worked alone and rewrote a significant amount of code so it definitely lacks an in-depth review. Other than that, most of what I did was stress testing and finding bugs that need to be fixed. There are stil some open issues but all in all I'm quite happy with the current state of the storage adapter.

What still worries me is the effects of the transaction time limit of FDB. Officially supporting FDB as a storage backend would currently leave the user in charge of handling these problems. Retrying can not solve all problems as some queries will never make it through the 5s limit, even when tried over and over again. This results in the FDB adapter only supporting a subset of all possible queries and this should be stated clearly in case it is officially released.


Yuvaraj Loganathan <uva...@...>
 

We would be really interested in a common fork.


Jason Plurad <plu...@...>
 

Sounds like there is some interest here from Chris (blindenvy) and Yuvaraj (skyrocknroll) on a common fork.

rngcntr -- Sorry, I didn't see your first name... are you interested as well?

I'd think the next steps would be to get a vote approved first, then we'd need a repo to seed to the project. There are a few options there on how to proceed with that, but let's get the above answered first before moving to a vote.

-- Jason

On Friday, June 5, 2020 at 9:51:01 PM UTC-4, Yuvaraj Loganathan wrote:
We would be really interested in a common fork.


f.gri...@...
 

I'm of course interested and would like to offer my support for everything that needs to be done.

-- Florian

rngcntr -- Sorry, I didn't see your first name... are you interested as well?


Lakshay Rastogi <lakshay1...@...>
 

I would like to offer my assistance and get involved too!


Anshul Pathak <anshul...@...>
 

+1 , we are also planning to use FDB and this will surely help


On Friday, 22 May 2020 12:08:42 UTC-7, jack...@... wrote:
Hi everyone,

Seems there may be a good deal of interest in having support for FoundationDB as a backend storage for Janusgraph. Ted Wilmes had created a storage adapter https://github.com/experoinc/janusgraph-foundationdb that hasn't seen any updates by Ted for some time, however other teams have picked up where Ted left off with a few forks seeing some activity:


I wanted to start a conversation about working towards getting this adapter added as part of the main janusgraph code base and making FDB an officially supported backend.

Personally, I am interested in seeing this happen as I work for IBM and we are planning on using Janusgraph on top of FoundationDB for a few projects. The https://github.com/blindenvy/janusgraph-foundationdb fork is where some of our team members have started to make changes. We originally forked from experoinc repo and only noticed the other forks after the fact. It seems both the rngcntr and skyrocknroll forks have seen a good deal of changes and may be better forks to choose as a starting point to bring in to the official code base.  

If the community decides they want to do this I would like to offer my assistance in helping bring the code in and adding documentation to jump start the process. 

I look forward to hearing everyones thoughts on this topic. 

Regards,
Christopher Jackson