How to improve Dgraph mutate latency

Users Dgraph
,
1

When I use dgraph，I find the mutate it`s not effective immediately.
The schema like this

<xid>: string @index(hash) @upsert .
<ww/attr/level>: int @index(int) .
type User {
    <xid>
    <ww/attr/level>
}

The pseudo code like this

startTransaction
update user level from 100 to 200
if sleep 10 milliseconds
    get user level it`s 200
if query immediately
    get user level it`s still 100

dgraph version: v20.03.4

2

Hi @xxm404,

Can you provide more details ? How are you making these transactions and mutations ? Is the transaction getting committed before querying it ?

3

Hi @rajas thanks for the reply.
We used the raw http client .
update and query are within the same transaction, not committed.
query like this

getUserNode(func: uid(0x1)) {
     uid
     level:  <ww/attr/level>
}

mutate like this

set {
    <0x1> <ww/attr/level> 200 .
}
4

Are you using mutate with commitNow=true ?
I tried to reproduce this on v20.03.4, the behaviour I observed is that if mutate is done with commitNow=true , the query always returned the updated value while when commitNow option is not set, it always returned the old value.

Ideally, a query should be run only after a mutation is commited, so that the updated value gets written to disk.

5

I have not use commitNow=true
In my function I need to update(mutate) and the query in the same transaction, like my pseudo code

startTransaction
set {
    <0x1> <ww/attr/level> 200 .
}
getUserNode(func: uid(0x1)) {
     uid
     level:  <ww/attr/level>
}
echo user level (In most cases it will output 200 but sometimes it will output 100)
commit

This problem may be related to the amount of data, we have 700 thousand node.

6

Is there any compulsion to mutate and query in the same transaction ?
Adding commitNow=true with mutate should solve the issue and the query will then output 200 always.

Let us know if you still face the problem after adding commitNow=true.

7

Does it mean that the mutate delay is normal?

8

Are you facing any delays for mutate with commitNow=true option ? Can you provide more details about the delay ?

Once a mutation is committed, there shouldn’t be any delay before the new value starts being shown with a query.

9

Once a mutation is committed, there shouldn’t be any delay before the new value starts being shown with a query.

When mutation and query in the same transaction, mutation not committed, query has any delay is normal?

10

Its not really a delay, you simply wont see 200 in your query result unless you commit the mutation before subsequently querying it. Its a different paradigm to e.g. RDBMS, as I understand until you commit your transaction is just a list of commands pending to be run, it wont be reflected in a graph query.

1 Like
11

Really？In my case，query result in most cases is 200, only in a few cases is 100.

12

Hi @xxm404,

If query is done before committing the mutate transaction, it will show the old value.
Can you share your code snippet and the way the code is run so that we can reproduce it ? In case there is inconsistency with the value in query result, this should be reported as a bug.