Importing 662 stuff

main.bib

@@ -1,13 +1,22 @@
 %% This BibTeX bibliography file was created using BibDesk.
 %% http://bibdesk.sourceforge.net/
 
-%% Created for Oliver Kennedy at 2016-01-17 23:38:39 -0500 
+%% Created for Oliver Kennedy at 2016-01-18 15:23:25 -0500 
 
 
 %% Saved with string encoding Unicode (UTF-8) 
 
 
 
+@misc{ramamurthy2015pocketdata,
+	Author = {Naveen Kumar Ramamurthy and Sankara Vadivel Dhandapani and Saravanan Adaikkalavan and Sathish Kumar Deivasigamani},
+	Date-Added = {2016-01-18 20:07:55 +0000},
+	Date-Modified = {2016-01-18 20:10:15 +0000},
+	Howpublished = {University at Buffalo CSE-662 Final Report},
+	Month = {Dec},
+	Title = {PocketData Benchmark (Team TBD)},
+	Year = {2015}}
+
 @article{Klonatos:2014:BEQ:2732951.2732959,
 	Acmid = {2732959},
 	Author = {Klonatos, Yannis and Koch, Christoph and Rompf, Tiark and Chafi, Hassan},

sections/1-1-metrics.tex

@@ -58,25 +58,25 @@ We noted above that a large proportion of \texttt{SELECT} queries were exact loo
   \begin{subfigure}[t]{0.33\textwidth}
     \includegraphics[width=\textwidth]{./graphs/activity/All_Devices__Top_10__All_Queries__ByAppPreviousQueryCDFGraph_noKey.pdf}
     \caption{}
-    \label{fig-app-interarrival}
+    \label{fig:app:interarrival}
   \end{subfigure}%
   \begin{subfigure}[t]{0.33\textwidth}
     \includegraphics[width=\textwidth]{./graphs/activity/All_Devices__Top_10__All_Queries__ByAppRuntimeCDFGraph_noKey.pdf}
     \caption{}
-    \label{fig-app-runtime}
+    \label{fig:app:runtime}
   \end{subfigure}%
   \begin{subfigure}[t]{0.33\textwidth}
     \includegraphics[width=\textwidth]{./graphs/activity/All_Devices__Top_10__All_Queries__ByAppRowcountCDFGraph_noKey.pdf}
     \caption{}
-    \label{fig-app-rowcount}
+    \label{fig:app:rowcount}
   \end{subfigure}%
   \caption{Per-App Summary Statistics for Android SQLite Queries. Distributions of (a) inter-query arrival times, (b) query runtimes, and (c) rows returned per query.}
-  \label{fig-app}
+  \label{fig:app}
 \end{figure*}
 
-Figure~\ref{fig-app} shows query interarrival times, runtimes, and returned row 
+Figure~\ref{fig:app} shows query interarrival times, runtimes, and returned row 
 counts for ten of the most active SQLite clients.  As seen in 
-Figure~\ref{fig-app-interarrival}, the 0.01Hz periodicity is not unique to any one
+Figure~\ref{fig:app:interarrival}, the 0.01Hz periodicity is not unique to any one
 application, further suggesting filesystem locking as a culprit.  Two of the most
 prolific SQLite clients, \textit{Google Play services} and \textit{Media Storage} 
 appear to be very bursty: 70\% of all statements for these applications are issued 
@@ -85,13 +85,13 @@ issued by the \textit{Android System} itself.  The interarrival time CDF appears
 to be almost precisely logarithmic for rates above 10$\mu$s, but has a notable lack 
 of interarrival times in the 1ms to 10ms range.  This could suggest caching 
 effects, with the cache expiring after 1ms.
-As seen in Figure~\ref{fig-app-runtime}, most apps hold to the average runtime of 
+As seen in Figure~\ref{fig:app:runtime}, most apps hold to the average runtime of 
 100$\mu$s, with several notable exceptions.   Over 50\% of the 
 \textit{Android System}'s statements take on the order of 1ms.  Just under 20\% of 
 \textit{Hangouts} statements take 10ms, suggesting an update-heavy workload.  Also, 
 \textit{Contacts Storage} has a heavier-duty workload, with 30\% of statements taking
 between 100$\mu$s and 1ms.  
-Figure~\ref{fig-app-rowcount} shows that the \textit{Android System} and 
+Figure~\ref{fig:app:rowcount} shows that the \textit{Android System} and 
 \textit{Media Storage} issue almost exclusively single-row lookup queries.  
 The remaining apps issue a large number of single-row queries --- Even 
 \textit{Contacts Storage} has a workload consisting of 45\% single-row reads --- 
@@ -101,6 +101,25 @@ at a time, suggesting that these views are backed directly by SQLite.  Although
 apps have long tails, two apps in particular: \textit{Gmail} and \textit{Google+} are
 notable for regularly issuing queries that return on the order of 100 rows.  
 
+\begin{figure*}
+\centering
+  \begin{subfigure}[t]{0.5\textwidth}
+    \includegraphics[width=\textwidth]{graphs/whatsapp-minified.pdf}
+    \caption{}
+  \end{subfigure}%
+  \begin{subfigure}[t]{0.5\textwidth}
+    \includegraphics[width=\textwidth]{graphs/facebook-minified.pdf}
+    \caption{}
+  \end{subfigure}%
+\caption{Variations in bursty data access patterns~\cite{ramamurthy2015pocketdata} for WatsApp (a) and Facebook (b).}
+\label{fig:burstiness}
+\end{figure*}
+
+Figure~\ref{fig:burstiness} shows variations in query burstiness across multiple apps and users\footnote{The PIs have already incorporated material from this proposal into their coursework.  Figure \ref{fig:burstiness} is from a student report~\cite{ramamurthy2015pocketdata} from UB's CSE-662, jointly instructed by PIs Kennedy and Ziarek.}.  
+Two features immediately emerge from this data.  
+First, \PocketData{} workloads are extremely bursty; The default steady state is completely idle, with infrequent bursts of hundreds of operations per second.  
+Second, the nature of these bursts varies significantly by the calling app; In this trace Facebook generates a read-only workload, while Watsapp produces two bursts each with a distinct mix of updates, inserts, deletes, and selects.
+
 \medskip
 
 We plan to freely releasing aggregate metrics about database usage patterns in

sections/1-description.tex

@@ -99,10 +99,10 @@ systems and query processing systems, in embedded deployments. The programming l
 community is exploring domain specific languages for specialized query processing.
 The mobile community is continually exploring how to push the envelope on smartphone based computing, 
 whether via power aware mechanisms, or through more adaptive systems.  Many of these solutions use mobile databases
-as their fundamental computation engine (e.g. the {\em Maybe} system developed at UB) or must
+as their fundamental computation engine (e.g. the `\texttt{maybe}' system developed at UB) or must
 consider the performance characteristics of database systems (e.g. power modeling).
 
-This proposal aims to create a community research around our \PocketData{} toolchain 
+This proposal aims to create a community research infrastructure around our \PocketData{} toolchain 
 to enable a myriad of research activities for above mentioned communities. Additionally,
 in this planning grant, we will explore the precise needs of these communities to ensure an
 infrastructure that has broad applicability.