...

Table of Contents

For Ignite 3.x the concept is formulated for the distributed table. The table is the base object which allow component that allows a store and update updates data in the cluster. The table provides a base guaranty would it provide it is a of consistency of data entry writewrites/readreads.

Motivation

All distributed table structures required require to have redundant redundancy of storing data to avoid loosing losing entries when one of the member (or more) member(s) of the structure got goes down. More over Moreover, the data which is available should be consistent every time, while a part of the data available in the structure.

The atomic protocol should provide an ability to store redundant keep data redundancy level and keep data consistency until all copes the copies of the data lose the clusterare lost.

Interface

Table creation

For create any table you need to specify two parameters Table creation requires next parameters to be specified for the protocol purpose:

• Partitions Amount of partitions - this is the total number of part of parts the data will divided be distributed among in the cluster.Replicas - this is the number of copy of each partition would be created (1 means the cluster would have only
• copy without redundancyA number of replicas - a redundancy level, desired number of copies each partition should have (1 means no redundancy - a single copy of partition will be in a cluster).

Key value interface

The familiar interface for atomic storage in a table is available through the Key-Value view[1] of a table:

...

All batch methods won't have atomically guaranties guarantees and added for optimization on network communication.

It is an analogue of Ignite cache interface form from Ignite 2.x.

Implementation

...

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.

Mapping entry to partition

All A table entry will have two partsconsists of:

• Key part (Affinity part), it is - a set of unique columns. It can be interpreted as the primary key.
• Optional Affinity part - a fixed subset of Key columns that define a partition the entry belongs to. By default, Affinity part = Key part.
• Value part, it is another columns.

...

• .

Flow description

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.

...

Tickets