forked from Deuxfleurs/garage
Add explanations about quorums
This commit is contained in:
parent
f5a7bc3736
commit
1f5e3aaf8e
6 changed files with 66 additions and 27 deletions
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
|
@ -684,20 +684,77 @@
|
||||||
\end{frame}
|
\end{frame}
|
||||||
|
|
||||||
\begin{frame}
|
\begin{frame}
|
||||||
\frametitle{Performance gains in practice}
|
\frametitle{Read-after-write consistency:}
|
||||||
\begin{center}
|
\textbf{Property:} If node $A$ did an operation $write(x)$ and received an OK response,\\
|
||||||
\includegraphics[width=.8\linewidth]{assets/endpoint-latency-dc.png}
|
\hspace{2cm} and node $B$ starts an operation $read()$ after $A$ received OK,\\
|
||||||
\end{center}
|
\hspace{2cm} then $B$ will read a value $x' \sqsupseteq x$.
|
||||||
\end{frame}
|
|
||||||
|
|
||||||
|
\vspace{1em}
|
||||||
|
|
||||||
|
\hspace{1em}
|
||||||
|
\begin{minipage}{6.8cm}
|
||||||
|
\textbf{Algorithm $write(x)$:}
|
||||||
|
\begin{enumerate}
|
||||||
|
\item Broadcast $write(x)$ to all nodes
|
||||||
|
\item Wait for $k > n/2$ nodes to reply OK
|
||||||
|
\item Return OK
|
||||||
|
\end{enumerate}
|
||||||
|
\end{minipage}
|
||||||
|
\hfill
|
||||||
|
\begin{minipage}{6.8cm}
|
||||||
|
\vspace{1em}
|
||||||
|
\textbf{Algorithm $read()$:}
|
||||||
|
\begin{enumerate}
|
||||||
|
\item Broadcast $read()$ to all nodes
|
||||||
|
\item Wait for $k > n/2$ nodes to reply\\
|
||||||
|
with values $x_1, \dots, x_k$
|
||||||
|
\item Return $x_1 \sqcup \dots \sqcup x_k$
|
||||||
|
\end{enumerate}
|
||||||
|
\end{minipage}
|
||||||
|
\hspace{1em}
|
||||||
|
|
||||||
|
\vspace{2em}
|
||||||
|
\textbf{Why does it work?} There is at least one node at the intersection between the two sets of nodes that replied to each request, that ``saw'' $x$ before the $read()$ started ($x_i \sqsupseteq x$).
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
\begin{frame}
|
\begin{frame}
|
||||||
\frametitle{An ever-increasing compatibility list}
|
\frametitle{Monotonical read consistency:}
|
||||||
\begin{center}
|
\textbf{Property:} If node $A$ did an operation $read()$ and received $x$ as a response,\\
|
||||||
\includegraphics[width=.7\linewidth]{assets/compatibility.png}
|
\hspace{2cm} and node $B$ starts an operation $read()$ after $A$ received $x$,\\
|
||||||
\end{center}
|
\hspace{2cm} then $B$ will read a value $x' \sqsupseteq x$.
|
||||||
|
|
||||||
|
\vspace{1em}
|
||||||
|
|
||||||
|
\textbf{Algorithm $read()$:}
|
||||||
|
\begin{enumerate}
|
||||||
|
\item Broadcast $read()$ to all nodes
|
||||||
|
\item Wait for $k > n/2$ nodes to reply with values $x_1, \dots, x_k$
|
||||||
|
\item If $x_i \ne x_j$ for some nodes $i$ and $j$,\\
|
||||||
|
\hspace{1cm}then call $write(x_1 \sqcup \dots \sqcup x_k)$ and wait for OK from $k' > n/2$ nodes
|
||||||
|
\item Return $x_1 \sqcup \dots \sqcup x_k$
|
||||||
|
\end{enumerate}
|
||||||
|
|
||||||
|
\vspace{1em}
|
||||||
|
This makes reads slower in some cases, and is \textbf{not implemented in Garage}.
|
||||||
\end{frame}
|
\end{frame}
|
||||||
|
|
||||||
|
\begin{frame}
|
||||||
|
\frametitle{Performance gains in practice}
|
||||||
|
\begin{center}
|
||||||
|
\includegraphics[width=.8\linewidth]{assets/endpoint-latency-dc.png}
|
||||||
|
\end{center}
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
\begin{frame}
|
||||||
|
\frametitle{The hard parts we don't address (yet!)}
|
||||||
|
\begin{itemize}
|
||||||
|
\item Maintain consistency changes when nodes assigned to a partition change:\\
|
||||||
|
\item TODO
|
||||||
|
\end{itemize}
|
||||||
|
\end{frame}
|
||||||
|
|
||||||
|
\section{Going further than the S3 API}
|
||||||
|
|
||||||
\begin{frame}
|
\begin{frame}
|
||||||
\frametitle{Further plans for Garage}
|
\frametitle{Further plans for Garage}
|
||||||
\begin{center}
|
\begin{center}
|
||||||
|
@ -728,24 +785,6 @@
|
||||||
\end{center}
|
\end{center}
|
||||||
\end{frame}
|
\end{frame}
|
||||||
|
|
||||||
\begin{frame}
|
|
||||||
\frametitle{Aerogramme data model}
|
|
||||||
\begin{center}
|
|
||||||
\only<1>{\includegraphics[width=.4\linewidth]{assets/aerogramme_datatype.drawio.pdf}}%
|
|
||||||
\only<2->{\includegraphics[width=.9\linewidth]{assets/aerogramme_keys.drawio.pdf}\vspace{1em}}%
|
|
||||||
\end{center}
|
|
||||||
\visible<3->{Aerogramme encrypts all stored values for privacy\\
|
|
||||||
(Garage server administrators can't read your mail)}
|
|
||||||
\end{frame}
|
|
||||||
|
|
||||||
\begin{frame}
|
|
||||||
\frametitle{Different deployment scenarios}
|
|
||||||
\begin{center}
|
|
||||||
\only<1>{\includegraphics[width=.9\linewidth]{assets/aerogramme_components1.drawio.pdf}}%
|
|
||||||
\only<2>{\includegraphics[width=.9\linewidth]{assets/aerogramme_components2.drawio.pdf}}%
|
|
||||||
\end{center}
|
|
||||||
\end{frame}
|
|
||||||
|
|
||||||
\begin{frame}
|
\begin{frame}
|
||||||
\frametitle{A new model for building resilient software}
|
\frametitle{A new model for building resilient software}
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
|
|
Loading…
Reference in a new issue