|
@@ -160,10 +160,116 @@ This paper demonstrates that ACID transactions and associated strong isolation l
|
|
|
\end{itemize}
|
|
|
\end{frame}
|
|
|
|
|
|
+\begin{frame}
|
|
|
+\frametitle{Introduction}
|
|
|
+With the drop in memory prices a set of in \textbf{main memory} database emerged. While for most of OLTP workloads often this solution is reasonable, due to the fact that often databases exhibit a skewed access patterns that divide records in hot (frequently accessed) and cold (rarely accessed) it is still convenient to find a way to maintain the hot records in memory and the cold ones on for example flash storage, that is still a lot less expensive than memory.
|
|
|
+\end{frame}
|
|
|
+
|
|
|
+\begin{frame}
|
|
|
+\frametitle{Introduction}
|
|
|
+In this paper it is presented \textbf{Project Siberia}, an extension to the \textbf{Hekaton} engine of Microsoft SQL Server that aims to pursue these objectives:
|
|
|
+\begin{itemize}
|
|
|
+ \item Cold data classification.
|
|
|
+ \item Cold data storage.
|
|
|
+ \item Cold storage access reduction.
|
|
|
+ \item Cold data access and migration mechanism (the focus of this paper is on this aspect).
|
|
|
+\end{itemize}
|
|
|
+\end{frame}
|
|
|
+
|
|
|
+\begin{frame}
|
|
|
+\frametitle{Hekaton}
|
|
|
+This figure shows how the storage and indexing is done in Hekaton:
|
|
|
+\centering
|
|
|
+\includegraphics[width=0.70\textwidth,height=0.70\textheight]{hekaton-storage}
|
|
|
+\end{frame}
|
|
|
+
|
|
|
+\begin{frame}
|
|
|
+\frametitle{Hekaton}
|
|
|
+Hekaton utilizes optimistic multi-version concurrency control (MVCC), it mainly leverage these features of timestamps to obtain this:
|
|
|
+\begin{itemize}
|
|
|
+ \item Commit/End Time (useful to determine the serialization order).
|
|
|
+ \item Valid Time.
|
|
|
+ \item Logical Read Time (start time of the transaction).
|
|
|
+\end{itemize}
|
|
|
+\end{frame}
|
|
|
+
|
|
|
+\begin{frame}
|
|
|
+\frametitle{Some important data structures}
|
|
|
+\begin{figure}
|
|
|
+\caption{Structure of a record in the cold store.}
|
|
|
+\centering
|
|
|
+\includegraphics[width=0.30\textwidth,height=0.10\textheight]{cold-record}
|
|
|
+\end{figure}
|
|
|
+\begin{figure}
|
|
|
+\caption{Structure of a cached record.}
|
|
|
+\centering
|
|
|
+\includegraphics[width=0.75\textwidth,height=0.15\textheight]{cached-record}
|
|
|
+\end{figure}
|
|
|
+\begin{figure}
|
|
|
+\caption{Structure of a timestamp notice in the update memo.}
|
|
|
+\centering
|
|
|
+\includegraphics[width=0.70\textwidth,height=0.15\textheight]{timestamp-notice}
|
|
|
+\end{figure}
|
|
|
+\end{frame}
|
|
|
+
|
|
|
+\begin{frame}
|
|
|
+\frametitle{The main operations on the cold storage}
|
|
|
+\begin{itemize}
|
|
|
+ \item \textbf{Insert:} done always in the hot storage.
|
|
|
+ \item \textbf{Migration to cold storage:} is the only way to move a record from the hot storage to the cold one.
|
|
|
+ \item \textbf{Delete.}
|
|
|
+ \item \textbf{Updates:} a delete operation on the cold storage followed by an insertion in the hot storage.
|
|
|
+ \item \textbf{Read.}
|
|
|
+ \item \textbf{Update Memo and Cold Store Cleaning.}
|
|
|
+\end{itemize}
|
|
|
+\end{frame}
|
|
|
+
|
|
|
+\begin{frame}
|
|
|
+\frametitle{Focus on migration}
|
|
|
+\begin{figure}
|
|
|
+\caption{Contents of cold store, hot store, and update memo during migration of a record.}
|
|
|
+\centering
|
|
|
+\includegraphics[width=0.60\textwidth,height=0.60\textheight]{cold-migration}
|
|
|
+\end{figure}
|
|
|
+\end{frame}
|
|
|
+
|
|
|
+\begin{frame}
|
|
|
+\frametitle{Focus on delete}
|
|
|
+\begin{figure}
|
|
|
+\caption{Effect on the cold store and update memo of a record deletion.}
|
|
|
+\centering
|
|
|
+\includegraphics[width=0.60\textwidth,height=0.70\textheight]{cold-delete}
|
|
|
+\end{figure}
|
|
|
+\end{frame}
|
|
|
+
|
|
|
+\begin{frame}
|
|
|
+\frametitle{Takeaways}
|
|
|
+\begin{itemize}
|
|
|
+ \item We nedd a new phase called \textbf{validation}, that checks just before a commit action that all the records used during the transactions still exist, are valid or are have not been modified.
|
|
|
+ \item There is \textbf{no deletion} in the strict sense of the term. The to-delete records have they end timestamps changed, and the garbage collection remove the unused records (when all the transactions alive begun after the deletion).
|
|
|
+\end{itemize}
|
|
|
+\end{frame}
|
|
|
+
|
|
|
\begin{frame}
|
|
|
\frametitle{Template}
|
|
|
\end{frame}
|
|
|
|
|
|
+
|
|
|
+\begin{frame}
|
|
|
+\frametitle{Template}
|
|
|
+\end{frame}
|
|
|
+
|
|
|
+
|
|
|
+\begin{frame}
|
|
|
+\frametitle{Template}
|
|
|
+\end{frame}
|
|
|
+
|
|
|
+
|
|
|
+\begin{frame}
|
|
|
+\frametitle{Template}
|
|
|
+\end{frame}
|
|
|
+
|
|
|
+
|
|
|
\begin{frame}
|
|
|
\frametitle{License}
|
|
|
\centering
|