cancel
Showing results for 
Search instead for 
Did you mean: 

Head's Up! Site migration is underway. Phase 2: migrate recent content

Modeling concept and its impact on the performance

kkris1983
Node Link

I kindly ask to point out the pros and cons of the solutions that I came up with for the challenge described below. Getting into the details of neo4j internals like how things are stored or processed is more than welcome.
I would appreciate for referring to the points e.g. U.2 / A.1.A for clear distinction.

I have been designing model where we have two types of actors: User and Administrator.

User of the system can:
U.1) list both valid OR invalid (issued OR revoked) Invitations with paginations
U.2) issue an Invitation (for other unregistered people),
U.3) revoke an Invitation (at any given moment),

and Administrator of the system by receiving invitation ID can:
A.1) list both valid AND invalid invitations in the system and find Invitation node by its ID
A.2) determine which User issued/revoked Invitation by its given ID

So I came up with an idea where Invitation node stores properties like:

  • IssueDate
  • RevokeDate

Explanation to the graphs below:
Green circle represent issued invitation node
Red circle represent revoked invitation node
Green dotted lines represent new relationship to be created
Red straight lines represent previous relationship to be deleted

A.1) Now Administrator part where he gets invitation ID (e.g. INV_ID_2) by which Invitation node is looked for(yellow node)
Three different solutions:
A.1.A) To make lookup fast I tought about giving another unique Label to the Invitation node which would stand for the ID itself - INV_ID_2

A.1.B) adding new node AllInvitations (blue one) and setting unique relations between it and every Invitation nodes. To find INV_ID_2 we would go through list of its relations.

A.1.C) storing ID as a indexed property on Invitation node - in given case property name ID with its value INV_ID_2

A.2) Taking into consideration solutions from above when given Invitation ID (yellow node) in order to find which User it is bound to, we would have to traverse graph by the PREVIOUS and (IN)VALID relations (yellow) until we get to UserInvitations node.
Quicker soulution would be adding BOUND_TO (blue) direct relation between every Invitation and UserInvitations nodes. However that consists of a lot of relations to be maintained.

Having all this in mind I thought of another solution where we keep User and its related Invitations details in direct link.

But now I get back to the starting point - how to distinguish VALID from INVALID invitations and also add pagination?
We have plenty options like:
A) adding date relations like DATE_2020_01_13 and VALID/INVALID ones
B) merging relations from point A to one like VALID_2020_01_13
C) adding properties to relation itself
D) and so on...
That would impact data pagination e.g. finding 10 latest VALID invitations for particular User would always require going through all of relations and sorting by the date.

I just wonder what is the impact on performance and what might be better approach than the ones presented above.

I would like to note that I am a rookie working with Neo4j.
I read some stuff regarding different design approaches, performance and internals.
However I found articles or book (Graph Databases) related to internals of how everything is stored in files and then processed lacking some crucial informations so I can get the whole picture.
Therefore, I kindly ask to shed some light on this topic and do not omit the details giving explanations.

0 REPLIES 0