-
Notifications
You must be signed in to change notification settings - Fork 465
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
storage: use exchange-based sequencing to broadcast internal commands #31147
Merged
teskje
merged 2 commits into
MaterializeInc:main
from
teskje:storage-exchange-sequencer
Jan 28, 2025
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is fine, but it essentially uses the
index
as a capability. I think there's an alternative design that uses Timely's capabilities, but I'm leaving it to you which one you'd like to implement here. I think the order from the source to the sequencer doesn't matter, as long as it's not reordered -- you could also think of this as a batch of data and a capability(worker, index)
. After the sequencer, it's simpler as there is only a single operator instance that retains a capability, so it could just use a counter as its capability. The data then would be a vectors of updates per time, i.e.,Stream<_, Vec<Command>>
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried using timestamps first, instead of putting the index into the data and it turned out more complicated. Maybe I missed something though.
(worker, index)
, so(usize, u64)
. Tuples already implementTimestamp
, but they don't implementRefines<()>
, so I can't use them directly. Instead I have to implement a new timestamp type, which requires a bunch of boilerplate.The "as long as it's not reordered" is important though! Correct me if I'm wrong, but I think this could happen:
C1
at(0, 0)
.C2
at(0, 1)
.C2
.C1
.Or is there any guarantee that updates with different times are received in time order?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I'm not sure you do! At least,
(worker, index)
is a totally ordered type, whereworker
trumpsindex
no matter what, and roughly everyone should wait for a worker to finish out all of itsindex
before moving on to the next worker. I think you might wantProduct<worker, index>
, which I think should implementRefines<()>
. Does that sound right? (I'm trying to back out the intent from my partial understanding).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, though the thing I was considering would not involve waiting for frontiers or even looking at frontiers at all, but just using the timestamp to transport the command index (instead of putting it into the data as this PR does). If you don't look at frontiers, the partial order of times doesn't matter. It's entirely possible that working with frontiers would lead to a simpler implementation, but I don't know what that could look like!
I'm not so sure! The only thing we need is that the commands coming from one worker retain their order in the output, between workers there is no defined order. So we'd need a
(worker, index)
where instances are only comparable ifworker
is equal. But that becomes awkward becauseTimestamp
assumes the existence of a minimum that you can downgrade to all other timestamps. So I guess an(Option<worker>, index)
where(None, 0)
is that minimum?