greg/stasis-aries-wal
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

clenaup

Browse source
This commit is contained in:
Eric Brewer 2006-08-13 23:58:13 +00:00
parent 94757ccc4d
commit bb2713ba5e
1 changed files with 40 additions and 39 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

79
doc/paper3/LLADD.tex
View file

@ -237,17 +237,24 @@ the ideas presented here is available at \eab{where?}.
Database research has a long history, including the development of Database research has a long history, including the development of
many technologies that our system builds upon. This section explains many technologies that our system builds upon. This section explains
why databases are fundamentally inappropriate tools for system why databases are fundamentally inappropriate tools for system
developers. The problems we present here have been the focus of developers, and covers some of the preivous responses of the systems
community. The problems we present here have been the focus of
database and systems researchers for at least 25 years. database and systems researchers for at least 25 years.
\subsection{The Database View} \subsection{The Database View}
Database systems are often thought of in terms of the high-level The database community approaches the limited range of DBMSs by either
abstractions they present. For instance, relational database systems creating new top-down models, such as XML databases or streaming
implement the relational model~\cite{codd}, object-oriented databases, or by extending the relational model~\cite{codd} along some axis, such
databases implement object abstractions \eab{[?]}, XML databases implement as new data types. (We cover these attempts in more detail in
hierarchical datasets~\eab{[?]}, and so on. Before the relational model, Section~\ref{related-work}.) \eab{add cites}
navigational databases implemented pointer- and record-based data models.
%Database systems are often thought of in terms of the high-level
%abstractions they present. For instance, relational database systems
%implement the relational model~\cite{codd}, object-oriented
%databases implement object abstractions \eab{[?]}, XML databases implement
%hierarchical datasets~\eab{[?]}, and so on. Before the relational model,
%navigational databases implemented pointer- and record-based data models.
An early survey of database implementations sought to enumerate the An early survey of database implementations sought to enumerate the
fundamental components used by database system implementors~\cite{batoryConceptual,batoryPhysical}. This fundamental components used by database system implementors~\cite{batoryConceptual,batoryPhysical}. This
@ -266,38 +273,32 @@ abstraction (such as the relational model). The physical data model
is chosen to support efficiently the set of mappings that are built on is chosen to support efficiently the set of mappings that are built on
top of it. top of it.
\diff{A conceptual mapping based on the relational model might A conceptual mapping based on the relational model might translate a
translate a relation into a set of keyed tuples. If the database were relation into a set of keyed tuples. If the database were going to be
going to be used for short, write-intensive and high-concurrency used for short, write-intensive and high-concurrency transactions
transactions (OLTP), the physical model would probably translate sets (OLTP), the physical model would probably translate sets of tuples
of tuples into an on-disk B-Tree. In contrast, if the database needed into an on-disk B-Tree. In contrast, if the database needed to
to support long-running, read only aggregation queries (OLAP) over high support long-running, read-only aggregation queries (OLAP) over high
dimensional data, a physical model that stores the data in a sparse array format would dimensional data, a physical model that stores the data in a sparse
be more appropriate~\cite{molap}. Although both OLTP and OLAP databases are based array format would be more appropriate~\cite{molap}. Although both
upon the relational model they make use of different physical models OLTP and OLAP databases are based upon the relational model they make
in order to serve different classes of applications.} use of different physical models in order to serve different classes
of applications.
\diff{ A basic claim of A basic claim of
this paper is that no single known physical data model can efficiently this paper is that no single known physical data model can efficiently
support the wide range of conceptual mappings that are in use today. support the wide range of conceptual mappings that are in use today.
In addition to sets, objects, and XML, such a model would need In addition to sets, objects, and XML, such a model would need
to cover search engines, version-control systems, work-flow to cover search engines, version-control systems, work-flow
applications, and scientific computing, as examples. applications, and scientific computing, as examples.
}
The database community approaches the limited range of DBMSs by either Instead of attempting to create such a unified model after decades of
creating new top-down models, such as XML databases or streaming database research has failed to produce one, we opt to provide a
databases, or by extending the relational model along some axis, such bottom-up transactional toolbox that supports many different models
as new data types. We cover these attempts in efficiently. This makes it easy for system designers to
Section~\ref{related-work}. implement most of the data models that the underlying hardware can
support, or to abandon the database approach entirely, and forgo the
Instead of attempting to create such a model after decades of database use of a structured physical model and abstract conceptual mappings.
research has failed to produce one, we opt to provide a bottom-up transactional
toolbox that supports many different models efficiently, somewhat similar in spirit to Exokernel and Nemesis~\cite{xxx,xxx}.
This makes it easy for system designers to implement most of the data
models that the underlying hardware can support, or to
abandon the database approach entirely, and forgo the use of a
structured physical model or abstract conceptual mappings.
\subsection{The Systems View} \subsection{The Systems View}
@ -331,13 +332,13 @@ hashtables, and other access methods. It provides flags that
let its users tweak various aspects of the performance of these let its users tweak various aspects of the performance of these
primitives, and selectively disable the features it provides. primitives, and selectively disable the features it provides.
With the With the exception of the benchmark designed to fairly compare the two
exception of the benchmark designed to fairly compare the two systems, none of the \yad systems, none of the \yad applications presented in
applications presented in Section~\ref{sec:extensions} are efficiently Section~\ref{sec:extensions} are efficiently supported by Berkeley DB.
supported by Berkeley DB. This is a result of Berkeley DB's This is a result of Berkeley DB's assumptions regarding workloads and
assumptions regarding workloads and decisions regarding low-level data decisions regarding low-level data representation. Thus, although
representation. Thus, although Berkeley DB could be built on top of \yad, Berkeley DB could be built on top of \yad, Berkeley DB's data model
Berkeley DB's data model and write-ahead logging system are too specialized to support \yad. and write-ahead logging system are too specialized to support \yad.