Advice on type system

Users
1

I am trying to create a type system in my graph so I can more easily navigate and understand the different kinds of things in it.

I have read this and have some questions:

https://docs.dgraph.io/howto/#giving-nodes-a-type

  1. Is this advice of avoiding a single type property still valid?

Even if I have multiple type properties, e.g. type.foo, type.bar etc…, there will be certain types that have orders of magnitude more nodes connected to them than others, and I suspect this will be the case in many applications. In that scenario, do I still gain something by splitting up types into multiple properties?

Also, this PR seems to be going in the opposite direction.

In my current implementation (one type(uid) property) I get all instances of a type this way:

{

isa(func: has(type)) @cascade {
uid
name
type @filter(uid(0x2712))
}
}

  1. If I use multiple type.* properties to denote types, are there any performance penalties in querying depending on the schema data type of the property?

I.e. are time, string or uid data types for the type.foo property equally performant when querying with has(type.foo).

Thanks

Michael

2

Having each type as a predicate would scale nicely, but at the cost of query execution latency.

We’ve started to work on splitting up very long posting lists, to deal with the high fan-out issue. So, the type system that we’re building counts on this split to be efficient (and it should).

No. Dgraph only iterates on the keys, doesn’t retrieve the values.

Yes.

3

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