Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix minor typo in BATCHING.md #717

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/BATCHING.md
Original file line number Diff line number Diff line change
Expand Up @@ -68,7 +68,7 @@ Note that purging enqueued messages should be considered safe, as long as Active

Yokozuna supports Active Anti-Entropy by maintaining a set of AAE trees in parallel with the Riak/KV AAE trees stored on the local node. Periodically, comparable AAE trees are exchanged locally between the Riak/KV AAE subsystem and the Yokozuna AAE subsystem. If any differences are detected, then the data in Solr is corrected. Specifically, if any data is detected in the YZ AAE tree that is not in the Riak/KV AAE tree, a Solr delete operation is generated. Conversely, if data is missing in a YZ AAE tree, or the hashes are not the same, then the entry is Solr is updated. In this sense, the data in Riak/KV is "canonical".

In both Riak/KV and Yokozuna, the AAE trees are representations of data that is stored in Riak/KV and Solr, respectively. They are not part of the Riak/KV or Solr data, but are instead auxiliary data structures (and persitent storage) alongside the actual data. In the case of Yokozuna, the YZ AAE trees are, with respect to the VNode, asynchronosly updated in the helper process, which may occur many milliseconds after the VNode has sent the message to the batching subsystem.
In both Riak/KV and Yokozuna, the AAE trees are representations of data that is stored in Riak/KV and Solr, respectively. They are not part of the Riak/KV or Solr data, but are instead auxiliary data structures (and persistent storage) alongside the actual data. In the case of Yokozuna, the YZ AAE trees are, with respect to the VNode, asynchronosly updated in the helper process, which may occur many milliseconds after the VNode has sent the message to the batching subsystem.

Because the Yokozuna batching subsystem introduces latency between the time that data is written to the Riak/KV AAE trees and the Yokozuna AAE trees, there is an increased likelihood that the AAE trees will diverge.

Expand Down