Performance advise on graph/schema design

[BenW]

@abhijit-kar

After all that’s the whole point of Dgraph.
You mimick graph structure as you see them in your mind, and alter the schema as you go. Unlike SQL or NoSQL, you are not tied down to ghosts of your past.

Sorry to resurrect and old post, but would love to hear core team comment on this ↑. I’m trying to come up with a list of best practices to follow in how I design my Dgraph schema and perhaps I’ve been conditioned through years of SQL hell to be nervous about n+1 queries and performance issues—but should I really just go ahead and create whatever schema I can think of with reckless abandon, or are there caveats?

@omar

Have User, Provider and Data as a type, and in Data nodes have a predicate to store the timestamp and index it. Also, link the Data node to the corresponding User and Provider nodes. That way you will be able to answer both the queries with the minimal graph traversal with the help of index on the timestamp. This is where you will need the between function, which will make your queries more efficient than the current state. We already forwarded this feature internally and expressed your interest in

Based on this ↑ it would seem that the best practices I should follow are:

• Worry less about size of database and more about how many edges your queries will need to traverse
• In order to ensure best possible query performance:
  1. Design your schema in such a way that the number of edges your queries need to traverse is minimised
  2. Rely on indexes (using @search directive?) of relevant predicates to get performance out of queries
• Generally it’s preferable to have more granular types if the existence of those types reduces the number edges a query needs to traverse …?

Am I missing anything?