Revising intro.

paper.tex

@@ -9,6 +9,7 @@
 
 \newtheorem{example}{Example}
 \usepackage[dvipsnames]{xcolor}
+\newcommand{\trimfigurespacing}{\vspace{-6mm}}
 
 %\numberofauthors{1}
 

sections/1-introduction.tex

@@ -16,11 +16,11 @@ Many modern smartphone applications (apps), operating systems, and services need
 For this task, developers typically turn to an embedded database like SQLite, which is a part of most modern smartphone operating systems.
 Embedded databases play a significant role in the performance of smartphone apps and can easily become sources of user-perceived latency~\cite{yang-icse15}.
 Providing database support for good user experiences presently requires tuning indexes, schemas, or other configutation options to the needs of the app.
-While the process of (automated) database tuning has received significant attention~\cite{DBLP:conf/vldb/ChaudhuriN07,DBLP:conf/vldb/AgrawalCN00,DBLP:conf/sigmod/AkenPGZ17}, each solution relies on a representative model of the database workload.
+While the process of (automated) database tuning has received significant attention~\cite{DBLP:conf/vldb/ChaudhuriN07,DBLP:conf/vldb/AgrawalCN00,DBLP:conf/sigmod/AkenPGZ17}, each solution relies on having a representative model of the database workload.
 
 In the server-class systems that the database community is familiar with, workloads are typically high-volume streams of homogeneous queries from a mix of simultaneous users.
-Hence, while there may be shifts in workload frequency, the workload itself can be modeled by a representative sample of queries.
-Conversely, each smartphone app has a dedicated database, and is typically used by only one user for a variety of tasks that are usually performed one at a time.
+Hence, while there may be shifts in workload frequency, queries in the workload itself can be modeled by a representative sample of queries.
+Conversely, every smartphone app: (1) has a dedicated database, (2) is typically used by only one user, and (3) is used for a variety of tasks that are usually performed one at a time.
 Simple workload samples are not representative of the bursty, variable, and noisy database access patterns of a typical app (e.g., Figure~\ref{fig:sampleFacebook}).
 
 \begin{figure}
@@ -28,36 +28,43 @@ Simple workload samples are not representative of the bursty, variable, and nois
     \includegraphics[width=0.45\textwidth]{graphics/ChangeOverTimeData}
     \caption{Sample Facebook Workload}
     \label{fig:sampleFacebook}
+    \trimfigurespacing
 \end{figure}
 
 In this paper, we develop a process for modeling smartphone database workload activity.  
-Nominally, this requires us to (1) understand how users interact with the app, and (2) how these interactions translate into database activity.
+Nominally, this requires us first to understand how users interact with the app, and then understand how these interactions translate into database activity.
 The most direct way to do this would be to instrument the app to monitor user interactions, as well as the resulting database activity.
 Assuming that it is possible to modify the app --- which is not always the case --- such instrumentation is not always productive.
 For example, latency sensitive operations like list scrolling can trigger rapid sequences of single-row or range queries~\cite{DBLP:conf/sigmod/EbensteinKN16}, but can be hard to instrument without affecting user experience.
-Such queries are frequently offloaded to background worker threads, making it hard to attribute these queries to any specific user action.
-In short, directly instrumenting the app is not always feasible.
+Worse, such queries are frequently offloaded to background worker threads, making it hard to attribute queries to the specific event that triggered them.
+In short, directly instrumenting the app is not always a viable option.
 
 We propose a more straightforward summarization technique that only requires a log of the app's queries.
 Such a log can be obtained by simply linking the app against an appropriately instrumented embedded database library~\cite{kennedy2015pocket}.
-Overtly, our approach is similar to the naive one: We first summarize user interactions with the app and then the effect of these interactions on the database.
-To summarize user interactions, we treat the query log as a collection of \emph{sessions}, or bursts of database activity typically triggered by self-contained user activities, such as checking a Facebook feed or composing an email.
-After partitioning a log into sessions, we attempt to recover the specific class of interaction associated with each sequence, mapping each session to one of a set of \emph{session categories}.
-In principle, recovering a session category could be accomplished by comparing subsets of the query log with ground truth queries generated in a controlled setting.
-Although our summarization strategy does support this mode of use, we also show that it is unnecessary and that sessions can be categorized automatically, without ground truth.
-Summaries resulting from our approach may embedded database developers to better understand app requirements, app developers to better tune app performance, mobile phone OS designers to tune OS level services, or even to generate synthetic workload traces.
-We validate our approach using recently collected traces of smartphone query activity in the wild~\cite{kennedy2015pocket}, and show that it is able to cluster queries into meaningful summaries of real world data.
+Overtly, our approach is similar to the naive one, modeling both the user's interactions with the app, as well as the effect of these interactions on the database.
+By necessity, this approach can only approximate the user's exact interactions.
+However, as we show experimentally, this simple two-level model fits existing training workloads well, and more importantly, reliably predicts testing workloads.
+
+Concretely, the contribution of this paper is a process for modeling smartphone workloads.
+The process consists of three stages: (1) Segmentation, (2) Session Categorization, and (3) Session Modeling.  
+The last of these stages mirrors the server-class workload modeling problem, so we focus our efforts on the first two stages.
 
 \tinysection{Segmenting Query Logs}
-The first major challenge we address is segmenting the query log into its component sessions.
-This is difficult for two reasons.
-First, there are no explicit cues from the user or app that signal a session has started or completed.
-Furthermore, some apps generate queries in background tasks, adding a level of noise to the session segmenting process.
-Nevertheless, we show that a simple approach based on query inter-arrival rates is sufficient to segment the log into meaningful sessions.
+The frist step of this process is to segment the query log into a collection of \emph{sessions}.
+Intuitively, a session would correspond to a specific user interaction like checking a Facebook feed or composing an email.
+However, directly modeling user activities is difficult for two reasons.
+First, there are no explicit cues from the user or app that signal a distinct user action has started or completed.
+Furthermore, some apps generate queries in background tasks, adding a consistent level of noise throughout the trace.
+Instead, we adopt a simpler view, where a session is simply defined as a continuous burst of database activity.
+As a result, a single session of the log may encompass multiple user activities, or a single user activity may be split across multiple segments.
+We show that in spite of this simplification, the resulting models retain their predictive power.
 We also propose a strategy for identifying an appropriate time threshold for each app, using similarities in query logs from across a diverse population of users.
 
+
 \tinysection{Assigning Session Categories}
-Second, we address the problem of effectively identifying session categories to create meaningful summaries of the log.
+The second step in the modeling process is to associate each sequence with a specific class of user interaction by mapping each session to one of a set of \emph{session categories}.
+In principle, recovering a session category could be accomplished by comparing subsets of the query log with ground truth queries generated in a controlled setting.
+Although our summarization strategy does support this mode of use, we also show that it is unnecessary and that sessions can be categorized automatically, without ground truth.
 Abstractly, we can accomplish this by using a clustering algorithm to group sessions with ``similar'' queries.
 However, for this we first need a good definition of what makes two queries similar.
 Query similarity has already received significant attention~\cite{aouiche2006,aligon2014similarity,makiyama2015text}.
@@ -65,12 +72,25 @@ A common approach is to describe queries in terms of features extracted from the
 Common features include the columns which are projected or what selection predicates are used.
 As our underlying approach is agnostic to how these features are extracted, we experiment with a variety of feature extraction techniques.
 
+% However, we do not rely on this correspondence being one-to-one (it may also be many-to-one or one-to-many).
+%As we will show, the resulting session categories and their component queries reliably model smartphone app workloads.
+
+
+
 Our final clustering approach adopts a feature extraction method proposed by Makiyama \textit{et al.}~\cite{makiyama2015text}, and addresses one further technical challenge.
 In principle each sub-sequence of queries could be described by the features of those queries.
 As we show, clustering directly on the query features is neither scalable nor reliable.
 Instead, we show the need for an intermediate step where we first cluster individual queries, allowing us to first link related queries.
 These cluster labels reduce noise, and serve as the basis for the session-similarity metric for clustering similar sessions together. 
 
+\tinysection{Target Applications}
+The resulting workload models are primarily targeted at database auto-tuning systems, allowing them to more reliably adapt to highly variable smartphone workloads.
+However, these models may also be used to help embedded database developers to better understand app requirements, app developers to better tune app performance, mobile phone OS designers to tune OS level services, and benchmark designers to generate synthetic workload traces.
+To ensure that the resulting models will be accurate, we validate our approach using recently collected traces of smartphone query activity in the wild~\cite{kennedy2015pocket}, and show that it is able to cluster queries into meaningful summaries of real world data.
+
+
+
+
 
 %We will model common behaviors and identify unusual patterns which can be used to realistically emulate synthetic workloads created by Android applications. 
 
@@ -98,10 +118,11 @@ These cluster labels reduce noise, and serve as the basis for the session-simila
 
 Concretely, in this paper we:
 \begin{enumerate*}
-\item identify the challenges posed by mobile app workloads for query log summarization,
-\item propose a two-level, activity-oriented summary format for mobile app workloads,
-\item design a process for creating session-oriented summaries from query logs,
-\item evaluate our summarization process, showing that it efficiently creates representative summaries.
+\item Identify the challenges posed by mobile app workloads for query log summarization,
+\item Propose a two-level, activity-oriented summary format for mobile app workloads,
+\item Propose and validate an automated segmentation process for extracting log sessions from query logs,
+\item Design and evaluate several schemes for labeling log sessions based on clustering.
+\item Evaluate our small-data workload model end-to-end, highlighting its predictive power and ability to generate representative models.
 \end{enumerate*}
 
 %An application of the core contribution of this work is the development of synthetic workload generator which could be used to create a benchmark.
@@ -113,4 +134,4 @@ We first present the related work in Section~\ref{sec:background} and define the
 Then, we give a detailed description of our session identification scheme in Section~\ref{sec:sessionidentifier} and our session clustering process in Section~\ref{sec:sessionclustering}.
 In Section~\ref{sec:experiments}, we introduce a sample dataset for workload characterization, and we evaluate our proposed techniques using this dataset.
 We discuss the experiment results and the limitations of our framework in Section~\ref{sec:discussion}.
-Finally, we conclude and identify the steps needed to deploy our methods into practice in Section~\ref{sec:conclusion}.
+Finally, we conclude and explore future work in Section~\ref{sec:conclusion}.