Optimization for performance for node property updates?

Use case:

User: UserId (string, index)
Conversation: ConversationId (string, index), lastUpdateTime (int)

User —ParticipatesIn----> Conversation
Conversation —ParticipatedBy-----> User


  1. Get all participants of a conversation, paginated, ordered by userId.
  2. Get all conversations an user is part of, paginated, ordered by lastUpdateTime

I will update the lastUpdateTime field of an conversation extremely frequently.

Do I have to (or is it suggested to) create an index on lastUpdateTime, for faster query (as I’m ordering based on it)?

And most importantly, is Dgraph suitable for such update-heavy workload?
Want honest opinion here.

Any “main” sorting edge in my opnion should be indexed. Unless you are doing some aggregation.

Dgraph sorts on the values and with the index in parallel and returns whichever result is computed first.

If you have enought resources and a well balanced cluster. Anything is possible.

-What do you mean by main sorting edge?
I’ll be sorting by an attribute (int) of the node Conversation.

Does the documentation mean sorting can be done without indexing as well, but if it is indexed, the sorting will happen in parallel, so faster?

Yeah, I just wanted to know if it’ll be efficient.
Coz by design some databases have some tradeoff.
Is Dgraph built for update heavy workloads?

Edge value, or “attribute”. They are synonyms.

It can, but is better indexed. Indexing is meant to be faster.

The horizontal scaling principle in Dgraph design is meant to this. But personally never be sure what the user expects when they ask this. Based in the horizontal scaling I could say yes, but what do you expects in terms of load? Are you going to build some heavy service with millions of requests per second?

I’ve already managed with a context of reasonable resources(32GB, NVMe, AMD 2700X), loading an average of 200k to 400k writes per second. But removing the ACID limitations. It’s a choice you make, guarantees vs speed.

1 Like