Fill in "Checking point reads"
All checks were successful
Tests / Release [gcc] total: 704, passed: 704
GNU C Compiler (gcc) |Total|New|Outstanding|Fixed|Trend
|:-:|:-:|:-:|:-:|:-:
|0|0|0|0|:clap:
Reference build: <a href="https://jenkins.weaselab.dev/job/weaselab/job/conflict-set/job/main/61//gcc">weaselab » conflict-set » main #61</a>
Tests / Release [gcc,aarch64] total: 703, passed: 703
Tests / Coverage total: 702, passed: 702
weaselab/conflict-set/pipeline/head This commit looks good
All checks were successful
Tests / Release [gcc] total: 704, passed: 704
GNU C Compiler (gcc) |Total|New|Outstanding|Fixed|Trend
|:-:|:-:|:-:|:-:|:-:
|0|0|0|0|:clap:
Reference build: <a href="https://jenkins.weaselab.dev/job/weaselab/job/conflict-set/job/main/61//gcc">weaselab » conflict-set » main #61</a>
Tests / Release [gcc,aarch64] total: 703, passed: 703
Tests / Coverage total: 702, passed: 702
weaselab/conflict-set/pipeline/head This commit looks good
This commit is contained in:
8
.vscode/settings.json
vendored
8
.vscode/settings.json
vendored
@@ -1,5 +1,9 @@
|
||||
{
|
||||
"files.associations": {
|
||||
"*.tikz": "latex"
|
||||
}
|
||||
}
|
||||
},
|
||||
"latex-workshop.view.pdf.invertMode.enabled": "compat",
|
||||
"latex-workshop.view.pdf.invert": 1,
|
||||
"latex-workshop.view.pdf.invertMode.sepia": 1,
|
||||
"latex-workshop.view.pdf.invertMode.grayscale": 0.5
|
||||
}
|
||||
|
@@ -33,7 +33,6 @@ For any ordered data structure we can implement \textit{lastCommit} using a repr
|
||||
This is a standard technique used throughout FoundationDB.
|
||||
|
||||
The problem with applying this to an off-the-shelf ordered data structure is that checking a read range is linear in the number of intersecting physical keys.
|
||||
In order to support higher concurrent write load, we must store write sets from more transactions.
|
||||
Scanning through every recent point write intersecting a large range read would make conflict checking unacceptably slow for high-write-throughput workloads.
|
||||
|
||||
This suggests we consider augmenting \cite{cormen2022introduction} an ordered data structure to make checking the max version of a range sublinear.
|
||||
@@ -59,18 +58,36 @@ The Height Optimized Trie (HOT) \cite{binna2018hot} outperforms ART, but has a f
|
||||
|
||||
\section{Augmented radix tree}
|
||||
|
||||
Each node in the tree is annotated with either one field \emph{max}, or three fields: \emph{max}, \emph{point}, and \emph{range}.
|
||||
We now propose our design for an augmented radix tree implementation of \emph{lastCommit}.
|
||||
The design is the same as the Adaptive Radix Tree \cite{DBLP:conf/icde/LeisK013}, but each node in the tree is annotated with either one field \emph{max}, or three fields: \emph{max}, \emph{point}, and \emph{range}.
|
||||
\emph{max} represents the maximum version among all keys starting with the prefix associated with the node's place in the tree (i.e. the search path from the root to this node).
|
||||
\emph{point} represents the version of the exact key starting with this node's prefix.
|
||||
\emph{range} represents the version of all keys $k$ such that this is the first node greater than or equal to $k$ with all three fields set.
|
||||
|
||||
See figure \ref{fig:tree} for an example of an augmented radix tree, after inserting
|
||||
\emph{point} represents the version of the exact key matching this node's prefix.
|
||||
\emph{range} represents the version of all keys $k$ such that this is the first node greater than $k$ with all three fields set.
|
||||
See figure \ref{fig:tree} for an example tree after inserting
|
||||
$[AND, ANT) \rightarrow 1$,
|
||||
$\{ANY\} \rightarrow 2$,
|
||||
$\{ARE\} \rightarrow 3$, and
|
||||
$\{ART\} \rightarrow 4$.
|
||||
Each node shows its partial prefix annotated with $(max,point,range)$.
|
||||
|
||||
\subsection{Checking point reads}
|
||||
|
||||
The algorithm for checking point reads follows directly from the definitions of the \emph{point} and \emph{range}.
|
||||
Our input is a key $k$ and a read version $r$, and we must report whether or not the write version $v_{k}$ of $k$ is less than or equal to $r$.
|
||||
In order to find $v_{k}$, we search for the node whose prefix matches $k$.
|
||||
If such a node exists and has \emph{point} set, then $v_{k}$ is its \emph{point} field.
|
||||
Otherwise, we scan forward to find the first node greater than $k$ with \emph{range} set.
|
||||
If such a node exists, then $v_{k}$ is its \emph{range} field.
|
||||
Otherwise $k$ logically has no write version, and so the read does not conflict.
|
||||
|
||||
As an optimization, during the search phase for a point read we can inspect the \emph{max} at each node that's a prefix of $k$.
|
||||
If the max version among all keys starting with a prefix of $k$ is less than or equal to $r$, then $v_{k} \leq r$.
|
||||
|
||||
\subsection{Checking range reads}
|
||||
\subsection{Adding point writes}
|
||||
\subsection{Adding range writes}
|
||||
\subsection{Reclaiming old entries}
|
||||
|
||||
\begin{figure}
|
||||
\caption{}
|
||||
\label{fig:tree}
|
||||
|
Reference in New Issue
Block a user