[Chapter 3. Detailed Configuration [section A],

[Chapter 3. Detailed Configuration [section A],
Chapter 3. Configuration3.1. Groups

Groups is defined in the NODE_GROUP table. The following SQL statement creates a node group for "corp" and "store" in the distribution store example.

insertinto SYM_NODE_GROUP                (node_group_id, description)          values ('store', 'A retail storenode');                             insert into SYM_NODE_GROUP          (node_group_id, description)          values ('corp', 'A corporate node');

insertinto SYM_NODE_GROUP                (node_group_id, description)          values ('store', 'A retail storenode');                             insert into SYM_NODE_GROUP          (node_group_id, description)          values ('corp', 'A corporate node');

3.2. Group Links

Group links is defined in the NODE_GROUP_LINK table. Links defines how nodes in a group can contact nodes in other groups. The following describes the communication mechanism.

Push (P)
Indicates that the data source node will initiate communication through the http put request.

Wait for Pull (W)
It indicates that the data source node will wait for the target node to pull data from the data source node through the http get request.

Route-Only (R)
Route-Only indicates that data transmission will not pass into ricds. This type may be useful when you use XML to publish a Router or an audit table to change the Router.
If the configuration data is synchronized on the link, the Link can also be defined. For example, you may not want the remote node to be able to change its configuration, so you may be confused about other nodes in the network. In this case, you can set the value of sync_config_enabled to 0 on the corresponding Link.

A Link can use the same node group as both the source and target. This configuration allows a node group to synchronize data with other nodes in the node group.
The following SQL statement connects the "corp" and "store" Node groups. The "store" Node pushes their data changes to the "corp" node, and the "corp" Node waits for the "store" node to pull the data changes on the node.

insert into SYM_NODE_GROUP_LINK                 (source_node_group, target_node_group, data_event_action)           values ('store', 'corp', 'P');                   insert into SYM_NODE_GROUP_LINK                 (source_node_group, target_node_group, data_event_action)           values ('corp', 'store', 'W');

3.3. Channels

By classifying data to different channels and different TRIGGER management, you can get more data flow control and more visibility. In addition, mongoricds allows synchronization to be enabled, suspended, or rescheduled by channels. The synchronization frequency and Data Synchronization sequence are also controlled at the channel layer.

The following SQL statement creates several channels for a distribution store. An "Item" channel processes the data of the commodity and commodity price information, and the "sale_transaction" Channel processes the transaction information data.

insert into SYM_CHANNEL (channel_id, rocessing_order, max_batch_size, max_batch_to_send,                 extract_period_millis, batch_algorithm, enabled, description)           values ('item', 10, 1000, 10, 0, 'default', 1, 'Item and pricing data');                 insert into SYM_CHANNEL (channel_id, processing_order, max_batch_size,                 max_batch_to_send, extract_period_millis, batch_algorithm, enabled, description)           values ('sale_transaction', 1, 1000, 10, 60000,                 'transactional', 1, 'retail sale transactions from register');

In the Batch process, a Channel groups the data to be transmitted and submits the data to the client (other nodes ). There are three different out-of-the-box (haha) batch algorithms. You can specify the value of the batch_algorithm column when defining the channel to specify the desired batch algorithm.

Default
All data changes in a transaction must be combined by batch. Multiple transactions are committed together until no more data is sent or the batch size reaches the set max_batch_size value.

Transactional
Batch will be mapped directly to database transactions. If there are multiple small database transactions, there will be a lot of batch. In this algorithm, the value of max_batch_size does not work.

Nontraditional
Multiple transactions are committed together until no more data is sent or the batch size reaches the value set by max_batch_size. Batch will be truncated at the size of max_batch_size, whether in the middle of the transaction or not.

 

If a channel contains only the database tables to be synchronized in one direction and the data is routed to all nodes in the target group, the batch on the Channel will be optimized, to share the submitted batch among all target nodes. This is an important feature when data needs to be routed to thousands of nodes. When this node is detected, you will see that the Batch common_flag in the OUTGOING_BATCH table is set to 1.

The Channel has several size-related attributes. Including:

Max_batch_size
Specifies the maximum value of data change events that can be processed in a batch in this channel.

Max_batch_to_send
Specifies the maximum batch value to be sent to a given channel during a synchronization of two nodes. One synchronization is to push data or pull data at a time. For example, if 12 batchs are ready to be sent to a channel, max_batch_to_send equals 10, and only the first 10 of the 12 are sent, even if the 12 are all ready.

Max_data_to_route
Specifies the maximum number of data rows in a single route of a channel.

 

Based on your synchronization requirements, you can specify whether to read and transmit old data (data before data changes) when a channel is performing route data ), new data (data after data changes) and primary key data (that is, the primary key ). This is set by the use_old_data_to_route column, use_row_data_to_route column, and use_pk_data_to_route column of the channel table respectively. By default, they are all 1 (true ).

If the data on a channel contains Lob data, you can set the contains_big_lob column of the channel table to 1 (true). This will imply that the channel contains Lob data. If your ricds knows that the DATA table will not contain large objects, you can use the features provided by some databases. Therefore, if there are large objects in the table, it is best to configure them to let them know. Different databases have different definitions for the size of a large object.