K2V PollRange, version 2 #471
No reviewers
Labels
No labels
action
check-aws
action
discussion-needed
action
for-external-contributors
action
for-newcomers
action
more-info-needed
action
need-funding
action
triage-required
kind
correctness
kind
ideas
kind
improvement
kind
performance
kind
testing
kind
usability
kind
wrong-behavior
prio
critical
prio
low
scope
admin-api
scope
background-healing
scope
build
scope
documentation
scope
k8s
scope
layout
scope
metadata
scope
ops
scope
rpc
scope
s3-api
scope
security
scope
telemetry
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Deuxfleurs/garage#471
Loading…
Reference in a new issue
No description provided.
Delete branch "k2v-watch-range-2"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR is the second proposal of an implementation of PollRange for K2V, and the one we will keep.
The hard part with implementing this new endpoint is that we need to define a "seen marker" type, which is compact enough but yet transmits enough information so that items that have already been seen will not be retransmitted upon further PollRange call, but most importantly, that items will never be missed, which could happen for example if they arrive out of order at the various storage nodes (because we do not have something like causal-order delivery).
The first version, which we abandonned, required to store the history of all K2V operations in a dedicated history table. This provided a seen marker that is just a vector clock (like an item's causality token), but it is too costly server side, so we developped this version 2, which reports the cost on the caller of PollRange. The "seen marker" type can be bigger in some cases, because it is a vector clock + a set of causality tokens for items not covered by the vector clock, but no further complexity on the server side is needed (except one thing: we made k2v timestamps globally increasing on each node, which requires to reinforce the transactional nature of K2V insertions).
be152c2dae
to9f5419f465
ed3e44c34e
toba00e81a42
ba00e81a42
to8bf06e0ba6
8bf06e0ba6
to57eabe7879
01a948edc4
to32aab06929
WIP: K2V PollRange, version 2to K2V PollRange, version 2