I’m a java developer, and I’m doing graph database selection for the company.
There is a question that bothers me about Dgraph
Zero will automatically rebalance the predicate according to the disk usage. During the move, the current predicate mutation will be rejected.
1.If the operation of moving a predicate is batched, then the mutation of a moving data will be rejected? Or is the mutation of the entire predicate data before the move is completed?
2.I really like to automatically rebalance this function, but I don’t want to lose this operation because of the predicate movement, which will cause my data to be incomplete. I can only try again when the client receives the rejection, but the rebalacing is automatic. The rebalancing time is not stable (for example, a very large predicate), so I can only put the failed mutation in a failure queue, and then start a new thread to retry continuously? I think this still does not solve the problem that the operation is delayed and there may be a sequence consistency problem. Or does the client’s retry will solve this problem?
3.I have seen a lot of replies from discussions that turned off automatic rebalancing (setting an extremely high balancing period), but this violates the original intention of distributed dynamic scaling, which I think is not a good suggestion
Perhaps it is my understanding of Dgraph, but this is the biggest confusion I have with Dgraph, I hope someone can help me solve it, thank you very much！
The mutations for the entire predicate will be rejected as at the time of rebalancing, the entire predicate is marked as read-only.
You need to take care of the order of your transactions. Client’s retry will not solve the problem/
Perhaps a solution could be to keep rebalancing off for a period of time and then starting it. There is a similar issue raised here, you can upvote it so that it can get prioritized in the roadmap. Or you can open an issue in Github and we can then prioritize and see when/if we have a solution for you.