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

new abstract

Browse source
This commit is contained in:
Sears Russell 2006-04-22 19:52:59 +00:00
parent 6e4d6878cf
commit 1f86c4e6a3
1 changed files with 33 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

49
doc/paper3/LLADD.tex
View file

@ -67,25 +67,42 @@ while providing applications with increased control over its
underlying modules. Generic transactional storage systems such as SQL underlying modules. Generic transactional storage systems such as SQL
and BerkeleyDB serve many applications well, but impose constraints and BerkeleyDB serve many applications well, but impose constraints
that are undesirable to developers of system software and that are undesirable to developers of system software and
high-performance applications, while filesystems provide limited high-performance applications. Conversely, while filesystems place
functionality to applications. few constraints on applications, the do not provide atomicity or
durability properties that naturally correspond to application needs.
This paper generalizes write-ahead-logging algorithms, providing This paper addresses this gap (and enables the development of
applications with specialized functionality, cleaner semantics and unforeseen variants on transactional storage) by generalizing
improved performance. write-ahead-logging algorithms. Our partial implementation of these
ideas already provides specialized (and cleaner) semantics and
improved performance to applications.
Applications may use our modular library of basic data strctures to %Applications may use our modular library of basic data strctures to
compose new concurrent transactional access methods, or write their %compose new concurrent transactional access methods, or write their
own from scratch. This paper presents concrete low level examples %own from scratch.
that modify the semantics of the buffer manager to reduce memory and This paper presents examples that make use of custom access methods,
CPU overhead, reorder log entries for increased efficiency, and do modifed buffer manager semantics, direct log file manipulation, and
away with per-page LSNs in order to perform zero-copy transactional LSN-free pages that facilitate zero-copy optimizations, and discusses
I/O. We argue that encapsulation allows applications to compose the composability of these extensions.
extensions.
These ideas have been partially implemented, and initial performance We argue that our ability to support such a diverse range of
figures, and experience using the library compare favorably with transactional systems stems directly from our rejectiion of
existing systems. assumptions made by early database designers. These assumptions
permeate ``database toolkit'' research. We attribute the success of
low-level transaction processing libraries (such as Berkeley DB) to
a partial break from traditional database dogma.
% entries, and
% to reduce memory and
%CPU overhead, reorder log entries for increased efficiency, and do
%away with per-page LSNs in order to perform zero-copy transactional
%I/O.
%We argue that encapsulation allows applications to compose
%extensions.
%These ideas have been partially implemented, and initial performance
%figures, and experience using the library compare favorably with
%existing systems.
\section{Introduction} \section{Introduction}