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 What database solution would you pick ? if you are curios.
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!
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.