Shard zero and alpha nodes in a federated flavour

Hello there,
I learned that Dgraph shards upon predicates, and i was wondering to which extent the admin is able to control the shard policies,
in particular I’d like to be able to decide that some specific predicate-value should be stored to some specific Alphas only, and never in others.

the use case:

We’re developing a federated platform:
Different organizations may independently deploy a platform instance
An instance may join a certain federation, in that case the underlying Alpha would join the federation shard
Sharded data should be available and searchable from any federated instance, but should be guaranteed to be stored and mutated in the generating instance’s local Alpha only, and never in others
I guess if it would be possible to achieve this by storing federated data under some specific predicate, probably the same predicate for all nodes, but with a different @prefix - this would mess with the “lang@*” feature for languages support, but that would be a a good tradeoff

should/could every federated instances run their own Zero too ?

also, this scenario would raise some questions about trust between federated Alphas/Zeros
in particular, how to prevent tampering of the agreed sharding policies ?

Hi @aleclofabbro
Welcome to Dgraph Community. Quoting from Dgraph architecture paper

Dgraph’s smallest unit of record is a triple (subject-predicate-object), with each predicate in its entirety forming a shard. In other words, Dgraph logically groups all the triples with the same predicate and considers them one shard. Each shard is then assigned a group (1…N) which can then be served by all the Alphas serving that group.

You can forcefully move one predicate to a group using /moveTablet?tablet=name&group=2. More can be found here. However, during shard rebalance this could change. To save that you can set the rebalance interval flag in Zero to something arbitrarily high, so Zero wouldn’t do tablet moves automatically.

thanks @aman-bansal ,

I’m thinking the *@predicate approach would be too hacky for the purpose…
I’ll post some new question to explore others