Redisgraph: How are you using RedisGraph

[swilly22]

We're interested in better understanding how RedisGraph is being used, please share with us who you are and what's your graph use-case.

[hobofan]

Hey @swilly22, I think that's I great idea, so I'll make a start :)

We are Rlay (@rlay-project), an open source project (2 developers) around decentralized ontologies (semantic data) and open data collaboration (in the past with a focus on blockchain, but that's mostly fading away). My co-maintainer is about to put it into production at their day-job.

In the context of graph databases, we currently leverage them for simple querying and filtering of entities in our semantic data model, and in the future hopefully as the basis for a semantic reasoner.

When we initially moved towards graph databases (~1 year ago), RedisGraph was still very new on the block and was lacking support for some key Cypher vocabulary, so we first opted to implement Neo4J. While Neo4J was overall very stable, we aren't really too happy with its performance (even with a moderate number of nodes), and with the mediocre client library in Rust. So all the time I kept checking on RedisGraph, and finally was able to implement a second backend based on RedisGraph a few weeks ago.

Current suboptimal parts I encountered when implementing the RedisGraph backend:

• MATCH ... MERGE (#181): As Entities in Rlay are content-addressable (= they are retrieved/referenced by a hash of their content), there should never be two nodes for the same Entity hash. So when storing an Entity into RedisGraph, we always have to make sure not to accidentally create a second node with the same hash when adding relationships to an existing partial node. Lacking support for idiomatic MATCH ... MERGE forced us to split it up into multiple smaller queries, which I wasn't too fond of. We currently do our best to ensure unique nodes in our application code and have some tests for that, but other features like unique constraints (#489) would also be a great thing to have in this context.
• General Cypher coverage: The most common actions in Rlay (inserting an entity, retrieving an entity) are abstracted away from the user, so they don't have to directly write any Cypher. However we also allow users to retrieve a batch of Rlay Entities by specifying a Cypher query that yields a list of Entity hashes, to allow building more complex use cases. Some of the more advanced use cases we have in Rlay are based on that feature and currently only work on Neo4J, as they use some Cypher features that are not yet supported in RedisGraph (#475 is one of them), and that's currently a blocker for actually using our RedisGraph backend. We are looking into workarounds for those specific queries, but in general, any step towards better coverage of Cypher, which allows for more natural use of it is greatly appreciated.
• Lack of support for multiple labels (#13): That was pretty easy to work around, but in the future it might be good to have, to allow for more targeted optimization of the graph.

The typical graph topology (?) in Rlay usually looks like this:

• Most nodes will have a relationship to one node of a small group of core nodes (<50)
• Most nodes will have a small number of relationships (3-5)
• A smallish number of nodes (few hundred to thousands) that represent the concepts in the ontology
• A huge number of nodes that represent the instances/individuals in the ontology, which are very sparsely connected among themselves, but each of then will have a relationship to one of the concept nodes

I hope this provides you with some insight in how we are using (/intend to use) RedisGraph in Rlay. If you have any further questions, just ask! 😊

[gnaneshr-zz]

We are not particularly using it for a use case, but we are building a GUI for redis and we provide support for RedisGraph module as well(Works better with redisgraph v2). RedisInsight

Higher level details about graph keys:

Graph view (redisgraph v2 only):

Table view:

Additional features like getting direct neighbours (on double click), getting relationships automatically (without returning the relationship variable), details of a node (on hover), export options etc., are supported.

We support various other features as well:

[siphonelee]

Hi @swilly22, I'm working for an education&tech group in China, and my team is building an educational application using RedisGraph to provide customized recommendations to users based on their interests. As a precaution since RedisGraph is still new, we place all business data in MySQL, only the skeleton data (necessary node, relationships, attributes) are mirrored into RedisGraph.

I'd investigated Neo4J and Janus Graph before, but the performance remained to be a big concern until I came across RedisGraph a couple months ago, which impressed me with GraphBLAS as its core engine. With some knowledge background in graph computing and deep learning, I immediately realized its great potential in further development. Now although RedisGraph is not in full support of cypher syntax yet, I believe we'll still stick to it with workarounds. Again, of coz, hope cypher support can be completed ASAP :smile:

[bionicles]

Can’t use it because you have to run a server 24/7 to use it. We need a Serverless option. I’m not sure why RedisLabs and all these database companies haven’t taken the hint from DynamoDB. Customers want On Demand pricing ...

[stevencox]

@hobofan - could you comment on how you worked around the lack of multiple labels? I've seen things like this

MATCH (n)-[:IS_A]->() 
WHERE any(l IN labels(n) WHERE l=~'Course_*_001')
RETURN distinct n;

But I'm hoping there's a better option.

@swilly22 I'm in academic research and am working with large biomedical graphs of ontological and other data. Support for multiple labels is the main thing I know of right now that would prevent adoption. Any thoughts on when this might happen?

[swilly22]

@stevencox multiple node labels is expected to be included in the next upcoming version, see:
RedisGraph 2.4
Support nodes with multiple labels

Would you care to describe your use-case for this feature?

[hobofan]

@stevencox

It did come around to something similar to that.

While we wanted to have entities like (n:RlayEntity,EntityType1), we ended up with entities like (n:RlayEntity { type: EntityType1 }) which was good enough for us.

[stevencox]

@hobofan - good to know. Thanks.

@swilly22 - also good news. Our use case is modeling graphs of chemicals, genes, diseases, phenotypes, etc using Biolink. The Biolink toolchain models inheritance hierarchies as labels. If there's a performant workaround I can use before 2.4's baked, I'd love to hear.