Estimating Query Complexity

Issues GraphQL
,
1

After developing an app for approximately a year with dgraph as our backend, we noticed that although it is nice that everyone can write their own queries when needed with arbitrary depth and complexity, it is very hard to estimate how efficient the query will be in the end.

Possible options that might make queries exponentially more expensive than it might look like:

  • use of @cascade due to lack of child-property filtering
  • use of pagination: dgraph seems to query the full data and only applies pagination afterwards
  • use of auth rules: dgraph seems to run multiple queries to the database to enforce auth rules

Proposal
It would be great if dgraph could give some kind of complexity estimates when writing GraphQL queries. So the frontend-dev could easily check if his/her query is behaving “nice”.

This is especially important because in a dev environment you usually don’t have a huge local database. So all queries might complete in milliseconds. There is no way to test the real latency of a query unless you execute is directly on the live system.

We had an example where the local query was finished in 20ms and on our live system 20seconds

2

Take a look at

The problem with query complexity is that the complexity relates to the actual data. So two same queries might be different complexity between systems as you saw with your test and production.

3

Actual data will of course significantly increase any time estimates.

I’m not asking for these. I’m rather asking about some complexity-score. It could e.g. be estimated like this:

score := 0
if query.usesAuth {
  score += 1
}

if query.usesPagination {
 score += 1 // complexity is higher then one would expect when using pagination
}

if query.usesOrdering {
  score += 1
}

if query.usesCascade {
   score += 1
}

score += query.maxDepth // no idea if depth has any impact here

...

The idea is, that when I write some query and the score estimate is high, I should revisit my query and change things. (e.g. instead of using @cascade one could start with the child of interest)

1 Like
4

I believe that the next focus for Dgraph development will be Query Planning. So you can have an idea about the estimation and so on.

2 Likes