Redis keyvalue storage implementation

[lina1101]

Feature description:

We would like to see a Redis keyvalue storage implementation added to the community-server.
We initially explored this when we experimented with scaling up the community-server horizontally by deferring the responsibility of concurrent read/write protection to the external keyvalue storage itself.

So we found out that in some cases (depending on the keyvalue storage utilized, e.g. Redis) the internal locking mechanism is unnecessary.

In our experiment we allowed immediate read/write operations to the Redis storage by implementing a (passthrough) VoidLocker.

We hope to open a PR with the implementation for:

• RedisKeyvalueStore
• VoidLocker

[joachimvh]

When you say RedisKeyvalueStore, do you mean that this class is an extension of KeyValueStorage, ResourceStore or DataAccessor? My assumption was the first, but then I'm not sure why locking is relevant since there is no locking mechanism in front of the internal KeyValueStorage. Unless you use the JsonResourceStorage but then locking is a consequence of the fact that a ResourceStore is used there.

[lina1101]

Yes,RedisKeyValueStorage is an extension of KeyValueStorage.
I see, the RedisKeyValueStorage and VoidLocker may be unrelated, should I instead open a separate issue addressing the specific need for the VoidLocker itself?

[woutermont]

I believe @ixuz' team actually has something like this, or was at least planning to look into it ...

[joachimvh]

VoidLocker may be unrelated, should I instead open a separate issue addressing the specific need for the VoidLocker itself?

Preferably since a VoidLocker might be useful for debugging/developer purposes, but there are certain risks associated with it that might need to be discussed.

[ixuz]

@woutermont That's correct and also @lina1101 is part of our team 😉

@joachimvh Then we'll open a separate issue for the VoidLocker discussion. Thanks 👍

[woutermont]

@woutermont That's correct and also @lina1101 is part of our team 😉

Haha, perfect, I already wondered 😄

[lina1101]

I have opened a separate issue for the VoidLocker discussion.
#1093

[RubenVerborgh]

Do we distinguish between usage of key/value stores within CSS where we need persistence between restarts, and where we don't?

[joachimvh]

Do we distinguish between usage of key/value stores within CSS where we need persistence between restarts, and where we don't?

No, current config options are to either use memory for everything, or the resource store. Storages where we don't need persistence would be some of the IDP storages, and the locks. Although we still would need to store these outside of memory in case of multithreading.

[ixuz]

Do we distinguish between usage of key/value stores within CSS where we need persistence between restarts, and where we don't?

No, current config options are to either use memory for everything, or the resource store. Storages where we don't need persistence would be some of the IDP storages, and the locks. Although we still would need to store these outside of memory in case of multithreading.

In our case, we deployed multiple community servers horizontally where each instance needed common external resource/keyvalue storages. We did not find a suitable KeyValueStorage implementation for this so we drafted up an example RedisKeyValueStorage implementation ourselves. This allowed us to verify that the community server could in practice be run in a horizontal setup.

[joachimvh]

In our case, we deployed multiple community servers horizontally where each instance needed common external resource/keyvalue storages. We did not find a suitable KeyValueStorage implementation for this so we drafted up an example RedisKeyValueStorage implementation ourselves. This allowed us to verify that the community server could in practice be run in a horizontal setup.

What was the reason the key/value storages needed to be shared but not the internal data?

We do have the plan to at some point fully support multithreading for the entire server so it should be easier to do this: #322

[ixuz]

As per the comment by @RubenVerborgh here: #1093 (comment)

I noticed that there already exists a useful implementation called JsonResourceStore(that implements KeyValueStore) which handles the interaction with a provided ResourceStore("source").

As such, we could instead implement a redis storage using the AtomicResourceStore interface and then inject it via the JsonResourceStore to the application.

Would that be preferred?

[ixuz]

In our case, we deployed multiple community servers horizontally where each instance needed common external resource/keyvalue storages. We did not find a suitable KeyValueStorage implementation for this so we drafted up an example RedisKeyValueStorage implementation ourselves. This allowed us to verify that the community server could in practice be run in a horizontal setup.

What was the reason the key/value storages needed to be shared but not the internal data?

Which internal data are you referring to? 🤔

When we tried running multiple instances of the community-server it needed to be stateless, so we configured the pods to be stored in a Sparql database, the IdP keyvalue data in a RedisKeyValueStore and then we disabled the locking mechanism. At least that got the setup up and running. Now I don't know how many crucial parts we've violated during this experiment 😂

[joachimvh]

Which internal data are you referring to? 🤔

I should have not used the word internal there, I meant the standard Solid data. But I see you used a SPARQL store there to make sure that is also identical.

That is indeed a nice way to have the same Solid server over multiple machines.

As such, we could instead implement a redis storage using the AtomicResourceStore interface and then inject it via the JsonResourceStore to the application.

Would that be preferred?

I'm not sure if my comment was interpreted that way, but I have no problem at all with a RedisKeyValueStorage. I think it can definitely be interesting for certain use cases such as the one you described.

I also think a RedisDataAccessor can have merit as a new possible data backend.

What I do think is a potential issue is having a RedisResourceStore because making it atomic is a potentially complex problem for some of the reasons I described in #1093 (comment)

The AtomicResourceStore interface exists because it was in the original architecture, but it has never been used and I'm not sure it will any time soon because of those reasons. This interface doesn't actually do anything special, it just allows you to declare in the code that your store is atomic. But a store is more than just an object where different functions are called based on RESTful methods, it is also expected that it answers those requests as described in the Solid spec. Currently we do this by having all our stores take a different store as input parameter so the behaviour can be delegated, and then at the end we have 1 big store that then handles all the Solid stuff. That is the DataAccessorBasedStore

If you make a RedisResourceStore you would have to implement all the behaviour in that class if you wanted your server to still be a valid Solid server, and somehow do that in an atomic way (which might be possible with redis transactions though). Note that at some point in the future we want to split up the DataAccessorBasedStore so you wouldn't fully have to reimplement that class (#998).

So I think the ideal situation would be to create a RedisDataAccessor, this would allow you to use the JsonResourceStorage with behing it the store with that data accessor. The additional benefit is that you could also use that backend for storing normal data, which would give CSS a second database-like backend besides the SPARQL backend.

Creating a DataAccessor is more complex than creating a KeyValueStorage though, which is one of the reasons the storage interface was made: we wanted a simpler interface for internal data. So creating a RedisKeyValueStorage would also be a valid solution if you are only interested in using redis for the internal storage