% by Mirella M. Moro; version: September/03/2010 @ 6:04pm 
% -- 09/03/2010: bib file with names for proceedings and journals; cls with shrinked {received}
% -- 08/27/2010: appendix, table example, more explanation within comments, editors' data

\documentclass[jidm,a4paper]{jidm} % NOTE: JIDM is published on A4 paper
\usepackage{graphicx,url}  % for using figures and url format
\usepackage[T1]{fontenc}   % avoids warnings such as "LaTeX Font Warning: Font shape 'OMS/cmtt/m/n' undefined"
\usepackage{textcomp} % to display the textmu %
\usepackage{eurosym} % display euro currency %

%\usepackage{cite} % NOTE: do **not** include this package because it conflicts with jidm.bst

% Standard definitions
\newtheorem{theorem}{Theorem}[section]
\newtheorem{conjecture}[theorem]{Conjecture}
\newtheorem{corollary}[theorem]{Corollary}
\newtheorem{proposition}[theorem]{Proposition}
\newtheorem{lemma}[theorem]{Lemma}
\newdef{definition}[theorem]{Definition}
\newdef{remark}[theorem]{Remark}
\newenvironment{latexcode}
{\vspace{0.1in}\setlength{\parindent}{18pt}}
{\vspace{0.1in}}


% ALL FIELDS DOWN TO BEGIN{document} ARE MANDATORY

% The following data (volume, number and page) are given by the editors prior to publishing your paper
\jidmVolume{1}
\jidmNumber{3}
\jidmYear{10}
\jidmMonth{October}
\setcounter{page}{1}


% Includes headers with simplified name of the authors and paper title
\markboth{I.Petrov, R.Gottstein, T.Ivanov, D.Bausch, A.Buchmann}
{Page Size Selection for OLTP Databases on SSD RAID Storage }
%  -> \markboth{}{}
%         takes 2 arguments
%         ex: \markboth{M. M. Moro}{Any paper title}


% Title of the paper
\title{Page Size Selection for OLTP Databases on SSD RAID Storage}


% List of authors
%IF THERE ARE TWO or more institutions, please use:
%\author{Name of Author1\inst{1}, Name of Author2\inst{2}, Name of Author3\inst{2}}
\author{Ilia Petrov, Robert Gottstein, Todor Ivanov, Daniel Bausch, Alejandro Buchmann}


%Affiliation and email
\institute{Databases and Distributed Systems Group, Department of Computer Science, \\
Technische Universit\"{a}t Darmstadt  \\ 
\email{\{petrov, gottstein, ivanov, bausch, buchmann\}@dvs.tu-darmstadt.de}
}


% Paper abstract - it should be from 100 to 300 words
\begin{abstract} Flash SSDs are a technology that has the potential of changing the database architecture and principles. We reevaluate the present trend of growing database page sizes considering its validity for SSD-based database storage. Our major findings are: (a) on Flash storage this trend is reverted and best OLTP performance can be attained with smaller page sizes; (b) DBMS with smaller page sizes require less buffer space while providing the same performance; (c) due to the lower response times we report better CPU utilization for small page sizes.
\end{abstract}


% ACM Computing Classification System categories
\category{H.2.4}{Database management }{Systems}
\category{H.2.2}{Database management }{Physical Design}
\category{H.2.7}{Database management }{Administration}
% Categories and Descriptors are available at the 1998 ACM Computing Classification System
% http://www.acm.org/about/class/1998/
%  -> \category{}{}{}
%         takes 3 arguments for the Computing Reviews Classification Scheme.
%         ex: \category{D.3.3}{Programming Languages}{Language Constructs and Features}
%                   [data types and structures]
%                   the last argument, in square brackets, is optional.

% Paper keywords
\keywords{Database Systems, Page Size, Flash Solid State Disks, RAID}
%  -> \keywords{} (in alphabetical order \keywords{document processing, sequences,
%                      string searching, subsequences, substrings})


% THE PAPER BEGINS
\begin{document}

% This is optional:
\begin{bottomstuff}
% similar to \thanks
% for authors' addresses; research/grant statements
\end{bottomstuff}

\maketitle


%======================================================
\section{Introduction}
\label{sect:intro}

Over past two decades the standard page size used by database systems has been continuously growing. This is viewed as an established trend by the database community \cite{ScAG03,GrGr97,Grae08}. Larger page sizes and hence larger database buffers compensate for the poor IO properties of magnetic hard drives, minimizing the so called access gap. Over the last two decades the  accesses per second and the transfer rate improved only about 10 times, while capacities grew by a factor of 1000 \cite{Grae08,GrGr97}. Hard disks as storage technology have reached their physical limits hence no significant technological improvement can be expected. Flash Solid-State Disks (SSDs), on the other hand, are a disruptive technology, that has the potential of changing the established principles of DBMS architecture. In comparison (Table 1), SSDs exhibit low latency  and very high random throughput (accesses per second or simply IOPS (Input/Output Operations Per Second) especially for small block sizes. 

Please consider the following introductory example: while the typical hard drive's random throughput remains constant for block sizes between 4KB and 32KB, the SSD performance ranges significantly (up to seven times) within the same block range (Figure \ref{fig:randThroughput}, Table \ref{table:perfNumbers}, Table \ref{table:ssdProp}). The seek time dominates the overall response time of hard drives; for smaller block sizes (between 4KB and 32KB) there is a negligible change in the random performance. Regarding SSDs the smaller the block size the higher the random throughput due to the lack of seek time. This fact influences significantly the OLTP database performance on SSD storage. In the present paper we explore this hypothesis in a TPC-C testbed using the MySQL database system.

% DO CHECK http://en.wikibooks.org/wiki/LaTeX/Tables FOR MORE TIPS & TRICKS ON TABLES
\begin{center} 	% TABLES SHOULD BE CENTERED
\begin{table}[t]% TABLES SHOULD BE AT THE TOP [t] OR BOTTOM [b} OF PAGES
	\caption{Comparison of enterprise HDDs, SSDs } % ALWAYS INCLUDE CAPTIONS IN YOUR TABLES
	\label{table:ssdProp} % USE THE CONTENT WITHIN label FOR REFERENCING IT (USE \ref WITHIN THE TEXT)

\sffamily % CHANGES THE FONT WITHIN THE TABLE TO sans serif
\begin{tabular}{|r|c|c|c|c|c|c|c|c|c|c|c|c|}
	\cline{1-12}  % DRAWS HORIZONTAL LINE FROM 2nd to 13th COLUMNS
	 \rotatebox{90}{\parbox{55pt}{Device}} 
	& \rotatebox{90}{\parbox{55pt}{Seq. Read \newline [MB/s] (128K)} } % ROTATES TEXT 90o
	& \rotatebox{90}{\parbox{55pt}{Seq. Write \newline [MB/s] (128K)}} 
	&\rotatebox{90}{\parbox{55pt}{Rand. Read \newline[ms] (4 KB)}} 
	&\rotatebox{90}{\parbox{55pt}{Rand. Write \newline[ms] (4 KB)}} 
	&\rotatebox{90}{\parbox{55pt}{Rand. Read \newline[ms] (16 KB)}} 
	&\rotatebox{90}{\parbox{55pt}{Rand. Write \newline[ms] (16KB)}}
	 &\rotatebox{90}{\parbox{55pt}{Read IOPS \newline(4 KB)}} 
	 &\rotatebox{90}{\parbox{55pt}{Write IOPS \newline(4 KB)}} 
	 &\rotatebox{90}{\parbox{55pt}{Read IOPS \newline(16 KB)}} 
	 &\rotatebox{90}{\parbox{55pt}{Write IOPS \newline(16 KB)}} 
	 &\rotatebox{90}{\parbox{55pt}{Price [\euro{}/GB]}} 
	 \\ \hline % DRAWS HORIZONTAL LINE
% THIS multicolumn JUST GUARANTEES THE VERTICAL LINE AT THE BEGINNING OF THE COLUMN
\multicolumn{1}{|r|}{E. HDD} & 160 &160 & 3.2 & 3.5 & 3.3 & 3.4 & 291 & 287  & 288 & 285 & 2.5 \\ \hline
\multicolumn{1}{|r|}{E. SSD} & 250 & 180 & 0.161 & 0.125 & 0.294 & 0.377 & 35 510 & 5 953 & 12 743 & 3.665 &10 \\ \hline
\end{tabular}
\rmfamily % RESTORES TO TIMES, SO THAT CAPTION IS WRITTEN PROPERLY
\end{table}
\end{center}

The contributions of the present work can be shortly summarized as follows:
\begin{itemize}
	\item SSD storage characteristics revert the trend of increasing page sizes of database systems. We claim that for OLTP databases a smaller 4KB page size is better choice than a larger one, e.g. 16 KB. 
	\item Smaller block sizes relax the demand for essential buffer space. Larger buffers can be used to additionally improve performance by buffering more data or for providing space for maintenance operations such as index rebuilding etc.
	\item We claim that all database systems (not only several commercial ones) should support multiple dynamically configurable block sizes. And the ''default'' block size should be smaller (in the range of 4KB to 8KB) since it influences the database catalogue. 
	\item Last but not least higher CPU utilization can be observed for OLTP databases, which are typically IO-Bound environments. This is a result of the lower response times for small block operations. This increased CPU demand is a natural fit for the multi-core CPU trend. 
\end{itemize}
	
The present paper is structured as follows: we continue by examining the IO properties of Flash SSDs and describing the system under test. Next we investigate the database page size influence on the performance of an OLTP database. We use TPC-C as a standard OLTP workload. Last but not least we summarize our findings.




%-----------------------------------------------
\subsection{Scope and Topics}
\label{sec:relWork}

There is a large body of research on the properties of NAND SSDs \cite{ChKZ09,APW08}, the design of Flash Translation Layer. Research influence of Flash SSDs in the database field \cite{LeMP09,LMP08} reflects primarily logging \cite{LeMo07}, indexing \cite{YBH09}, page organization for analytical loads and  its influence on joins \cite{SHWG08,DoPa09}. There are new algorithms and data structures emerging. They address issues such as indices, page formats, logging and log record formats \cite{NaKa07,LeMo07,SHWG08,YBH09}. \cite{Grae08} outlines the influence of SSDs on 5-Minute-Rule and discusses the influence of flash properties the node utility metric and on the page size of an B-Tree database storage. \cite{Grae08} proposes an optimal page size of 2KB. A detailed analysis of the database page size influence on performance does not exist.



%======================================================
\section{Enterprise Flash SSDs and 	SSD RAID Configurations }
\label{sect:enterpiseSSD}

The performance Flash SSDs is characterized through (Table \ref{table:ssdProp}):  asymmetry, very high random throughput; high sequential performance; low latency ; low power consumption. The basic characteristics of the Flash SSDs are well documented \cite{ChKZ09,APWDMP2008,HuSc2011}.
These can be summarized as follows: 
 (a) asymmetric read/write performance - the read performance is significantly better than the write performance, up to an order of magnitude. This is due to the internal organization of the NAND memory and FTL algorithms.
(b) excellent random read throughput (IOPS) - especially for small block sizes. %\ref{fig:randomThroughput}
(c) acceptable random write throughput - small random writes are 5x to 10x slower than the random reads. The random throughput also deteriorates over the time.
(d) very good sequential read/write transfer. Although it is still commonly assumed that HDDs have higher sequential throughput, however newer generations of SSDs perform significantly better.
(e) IO Parallelism and Command Queuing (CQ) allows several IO requests to be executed in parallel. It enables database systems to successfully use asynchronous paged I/O in OLTP environments where traditional blocked I/O cannot be used.  

Modern database systems manage growing constantly growing data volumes. Using SSDs as primary database storage for large data volume yields special challenges related to producing sizable SSD space: (a) for the time being a single SSD device has a relatively low volume; (b) the performance and reliability bottlenecks of a single device can be avoided by a combination of devices. It seems that the RAID technology may deliver the right answer, however as reported by \cite{dash2,ssdraid} classical RAID configurations are plagued by performance and scalability bottlenecks due to hardware. These can be avoided by relying on software RAID spanning multiple SSDs attached to simple controllers and exposed directly (without any hardware functionality). In the following subsection we describe the organization and characteristics of our testbed.

%\begin{figure}[t] % FIGURES SHOULD BE AT THE TOP [t] OR BOTTOM [b} OF PAGES
%	\centering	% FIGURES SHOULD BE CENTERED
%		\includegraphics[width=0.6\textwidth]{Picts/randomThroughput.pdf}

%	\caption{Random Throughput SSD}	
%	\label{fig:randomThroughput} 
%\end{figure}

%======================================================
\subsection{Experimental Testbed}
\label{sect:experimentalTestbed}

The used hardware testbed comprises eight Intel X25-E SSDs attached to two LSI 9211-4i STAT2 controllers (Figure \ref{fig:architecture}). The SSDs are exposed as simple SATA2 devices without any additional hardware enhancements through the controllers. We neither use the hardware RAID features of the controllers nor do we use any hardware cache on the controller. Based on previous work showing that a software RAID on top of single devices is a way to overcome the performance bottlenecks of a hardware RAID controller \cite{ssdraid} we configured all devices in a software RAID0 volume using the Linux MD package. In doing so we configured Linux to use the NOOP IO-Scheduler and turned of the read-ahead on the the devices. The hardware testbed (Figure \ref{fig:architecture}) comprises a total of 48GB RAM, two 4-Core Intel Xeon 5630 CPUs (two hardware threads per core) and is based on a QPI technology. The system operates under 64 bit Gentoo Linux (2.6.34-gentoo-r12).

\begin{figure}[htbp]
  \centering
	\begin{minipage}[h]{7cm}
		\centering
		\includegraphics[width=0.6\textwidth]{Picts/Architecture.pdf} 
		\vspace{-0.4cm}
		\caption{Experimental testbed architecture}	
		\label{fig:architecture} 
	\end{minipage}
	\hfill
	\begin{minipage}[h]{8cm}
		\centering
		\sffamily
			\begin{tabular}{|c|c|c|c|c|c|}
				\cline{1-6}  % DRAWS HORIZONTAL LINE FROM 2nd to 13th COLUMNS
				 \rotatebox{90}{\parbox{70pt}{}} 
			 	 &\rotatebox{90}{\parbox{70pt}{\footnotesize Seq. Throughput \newline[MB/s] (256KB)}} 
				 & \rotatebox{90}{\parbox{70pt}{\footnotesize Seq. Throughput \newline[MB/s] (512KB)}}
				 &\rotatebox{90}{\parbox{70pt}{\footnotesize Rand. Throughput \newline[IOPS] (4KB)}} 
				 &\rotatebox{90}{\parbox{70pt}{\footnotesize Rand. Throughput \newline[IOPS] (8KB)} } 
				 &\rotatebox{90}{\parbox{70pt}{\footnotesize Rand. Throughput \newline[IOPS] (16KB)} } 
				 \\ \hline
			\multicolumn{1}{|r|}{\footnotesize Read} & \footnotesize 2018 
				&\footnotesize 2027 &\footnotesize 279 776 &\footnotesize 184 469 &\footnotesize 106 186 \\ \hline
			\multicolumn{1}{|r|}{\footnotesize Write} & \footnotesize 1477 &\footnotesize 1487 &
				\footnotesize 41 882 &\footnotesize 30 458 &\footnotesize 16 384 \\ \hline
			\end{tabular}
		\rmfamily 
		\caption{Performance figures overview}
		\label{table:perfNumbers}
	\end{minipage}
\end{figure}

%\begin{figure}[b] % FIGURES SHOULD BE AT THE TOP [t] OR BOTTOM [b} OF PAGES
%	\centering	% FIGURES SHOULD BE CENTERED
%		\includegraphics[width=0.4\textwidth]{Picts/Architecture.pdf} 
%	\caption{Experimental testbed architecture}	
%	\label{fig:architecture} 
%\end{figure}

We measured the performance of the IO-system using various benchmarks such as IOMeter, %\cite{Iome10}, 
fIO or XDD under different operating systems and validated the results with Oracle Orion \cite{Orio10}. Table \ref{table:perfNumbers} and Figures \ref{fig:seqThroughput} and \ref{fig:randThroughput}  reports the sequential and random throughput as well as sequential and random latency for different block sizes. Table \ref{table:perfNumbers} clearly shows the performance dependence on the blocksize. The random throughput for 4KB blocksize is approximately 2.5x better than the random throughput for 16KB blocksizes. Using this architecture we achieve 6x better random read performance, respectively 2x better random write performance over the testbed described in \cite{ssdraid}.

\begin{figure}[htbp]
  \centering
	\begin{minipage}[h]{7cm}
		\centering
		\includegraphics[width=6.5cm]{Picts/sequentialThroughput.pdf}
		\caption{Measured sequential throughput}
		\label{fig:seqThroughput}
	\end{minipage}
	\hfill
	\begin{minipage}[h]{7cm}
		\centering
		\includegraphics[width=7cm]{Picts/randomThroughput.pdf}
		\caption{Measured random throughput}
		\label{fig:randThroughput}
	\end{minipage}
\end{figure}
 

%??? Based on these numbers and general database experience we can draw the following conclusions: (i) In contrast to HDD storage SSDs storage can offer high sequential bandwidth and high random throughput at the same time. For database systems this requires database support for multiple concurrent page-sizes to harness the random and sequential performance. (ii) performance is asymmetric (better reads than writes). (iii) Sequential throughput is naturally better for larger block sizes, while the random throughput is better for small block sizes. Please notice the performance difference between 4KB and 16KB blocksize. OLTP databases should use small page sizes to harness the random performance. (iv) The lower the block size the lower the random latency (Table 3 (b)). (v) extensive use of command queuing (asynchronous I/O) improves the performance significantly. For OLTP databases the use of blocked IO can be successfully replaced by asynchronous paged IO due to the good command queuing behavior.

The logical question now is whether the database can benefit from the hardware improvements. If so what aspects contribute to the best improvement? Last but not least, do established assumptions regarding the influence of hardware components such as CPU change in presence of SSD storage with the above characteristics? 

We investigated our hypotheses by performing TPC-C experiments on a testbed comprising a MySQL database and SSD storage described above. The used benchmark - DBT2 \cite{DBT10} is an open source TPC-C implementation \cite{TPCC10} on top of MySQL version 5.5.9 with innoDB 1.1.5. DBT2 is instrumented according to the TPC-C specification (Section 4.2.2 of the TPC-C specification \cite{TPCC10}), i.e. to use 20 database connections and 10 terminals per warehouse. The standard MySQL codebase uses a static page size of 16KB, whereas the best random performance of our testbed is achieved with 4KB blocksize. Therefore we reconfigured and recompiled MySQL for the two sizes, as well as for 8KB. For all experiments the block size of the xfs file system was set to the default value of 4KB. The TPC-C tests were performed on all page size variations for different CPU and RAM configurations. We measure the average response time and the average throughput in New Order Transactions Per Minute (NoTPM) by varying the number of warehouses, to increase the load on the system. The dataset contains 1800 warehouses amounting to approx. 150-180GB, strongly depending on the database page size. As defined in Section 4.2 of the TPC-C specification \cite{TPCC10} we preserve the specification defined ratio of connections and terminals (and hence transactions) per warehouse; therefore the only way to increase the load on the system is to increase the dataset in terms of warehouses(Figure 4). This not only loads the IO-subsystem, it also increases the memory demand of the buffer manager.


%======================================================
\section{Performance Influence of Database Page Sizes}
\label{sect:Perf}

The database research community has widely recognized the trend of growing database page sizes to compensate for the IO characteristics of magnetic disks. Small random accesses (omnipresent in OLTP environments) are a weakness of existing HDDs. For large sequential operations (blocked IO) the HDD efficiency increases since the transfer rate dominates over the positioning costs. Large blocks however lead to larger database buffers. As pointed out by \cite{ScAG03,ScAG03,Grae08} there is a compromise between IO efficiency and buffer size. However a larger page size stands in stark contrast to the characteristics of SSDs.


\begin{figure}[htbp]
  \centering
	\begin{minipage}[h]{7cm}
		\centering
		\includegraphics[scale=0.4]{Picts/notpm_4k.pdf}
		\caption{Transactional throughput [NoTPM] 4KB}
		\label{fig:notpm4K}
	\end{minipage}
	\hfill
	\begin{minipage}[h]{7cm}
		\centering
		\includegraphics[scale=0.4]{Picts/notpm_8k.pdf}
		\caption{Transactional throughput [NoTPM] 8KB}
		\label{fig:notpm8K}
	\end{minipage}
	\begin{minipage}[h]{7cm}
		\centering
		\includegraphics[scale=0.4]{Picts/notpm_16k.pdf}
		\caption{Transactional throughput [NoTPM] 16KB}
		\label{fig:notpm16K}
	\end{minipage}
%=============================================
%	\begin{minipage}[h]{7cm}
%		\centering
%		\includegraphics[scale=0.4]{Picts/RespTime_4k.pdf}
%		\caption{Avg. Response Time [s] 4KB}
%		\label{fig:respTime4K}
%	\end{minipage}
%	\hfill
%	\begin{minipage}[h]{7cm}
%		\centering
%		\includegraphics[scale=0.4]{Picts/RespTime_8k.pdf}
%		\caption{Avg. Response Time [s] 8KB}
%		\label{fig:respTime8K}
%	\end{minipage}
%	\begin{minipage}[h]{7cm}
%		\centering
%		\includegraphics[scale=0.4]{Picts/RespTime_16k.pdf}
%		\caption{Avg. Response Time [s] 16KB}
%		\label{fig:respTime16K}
%	\end{minipage}
\end{figure}

Figures \ref{fig:notpm4K}, \ref{fig:notpm8K}, \ref{fig:notpm16K} represent the MySQL results of the TPC-C experiments for different page sizes, buffer sizes and CPUs. We observe a max. 20\% performance improvement in transaction throughput (NoTPM) due to the page size performance influence (4KB over 16 KB). 
%This very number can also be derived from the results in Figure \ref{table:perfNumbers} considering the 75\%/25\% read/write ratio DBT2 exhibits. 
The measured transaction throughput improvement can be attributed to the SSDs characteristics. These figures substantiate the claim that SSD storage reverts the trend towards larger page sizes. We claim that depending on the use of indices versus direct table operations the optimal page size is between 2KB and 4KB.

\begin{figure}
	\centering
	\includegraphics[scale=0.55]{Picts/table_NoTPM_Max.pdf}
	\caption{Maximum Values for NoTPM}
	\label{fig:maxNoTPM}
\end{figure}

Let us now consider Figure \ref{fig:maxNoTPM}, which contains the NoTPM maxima from Figures \ref{fig:notpm4K}, \ref{fig:notpm8K}, \ref{fig:notpm16K} and the relation between buffer size, page size and transaction throughput. Clearly for the same number of CPUs and the same buffer size there is between 15\% and 20\% performance advantage for the 4KB page size over 16KB. Consider the data for four CPUs (Figure \ref{fig:maxNoTPM}): the NoTPM throughput for 4KB page size and 1GB buffer size is comparable (11.5\% better) to the throughput with 16KB page size and 4GB buffer size (page size and buffer size are four times larger). The same result is visible in the eight CPU data. This observation is even more interesting in light of the TPC-C access skew \cite{HsSY01} due to which comparatively small database buffers can significantly reduce the number of accesses (for instance buffering 10\% of the database pages reduces 50\% of all accesses). On this basis we can conclude that smaller page sizes relax the demand for essential buffer space. 
%??? Figures \ref{fig:respTime8K}, \ref{fig:respTime8K}, \ref{fig:respTime16K}  shows the average response times for the New Order transaction (\cite{TPCC10}) for the maxima (Table 4). It can be clearly seen that the difference of transaction throughput is reflected at the response times as well. The maxima in transaction throughput for 4KB page size are not only 30\% higher they are also achieved at lower response times. This results should not be surprising ? it is a direct consequence of the results described in Section 1 (Table 2) and Section 6 (Table 3 (b)). ???
Last but not least OLTP databases on SSD storage exhibit good CPU utilization due to the lower response times. The transaction throughput and response times in Figure \ref{fig:maxNoTPM} improve with the higher number of CPUs. We depict the transactional throughput over the different database buffer sizes (Figure \ref{fig:NotpmPsBuffsize}) and number of CPUs (Figure \ref{fig:NotpmCpuBuffsize}). We observe an increase in NoTPM with more CPUs and larger buffer sizes. Although the slope of the curves in Figure \ref{fig:NotpmCpuBuffsize} decreases this is still a very interesting observation in an IO-bound environment. HDD based systems will not exhibit such behavior: they will be influenced more by the buffer increase and remain practically unaffected by CPU increase (in the same resource range). Clearly the higher random performance and lower latency on the SSD storage yield better CPU utilization. Hence the demand for more CPU power which leverages the multicore-CPU trend.
 \begin{figure}[htbp]
  \centering
	\begin{minipage}[h]{7cm}
		\centering
		\includegraphics[scale=0.5]{Picts/notpm_ps_buffSize.pdf}
		\caption{Increase in transactional throughput (NoTPM) for different buffer sizes (number of CPUs - constant, page size 4KB)}
		\label{fig:NotpmPsBuffsize}
	\end{minipage}
	\hfill
	\begin{minipage}[h]{7cm}
		\centering
		\includegraphics[scale=0.5]{Picts/notpm_CPU_Buffersize.pdf}
		\caption{Increase in transactional throughput (NoTPM) for different number of CPUs (buffer size - constant, page size 4KB)}
		\label{fig:NotpmCpuBuffsize}
	\end{minipage}
\end{figure}


%======================================================
\section{Conclusions}
\label{sect:conclusions}

The access gap between memory and HDD has been constantly increasing due to hardware developments. To compensate for the low random performance, page sizes for OLTP database systems have been growing (16KB, 32KB). SSDs however offer superior random performance for smaller block sizes (4KB), which reverts the established trend towards larger page sizes. 
In the present paper we proved this hypothesis by performing TPC-C experiments on a database system configured with 4KB, 8KB and 16KB page sizes on SSD storage. We observe a 20\% performance and response time improvement for the smaller block sizes. In addition we see that on SSD storage databases with smaller page sizes require proportionally less buffer space while offering comparable performance. Last but not least OLTP databases on SSD storage exhibit good CPU utilization due to the lower response times. Since these vary with the page size - the smaller the page size the higher the CPU utilization.
SSD storage can offer both good random and sequential throughput depending on the block size (Figure \ref{table:perfNumbers}). It is therefore important to support multiple concurrent block sizes to accommodate the requirements of different database objects types and access patterns. Larger block sizes are better suited for tables processed by sequential operations (e.g. full table scan) while smaller block sizes are better for operations yielding random accesses (e.g. index scan).


\texttt{Acknowledgement}: This work has been partially supported by the DFG project 'Flashy-DB'.




	
% INCLUDE BIBLIOGRAPHY WHICH MUST FOLLOW jidm.bst TEMPLATE
\bibliographystyle{jidm}
\bibliography{jidmb}
% For information on how to write bibliography entries, 
% see file jidmb.bib

\begin{received}
\end{received}

\end{document}
