- Making graphs more consistent/readable

- Complexity line graph formatting changed to be consistent with activity graphs - axis labels, grid, line color/width, box
  - Complexity bar graph formatting changed to be consistent with activity graphs - axis labels, box color
  - Per-app Activity graphs hard-edited to pull the key out and have one (far more readable) key for all three.
- A few minor flow tweaks
  - Added (obvious in retrospect) cite to LINQ
master
Oliver Kennedy 2015-06-20 16:02:39 -04:00
parent 98e2321806
commit 7edfd2fdd6
14 changed files with 343 additions and 293 deletions

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

418
main.bib
View File

@ -1,236 +1,254 @@
%% This BibTeX bibliography file was created using BibDesk.
%% http://bibdesk.sourceforge.net/
%% Created for Oliver Kennedy at 2015-06-20 15:03:07 -0400
%% Saved with string encoding Unicode (UTF-8)
@article{box2007linq,
Author = {Box, Don and Hejlsberg, Anders},
Date-Added = {2015-06-20 19:01:17 +0000},
Date-Modified = {2015-06-20 19:01:17 +0000},
Journal = {MSDN Developer Centre},
Title = {LinQ: .NET language-integrated query},
Volume = {89},
Year = {2007}}
@misc{nexus5,
author = {{Wikipedia}},
title = "{Nexus 5}",
howpublished =
{\texttt{http://en.wikipedia.org/wiki/Nexus\_5}}
}
Author = {{Wikipedia}},
Howpublished = {\texttt{http://en.wikipedia.org/wiki/Nexus\_5}},
Title = {{Nexus 5}}}
@misc{phones,
key = {One In Every 5 People In The World Own A Smartphone},
title = {{O}ne {I}n {E}very 5 {P}eople {I}n {T}he {W}orld {O}wn {A} {S}martphone},
howpublished = {\url{http://www.businessinsider.com/smartphone-and-tablet-penetration-2013-10}}
}
Howpublished = {\url{http://www.businessinsider.com/smartphone-and-tablet-penetration-2013-10}},
Key = {One In Every 5 People In The World Own A Smartphone},
Title = {{O}ne {I}n {E}very 5 {P}eople {I}n {T}he {W}orld {O}wn {A} {S}martphone}}
@inproceedings{Dit2015CIDR,
author = {Jens Dittrich},
title = {{The Case for Small Data Management}},
booktitle = {CIDR},
year = {2015},
}
Author = {Jens Dittrich},
Booktitle = {CIDR},
Title = {{The Case for Small Data Management}},
Year = {2015}}
@inproceedings{phonelab,
author = {Nandugudi, Anandatirtha and Maiti, Anudipa and Ki, Taeyeon and Bulut, Fatih and Demirbas, Murat and Kosar, Tevfik and Qiao, Chunming and Ko, Steven Y. and Challen, Geoffrey},
title = {PhoneLab: A Large Programmable Smartphone Testbed},
booktitle = {Proceedings of First International Workshop on Sensing and Big Data Mining},
series = {SENSEMINE'13},
year = {2013},
isbn = {978-1-4503-2430-4},
location = {Roma, Italy},
pages = {4:1--4:6},
articleno = {4},
numpages = {6},
url = {http://doi.acm.org/10.1145/2536714.2536718},
doi = {10.1145/2536714.2536718},
acmid = {2536718},
publisher = {ACM},
address = {New York, NY, USA},
keywords = {Smartphones, mobile devices, testbed},
}
Acmid = {2536718},
Address = {New York, NY, USA},
Articleno = {4},
Author = {Nandugudi, Anandatirtha and Maiti, Anudipa and Ki, Taeyeon and Bulut, Fatih and Demirbas, Murat and Kosar, Tevfik and Qiao, Chunming and Ko, Steven Y. and Challen, Geoffrey},
Booktitle = {Proceedings of First International Workshop on Sensing and Big Data Mining},
Doi = {10.1145/2536714.2536718},
Isbn = {978-1-4503-2430-4},
Keywords = {Smartphones, mobile devices, testbed},
Location = {Roma, Italy},
Numpages = {6},
Pages = {4:1--4:6},
Publisher = {ACM},
Series = {SENSEMINE'13},
Title = {PhoneLab: A Large Programmable Smartphone Testbed},
Url = {http://doi.acm.org/10.1145/2536714.2536718},
Year = {2013},
Bdsk-Url-1 = {http://doi.acm.org/10.1145/2536714.2536718},
Bdsk-Url-2 = {http://dx.doi.org/10.1145/2536714.2536718}}
@misc{tpch,
title={{TPC-H} specification},
author={Transaction Processing Performance Council},
howpublished={http://www.tpc.org/tpch/},
}
Author = {Transaction Processing Performance Council},
Howpublished = {http://www.tpc.org/tpch/},
Title = {{TPC-H} specification}}
@misc{tpcc,
title={{TPC-C} specification},
author={Transaction Processing Performance Council},
howpublished={http://www.tpc.org/tpcc/},
}
Author = {Transaction Processing Performance Council},
Howpublished = {http://www.tpc.org/tpcc/},
Title = {{TPC-C} specification}}
@misc{tpcds,
title={{TPC-DS} specification},
author={Transaction Processing Performance Council},
howpublished={http://www.tpc.org/tpcds/},
}
Author = {Transaction Processing Performance Council},
Howpublished = {http://www.tpc.org/tpcds/},
Title = {{TPC-DS} specification}}
@misc{o2007star,
title={The star schema benchmark (SSB)},
author={ONeil, Patrick E and ONeil, Elizabeth J and Chen, Xuedong},
year={2007}
}
Author = {O'Neil, Patrick E and O'Neil, Elizabeth J and Chen, Xuedong},
Title = {The star schema benchmark (SSB)},
Year = {2007}}
@incollection{ssb,
year={2009},
isbn={978-3-642-10423-7},
booktitle={Performance Evaluation and Benchmarking},
volume={5895},
series={Lecture Notes in Computer Science},
editor={Nambiar, Raghunath and Poess, Meikel},
doi={10.1007/978-3-642-10424-4_17},
title={The Star Schema Benchmark and Augmented Fact Table Indexing},
url={http://dx.doi.org/10.1007/978-3-642-10424-4_17},
publisher={Springer Berlin Heidelberg},
keywords={Benchmark; Star Schema; Data Warehousing; Clustering; Multi-Dimensional Clustering; DB2; Oracle; Vertica},
author={ONeil, Patrick and ONeil, Elizabeth and Chen, Xuedong and Revilak, Stephen},
pages={237-252},
language={English}
}
Author = {O'Neil, Patrick and O'Neil, Elizabeth and Chen, Xuedong and Revilak, Stephen},
Booktitle = {Performance Evaluation and Benchmarking},
Doi = {10.1007/978-3-642-10424-4_17},
Editor = {Nambiar, Raghunath and Poess, Meikel},
Isbn = {978-3-642-10423-7},
Keywords = {Benchmark; Star Schema; Data Warehousing; Clustering; Multi-Dimensional Clustering; DB2; Oracle; Vertica},
Language = {English},
Pages = {237-252},
Publisher = {Springer Berlin Heidelberg},
Series = {Lecture Notes in Computer Science},
Title = {The Star Schema Benchmark and Augmented Fact Table Indexing},
Url = {http://dx.doi.org/10.1007/978-3-642-10424-4_17},
Volume = {5895},
Year = {2009},
Bdsk-Url-1 = {http://dx.doi.org/10.1007/978-3-642-10424-4_17}}
@book{sqlite,
title={SQLite},
author={Owens, Mike and Allen, Grant},
year={2010},
publisher={Springer}
}
Author = {Owens, Mike and Allen, Grant},
Publisher = {Springer},
Title = {SQLite},
Year = {2010}}
@inproceedings{kang2013xftl,
author = {Kang, Woon-Hak and Lee, Sang-Won and Moon, Bongki and Oh, Gi-Hwan and Min, Changwoo},
title = {X-FTL: Transactional FTL for SQLite Databases},
booktitle = {Proceedings of the 2013 ACM SIGMOD International Conference on Management of Data},
series = {SIGMOD '13},
year = {2013},
isbn = {978-1-4503-2037-5},
location = {New York, New York, USA},
pages = {97--108},
numpages = {12},
url = {http://doi.acm.org/10.1145/2463676.2465326},
doi = {10.1145/2463676.2465326},
acmid = {2465326},
publisher = {ACM},
address = {New York, NY, USA},
keywords = {copy-on-write, flash storage devices, flash translation layer, sqlite, transactional atomicity},
}
Acmid = {2465326},
Address = {New York, NY, USA},
Author = {Kang, Woon-Hak and Lee, Sang-Won and Moon, Bongki and Oh, Gi-Hwan and Min, Changwoo},
Booktitle = {Proceedings of the 2013 ACM SIGMOD International Conference on Management of Data},
Doi = {10.1145/2463676.2465326},
Isbn = {978-1-4503-2037-5},
Keywords = {copy-on-write, flash storage devices, flash translation layer, sqlite, transactional atomicity},
Location = {New York, New York, USA},
Numpages = {12},
Pages = {97--108},
Publisher = {ACM},
Series = {SIGMOD '13},
Title = {X-FTL: Transactional FTL for SQLite Databases},
Url = {http://doi.acm.org/10.1145/2463676.2465326},
Year = {2013},
Bdsk-Url-1 = {http://doi.acm.org/10.1145/2463676.2465326},
Bdsk-Url-2 = {http://dx.doi.org/10.1145/2463676.2465326}}
@inproceedings{jeong2013iostack,
author = {Jeong, Sooman and Lee, Kisung and Lee, Seongjin and Son, Seoungbum and Won, Youjip},
title = {I/O Stack Optimization for Smartphones},
booktitle = {Proceedings of the 2013 USENIX Conference on Annual Technical Conference},
series = {USENIX ATC'13},
year = {2013},
location = {San Jose, CA},
pages = {309--320},
numpages = {12},
url = {http://dl.acm.org/citation.cfm?id=2535461.2535499},
acmid = {2535499},
publisher = {USENIX Association},
address = {Berkeley, CA, USA},
}
Acmid = {2535499},
Address = {Berkeley, CA, USA},
Author = {Jeong, Sooman and Lee, Kisung and Lee, Seongjin and Son, Seoungbum and Won, Youjip},
Booktitle = {Proceedings of the 2013 USENIX Conference on Annual Technical Conference},
Location = {San Jose, CA},
Numpages = {12},
Pages = {309--320},
Publisher = {USENIX Association},
Series = {USENIX ATC'13},
Title = {I/O Stack Optimization for Smartphones},
Url = {http://dl.acm.org/citation.cfm?id=2535461.2535499},
Year = {2013},
Bdsk-Url-1 = {http://dl.acm.org/citation.cfm?id=2535461.2535499}}
@incollection{kim2012androbench,
year={2012},
isbn={978-3-642-27551-7},
booktitle={Frontiers in Computer Education},
volume={133},
series={Advances in Intelligent and Soft Computing},
editor={Sambath, Sabo and Zhu, Egui},
doi={10.1007/978-3-642-27552-4_89},
title={AndroBench: Benchmarking the Storage Performance of Android-Based Mobile Devices},
url={http://dx.doi.org/10.1007/978-3-642-27552-4_89},
publisher={Springer Berlin Heidelberg},
keywords={AndroBench; Android; Storage performance; Benchmark},
author={Kim, Je-Min and Kim, Jin-Soo},
pages={667-674},
language={English}
}
Author = {Kim, Je-Min and Kim, Jin-Soo},
Booktitle = {Frontiers in Computer Education},
Doi = {10.1007/978-3-642-27552-4_89},
Editor = {Sambath, Sabo and Zhu, Egui},
Isbn = {978-3-642-27551-7},
Keywords = {AndroBench; Android; Storage performance; Benchmark},
Language = {English},
Pages = {667-674},
Publisher = {Springer Berlin Heidelberg},
Series = {Advances in Intelligent and Soft Computing},
Title = {AndroBench: Benchmarking the Storage Performance of Android-Based Mobile Devices},
Url = {http://dx.doi.org/10.1007/978-3-642-27552-4_89},
Volume = {133},
Year = {2012},
Bdsk-Url-1 = {http://dx.doi.org/10.1007/978-3-642-27552-4_89}}
@misc{ahmed2009mobigen,
title={MobiGen: a mobility generator for environment aware mobility model},
howpublished={http://arrow.monash.edu.au/hdl/1959.1/109933},
author={Ahmed, Sabbir},
year={2009}
}
Author = {Ahmed, Sabbir},
Howpublished = {http://arrow.monash.edu.au/hdl/1959.1/109933},
Title = {MobiGen: a mobility generator for environment aware mobility model},
Year = {2009}}
@article{madden2005tinydb,
author = {Madden, Samuel R. and Franklin, Michael J. and Hellerstein, Joseph M. and Hong, Wei},
title = {TinyDB: An Acquisitional Query Processing System for Sensor Networks},
journal = {ACM Trans. Database Syst.},
issue_date = {March 2005},
volume = {30},
number = {1},
month = mar,
year = {2005},
issn = {0362-5915},
pages = {122--173},
numpages = {52},
url = {http://doi.acm.org/10.1145/1061318.1061322},
doi = {10.1145/1061318.1061322},
acmid = {1061322},
publisher = {ACM},
address = {New York, NY, USA},
keywords = {Query processing, data acquisition, sensor networks},
}
Acmid = {1061322},
Address = {New York, NY, USA},
Author = {Madden, Samuel R. and Franklin, Michael J. and Hellerstein, Joseph M. and Hong, Wei},
Doi = {10.1145/1061318.1061322},
Issn = {0362-5915},
Issue_Date = {March 2005},
Journal = {ACM Trans. Database Syst.},
Keywords = {Query processing, data acquisition, sensor networks},
Month = mar,
Number = {1},
Numpages = {52},
Pages = {122--173},
Publisher = {ACM},
Title = {TinyDB: An Acquisitional Query Processing System for Sensor Networks},
Url = {http://doi.acm.org/10.1145/1061318.1061322},
Volume = {30},
Year = {2005},
Bdsk-Url-1 = {http://doi.acm.org/10.1145/1061318.1061322},
Bdsk-Url-2 = {http://dx.doi.org/10.1145/1061318.1061322}}
@inproceedings{ycsb,
author = {Cooper, Brian F. and Silberstein, Adam and Tam, Erwin and Ramakrishnan, Raghu and Sears, Russell},
title = {Benchmarking Cloud Serving Systems with YCSB},
booktitle = {Proceedings of the 1st ACM Symposium on Cloud Computing},
series = {SoCC '10},
year = {2010},
isbn = {978-1-4503-0036-0},
location = {Indianapolis, Indiana, USA},
pages = {143--154},
numpages = {12},
url = {http://doi.acm.org/10.1145/1807128.1807152},
doi = {10.1145/1807128.1807152},
acmid = {1807152},
publisher = {ACM},
address = {New York, NY, USA},
keywords = {benchmarking, cloud serving database},
}
Acmid = {1807152},
Address = {New York, NY, USA},
Author = {Cooper, Brian F. and Silberstein, Adam and Tam, Erwin and Ramakrishnan, Raghu and Sears, Russell},
Booktitle = {Proceedings of the 1st ACM Symposium on Cloud Computing},
Doi = {10.1145/1807128.1807152},
Isbn = {978-1-4503-0036-0},
Keywords = {benchmarking, cloud serving database},
Location = {Indianapolis, Indiana, USA},
Numpages = {12},
Pages = {143--154},
Publisher = {ACM},
Series = {SoCC '10},
Title = {Benchmarking Cloud Serving Systems with YCSB},
Url = {http://doi.acm.org/10.1145/1807128.1807152},
Year = {2010},
Bdsk-Url-1 = {http://doi.acm.org/10.1145/1807128.1807152},
Bdsk-Url-2 = {http://dx.doi.org/10.1145/1807128.1807152}}
@INPROCEEDINGS{lam2009healthmonitoring,
author={Lam, S.C.K. and Kai Lap Wong and Kwok On Wong and Wenxiu Wong and Wai Ho Mow},
booktitle={Information, Communications and Signal Processing, 2009. ICICS 2009. 7th International Conference on},
title={A smartphone-centric platform for personal health monitoring using wireless wearable biosensors},
year={2009},
month={Dec},
pages={1-7},
keywords={biosensors;body area networks;health care;patient monitoring;personal area networks;plethysmography;wireless sensor networks;battery life;biosignal processing;body area sensor network;closed loop control capability;healthcare;personal health monitoring;photoplethysmographic biosensors;portability;smartphone centric platform;upgradability;wireless wearable biosensors;Aging;Application software;Biomedical monitoring;Biosensors;Costs;Medical services;Operating systems;Smart phones;Wearable sensors;Wireless sensor networks;COTS wearable biosensors;Health monitoring;body area sensor network;pervasive computing},
doi={10.1109/ICICS.2009.5397628},}
@inproceedings{lam2009healthmonitoring,
Author = {Lam, S.C.K. and Kai Lap Wong and Kwok On Wong and Wenxiu Wong and Wai Ho Mow},
Booktitle = {Information, Communications and Signal Processing, 2009. ICICS 2009. 7th International Conference on},
Doi = {10.1109/ICICS.2009.5397628},
Keywords = {biosensors;body area networks;health care;patient monitoring;personal area networks;plethysmography;wireless sensor networks;battery life;biosignal processing;body area sensor network;closed loop control capability;healthcare;personal health monitoring;photoplethysmographic biosensors;portability;smartphone centric platform;upgradability;wireless wearable biosensors;Aging;Application software;Biomedical monitoring;Biosensors;Costs;Medical services;Operating systems;Smart phones;Wearable sensors;Wireless sensor networks;COTS wearable biosensors;Health monitoring;body area sensor network;pervasive computing},
Month = {Dec},
Pages = {1-7},
Title = {A smartphone-centric platform for personal health monitoring using wireless wearable biosensors},
Year = {2009},
Bdsk-Url-1 = {http://dx.doi.org/10.1109/ICICS.2009.5397628}}
@inproceedings{klasnja2009using,
title={Using mobile \& personal sensing technologies to support health behavior change in everyday life: lessons learned},
author={Klasnja, Predrag and Consolvo, Sunny and McDonald, David W and Landay, James A and Pratt, Wanda},
booktitle={AMIA Annual Symposium Proceedings},
volume={2009},
pages={338},
year={2009},
organization={American Medical Informatics Association}
}
Author = {Klasnja, Predrag and Consolvo, Sunny and McDonald, David W and Landay, James A and Pratt, Wanda},
Booktitle = {AMIA Annual Symposium Proceedings},
Organization = {American Medical Informatics Association},
Pages = {338},
Title = {Using mobile \& personal sensing technologies to support health behavior change in everyday life: lessons learned},
Volume = {2009},
Year = {2009}}
@ARTICLE{campbell2008peoplesensing,
author={Campbell, A.T. and Eisenman, S.B. and Lane, N.D. and Miluzzo, E. and Peterson, R.A. and Hong Lu and Xiao Zheng and Musolesi, M. and Fodor, K. and Gahng-Seop Ahn},
journal={Internet Computing, IEEE},
title={The Rise of People-Centric Sensing},
year={2008},
month={July},
volume={12},
number={4},
pages={12-21},
keywords={social aspects of automation;ubiquitous computing;global mobile sensing device;mesh sensor networks;mobile devices;near-ubiquitous mobile phone;people-centric sensing;social sensing;Educational institutions;Humans;Mobile communication;Mobile computing;Mobile handsets;Monitoring;Portable media players;Prototypes;Visualization;Wireless sensor networks;Wi-Fi;mesh networking;people-centric sensing},
doi={10.1109/MIC.2008.90},
ISSN={1089-7801},}
@article{campbell2008peoplesensing,
Author = {Campbell, A.T. and Eisenman, S.B. and Lane, N.D. and Miluzzo, E. and Peterson, R.A. and Hong Lu and Xiao Zheng and Musolesi, M. and Fodor, K. and Gahng-Seop Ahn},
Doi = {10.1109/MIC.2008.90},
Issn = {1089-7801},
Journal = {Internet Computing, IEEE},
Keywords = {social aspects of automation;ubiquitous computing;global mobile sensing device;mesh sensor networks;mobile devices;near-ubiquitous mobile phone;people-centric sensing;social sensing;Educational institutions;Humans;Mobile communication;Mobile computing;Mobile handsets;Monitoring;Portable media players;Prototypes;Visualization;Wireless sensor networks;Wi-Fi;mesh networking;people-centric sensing},
Month = {July},
Number = {4},
Pages = {12-21},
Title = {The Rise of People-Centric Sensing},
Volume = {12},
Year = {2008},
Bdsk-Url-1 = {http://dx.doi.org/10.1109/MIC.2008.90}}
@inproceedings{cheung2013statusquo,
title={StatusQuo: Making Familiar Abstractions Perform Using Program Analysis.},
author={Cheung, Alvin and Arden, Owen and Madden, Samuel and Solar-Lezama, Armando and Myers, Andrew C},
booktitle={CIDR},
year={2013}
}
Author = {Cheung, Alvin and Arden, Owen and Madden, Samuel and Solar-Lezama, Armando and Myers, Andrew C},
Booktitle = {CIDR},
Title = {StatusQuo: Making Familiar Abstractions Perform Using Program Analysis.},
Year = {2013}}
@inproceedings{wimmer2012truffle,
author = {Wimmer, Christian and W\"{u}rthinger, Thomas},
title = {Truffle: A Self-optimizing Runtime System},
booktitle = {Proceedings of the 3rd Annual Conference on Systems, Programming, and Applications: Software for Humanity},
series = {SPLASH '12},
year = {2012},
isbn = {978-1-4503-1563-0},
location = {Tucson, Arizona, USA},
pages = {13--14},
numpages = {2},
url = {http://doi.acm.org/10.1145/2384716.2384723},
doi = {10.1145/2384716.2384723},
acmid = {2384723},
publisher = {ACM},
address = {New York, NY, USA},
keywords = {dynamic languages, graal, j, java, javascript, language implementation, truffle, virtual machine},
}
Acmid = {2384723},
Address = {New York, NY, USA},
Author = {Wimmer, Christian and W\"{u}rthinger, Thomas},
Booktitle = {Proceedings of the 3rd Annual Conference on Systems, Programming, and Applications: Software for Humanity},
Doi = {10.1145/2384716.2384723},
Isbn = {978-1-4503-1563-0},
Keywords = {dynamic languages, graal, j, java, javascript, language implementation, truffle, virtual machine},
Location = {Tucson, Arizona, USA},
Numpages = {2},
Pages = {13--14},
Publisher = {ACM},
Series = {SPLASH '12},
Title = {Truffle: A Self-optimizing Runtime System},
Url = {http://doi.acm.org/10.1145/2384716.2384723},
Year = {2012},
Bdsk-Url-1 = {http://doi.acm.org/10.1145/2384716.2384723},
Bdsk-Url-2 = {http://dx.doi.org/10.1145/2384716.2384723}}

View File

@ -52,7 +52,7 @@ Website: \texttt{http://odin.cse.buffalo.edu/research/}
\label{sec:queryc}
\input{sections/4-queryc}
\section{Database Activity}
\section{Runtime Characteristics}
\label{sec:dba}
\input{sections/5-dba}

View File

@ -1,63 +1,72 @@
\begin{figure}
\centering
\input{tables/query_breakdown}
\caption{Types and numbers of SQL statements executed during the trace, and query features used in each.}
\caption{\textbf{Types and numbers of SQL statements executed during the trace, and query features used in each.}}
\label{fig:breakdownByCatAndFeature}
\end{figure}
In this section we discuss the query complexity we observed during our study and illustrate typical workloads over pocket data.
Figure~\ref{fig:breakdownByCatAndFeature} summarizes all 45 million statements executed by SQLite over the 1 month period. As might be expected, \texttt{SELECT} forms almost three quarters of the workload by volume. \texttt{UPSERT} statements (\textit{i.e.}, \texttt{INSERT OR REPLACE}) form a similarly substantial 16\% of the workload --- more than simple \texttt{INSERT} and \texttt{UPDATE} statements combined. Also of note is a surprising level of complexity in \texttt{DELETE} statements, many of which rely on nested sub-queries when determining which records to delete.
\begin{figure}
\centering
\begin{tabular}{ccc}
\begin{tabular}{c|c}
\textbf{Client App} & \textbf{Statements Executed} \\ \hline
Google Play services & 14,813,949 \\
Media Storage & 13,592,982 \\
Gmail & 2,259,907 \\
Google+ & 2,040,793 \\
Facebook & 1,272,779 \\
Hangouts & 974,349 \\
Messenger & 676,993 \\
Calendar Storage & 530,535\\
User Dictionary & 252,650 \\
Android System & 237,154\\
\end{tabular}
& &
\begin{tabular}{c|c}
\textbf{Client App} & \textbf{Statements Executed} \\ \hline
Weather & 12 \\
Speedtest & 11 \\
KakaoStory & 8 \\
MX Player Pro & 4 \\
Quickoffice & 4\\
VLC & 4\\
Barcode Scanner & 2\\
Office Mobile & 2\\
PlayerPro & 2\\
KBS kong & 2 \\
\end{tabular}
\\
(a) & (b)
\end{tabular}
\caption{Apps that executed the (a) 10 most and (b) 10 fewest number of SQL statements.}
\begin{figure*}
\begin{subfigure}[t]{0.5\textwidth}
\centering
\begin{tabular}{c|c}
\textbf{Client App} & \textbf{Statements Executed} \\ \hline
Google Play services & 14,813,949 \\
Media Storage & 13,592,982 \\
Gmail & 2,259,907 \\
Google+ & 2,040,793 \\
Facebook & 1,272,779 \\
Hangouts & 974,349 \\
Messenger & 676,993 \\
Calendar Storage & 530,535\\
User Dictionary & 252,650 \\
Android System & 237,154\\
\end{tabular}
\caption{}
\label{fig:topBottom10Apps:top}
\end{subfigure}%
\begin{subfigure}[t]{0.5\textwidth}
\centering
\begin{tabular}{c|c}
\textbf{Client App} & \textbf{Statements Executed} \\ \hline
Weather & 12 \\
Speedtest & 11 \\
KakaoStory & 8 \\
MX Player Pro & 4 \\
Quickoffice & 4\\
VLC & 4\\
Barcode Scanner & 2\\
Office Mobile & 2\\
PlayerPro & 2\\
KBS kong & 2 \\
\end{tabular}
\caption{}
\label{fig:topBottom10Apps:bottom}
\end{subfigure}%
\caption{\textbf{Apps that executed the (a) 10 most and (b) 10 fewest SQL statements.}}
\label{fig:topBottom10Apps}
\end{figure}
\end{figure*}
Figure~\ref{fig:topBottom10Apps} shows the 10 most frequent and 10 least frequent clients of SQLite over the one month trace. The most active SQLite clients include internal android services that broker access to data shared between apps such as personal media, calendars and address books, as well as pre-installed and popular social media apps. There is less of a pattern at the low end, although several infrequent SQLite clients are themselves apps that may be used only infrequently, especially on a phone-sized device. We suspect that the distribution of apps would differ significantly for a tablet-sized device.
\subsection{Database Reads}
\begin{figure}
\begin{figure*}
\centering
\begin{tabular}{c c}
\includegraphics[width=0.49\textwidth]{graphs/select_breakdown_by_width}\ &
\ \includegraphics[width=0.49\textwidth]{graphs/select_breakdown_by_nesting}\\
(a) & (b) \\
\end{tabular}
\caption{\texttt{SELECT} queries grouped by (a) number of tables accessed and (b) maximum nesting depth.}
\begin{subfigure}[t]{0.5\textwidth}
\includegraphics[width=\textwidth]{graphs/select_breakdown_by_width}
\caption{}
\label{fig:coarseSelectComplexity:byWidth}
\end{subfigure}%
\begin{subfigure}[t]{0.5\textwidth}
\includegraphics[width=\textwidth]{graphs/select_breakdown_by_nesting}
\caption{}
\label{fig:coarseSelectComplexity:byNesting}
\end{subfigure}%
\caption{\textbf{\texttt{SELECT} queries by (a) number of tables accessed and (b) maximum nesting depth.}}
\label{fig:coarseSelectComplexity}
\end{figure}
\end{figure*}
Of the 45 million queries analyzed, 33.47 million were read-only SELECT queries.
Figure~\ref{fig:coarseSelectComplexity} shows the distribution of \texttt{SELECT} queries by number of tables accessed by the query, as well as the maximum level of query nesting. Nesting includes from-nesting (\textit{e.g.}, \texttt{SELECT \ldots\ FROM (SELECT \ldots)}), as well as expression-nesting (\textit{e.g.}, \texttt{SELECT \ldots\ WHERE EXISTS (SELECT \ldots)}).
@ -73,7 +82,7 @@ Conversely, the workload also has a tail that consists of complex, TPC-H-like~\c
\begin{figure}
\centering
\input{tables/spjsort_by_width_and_where}
\caption{Number of simple look-up queries subdivided by join width (number of tables) and number of conjunctive terms in the \texttt{WHERE} clause.}
\caption{\textbf{Number of simple look-up queries subdivided by join width (number of tables) and number of conjunctive terms in the \texttt{WHERE} clause.}}
\label{fig:spjsByWidthAndWhere}
\end{figure}
@ -82,38 +91,46 @@ Figure~\ref{fig:spjsByWidthAndWhere} shows queries of this class, broken down by
\texttt{SELECT R.A FROM R, S WHERE R.B = S.B AND S.C = 10}
This query would have a join width of 2 (\texttt{R}, \texttt{S}) and 2 conjunctive terms (\texttt{R.B = S.B} and \texttt{S.C = 10}). For uniformity, \texttt{NATURAL JOIN} and \texttt{JOIN ON} (\textit{e.g.}, \texttt{SELECT R.A from R JOIN S ON B}) expressions appearing in the \texttt{FROM} clause are rewritten into equivalent expressions in the \texttt{WHERE} clause.
The first column of this table indicates queries to a single relation. Just over 1 million queries were full table scans (0 where clauses), and just under 27 million queries involved only a single conjunctive term. This latter class constitutes the bulk of the simple query workload, at just over 87 percent of the simple look-up queries. Single-clause queries appear to be the norm. Recall that an N-way equi-join requires N-1 conjunctive terms; Spikes occur in the number of queries with one more term than strictly required to perform a join, suggesting a constraint on at least one relation.
\begin{figure}
\centering
{\small
\input{tables/sp_trivial_condition_breakdown}
\caption{The \texttt{WHERE} clause structure for single-tabled simple lookup queries with a single conjunctive term in the \texttt{WHERE} clause.}
}
\caption{\textbf{The \texttt{WHERE} clause structure for single-tabled simple lookup queries with a single conjunctive term in the \texttt{WHERE} clause.}}
\label{fig:singleClauseExpressions}
\end{figure}
The first column of this table indicates queries to a single relation. Just over 1 million queries were full table scans (0 where clauses), and just under 27 million queries involved only a single conjunctive term. This latter class constitutes the bulk of the simple query workload, at just over 87 percent of the simple look-up queries. Single-clause queries appear to be the norm. Recall that an N-way equi-join requires N-1 conjunctive terms; Spikes occur in the number of queries with one more term than strictly required to perform a join, suggesting a constraint on at least one relation.
Narrowing further, we examine simple look-up queries referencing only a single source table and a single conjunctive term in the WHERE clause. Figure~\ref{fig:singleClauseExpressions} summarizes the structure of the predicate that appears in each of these queries. In this figure, constant terms (Const) are any primitive value term (\textit{e.g.}, a quoted string, an integer, or a float), or any JDBC-style parameter ($?$). For simple relational comparators, we group together \textit{in}equalities (\textit{i.e.}, $<$, $\leq$, $>$, $\geq$ and $\neq$) under the symbol $\theta$, and explicitly list equalities. Other relational operators such as \texttt{LIKE}, \texttt{BETWEEN}, and \texttt{IN} are also seen with some frequency. However, the majority of look-ups (85\% of all simple look-ups) are exact match look-ups.
Not surprisingly, this suggests that the most common use-case for SQLite is as a relational key-value store. As we show shortly through a per-app analysis of the data (Section~\ref{sec:select:perapp}), 24 out of the 179 apps that we encountered posed no queries other than exact look-ups and full table scans.
\subsubsection{Other \texttt{SELECT} Queries}
\begin{figure}
\centering
\input{tables/select_condition_breakdown}
\caption{WHERE clause expression structures, and the number of SELECT queries in which the structure appears as a conjunctive clause.}
\label{fig:allSelectConditionBreakdown}
\end{figure}
Figure~\ref{fig:allSelectConditionBreakdown} shows a similar breakdown for all 33.5 million \texttt{SELECT} queries seen. As before, the table shows the form of all expressions that appear as one of the conjunctive terms of a \texttt{WHERE} clause, alongside the number of queries where the expression appears. 31.0 million of these queries contain an exact lookup.
1.6 million queries contain at least one multi-attribute equality expression such as an equijoin constraint, lining up nicely with the 1.7 million queries that reference at least two tables.
\begin{figure}
\centering
{\small
\input{tables/select_condition_breakdown}
}
\caption{\textbf{WHERE clause expression structures, and the number of SELECT queries in which the structure appears as a conjunctive clause.}}
\label{fig:allSelectConditionBreakdown}
\end{figure}
App developers make frequent use of SQLite's dynamic typing: Where clauses include bare column references (\textit{e.g.}, \texttt{WHERE A}, implicitly equivalent to \texttt{WHERE A <> 0}) as well as bare bit-wise AND expressions (\textit{e.g.}, \texttt{A\&0xc4}). This latter predicate appearing in a half-million queries indicates extensive use of bit-arrays packed into integers.
\subsubsection{Functions}
\begin{figure}
\centering
{\small
\input{tables/select_functions}
\caption{Functions appearing in SELECT queries, sorted by number of times the function is used.}
}
\caption{\textbf{Functions appearing in SELECT queries by number of times the function is used.}}
\label{fig:selectFunctions}
\end{figure}
@ -126,22 +143,27 @@ The most commonly used function was \texttt{GROUP\_CONCAT}, an aggregate operato
\subsubsection{Per-Application Analysis}
\label{sec:select:perapp}
\begin{figure}
\begin{figure*}
\centering
\begin{tabular}{cc}
\includegraphics[width=0.49\textwidth]{graphs/select_count_cdf_by_app} &
\includegraphics[width=0.49\textwidth]{graphs/select_percent_simple_cdf_by_app} \\
(a) & (b)
\end{tabular}
\caption{Breakdown of \texttt{SELECT} queries by app. (a) Cumulative distribution of applications by the number of \texttt{SELECT} queries issued (note the logarithmic scale). (b) Cumulative distribution of applications by the percent of the app's \texttt{SELECT} queries that are full table scans or exact look-ups.}
\begin{subfigure}[t]{0.5\textwidth}
\includegraphics[width=\textwidth]{graphs/select_count_cdf_by_app}
\caption{}
\label{fig:selectByApp:all}
\end{subfigure}%
\begin{subfigure}[t]{0.5\textwidth}
\includegraphics[width=\textwidth]{graphs/select_percent_simple_cdf_by_app}
\caption{}
\label{fig:selectByApp:simple}
\end{subfigure}%
\caption{\textbf{Breakdown of \texttt{SELECT} queries by app. (a) Cumulative distribution of applications by the number of \texttt{SELECT} queries issued (note the logarithmic scale). (b) Cumulative distribution of applications by the percent of the app's \texttt{SELECT} queries that are full table scans or exact look-ups.}}
\label{fig:selectByApp}
\end{figure}
\end{figure*}
We next break the \texttt{SELECT} workload down by the calling application (app).
Due to limitations of the logging infrastructure, 4.32 million queries (just over 12.9\% of the workload) could not be associated with a specific application, and our app-specific analysis excludes these queries.
Additionally, system services in Android are often implemented as independent apps and counted as such in the numbers presented.
Over the course of the one-month trace we observed 179 distinct apps,, varying from built-in android applications such as \textit{Gmail} or \textit{YouTube} to video players such as \textit{VLC} to games such as \textit{3 Kingdoms}. Figure~\ref{fig:selectByApp}.a shows the cumulative distribution of apps sorted by the number of queries that the app performs. The results are highly skewed, with the top 10\% of apps each posing more than 100 thousand queries over the one month trace, or an average of about 1 query every 4 minutes on any given phone. The most query-intensive system service, \textit{Media Storage} was responsible for 13.57 million queries or just shy of 40 queries per minute per phone. The most query-intensive user-facing app was \textit{Google+}, which performed 1.94 million queries over the course of the month or 5 queries per minute.
Over the course of the one-month trace we observed 179 distinct apps,, varying from built-in android applications such as \textit{Gmail} or \textit{YouTube} to video players such as \textit{VLC} to games such as \textit{3 Kingdoms}. Figure~\ref{fig:selectByApp:all} shows the cumulative distribution of apps sorted by the number of queries that the app performs. The results are highly skewed, with the top 10\% of apps each posing more than 100 thousand queries over the one month trace, or an average of about 1 query every 4 minutes on any given phone. The most query-intensive system service, \textit{Media Storage} was responsible for 13.57 million queries or just shy of 40 queries per minute per phone. The most query-intensive user-facing app was \textit{Google+}, which performed 1.94 million queries over the course of the month or 5 queries per minute.
At the other end of the spectrum, the bottom 10\% of apps posed as few as 30 queries over the entire month.
@ -150,10 +172,10 @@ We noted above that a large proportion of \texttt{SELECT} queries were exact loo
INSERT OR REPLACE INTO properties(property_key,property_value) VALUES (?,?);
SELECT property_value FROM properties WHERE property_key=?;
\end{verbatim}
Note that \texttt{?} is a prepared statement parameter, which acts as a placeholder for values that are bound when the prepared statement is evaluated.
In this query, \texttt{?} is a prepared statement parameter that acts as a placeholder for values that are bound when the prepared statement is evaluated.
To broaden the scope of our search for key/value queries, we define a key-value look-up query as a \texttt{SELECT} query over a single relation that either performs a full table scan, or performs an exact look-up on a single attribute.
Figure~\ref{fig:selectByApp}.b shows the cumulative distribution of apps sorted by the percent of its queries that are key-value lookup queries. For 24 apps (13.4\%), we observed only key-value queries during the entire, month-long trace.
Figure~\ref{fig:selectByApp:simple} shows the cumulative distribution of apps sorted by the percent of its queries that are key-value lookup queries. For 24 apps (13.4\%), we observed only key-value queries during the entire, month-long trace.
% Adobe Reader, Barcode Scanner, BuzzFeed, Candy Crush Saga, Discover, Evernote, Foursquare, GPS Status, Google Play Newsstand, Google Sky Map, KBS kong, LTE Discovery, MX Player Pro, Muzei, My Tracks, Office Mobile, PayPal, Quickoffice, SignalCheck Lite, Titanium Backup, TuneIn Radio Pro, VLC, Weather, Wifi Analyzer
@ -167,14 +189,16 @@ Write statements, \texttt{INSERT}, \texttt{INSERT OR REPLACE} (here abbreviated
\begin{figure}
\centering
{\small
\input{tables/delete_condition_breakdown}
\caption{\texttt{WHERE} clause expression structures, and the number of \texttt{DELETE} statements in which the structure appears.}
}
\caption{\textbf{\texttt{WHERE} clause expression structures, and the number of \texttt{DELETE} statements in which the structure appears.}}
\label{fig:allDeleteConditionBreakdown}
\end{figure}
The trace includes 1.25 million \texttt{DELETE} statements. This was by far the most expensive class of statement, with an average \texttt{DELETE} taking just under 4 ms to complete. A significant portion of this cost is attributable to the use of \texttt{DELETE} as a form of bulk erasure. 323 thousand \texttt{DELETE}s have no exact match condition in their WHERE clause, while 528 thousand do include a range predicate.
\texttt{DELETE} predicates can become quite complex; 46,122 \texttt{DELETE}s (just under 3.7 percent) use nested \texttt{SELECT} queries, and touch as many as 7 separate tables (in 616 cases).
This suggests extensive use of \texttt{DELETE} as a form of garbage-collection or cache invalidation, where SQL is used to express the corresponding deletion policy.
This suggests extensive use of \texttt{DELETE} as a form of garbage-collection or cache invalidation, where the invalidation policy is expressed through SQL.
%\ask{Suggestion is one thing... how might we validate the claim that DELETE is used for cache invalidation?}
@ -182,8 +206,10 @@ This suggests extensive use of \texttt{DELETE} as a form of garbage-collection o
\begin{figure}
\centering
{\small
\input{tables/update_condition_breakdown}
\caption{\texttt{WHERE} clause expression structures, and the number of \texttt{UPDATE} statements in which the structure appears.}
}
\caption{\textbf{\texttt{WHERE} clause expression structures, and the number of \texttt{UPDATE} statements in which the structure appears.}}
\label{fig:allUpdateConditionBreakdown}
\end{figure}
@ -195,7 +221,7 @@ Although the \texttt{WHERE} clause of the updates included a variety of expressi
\begin{verbatim}
UPDATE ScheduledTaskProto SET value=?,key=?,sortingValue=? WHERE key = ?;
\end{verbatim}
Not a single \texttt{UPDATE} expression attempted to compute new values in the SQL space, suggesting a strong preference for doing so in the application itself. This is not entirely unexpected, as the database lives in the address space of the application, minimizing the round-trip latency of first performing a \texttt{SELECT} to read values out of the database, followed by an \texttt{UPDATE} to write out the changes. However, it also hints that database objects might be getting cached at the application layer unnecessarily, and that language primitives that couple imperative programming languages with declarative query languages (e.g., StatusQuo~\cite{cheung2013statusquo} or Truffle~\cite{wimmer2012truffle}) could provide a significant benefit to mobile developers.
Not a single \texttt{UPDATE} expression attempted to compute new values in the SQL space, suggesting a strong preference for doing so in the application itself. This is not entirely unexpected, as the database lives in the address space of the application. Consequently, it is feasible to first perform a \texttt{SELECT} to read values out of the database and then perform an \texttt{UPDATE} to write out the changes, a tactic used by many ORMs. An unfortunate consequence of this tactic is that ORMs cache database objects at the application layer unnecessarily, suggesting that a stronger coupling between SQL and Java (e.g. language primitives like LINQ~\cite{box2007linq}, StatusQuo~\cite{cheung2013statusquo} or Truffle~\cite{wimmer2012truffle}) could be of significant benefit for Android developers.
% \begin{figure}
@ -213,18 +239,23 @@ Not a single \texttt{UPDATE} expression attempted to compute new values in the S
\begin{figure}
\centering
\begin{tabular}{cc}
\includegraphics[width=0.49\textwidth]{graphs/data_mod_ops_cdf_by_app} &
\includegraphics[width=0.49\textwidth]{graphs/read_write_ratio_cdf_by_app} \\
(a) & (b)
\end{tabular}
\caption{App-level write behavior. (a) Cumulative distribution of applications by number of data manipulation statements performed (note the logarithmic scale). (b) Cumulative distribution of applications by read/write ratio. }
\begin{subfigure}[t]{0.5\textwidth}
\includegraphics[width=\textwidth]{graphs/data_mod_ops_cdf_by_app}
\caption{}
\label{fig:updateByApp:modOps}
\end{subfigure}%
\begin{subfigure}[t]{0.5\textwidth}
\includegraphics[width=\textwidth]{graphs/read_write_ratio_cdf_by_app}
\caption{}
\label{fig:updateByApp:writeRatio}
\end{subfigure}%
\caption{\textbf{App-level write behavior. (a) Cumulative distribution of applications by number of data manipulation statements performed (note the logarithmic scale). (b) Cumulative distribution of applications by read/write ratio. }}
\label{fig:updateByApp}
\end{figure}
Figure~\ref{fig:updateByApp}.a illustrates app-level write workloads, sorting applications by the number of \texttt{INSERT}, \texttt{UPSERT}, \texttt{UPDATE}, and \texttt{DELETE} operations that could be attributed to each. The CDF is almost perfectly exponential, suggesting that the number of write statements performed by any given app follows a long-tailed distribution, a feature to be considered in the design of a pocket data benchmark.
Figure~\ref{fig:updateByApp:modOps} illustrates app-level write workloads, sorting applications by the number of \texttt{INSERT}, \texttt{UPSERT}, \texttt{UPDATE}, and \texttt{DELETE} operations that could be attributed to each. The CDF is almost perfectly exponential, suggesting that the number of write statements performed by any given app follows a long-tailed distribution, a feature to be considered in the design of a pocket data benchmark.
Figure~\ref{fig:updateByApp}.b breaks apps down by their read/write ratio. Surprisingly, 25 apps (14\% of the apps seen) did not perform a single write over the course of the entire trace. Manual examination of these apps suggested two possible explanations. Several apps have reason to store state that is updated only infrequently. For example, \textit{JuiceSSH} or \textit{Key Chain} appear to use SQLite as a credential store. A second, far more interesting class of apps includes apps like \textit{Google Play Newsstand}, \textit{Eventbrite}, \textit{Wifi Analyzer}, and \textit{TuneIn Radio Pro}, which all have components that query data stored in the cloud. We suspect that the cloud data is being encapsulated into a pre-constructed SQLite database and being pushed to, or downloaded by the client applications.
Figure~\ref{fig:updateByApp:writeRatio} breaks apps down by their read/write ratio. Surprisingly, 25 apps (14\% of the apps seen) did not perform a single write over the course of the entire trace. Manual examination of these apps suggested two possible explanations. Several apps have reason to store state that is updated only infrequently. For example, \textit{JuiceSSH} or \textit{Key Chain} appear to use SQLite as a credential store. A second, far more interesting class of apps includes apps like \textit{Google Play Newsstand}, \textit{Eventbrite}, \textit{Wifi Analyzer}, and \textit{TuneIn Radio Pro}, which all have components that query data stored in the cloud. We suspect that the cloud data is being encapsulated into a pre-constructed SQLite database and being pushed to, or downloaded by the client applications.
This type of behavior might be compared to a bulk ETL process or log shipment in a server-class database workload, except that here, the database has already been constructed. Pre-caching through database encapsulation is a unique feature of embedded databases, and one that is already being used in a substantial number of apps.
% Barcode Scanner, BharatMatrimony, CamCard, CityMaps2Go Pro, Discover, Download Manager, Eventbrite, GPS Status, Google Play Newsstand, JuiceSSH, KBS kong, Key Chain, LTE Discovery, MX Player Pro, My Tracks, PlayerPro, Pushbullet, Quickoffice, SignalCheck Lite, Sound Search for Google Play, Splitwise, TuneIn Radio Pro, VLC, WeChat, Wifi Analyzer

View File

@ -16,13 +16,13 @@
\label{fig-overview-rowcount}
\end{subfigure}%
\caption{\textbf{Summary Statistics for Android SQLite Queries}}
\caption{\textbf{Summary Statistics for Android SQLite Queries. Distributions of (a) inter-query arrival times, (b) query runtimes, and (c) rows returned per query.}}
\label{fig-overview}
\end{figure*}
Next, we look at overall workload characteristics of the queries observed
Next, we look at overall runtime characteristics of the query workload observed
during our study. We examine how often queries arrive, how long they run, and
how many rows they return---all important inputs into desiging the TPC-Mobile
embedded database benchmark.
@ -40,12 +40,13 @@ Figure~\ref{fig-overview-interarrival}, it is interesting to observe that
many queries seem to arrive much more quickly than the minimum query runtime
shown in Figure~\ref{fig-overview-runtime}. Part of this may be due to apps
that use multiple separate databases, which is not yet captured by our
analysis. \XXXnote{However, our logging is also done above any locking
analysis. However, our logging is also done above any locking
performed by SQLite, and so this may demonstrate that there are many cases
where multiple application threads are issuing overlapping queries in
parallel, even if the queries are eventually serialized before results are
returned.} Figure~\ref{fig-overview-interarrival} also shows that there are
clearly a large number of periodic queries generated at around 0.1~Hz.
returned. Figure~\ref{fig-overview-interarrival} also shows that, in addition
to a standard long-tailed distribution of query inter-arrival times, about
20\% of the workload is very periodic, arriving at a rate of 0.01~Hz.
The runtime CDF shown in Figure~\ref{fig-overview-runtime} shows while
overall query runtimes show variation over several orders of magnitude, a
@ -53,8 +54,8 @@ large fraction of queries are executed in between 100~and~1000~$\mu$s.
Further investigation into the small fraction of extremely slow queries may
discover areas for database or application improvement. Finally, the row
count CDF shown in Figure~\ref{fig-overview-rowcount} shows that 80\% of
queries return only one row, indicating that many applications seem to be
using the SQLite database almost as a key-value store.
queries return only one row, further supporting our observation that many
applications seem to be using the SQLite database almost as a key-value store.
\begin{figure*}[t]
@ -74,31 +75,31 @@ using the SQLite database almost as a key-value store.
\label{fig-app-rowcount}
\end{subfigure}%
\caption{\textbf{By-Type Statistics for Android SQLite Queries}}
\caption{\textbf{By-Query-Type Statistics for Android SQLite Queries. Distribution of times since the query (a) immediately preceeding, and (b) immediately following the query in question. (c) Distribution of runtimes for each query.}}
\label{fig-app}
\end{figure*}
\begin{figure*}[t]
\centering
\includegraphics[width=0.6\textwidth]{./graphs/activity/All_Devices__Top_10__Key}
\begin{subfigure}[t]{0.33\textwidth}
\includegraphics[width=\textwidth]{./graphs/activity/All_Devices__Top_10__All_Queries__ByAppPreviousQueryCDFGraph.pdf}
\includegraphics[width=\textwidth]{./graphs/activity/All_Devices__Top_10__All_Queries__ByAppPreviousQueryCDFGraph_noKey.pdf}
\caption{}
\label{fig-type-interarrival}
\end{subfigure}%
\begin{subfigure}[t]{0.33\textwidth}
\includegraphics[width=\textwidth]{./graphs/activity/All_Devices__Top_10__All_Queries__ByAppRuntimeCDFGraph.pdf}
\includegraphics[width=\textwidth]{./graphs/activity/All_Devices__Top_10__All_Queries__ByAppRuntimeCDFGraph_noKey.pdf}
\caption{}
\label{fig-type-runtime}
\end{subfigure}%
\begin{subfigure}[t]{0.33\textwidth}
\includegraphics[width=\textwidth]{./graphs/activity/All_Devices__Top_10__All_Queries__ByAppRowcountCDFGraph.pdf}
\includegraphics[width=\textwidth]{./graphs/activity/All_Devices__Top_10__All_Queries__ByAppRowcountCDFGraph_noKey.pdf}
\caption{}
\label{fig-type-rowcount}
\end{subfigure}%
\caption{\textbf{Summary Statistics for Android SQLite Queries}}
\caption{\textbf{Summary Statistics for Android SQLite Queries. Distributions of (a) inter-query arrival times, (b) query runtimes, and (c) rows returned per query.}}
\label{fig-type}