Questions regarding predicates

Users Dgraph
#1

Hello, I’m using dgraph for my new project, but coming from a RDBMS background I have the following doubts regarding predicates, and I want to be clear before starting to write code:

  1. Does dgraph performance it’s better with more predicates? for example if we have a node for USERS and a node for CITIES and both of them have a NAME predicate it’s better to leave it as NAME or it would be better to make a USER_NAME and CITY_NAME predicates distinct for each node?

  2. I’m making a multitenant app, so for security each node should have some reference to the tenant, so I have thinked of three possibilities, but Im not sure what would be the most performance-wise:
    - Each node have an edge connecting to the tenant node.
    - Each node have a predicate named after the tenant id (eg: t-xxid="")
    - Each node have a predicate called tenantId with the value of the tenant id(eg: tenandId = xxxid)

  3. Does predicates are indexed??

  4. Finallly and not regarding predicates… when we use a HA replicas, the writes can be to any server or only to the master??

#2

This will depend on you, you can use “name” for all types of Nodes. But indexing would be unique. The ideal IMO would be to have a different indexing for each type of Node (User type, doc type, obj type and os on).

You can try https://docs.dgraph.io/howto/#giving-nodes-a-type or do a custom structure for tenant (+ a type/label).

No, only predicates settled in the schema.

Any server. Also, you can create a balancer for this. Although not necessary.

Cheers.

#3

Hello Michel thank you for your time and quick response!

I have read in some quesitons in this forums, that dgraph benefits for multiple predicates for sharding, so for predicates that i’m sure that are not going to be indexed and are common to different nodes, as the example above USER_NAME, COLLECTION_NAME, CITY_NAME etc…
for dgraph performance it’s better to call all of them only as a NAME and have a predicate type on each node or keep the predicate unique within nodes types?.. I know that both can be done just want to be sure which path would be better for performance.

Also having too many predicates can be bad?, because if I choose the Tenant predicate way I’m going to have N predicates, where N is the number of tenants in the app.

#4

I can not say with exact precision which approach is more performative. But I believe that using both can be quite useful. As I said IMO, having separate predicates indexed separately is interesting. Especially if you will practice queries of different approaches on each type of Node.

I’d say that labeling Node types and merging with @filter is a powerful approach.

E.g:

email: string @index(exact) .

{
 userWithEmail(func: has(_user)) @filter( eq(email, "test@user.com") {
   name
   email
   }
}

E.g 2:

name: string @index(hash, term, trigram) .

{
 myusers(func: has(_user)) @filter(regexp(name@en, /Donald/i)) {
   name
   email
   }
}

By Logic, if you have a single indexed predicate, it will become gigantic over time. So it would be interesting to have different predicates thus having different indexing tables. In my opinion. But this is a personal view, the Dgraph can perfectly handle gigantic indexing table.

Never

2 Likes