Proper way to implement multi-tenancy on Neo4j

cypher

(Guilherme Junqueira) #1

Guys,

First of all, good move on bringing the knowledge database from slack to here! :slight_smile:

I would like to know the following: how would you recommend implementing multi tenancy on Neo4j?

Would you connect all nodes of a tenant with a :Tenant node or would you mark all the nodes with an additional label? Is there another option?

Thanks in advance!


(M. David Allen) #2

The most popular option does seem to be to apply a certain label to all nodes within a sub-graph. In this way, the app layer (by applying that label to all queries) may restrict what data can possibly come back to be just items from a particular tenant.

Some folks differ though in how they define subgraphs. You might also need relationship properties so that paths and such can be filtered down to relationships that exist only in one particular graph. Depends on the use case.

In the future, other features are coming in neo4j which will permit multi-graph storage without a label work-around like this, but I'm not certain on timeline.


(Wparton) #3

Hi David,
Could you please provide further insight into the multi-graph storage you mention in your final paragraph? What's on the roadmap?

I am looking at a slighty different but related issue. We instantiate an abstract model of an organisation as a graph. We currently don't have any restrictions on what area(s) of a model a user can observe but need to add this capability (i.e. someone in HR can only see HR related nodes/edges, someone in the US division can see US nodes/edges and nodes/edges in the core division that are also relevant..). In graph theory I'm trying to control visibility to induced subgraphs within the complete graph. Ideally each user might view a different (i.e. unique) subgraph, though in reality there will be multiple users looking at the same subgraph (most of HR will likely see the same subgraph). So I'm looking at options for how to do this as efficiently as possible in Neo4j. I've had a look through the community pages but not found anything on the subject. I'm interested to know if there are any product roadmap items that might assist.

Thanks
Will


(M. David Allen) #4

I'm sorry -- can't give you many details about the multi-graph storage. I'll see if I can ask one of our PMs to follow up on this thread and maybe there's more they can say about timeline and features there.

On the topic of sub-graph access restrictions, this is currently possible. There's a section in the operations manual that takes you through each of the steps about how to do this:

https://neo4j.com/docs/operations-manual/current/security/authentication-authorization/subgraph-access-control/

Hope this helps!


(evdev) #5

@david.allen and Neo4j staff any updates on best practices for multi-tenancy?

Since v3.4+ the newer multi-clustering features seem to have introduced better multi-tenancy solutions for many use cases. I'm very curious about methods/integrations that could enable programatic management of tenants within a multi-cluster, anyone have thoughts on this?

It's been a decent amount of time since this feature was released but there's not much material out there that's new enough to explore multi-clustering (aside from the release blogpost/vid). If anyone has resources to share that'd be much appreciated


Can we run multiple databases at a time?
(Bob Bierman) #6

This subject is of particular interest to my company as well. I have been in direct contact with @dan.flavin, Sr Systems Engineer at Neo4j, and he directed me towards this strategy:

Bob, I heard back about modifying each of the queries from the dev team. There’s been a service provider interface added to the Neo4j OGM to modify the Cypher statements generated by the OGM. The relevant postings are:

Blog: [https://medium.com/neo4j/neo4j-ogms-service-provider-interface-7e5bccbb72c4]

Github: [https://github.com/meistermeier/neo4j-ogm-label-extension]

The use of CypherModificationProvider does look promising, but implementing this strategy in a comprehensive way appears daunting. My attempted implementation of the neo4j-ogm-label-extension project hit a roadblock immediately in that it does not support the MERGE statement (in fact, it removes the label rather than adds it, appropriate in some cases but not others). See the Limitations section of the github page for more info, but suffice it to say that the project is incomplete at best. I am willing to contribute to this or a fork of the project, and would certainly welcome assistance from the community to make this thing more durable. Understand that this will require a good working knowledge of the openCypher spec and the AST it provides for statement parsing.

Another challenge here is devising a solution that works for every data access mechanism. I'm only a couple of months into Neo4j development and already have multiple access strategies, namely in java with neo4j-ogm and spring-data-neo4j, and liquigraph for changeset management. I am building Cypher strings directly in code, and using @NodeEntity objects, and also the Spring find methods. And (of course) direct Cypher via the Neo browser. Whatever solution we devise will have to support all those approaches in a bulletproof way. And at the very least, it will require a clear understanding of the limitations of each in supporting label modification.

So...perhaps connecting all parent nodes to a :Tenant node as suggested at the top of this thread is the safest approach? But that requirement seems prone to more complex and less performant queries.

I'd welcome any feedback, or working directly with anyone who is actively tackling this important challenge. The enterprise solution we're developing is dependent on this feature.


(Jim Webber) #7

Today I think @david.allen's suggestion is a reasonable pattern: tenant by label.

In Neo4j 4.0 multi-tenancy and multi-database are promised.

If you do the label-based separation today, it's an easy move to multi-tenant in the DB infrastructure in the future.

Jim


(Bob Bierman) #8

I tend to agree. Doing so in a comprehensive and reliable way is my challenge.

Do you have a tentative release schedule for 4.0?


(Jim Webber) #9

2H 2019 to the best of my knowledge.


Multi-tenancy