...
ID | IEP-72 |
Author | |
Sponsor | |
Created |
|
Status | DRAFTDECLINED |
Table of Contents |
---|
For Ignite 3.x the concept is formulated for the distributed table. The table is the base component that allows a store and updates data in the cluster. The table provides a base guaranty of consistency of data writes/reads.
...
Every partition replicas will be served by one RAFT group (it is implemented into IEP-61[2]). All synchronization guaranties guarantees between replies will be provided by RAFT protocol.
Since the RAFT elect leader as it wants, a elects a leader on its own, there is no difference between primary and backup replies - all the replicas are equal for the atomic protocol implementation.
...
All partitions should be distributed around the cluster as even as it is possible to pursuing a balanced load goal. For this purpose we will use an implementation , the Rendezvous affinity function will be used (the similar one as use for is used in Ignite 2.x).
The function is calculated once in for the cluster and store to topology on one of the nodes and it's result (partition distribution) is stored to a Distributed metastorage, all nodes gets the distribution and uses locally (not need to recalculatethe other nodes get precalculated the partition distribution and are able to use it local copy (no recalculation required) before the table will be available for operations.
All A table entry will have two partsconsists of:
...
Table starts to create through public API. In the time a partition distribution is being calculated and will have been available into each node when the table is returned to the client code.
...