-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
HBASE-25975 Row Commit Sequencer #3360
base: master
Are you sure you want to change the base?
Conversation
The main issue with #3352 is serializing commits with the act of getting the time requires that everything that might mutate the resource you are trying to protect must be within that scope. For a single row update the scope would be a row, and highly granular, so performance will not be affected that much. For batch mutations, which are typical, the scope is the region, and serializing commits to a region is expensive. I struggled for a while with various forms of hierarchical clocks where one might get a clock for the region, then use that clock to get child clocks for a row, and was not successful because they always ended up serializing something at region scope, but then reconsidered... What is it we are really tracking? We are tracking per region a set of rows per clock tick. Why not track that explicitly? It seemed much simpler in retrospect. Hence this PR, to explore that idea instead. |
🎊 +1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
f6799b9
to
ccc2f9a
Compare
🎊 +1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
1 similar comment
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
1 similar comment
💔 -1 overall
This message was automatically generated. |
Use a row commit sequencer in HRegion to ensure that only the operations that mutate disjoint sets of rows are able to commit within the same clock tick. This maintains the invariant that more than one mutation to a given row will never be committed in the same clock tick. Callers will first acquire row locks for the row(s) the pending mutation will mutate. Then they will use RowCommitSequencer.getRowSequence to ensure that the set of rows about to be mutated do not overlap with those for any other pending mutations in the current clock tick. If an overlap is identified, getRowSequence will yield and loop until there is no longer an overlap and the caller's pending mutation can succeed.
🎊 +1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
Use a row commit sequencer in HRegion to ensure that only the operations that mutate disjoint sets of rows are able to commit within the same clock tick. This maintains the invariant that more than one mutation to a given row will never be committed in the same clock tick.
Callers will first acquire row locks for the row(s) the pending mutation will mutate. Then they will use RowCommitSequencer.getRowSequence to ensure that the set of rows about to be mutated do not overlap with those for any other pending mutations in the current clock tick. If an overlap is identified, getRowSequence will yield and loop until there is no longer an overlap and the caller's pending mutation can succeed.
TODO
Microbenchmarks
Measuring exactly the time to call region.batchMutate() at each iteration. Times are per op, measured in nanos, converted to milliseconds for printing.
Baseline:
0% contention case
100% contention case