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

abstract

Browse source
This commit is contained in:
Eric Brewer 2005-03-26 08:15:34 +00:00
parent 93e91fc502
commit 40b412eee0
1 changed files with 13 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

29
doc/paper2/LLADD.tex
View file

@ -33,7 +33,7 @@
\begin{document} \begin{document}
\title{\vspace*{-36pt}\yad: A Flexible Transactional Storage System\vspace*{-36pt}} \title{\vspace*{-36pt}\yad: A Flexible Transactional Storage System\vspace*{-36pt}}
%\author{} %\author{}
\date{Paper 198}
\maketitle \maketitle
@ -42,21 +42,18 @@
{\em Existing transactional systems are designed to handle specific {\em Existing transactional systems are designed to handle specific
workloads well. Unfortunately, these implementations are generally workloads well. Unfortunately, these implementations are generally
monolithic, and do not generalize to other applications or classes of monolithic and hide the transaction support under a SQL interface, which forces many systems to ``work around'' the relational data model.
problems. As a result, many systems are forced to ``work around'' the Manifestations of this problem include the
data models provided by a transactional storage layer. Manifestations %``impedance mismatch'' in the database world, and
of this problem include ``impedance mismatch'' in the database world, the poor fit of existing transactional storage systems to persistent
and the poor fit of existing transactional storage management systems objects and hierarchical or semi-structured data, such as XML or
to hierarchical or semi-structured data types such as XML or scientific data. This work proposes a novel flexible transaction
scientific data. This work proposes a novel set of abstractions for framework intended for non-database transactional systems; for
transactional storage systems and generalizes an existing example, \yad makes it is easy to develop high-performance transactional
transactional storage algorithm to provide an implementation of these data structures. It generally outperforms Berkeley DB, and its
primitives. Due to the extensibility of our architecture, the extensibility enables optimizations that outperform Berkeley DB by 2x
implementation is competitive with existing systems on conventional and MySQL by up to 5x. We present novel optimizations for object
workloads and outperforms existing systems on specialized serialization and graph traversal that demonstrate this flexibility.}
workloads. Finally, we discuss characteristics of this new
architecture that provide opportunities for novel classes of
optimizations and enhanced usability for application developers.}
%Although many systems provide transactionally consistent data %Although many systems provide transactionally consistent data
%management, existing implementations are generally monolithic and tied %management, existing implementations are generally monolithic and tied