diff --git a/doc/paper3/LLADD.bib b/doc/paper3/LLADD.bib index 1ea7426..0ba758a 100644 --- a/doc/paper3/LLADD.bib +++ b/doc/paper3/LLADD.bib @@ -297,12 +297,24 @@ OPTkey = {}, volume = {12}, number = {1}, - pages = {33-57}, - month = {Februrary}, + pages = {33--57}, + month = {February}, OPTnote = {}, OPTannote = {} } +@InProceedings{XMLdb, + author = {J. McHugh and S. Abiteboul and R. Goldman and D. Quass and J. Widom}, + title = {Lore: A Database Management System for Semistructured Data}, + booktitle = {SIGMOD Record}, + volume = {26}, + number = {3}, + pages = {54--66}, + month = {September}, + year = 1997 +} + + @Article{genesis, author = {D. S. Batory and J. R. Barnett and J. F. Garza and K. P. Smith and K. Tsukuda and B. C. Twichell and T. E. Wise}, title = {{GENESIS}: An Extensible Database Management System}, diff --git a/doc/paper3/LLADD.tex b/doc/paper3/LLADD.tex index 8caf215..ed9cc3a 100644 --- a/doc/paper3/LLADD.tex +++ b/doc/paper3/LLADD.tex @@ -379,7 +379,7 @@ We relax this restriction in Section~\ref{sec:lsn-free}. This section provides the ``Atomicity'' and ``Durability'' properties for a single ACID transaction.\endnote{The ``A'' in ACID really means atomic persistence of data, rather than atomic in-memory updates, as the term is normally -used in systems work~\cite{GR97}; the latter is covered by ``C'' and ``I''.} +used in systems work; the latter is covered by ``C'' and ``I''~\cite{GR97}.} First we describe single-page transactions, then multi-page transactions. ``Consistency'' and ``Isolation'' are covered with concurrent transactions in the next section. @@ -1354,7 +1354,7 @@ handled in any order, improving locality and merging opportunities.} \begin{figure}[t] \includegraphics[width=1\columnwidth]{figs/trans-closure-hotset.pdf} \vspace{-12pt} -\caption{\sf\label{fig:hotGraph} Hot set based graph traversal for random graphs with out-degrees of 3 and 9. Here +\caption{\sf\label{fig:hotGraph} Hot-set based graph traversal for random graphs with out-degrees of 3 and 9. Here we see that the multiplexer helps when the graph has poor locality. In the cases where depth first search performs well, the reordering is inexpensive.} @@ -1372,7 +1372,7 @@ many nodes, providing load balancing. Requests that update the same piece of in can be merged into a single request (RVM's ``log merging'' implements this type of optimization~\cite{lrvm}). Stream aggregation techniques and relational algebra operators could be used to -efficiently transform data while it is laid out sequentially in + transform data efficiently while it is laid out sequentially in non-transactional memory. To experiment with the potential of such optimizations, we implemented @@ -1636,8 +1636,8 @@ layout that we believe \yad could eventually support. Some large object storage systems allow arbitrary insertion and deletion of bytes~\cite{esm} within the object, while typical file systems provide append-only allocation~\cite{ffs}. -Record-oriented allocation is an older~\cite{multics}\rcs{Is comparing to multic accurate? Did it have variable length records?}, but still-used~\cite{gfs} -alternative. Write-optimized file systems lay files out in the order they +Record-oriented allocation, including Multics' segments~\cite{multics} and GFS~\cite{GFS}, is an alternative. +Write-optimized file systems lay files out in the order they were written rather than in logically sequential order~\cite{lfs}. Schemes to improve locality between small @@ -1656,7 +1656,7 @@ Allocation of records that must fit within pages and be persisted to disk raises concerns regarding locality and page layouts. Depending on the application, data may be arranged based upon hints~\cite{cricket}, pointer values and write order~\cite{starburst}, -data type~\cite{orion}, or reorganization based on access +data type~\cite{orion}, or access patterns~\cite{storageReorganization}. %Other work makes use of the caller's stack to infer @@ -1701,26 +1701,28 @@ by reusing \yads default extensions and implementing new ones. \section{Conclusion} -We have presented \yad, a transactional storage library that addresses +We presented \yad, a transactional storage library that addresses the needs of system developers. \yad provides more opportunities for specialization than existing systems. The effort required to extend \yad to support a new type of system is reasonable, especially when -compared to currently common practices, such as working around +compared to current practices, such as working around limitations of existing systems, breaking guarantees regarding data integrity, or reimplementing the entire storage infrastructure from scratch. -We have demonstrated that \yad provides fully -concurrent, high performance transactions, and explained how it can +We demonstrated that \yad provides fully +concurrent, high-performance transactions, and explored how it can support a number of systems that currently make use of suboptimal or -ad-hoc storage approaches. Finally, we have explained how \yad can be +ad-hoc storage approaches. Finally, we described how \yad can be extended in the future to support a larger range of systems. + + \section{Acknowledgements} Thanks to shepherd Bill Weihl for helping us present these ideas well, or at least better. The idea behind the \oasys buffer manager -optimization is from Mike Demmer. He and Bowei Du implemented \oasys. +optimization is from Mike Demmer; he and Bowei Du implemented \oasys. Gilad Arnold and Amir Kamil implemented pobj. Jim Blomo, Jason Bayer, and Jimmy Kittiyachavalit worked on an early version of \yad.