This commit is contained in:
Eric Brewer 2006-09-03 20:02:03 +00:00
parent 742fc3bf5d
commit feabcac61e
2 changed files with 28 additions and 14 deletions

View file

@ -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},

View file

@ -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.