None. Any replication pattern is allowed and auto-detect loops prevent issues. In addition, arbitrary subsets of a table to be replicated to other tables are also allowed. Some reasonable topologies include the following:
Unusual topologies are also allowed. For example:
You might be concerned about forwarding loops after looking at these sample topologies. MapR-DB prevents these loops. When data is replicated from one table to another, the sending table adds its own UUID to the forwarding records. Before forwarding data to another replica, the sender checks to see if the target UUID is already in the chain. If it’s in the chain, the data is not forwarded since it has already been there. For example, if a write is performed to A, it will be forwarded to B, and then forwarded to C. C will not forward the write to A because the UUID chain indicates A already has the data.
Note: This approach doesn’t prevent extra (perhaps wasted) effort. For example, in the example scenario above, A also sends its writes directly to C. This means that C sees the same write from B and from A. This approach is somewhat harmless because the same data (with the same timestamp) is repeated. However, it wastes some system resources. A Put with the same exact value (including the timestamp) is performed twice. (This might seem to be inefficient. The alternative is to check to see if the value is already present before the Put. The problem with this approach is that it requires a Get, which is more expensive than a Put.) The Put consumes network and disk resources. Eventually, the duplicate is removed in a pack. (However, until then, it consumes space and impacts IO, and so on.)
Retrieving data ...