Interference is an opensource branch of proprietary software designed for solutions in the telecommunications industry related to the processing of a large amount of data (CDRs) coming from switches, their analysis and grouping to quickly obtain engineering reports and generate routing events.
a brief scheme of using a cluster as part of a telecom solution:
a brief diagram of the internal implementation of the service on the example of one node:
Distributed persistent model
Each interference node separately represents a fully functional database. To include a node in the cluster, you must specify the full list of cluster nodes (excluding this one) in the cluster.nodes configuration parameter. The minimum number of cluster nodes is 2, and the maximum is 64 (for more details, see cluster configuration rules below).
Attention! Cluster.nodes parameter should be filled completely before the first start of any of the nodes, and subsequently should not be changed. Then, you can start nodes in any order and at any time.
After such configuration, we may start all configured nodes as cluster. In this case, all nodes will be use specific messages (events) for provide inter-node data consistency and horizontal-scaling queries.
Interference cluster is a decentralized system. This means that the cluster does not use any coordination nodes; instead, each node follows to a set of some formal rules of behavior that guarantee the integrity and availability of data within a certain interaction framework.
Within the framework of these rules, all nodes of the Interference cluster are equivalent. This means that there is no separation in the system of master and slave nodes - changes to user tables can be made from any node, also all changes are replicated to all nodes, regardless of which node they were made on.
Running commit in a local user session automatically ensures that the changed data is visible on all nodes in the cluster.
Rules of distribution
all cluster nodes are equivalent
all changes on any of the nodes are mapped to other nodes
if replication is not possible (the node is unavailable or the connection is broken), a persistent change queue is created for this node
the owner of any data frame is the node on which this frame has been allocated
the system uses the generation of unique identifiers for entities (@DistributedId) so that the identifier is unique within the cluster, and not just within the same node
the system does not use any additional checks for uniqueness, requiring locks at the cluster level
data inserts are performed strictly in local structures and then replicated
changes (update / delete) can be performed only on the node-owner of the data frame with this record. In future versions, it will be possible to change data from any node by obtaining a lock on the owner node.
SQL horizontal-scaling queries
All SQL queries called on any of the cluster nodes will be automatically distributed among the cluster nodes for parallel processing, if such a decision is made by the node based on the analysis of the volume of tasks (the volume of the query tables is large enough, etc.)
If during the processing of a request a node is unavailable, the task distributed for this node will be automatically rescheduled to another available node.