Beginner Question on Graph data modelling

Misc
#1

This is not really a question on dgraph. We currently have a system with ELK for storage. We have felt that some of our data access patterns could be better served from a graph database instead of ELK. So we are trying to evaluate how good graph-databases will be for our use-cases.

I have come across Dgraph in my tech feeds so often that I want to try this along with redisgraph as the first option. But I want to know some of the basics of modelling our data for a graph-based database, choosing a right querying mechanism (graphql vs cypher etc.). So I am basically looking for some good introductory material which people have come across / recommend wrt graph databases, modelling our data for graphs (Should we create an edge or should we store it as a node property ? etc.).

The reason why we want to move away from ELK is primarily because it scales poorly when we have multiple GBs of data and we try to do a temporal query. Our setup and usecase is somewhat documented at https://psankar.blogspot.com/2020/05/what-database-solution-would-you-pick.html if you are curios.

Thanks.

#2

Excerpt from your link:

We can give as much diskspace for writes and indexes without worry (via kubernetes persistent volumes, if it matters). But SSDs are not possible and RAM is constrained. The entire dataset would anyway not fit in the memory fully.

Is it true, that you won’t have SSDs?

Dgraph uses Badger underneath which takes advantage of SSDs!

1 Like
#3

Hey @Sankar,

You can follow tour for dgraph. Here you can learn to model the data wrt graph databases(dgraph in this case).

#4

I have been there in 2017, so I have found Dgraph and I felt in love. Not sure how things are in Redis right now, but Dgraph is amazing and easy to grow when you surpass the first barrier on the learning curve. Things get really easy with time.

Graph Databases are like a blank painting board, you can have literally any model. With the use of reverse edges, facets and so on you can do complex things even with small models. Or you can have several Graphs branches and interconnect them by making a pseudo-hypergraph. Things like Knowledge Graph can be really cool to implement in Dgraph. Although we don’t support a Knowledge Graph paradigm, you can invent yours and when you get used to GraphQL+- do really cool magic tricks.

We don’t support Cypher and we won’t do it in the next years. As we have chosen GraphQL instead (Actually Cypher was never on the radar).

It depends, if you need to have heavy relational information on your model, go with edges. If you need entities with tons of information that you won’t need to do something like “Knowledge Graph” or Ontology, go with property on node.

#5

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.