This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "". The branch, master has been updated via 9d91c531f890347458ff4a251e0bacb62216a0a9 (commit) from bd61cc1d2a6766b21646a835033f116f4ffc4ee6 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 9d91c531f890347458ff4a251e0bacb62216a0a9 Author: Phil Carns <[email protected]> Date: Fri Jun 21 12:03:55 2013 -0400 clarify data models and use cases ----------------------------------------------------------------------- Summary of changes: papers/asg-osd/sections/abstract.tex | 4 ++-- papers/asg-osd/sections/casestudies.tex | 6 +++--- papers/asg-osd/sections/introduction.tex | 25 +++++++++---------------- 3 files changed, 14 insertions(+), 21 deletions(-) Diff of changes: diff --git a/papers/asg-osd/sections/abstract.tex b/papers/asg-osd/sections/abstract.tex index 9c1d5db..e1d52f5 100644 --- a/papers/asg-osd/sections/abstract.tex +++ b/papers/asg-osd/sections/abstract.tex @@ -17,5 +17,5 @@ storage systems that address these requirements and explore how they can be unified effectively without sacrificing usability. We validate the effectiveness of our approach by evaluating how the API could be used in the construction of three diverse but representative use cases: -a POSIX file system name space, a column-store NOSQL database and a -\todo{is this third use case right?} data set with concurrent writers. +a POSIX file system name space, a column-store key/value database, and +an HPC application checkpoint. diff --git a/papers/asg-osd/sections/casestudies.tex b/papers/asg-osd/sections/casestudies.tex index e19600b..5eaefb3 100644 --- a/papers/asg-osd/sections/casestudies.tex +++ b/papers/asg-osd/sections/casestudies.tex @@ -2,14 +2,14 @@ In this section we show how ASG storage model can be used as a basis to construct a namespace and a column store and to support concurrent write accesses. -\subsection{Namespace Implementation} +\subsection{POSIX file system name space} \label{namespace} \input{sections/namespace_usecase} -\subsection{Column Store} +\subsection{Column-store key/value database} \input{sections/columnstore_usecase} -\subsection{Concurrent Write Access} +\subsection{HPC application checkpoint} \input{sections/concurrentwrite_usecase} diff --git a/papers/asg-osd/sections/introduction.tex b/papers/asg-osd/sections/introduction.tex index 8353b21..6df4ac0 100644 --- a/papers/asg-osd/sections/introduction.tex +++ b/papers/asg-osd/sections/introduction.tex @@ -48,32 +48,26 @@ data models sharing a unified storage pool?} In order to address this problem, we first begin by identifying some of the most popular large-scale data models in use today. The following list -divides them into five categories with representative examples: +divides them into four categories with representative examples: \todo{should we add citations for each example?} \begin{itemize} \item \textbf{Parallel file systems}: Lustre, GPFS, Panasas, PVFS, Ceph \item \textbf{Cloud object storage}: Amazon S3, Swift, Rados Gateway \item \textbf{MapReduce}: Google File System (GFS), Hadoop HDFS -\item \textbf{Key/Value stores}: Dynamo, Redis, Hyperdex, Cassandra -\item \textbf{NOSQL}: BigQuery, MongoDB, CouchDB \todo{NOSQL is really broad -when you get down to it. The things I'm listing here are really -document-oriented or non-sql column stores. Maybe we should narrow this -down some or categorize differently. It would be nice to keep column -oriented non-sql examples in here somewhere though...} +\item \textbf{NOSQL Key/Value stores}: Dynamo, Redis, Hyperdex, Cassandra, +BigQuery \end{itemize} Note that these data models aren't necessarily mutually exclusive. For -example, key/value stores are often considered to be a subset of the NOSQL -storage taxonomy and many parallel file systems have been extended to support +example, several parallel file systems have been extended to support MapReduce workloads. We will refer to these classifications in the remainder of the paper for clarity, however, in order to simplify the discussion of use cases and requirements that are shared across groups of storage -systems. -\todo{Also say something about why we aren't including -conventional SQL databases? Basically the API and semantics are so well -established and well defined that those systems have become highly -specialized already...} +systems. We do not include SQL databases in our taxonomy of data models, +however, as most SQL database implementations are built using customized +internal data models to better support sophisticated read/modify/write +transactions. \begin{table} \begin{center} @@ -84,8 +78,7 @@ specialized already...} \multicolumn{1}{|c|}{Parallel File System} & \cmark & \cmark & \cmark & & & \\\hline \multicolumn{1}{|c|}{Cloud Object Storage} & & & \cmark & & & \\\hline \multicolumn{1}{|c|}{Mapreduce} & & & & \cmark & & \\\hline -\multicolumn{1}{|c|}{Key-value Store} & \cmark & \cmark & \cmark & & \cmark & \\\hline -\multicolumn{1}{|c|}{NOSQL Databases} & & \cmark & \cmark & & \cmark & \cmark \\\hline +\multicolumn{1}{|c|}{NOSQL Key-value Store} & \cmark & \cmark & \cmark & & \cmark & \cmark \\\hline \end{tabular}} \end{center} \caption{Distinguishing requirements for popular scalable storage data models} hooks/post-receive --