\documentclass[11pt,twoside]{article}\makeatletter

\IfFileExists{xcolor.sty}%
  {\RequirePackage{xcolor}}%
  {\RequirePackage{color}}
\usepackage{colortbl}
\usepackage{wrapfig}
\usepackage{ifxetex}
\ifxetex
  \usepackage{fontspec}
  \usepackage{xunicode}
  \catcode`⃥=\active \def⃥{\textbackslash}
  \catcode`❴=\active \def❴{\{}
  \catcode`❵=\active \def❵{\}}
  \def\textJapanese{\fontspec{Noto Sans CJK JP}}
  \def\textChinese{\fontspec{Noto Sans CJK SC}}
  \def\textKorean{\fontspec{Noto Sans CJK KR}}
  \setmonofont{DejaVu Sans Mono}
  
\else
  \IfFileExists{utf8x.def}%
   {\usepackage[utf8x]{inputenc}
      \PrerenderUnicode{–}
    }%
   {\usepackage[utf8]{inputenc}}
  \usepackage[english]{babel}
  \usepackage[T1]{fontenc}
  \usepackage{float}
  \usepackage[]{ucs}
  \uc@dclc{8421}{default}{\textbackslash }
  \uc@dclc{10100}{default}{\{}
  \uc@dclc{10101}{default}{\}}
  \uc@dclc{8491}{default}{\AA{}}
  \uc@dclc{8239}{default}{\,}
  \uc@dclc{20154}{default}{ }
  \uc@dclc{10148}{default}{>}
  \def\textschwa{\rotatebox{-90}{e}}
  \def\textJapanese{}
  \def\textChinese{}
  \IfFileExists{tipa.sty}{\usepackage{tipa}}{}
\fi
\def\exampleFont{\ttfamily\small}
\DeclareTextSymbol{\textpi}{OML}{25}
\usepackage{relsize}
\RequirePackage{array}
\def\@testpach{\@chclass
 \ifnum \@lastchclass=6 \@ne \@chnum \@ne \else
  \ifnum \@lastchclass=7 5 \else
   \ifnum \@lastchclass=8 \tw@ \else
    \ifnum \@lastchclass=9 \thr@@
   \else \z@
   \ifnum \@lastchclass = 10 \else
   \edef\@nextchar{\expandafter\string\@nextchar}%
   \@chnum
   \if \@nextchar c\z@ \else
    \if \@nextchar l\@ne \else
     \if \@nextchar r\tw@ \else
   \z@ \@chclass
   \if\@nextchar |\@ne \else
    \if \@nextchar !6 \else
     \if \@nextchar @7 \else
      \if \@nextchar (8 \else
       \if \@nextchar )9 \else
  10
  \@chnum
  \if \@nextchar m\thr@@\else
   \if \@nextchar p4 \else
    \if \@nextchar b5 \else
   \z@ \@chclass \z@ \@preamerr \z@ \fi \fi \fi \fi
   \fi \fi  \fi  \fi  \fi  \fi  \fi \fi \fi \fi \fi \fi}
\gdef\arraybackslash{\let\\=\@arraycr}
\def\@textsubscript#1{{\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}}
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\def\abbr{}
\def\corr{}
\def\expan{}
\def\gap{}
\def\orig{}
\def\reg{}
\def\ref{}
\def\sic{}
\def\persName{}\def\name{}
\def\placeName{}
\def\orgName{}
\def\textcal#1{{\fontspec{Lucida Calligraphy}#1}}
\def\textgothic#1{{\fontspec{Lucida Blackletter}#1}}
\def\textlarge#1{{\large #1}}
\def\textoverbar#1{\ensuremath{\overline{#1}}}
\def\textquoted#1{‘#1’}
\def\textsmall#1{{\small #1}}
\def\textsubscript#1{\@textsubscript{\selectfont#1}}
\def\textxi{\ensuremath{\xi}}
\def\titlem{\itshape}
\newenvironment{biblfree}{}{\ifvmode\par\fi }
\newenvironment{bibl}{}{}
\newenvironment{byline}{\vskip6pt\itshape\fontsize{16pt}{18pt}\selectfont}{\par }
\newenvironment{citbibl}{}{\ifvmode\par\fi }
\newenvironment{docAuthor}{\ifvmode\vskip4pt\fontsize{16pt}{18pt}\selectfont\fi\itshape}{\ifvmode\par\fi }
\newenvironment{docDate}{}{\ifvmode\par\fi }
\newenvironment{docImprint}{\vskip 6pt}{\ifvmode\par\fi }
\newenvironment{docTitle}{\vskip6pt\bfseries\fontsize{22pt}{25pt}\selectfont}{\par }
\newenvironment{msHead}{\vskip 6pt}{\par}
\newenvironment{msItem}{\vskip 6pt}{\par}
\newenvironment{rubric}{}{}
\newenvironment{titlePart}{}{\par }

\newcolumntype{L}[1]{){\raggedright\arraybackslash}p{#1}}
\newcolumntype{C}[1]{){\centering\arraybackslash}p{#1}}
\newcolumntype{R}[1]{){\raggedleft\arraybackslash}p{#1}}
\newcolumntype{P}[1]{){\arraybackslash}p{#1}}
\newcolumntype{B}[1]{){\arraybackslash}b{#1}}
\newcolumntype{M}[1]{){\arraybackslash}m{#1}}
\definecolor{label}{gray}{0.75}
\def\unusedattribute#1{\sout{\textcolor{label}{#1}}}
\DeclareRobustCommand*{\xref}{\hyper@normalise\xref@}
\def\xref@#1#2{\hyper@linkurl{#2}{#1}}
\begingroup
\catcode`\_=\active
\gdef_#1{\ensuremath{\sb{\mathrm{#1}}}}
\endgroup
\mathcode`\_=\string"8000
\catcode`\_=12\relax

\usepackage[a4paper,twoside,lmargin=1in,rmargin=1in,tmargin=1in,bmargin=1in,marginparwidth=0.75in]{geometry}
\usepackage{framed}

\definecolor{shadecolor}{gray}{0.95}
\usepackage{longtable}
\usepackage[normalem]{ulem}
\usepackage{fancyvrb}
\usepackage{fancyhdr}
\usepackage{graphicx}
\usepackage{marginnote}

\renewcommand{\@cite}[1]{#1}


\renewcommand*{\marginfont}{\itshape\footnotesize}

\def\Gin@extensions{.pdf,.png,.jpg,.mps,.tif}

  \pagestyle{fancy}

\usepackage[pdftitle={A Novel Approach for Elastic Query Processing in the Cloud},
 pdfauthor={}]{hyperref}
\hyperbaseurl{}

	 \paperwidth210mm
	 \paperheight297mm
              
\def\@pnumwidth{1.55em}
\def\@tocrmarg {2.55em}
\def\@dotsep{4.5}
\setcounter{tocdepth}{3}
\clubpenalty=8000
\emergencystretch 3em
\hbadness=4000
\hyphenpenalty=400
\pretolerance=750
\tolerance=2000
\vbadness=4000
\widowpenalty=10000

\renewcommand\section{\@startsection {section}{1}{\z@}%
     {-1.75ex \@plus -0.5ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large\bfseries}}
\renewcommand\subsection{\@startsection{subsection}{2}{\z@}%
     {-1.75ex\@plus -0.5ex \@minus- .2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large}}
\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}%
     {-1.5ex\@plus -0.35ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\large}}
\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
     {-1ex \@plus-0.35ex \@minus -0.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\normalsize}}
\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}%
     {1.5ex \@plus1ex \@minus .2ex}%
     {-1em}%
     {\reset@font\normalsize\bfseries}}


\def\l@section#1#2{\addpenalty{\@secpenalty} \addvspace{1.0em plus 1pt}
 \@tempdima 1.5em \begingroup
 \parindent \z@ \rightskip \@pnumwidth 
 \parfillskip -\@pnumwidth 
 \bfseries \leavevmode #1\hfil \hbox to\@pnumwidth{\hss #2}\par
 \endgroup}
\def\l@subsection{\@dottedtocline{2}{1.5em}{2.3em}}
\def\l@subsubsection{\@dottedtocline{3}{3.8em}{3.2em}}
\def\l@paragraph{\@dottedtocline{4}{7.0em}{4.1em}}
\def\l@subparagraph{\@dottedtocline{5}{10em}{5em}}
\@ifundefined{c@section}{\newcounter{section}}{}
\@ifundefined{c@chapter}{\newcounter{chapter}}{}
\newif\if@mainmatter 
\@mainmattertrue
\def\chaptername{Chapter}
\def\frontmatter{%
  \pagenumbering{roman}
  \def\thechapter{\@roman\c@chapter}
  \def\theHchapter{\roman{chapter}}
  \def\thesection{\@roman\c@section}
  \def\theHsection{\roman{section}}
  \def\@chapapp{}%
}
\def\mainmatter{%
  \cleardoublepage
  \def\thechapter{\@arabic\c@chapter}
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \pagenumbering{arabic}
  \setcounter{secnumdepth}{6}
  \def\@chapapp{\chaptername}%
  \def\theHchapter{\arabic{chapter}}
  \def\thesection{\@arabic\c@section}
  \def\theHsection{\arabic{section}}
}
\def\backmatter{%
  \cleardoublepage
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \setcounter{secnumdepth}{2}
  \def\@chapapp{\appendixname}%
  \def\thechapter{\@Alph\c@chapter}
  \def\theHchapter{\Alph{chapter}}
  \appendix
}
\newenvironment{bibitemlist}[1]{%
   \list{\@biblabel{\@arabic\c@enumiv}}%
       {\settowidth\labelwidth{\@biblabel{#1}}%
        \leftmargin\labelwidth
        \advance\leftmargin\labelsep
        \@openbib@code
        \usecounter{enumiv}%
        \let\p@enumiv\@empty
        \renewcommand\theenumiv{\@arabic\c@enumiv}%
	}%
  \sloppy
  \clubpenalty4000
  \@clubpenalty \clubpenalty
  \widowpenalty4000%
  \sfcode`\.\@m}%
  {\def\@noitemerr
    {\@latex@warning{Empty `bibitemlist' environment}}%
    \endlist}

\def\tableofcontents{\section*{\contentsname}\@starttoc{toc}}
\parskip0pt
\parindent1em
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\newenvironment{reflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemsep}{0pt}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\itshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{sansreflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\itemsep}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\upshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{specHead}[2]%
 {\vspace{20pt}\hrule\vspace{10pt}%
  \phantomsection\label{#1}\markright{#2}%

  \pdfbookmark[2]{#2}{#1}%
  \hspace{-0.75in}{\bfseries\fontsize{16pt}{18pt}\selectfont#2}%
  }{}
      \def\TheFullDate{2014-01-15 (revised: 15 January 2014)}
\def\TheID{\makeatother }
\def\TheDate{2014-01-15}
\title{A Novel Approach for Elastic Query Processing in the Cloud}
\author{}\makeatletter 
\makeatletter
\newcommand*{\cleartoleftpage}{%
  \clearpage
    \if@twoside
    \ifodd\c@page
      \hbox{}\newpage
      \if@twocolumn
        \hbox{}\newpage
      \fi
    \fi
  \fi
}
\makeatother
\makeatletter
\thispagestyle{empty}
\markright{\@title}\markboth{\@title}{\@author}
\renewcommand\small{\@setfontsize\small{9pt}{11pt}\abovedisplayskip 8.5\p@ plus3\p@ minus4\p@
\belowdisplayskip \abovedisplayskip
\abovedisplayshortskip \z@ plus2\p@
\belowdisplayshortskip 4\p@ plus2\p@ minus2\p@
\def\@listi{\leftmargin\leftmargini
               \topsep 2\p@ plus1\p@ minus1\p@
               \parsep 2\p@ plus\p@ minus\p@
               \itemsep 1pt}
}
\makeatother
\fvset{frame=single,numberblanklines=false,xleftmargin=5mm,xrightmargin=5mm}
\fancyhf{} 
\setlength{\headheight}{14pt}
\fancyhead[LE]{\bfseries\leftmark} 
\fancyhead[RO]{\bfseries\rightmark} 
\fancyfoot[RO]{}
\fancyfoot[CO]{\thepage}
\fancyfoot[LO]{\TheID}
\fancyfoot[LE]{}
\fancyfoot[CE]{\thepage}
\fancyfoot[RE]{\TheID}
\hypersetup{citebordercolor=0.75 0.75 0.75,linkbordercolor=0.75 0.75 0.75,urlbordercolor=0.75 0.75 0.75,bookmarksnumbered=true}
\fancypagestyle{plain}{\fancyhead{}\renewcommand{\headrulewidth}{0pt}}

\date{}
\usepackage{authblk}

\providecommand{\keywords}[1]
{
\footnotesize
  \textbf{\textit{Index terms---}} #1
}

\usepackage{graphicx,xcolor}
\definecolor{GJBlue}{HTML}{273B81}
\definecolor{GJLightBlue}{HTML}{0A9DD9}
\definecolor{GJMediumGrey}{HTML}{6D6E70}
\definecolor{GJLightGrey}{HTML}{929497} 

\renewenvironment{abstract}{%
   \setlength{\parindent}{0pt}\raggedright
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
   \textcolor{GJBlue}{\large\bfseries\abstractname\space}
}{%   
   \vskip8pt
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
}

\usepackage[absolute,overlay]{textpos}

\makeatother 
      \usepackage{lineno}
      \linenumbers
      
\begin{document}

             \author[1]{CH.  Pavani}

             \author[2]{CH.  Pavani}

             \author[3]{B.Naga  Sai}

             \affil[1]{  K L University}

\renewcommand\Authands{ and }

\date{\small \em Received: 8 December 2013 Accepted: 4 January 2014 Published: 15 January 2014}

\maketitle


\begin{abstract}
        


Cloud computing is a promising model of serviceoriented computing. One major advantage of cloud computing is its elasticity, i.e., the system's capability to supply and take away resources dynamically at runtime. For that, it's essential to design and implement a systematic and effective technique that takes complete advantage of the system's potential flexibility. This paper presents a non-invasive approach that monitors the performance of relational database management systems in cloud infrastructure, and dynamically makes choices to maximise the effectiveness of the provider's environment whereas still satisfying specified service level agreements" (SLAs).

\end{abstract}


\keywords{elasticity, query processing, non-intrusive, service level agreement.}

\begin{textblock*}{18cm}(1cm,1cm) % {block width} (coords) 
\textcolor{GJBlue}{\LARGE Global Journals \LaTeX\ JournalKaleidoscope\texttrademark}
\end{textblock*}

\begin{textblock*}{18cm}(1.4cm,1.5cm) % {block width} (coords) 
\textcolor{GJBlue}{\footnotesize \\ Artificial Intelligence formulated this projection for compatibility purposes from the original article published at Global Journals. However, this technology is currently in beta. \emph{Therefore, kindly ignore odd layouts, missed formulae, text, tables, or figures.}}
\end{textblock*}


\let\tabcellsep& 	 	 		 
\section[{Introduction}]{Introduction}\par
loud Computing is a platform consists of a commonly very large number of computers responsible for data computing and storage. Such large computing re-sources are combined to serve multiple consumers using a multi holder model, with different physical and virtual resources dynamically assigned and reassigned according to the users' demands. Consider a cloud computing environment as a set of virtual machines (VMs) which may be assigned to different physical machines (PMs), different VMs may return different performances due to many factors, e.g., concurrency with other processes on the PMs.\par
Cloud computing elasticity enables the system to provide and remove resources according to the application's needs in real-time. providing suitable cloud elasticity on demand is not a frivolous matter. A cloud computing environment is apt to several factors that may influence its performance, including different types of virtual systems provided by the service, different time zones, and demand variation .To providing cloud computing elasticity requires monitoring closely the system's demand for resources in order to decide when to add or to remove resources. When users purchase figure out time from a cloud provider, commonly both sides, the user and provider agree on the quality of service, via a service level agreement (SLA), which may be composed of the following parameters:\par
Revenue: monetary value paid by the user to the provider for the computing time.\par
Operating Costs: monetary value paid by the user to the provider for the computing resources allocated for processing the user's workload.\par
Service Level Objective (SLO): It is associated with a user-defined metric which must be satisfied by the provider. e.g., response time, throughput, availability. Penalty: monetary value paid by the provider to the user for not satisfying the SLO.\par
The advantage of cloud providers to accordingly monitor and scale their resources, e.g., VMs, in real-time as a function of the current workload, in order to lower their computing cost while satisfying all current SLAs and minimizing penalties as much as possible. This is the very problem we address.\par
In this paper we aim at continuously monitoring a DBMS's performance and automatically minimizing the VMs used for query processing while minimizing potential SLO violations. We use query processing time as the contracted SLO metric.\par
Our resource provisioning approach does not assume that the number of VMs is fixed, or that VMs yield the same performance, nor we assume we can conclude the workload beforehand.\par
Using our elastic solution to ensure those, the immigrate process of applications to the cloud can be made directly. Our approach uses the relational data model and works with full reproduction. Thus, each set up VM has a DBMS with a complete copy of the database. Our solution does not partition the data, but the query.\par
We apply virtual partitioning to divide the query into sub queries to be processed on allocated virtual machines.\par
In that paper only select-range queries based on key attributes were investigated. This paper extends by showing how to address select-range queries on non-key attributes as well as aggregation queries. 
\section[{Main contributions are :}]{Main contributions are :}\par
? a non-intrusive, automatic and adaptive performance monitoring technique for DBMSs on the currently allocated VMs ? a pragmatic approach which dynamically aims at providing the smallest set of VMs capable of satisfying each query's SLO and thus the user's SLA in general.( D D D D D D D D ) Year B\par
One of the main advantages of the approach that we propose is that it may be easily applied to cases where the user already has its applications using relational database and ambition to deploy it in a cloud infrastructure, without the need of re architect ring the applications which are especially based on RDBMS technology. 
\section[{II.}]{II.} 
\section[{Related Work}]{Related Work}\par
An adaptive approach for provisioning VMs for the use of a distributed stream processing systems (DSPS)in the cloud. The proposed provisioning algorithm uses a black box approach, i.e., it is independent of the specifics of the queries running in the DSPS. It scales the number of VMs used entirely based on measurements of input stream rates. It detects an overload condition when a decrease in the processing rate of input data occurs because of discarded data tuples due to load dropping. The algorithm is invoked periodically and calculates the new number of VMs that are needed to support the current workload demand however, the paper does not specify how often this algorithm is invoked. We do not focus only on resource provision, and our contribution is also an adaptive monitoring, and re provisioning if necessary, during querying processing. \hyperref[b0]{[1]} The authors of proposed Kingfisher, a costaware system that tries to minimize the customer-centric cost, the cost of renting servers while meeting the application's SLA. It solves an integer linear program to account for both the infrastructure and transition cost deriving appropriate elasticity decisions under each workload change. Kingfisher uses a proactive approach to know when to provision as well as an ideal workload predictor that uses statistics gathered by the monitoring engine to derive estimates of future workload. Our approach differs from this approach in many ways: we use a cloud-provider-centric approach, and we do not assume a workload predictor, rather than the system's performance is continuously monitored. \hyperref[b1]{[2]} The problem of provisioning resources in a public cloud to execute data analytic workloads is exited. The algorithm presented an lazes the space of possible structure for the input workload based on conclude costs of the structure. The algorithm tries to find a structure where resource costs are minimized while the SLA associated with the workload is met. The cost model presented is similar to ours. However, considering that the performance of a particular structure can therefore degrade and SLAs are violated, it might be necessary to change the resources allocated to the application. The paper does not present a dynamic provisioning as we have done in our work. \hyperref[b2]{[3]} This paper presents an adaptive method to optimize the response time of range queries in a distributed database. The algorithm partitions and adaptively identifies the best level of parallelism for each query, since choosing the maximum level of parallelism is not necessarily the best strategy to optimize a query's performance. If a query is sent to too many storage hosts, it can saturate a single client by returning results faster than the client can consume them. That work, similar to ours, proposes an adaptive provisioning algorithm for range queries and considers possible variation in VM performances, but it differs from our work as it does not have an SLA to observe and does not specify how often the algorithm is invoked. \hyperref[b3]{[4]} III. 
\section[{Proposed Work}]{Proposed Work} 
\section[{Problem Formulation}]{Problem Formulation}\par
Let TRQ denotes the estimated total time needed to process a query Q and let SLOQ be the agreed time to process a given query Q as per the SLA. If p is the cost, per unit of time, of failing to satisfy SLOQ, we can define the provider's penalty (cost) as:pp Q = max\{(TR Q -SLO Q ) * p, 0\}\textbf{(1)}\par
Let c vm be the cost, per unit of time, for using a VM which contains a full model of a relational database and let n Q (t) be the number of VMs allocated to execute Q at time t, where time is discretized in billable units. Then, we can define the computing cost for running Q as:cc Q= ? (????(??) * ??????) ?????? ??=1\par
allocating as many VMs as possible will output an optimally minimum provider's penalty cost, but will increase its computing cost. Like wise , allocating a single VM will minimize the provider's computing cost, but will very likely output a potentially large penalty cost. given a query Q, we need to obtain, for each time point t, the number of VMs (n Q (t)) minimizing Q's cost(pp Q + cc Q )\par
This problem definition captures the elasticity of the cloud environment, namely that in different points of time a different number of VMs may be sufficient to process a query with respect to its SLO. 
\section[{a) Query Definition}]{a) Query Definition}\par
A preliminary version of this paper appears in that paper only select-range queries based on Key attributes were investigated. A select-range query is defined as follows: where T1.pk denotes the primary key attribute of T1.SELECT * FROM\par
We can also handle aggregation queries and aggregation over range: SELECT OPER (T1.attr) FROM table  {\ref T1};\par
where OPER is an aggregate operator (SUM, for example) and T1.attr denotes an attribute of a table T. 
\section[{b) Motivating Example i. Select-Range Query}]{b) Motivating Example i. Select-Range Query}\par
Assume that the following single select-range queryQ with SLO Q is received by the cloud provider.\par
SELECT * // <---Q FROM table T1 WHERE T.pk >= 0 and T.pk < 4000; where T1.pk is the primary key of table  {\ref T1}.\par
Assuming that T's primary key has no gaps, Q s =4000 tuples. Further let us assume that SLO Q is 100 seconds and that our initial provisioning is one single machine vm 0 such that RR 0 = 30 and consequently NT 0 Q = 3000. Clearly, using only vm 0 will output a penalty to be paid by the provider, namely the cost of reading all the 4000 tuples, (TR Q -SLO Q ) * p = (150-100)*p = 50*p. It is wise then to bring another VM (vm 1 ) up, to help. Let us assume that RR 1 = 10 and NT 1 Q = 2000. At this point it may be seemed that those two VMs are enough to process Q and satisfy its SLO by rewriting Q into the following two (sub)queries, Q 1 and Q 2 , running the first on vm0 and the second on vm 1 , respectively. Note that we use virtual partitioning (i.e. partitioning the range over the primary key) to divide Q into Q 1 and Q 2 .\par
SELECT * // <---Q1 FROM table  {\ref T1} WHERE T1.pk >= 0 and T1.pk < 3000; SELECT * // <---Q2 FROM table  {\ref T1} WHERE T1.pk >= 3000 and T1.pk < 4000;\par
Our proposal to deal with this issue is to more partition queries so that the executing VMs' reading rate can be monitored often enough in such way that other VMs can be added as needed in order to enforce SLO Q .\par
If monitoring is too constant that means the original queries would have to be partitioned in too many sub-queries, then the overhead added may hurt more than help. If hardly done it may be too late to make any corrections and to avoid potential penalties.\par
To address the partitioning process we build on historical data, i.e., how long it took to process a selectrange query with a given selectivity using a certain number of partitions. We assume the existence of a table H for each VM where each entry has a 4-tuple: (Partitioning attribute, query's selectivity, number of partitions, average processing time).\par
Using H we can find the maximum number of partitions and we can divide a query on, thus allowing an as-frequent-as-possible monitoring, while still satisfying SLO Q .\par
For the sake of argumentation, let us assume that H has enough information so that the following entries can be found when the query's selectivity is set to 4000and the partitioning attribute is pk as follows:\par
In this case, the larger number of partitions we can use is 4, maximizing the chance to monitor Q's performance while still satisfying SLOQ. Thus, we divide query Q1 into four queries: SELECT * // <---Q1, Even though it is not discussed here for the sake of brevity, a similar reasoning would be applied with respect to Q2 to be processed at vm1. This partitioning methodology using primary key as a partitioning attribute is the same for both selectrange queries and aggregation queries which are presented in the next subsection. Let us assume that( D D D D D D D D ) Year B 2014\par
vm1's performance is stable though and it is able to finish its workload as planned.\par
When Q1; 1 finishes we have the first opportunity to monitor, in a non-invasive manner, the VM's performance. Let us assume that it spent actually 40 seconds to finish. This leads us to reset the value of that VM's reading rate to RR 0 = 20 (500 tuples in 50 seconds), which leads to an expected completion time, for all five remaining sub-queries, of 200 seconds. This brings the expected completion time above SLOQ, and triggers a revision of the initial provisioning, so that SLAQ can still be satisfied. Note that before reviewing the initial provisioning, the three remaining partitions (Q1, 2, Q1, 3 and Q1, 4,Q1,5and Q1,6) are gathered in a single query.\par
Our elastic system would be able to process Q as follows: vm 0 would be used from time 0 to110 in order to retrieve tuples satisfying the primary key range  SELECT OPER(T.attr) // <---Q FROM table  {\ref T1}; The difference between this example and the previous one is how to partition an aggregation query. For partitioning Q, we added a range over the primary key of T1 which is used as the partitioning attribute. The range value in this case is between the maximum and minimum value for the primary key. In order to simplify, let the maximum value be 2999 and the minimum be zero. SELECT OPER(T1.attr) // <---Q FROM table T WHERE T1.pk >= 0 and T1.pk < 4000;\par
We assume that the query's selectivity in this case is the range' selectivity over T.pk (Qs = 4000 tuples).\par
If the aggregation operator is a distributive function as COUNT, for example, the result of Q is the summation of the results collected for each partition. However, if the aggregation operator is an algebraic function as AVG, the original query result may not be easily obtained through the partitions. We have to transform to distributive functions; in the case of AVG, we could transform on SUM and COUNT, so that the original query result can be easily obtained through the summation of partitions' results.\par
If we consider the same scenario presented in the previous example, vm 0 has a reading rate RR 0 = 30 and consequently NT Q 0 = 3000. Using only vm 0 will yield a ((TR Q -SLO Q )*p = (150-100)*p = 50*p) to be paid by the provider. It is wise then to bring another VM (vm1) up, to help. Let us assume that RR 1 = 10 and NTQ1 = 2000.\par
We rewrite Q into the two following (sub)queries, Q1 and Q2, running the first on vm 0 and the second on vm    WHERE T1.pk >= 2500 and T1.pk < 3000;\par
A similar thinking would be applied with respect to Q 2 to be run at vm1. As in the previous example, we assume that vm 1 's performance is stable yet and it is able to finish its workload as planned.\par
After Q 1.1 finishes we have the first opportunity to monitor the VM's performance in a non-invasive manner.\par
For the sake of brevity, we could suppose the same what happened in the previous example where Q1,1 spent 40 seconds to finish, therefore the VM's reading rate decreases to RR 0 = 20 and leads to an expected completion time, for all three remaining partitions (Q1,2, Q1,3 and Q1,4,Q1,5and Q1,6), of 200 seconds.\par
Let us allocate a new VM (vm2) with RR2 = 40 to satisfy the SLOQ and to o²oad some query processing. Then all remaining 1000 tuples might be read by vm2 in 20 seconds, in the best case, which does not lead to a violation of SLOQ (recall that at this point 40 seconds have already been spent on Q1;1). We have the same elastic behaviour (two VMs between time [0,40], three VMs between time [40, 60] and again two VMs between time [60, 90]) presented in Fig. \hyperref[fig_1]{1}.\par
The fact that a single basic approach can be easily adapted/ applied to different types of queries is a significant advantage. For instance, any optimization that can be done to the basic underlying (select-range) query can benefit other types of queries.\par
SELECT OPER(T1.attr) // <---Q 1 ,1 FROM table  {\ref T1} WHERE T1.pk >= 0 and T1.pk < 500; SELECT OPER(T1.attr) // <---Q1,2 
\section[{FROM table T1}]{FROM table T1}\par
WHERE T1.pk >= 500 and T1.pk < 1000; SELECT OPER(T1.attr) // <---Q1,3 this case is4, because it maximizes the chance to monitor Q's performance while still satisfying SLO Q . Thus, we divide query Q 1 into four queries: Step3: For each vm i that belongs to V do the following four steps i. Calculate Q i which is sub query of Q with NT i Q selectivity. ii. Calculate n i Q which is the query in H, the maximum number of partitions for Q i satisfying SLOQ . iii. Calculate P i i.e. divide Q i in n i Q partitions. iv. Call monitoring algorithm by passing Pi and SLO Q as input.\par
Step4: Stop/end Partition Query algorithm describes how partitions are created from a query Q taking into account SLO Q , performance of all vm i that belongs to V and data table H.\par
The working of this algorithm is as follows:\par
For each vmi allocated to process Q, the partition engine rewrites Q into a sub query Q i which has selectivity equal to the number of tuples that vm i can read without violating SLO Q , i.e., NT i Q and then Q i is partitioned using data table H by constructing the largest set of partitions Pi to be processed by vmi, such that the average Pi processing time does not exceed SLO Q .\par
How to obtain the value NT i Q for each vm i is discussed in the next section. After built Partitions, Algorithm 2 i.e. monitoring algorithm is applied inside each vmi. 
\section[{b) VM's Monitoring Algorithm Step 1: Start/begin}]{b) VM's Monitoring Algorithm Step 1: Start/begin}\par
Step 2: Read the input elements P i , SLO Q which are obtained from partitioning algorithm.\par
Step 3: P s := selectivity (P i );\par
Step 4: until P i ? 0 do the following steps i. Q := P i .remove( ); v. T q := T end -T start ; vi. T spent := T spent + Tq; vii. P s := Ps -|TP|; viii. T estimated := P s /RR i ; ix. TR Q := T spent + T estimated + TM i ;\par
x. Check if TR Q -SLO Q > 0 then do the following two steps a. T remain := SLO Q -(T spent + TM i ); b. return make Decision (Vm i , P i , T remain ); else if TR Q -SLO Q < 0 then do the following two steps a. ST i :=SLO Q -TR Q ; b. HasSlackTime(ST i ); xi. remove VM(vm i );\par
Step 5: Stop/end. Monitoring algorithm, monitors query partition processing, is carried on at each virtual machine allocated to this process.\par
The working of this algorithm is as follows:\par
At each vmi, monitoring algorithm starts monitoring the VMs' reading rate and estimates how long it takes to finish all partitions in P i . For each partition P i , monitoring algorithm calculates the time spent to process the partition. Therefore, it is possible to know how many tuples of P i remain to be retrieved, and also the estimated time to do that. This estimated time is based on the VM's reading rate, i.e., RR i . If the estimated total time needed to process Q is greater than SLO Q , this indicates that SLO Q may be violated. Note that we also consider the time TM i spent to monitor vm i 's performance. Hence, continuing to process Pi only with vmi will yield a penalty. In order to use the remaining time to process the remaining partitions in Pi without violating SLO Q , we have to make some decision .At this point P i should be recomputed for vm i , using make decision algorithm.\par
Monitoring algorithm should also work in the situation when the SLO Q could be satisfied faster than expected. In such case, we may use the slack time for processing other incoming query partitions or to reduce the number of VMs allocated. ST i represents the slack time value of vm i that can be further allocated without violating SLO Q . The VMs with slack time are used by provisioning algorithms, for reusing overloaded machine resources. The selectivity of each partition is calculated in accordance to the range selectivity of partitioning\par
? The partition engine uses table H and is responsible for partitioning the query aiming at respecting the query's SLO.\par
? The monitoring engine is executed within each VM vm i allocated to process a query Q and aims at making sure each VM keeps within the expected SLO. VMs can request" and offer" help. Both the partition engine and monitoring engine form the core of our approach.\par
Step 4: Q s := Selectivity(Q);\par
Step 5: Until Q s >0 \textasciicircum  S? 0 do the following steps i. (vm i ,ST i ) :=S.remove( ); Recall that in Algorithm 2 we have to make some decision to continue query processing while( D D D D D D D D ) Year B 2014 ii. Check a. if (ST i > SLO Q ) then NT i Q :=SLO Q * RR i ; b. else NTiQ :=ST i * RR i ; iii. Q s := Q s -NT i Q ; iv. V := V U \{vm i \};\par
Step 6: Until Qs >0 do the following steps i. Vm i :=new( ); ii. NT iQ :=SLO Q * RR i ; iii. Q s := Q s -NT i Q ; iv. V := V U \{vm i \};\par
Step 7: Call Partioning Query algorithm by passing the variables H, Q, SLO Q , V as input.\par
Step 8: Stop/end. This algorithm implements the initial provisioning approach. The purpose of this algorithm is to compute the smallest set V of virtual machines (V = \{vm 0 , ??,vm n \}) that should be initially dedicated to processing Q while satisfying SLO Q . For each vm i allocated it is required to know the amount of Q's tuples that vm i can process without violating SLO Q i.e., NT i Q . NT i Q is computed agreeing to the vm i 's reading rate capacity (RR i) within SLO Q . It computes the Q's selectivity and computes the adequate amount of tuples (NT i Q ) that should be provided to each vm i that belongs to V .We can get the query's selectivity by using the query plan statistics presented by the using the query plan statistics presented by the Database Management Systems.\par
Here we take the advantage of VM's slack time. This algorithm finds in S the largest set of vm i whose ST i can be devoted to processing Q. The choice of the largest set is to allow the provider to serve more clients using less computing resources (VMs) and meeting the SLA. The choice is made using a greedy method, following the order of S. Let S be an ordered set of pairs (vm i , ST i ), which contains slack time ST i for each vm i , such that there is only one element for each vm i and ST i is greater than 0 for all set elements. The set S is ordered by the descendent order of ST i value.\par
This algorithm calculates Q's selectivity. If S =0, the algorithm removes the first vm i from S and computes the number of tuples vm i can retrieve. If ST i > SLO Q , then NT i Q is calculated based on SLO Q and RR i . Otherwise, NTQ i is computed based on ST i and RR i .\par
The second loop in this Algorithm is responsible for distributing remaining tuples in Q to new VMs. When instantiating a new virtual machine vm i , the algorithm calculates its NT i Q . NT i Q is calculated using the VM's reading rate (RR i ) and the value of SLO Q . Algorithm 3 terminates when there is no tuples in Q to be distributed. After that, our strategy partitions Q (Algorithm 1 discussed in the previous subsection) is called to monitor the performance of each provisioned VM during Q execution. satisfying SLO. We therefore propose an elastic solution (described in Algorithm 4), which dynamically provisions VMs. At the monitoring stage, Algorithm 4 is called for each vmi that has the possibility of violating SLO Q . Suppose that vmi has a set of remaining partitions Pi, which should be processed within T remain units of time without violating the SLO Q . Algorithm 4 recalculates the number of VMs to help vm i to finish the processing of Pi within T remains, aiming at satisfying SLO Q . First, Algorithm 4 recalculates how many tuples vmi may retrieve while satisfying SLO Q . After that, Algorithm 4 provisions a new set of VMs and allocates to each of them an amount of tuples to be processed. Step 8: V := V U \{vm i \}; while Q's >0 \textasciicircum  S ? 0 do the following steps i. (vm i ,ST i ) :=S.remove( ); ii. Check a. if (ST i > SLO Q ) then NT i Q :=Tremain* RR j ; b. else NT i Q :=ST j * RR j ; iii. Q's := Q's -NT j Q ; iv. V := V U \{vm j \}; 
\section[{d) Decision Making Algorithm}]{d) Decision Making Algorithm}\par
Step 9: Until Q's >0 do the following steps i. Vm j :=new( ); ii. NT j Q :=Tremain * RR j ; iii. Q's := Q's -NT j Q ; iv. V := V U \{vm j \};\par
Step 10: Call Partioning Query algorithm by passing the variables H, Q, Tremain, V as input.\par
Step 11: Stop/end. At the monitoring stage, Algorithm 4 is called for each vmi that has the possibility of violating SLO Q . 
\section[{c) Initial Dynamic Provisioning Algorithm}]{c) Initial Dynamic Provisioning Algorithm}\par
Step 1: Start/begin Step 2: Read input elements Q, SLO Q .\par
Step 3: V := ø ; attribute. Recall that in all queries we chose the primary key as the partitioning attribute.  
\section[{Conclusion}]{Conclusion}\par
A cloud-based, non-intrusive, automatic and adaptive performance monitoring technique for DBMSs for select-range queries and aggregation queries, as well as an approach that dynamically minimizes the number of VMs needed to satisfy the queries' SLO. 
\section[{VII.}]{VII.} 
\section[{Future Scope}]{Future Scope}\par
Future work will focus on queries that use joins. Future work is to study the other parameters that can be used beyond the reading rate of each VM, such as CPU and effective memory available in each VM.\begin{figure}[htbp]
\noindent\textbf{0}\includegraphics[]{image-2.png}
\caption{\label{fig_0}[ 0 ,}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{1}\includegraphics[]{image-3.png}
\caption{\label{fig_1}Figure 1 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-4.png}
\caption{\label{fig_3}}\end{figure}
    \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.85\textwidth}}
SELECT MIN (T1.pk) into Vs, MAX (T1.pk) into Vf FROM\\
table T1;\\
SELECT MIN (T1.pk) into Vs, MAX (T1.pk) into Vf FROM\\
table T1;\\
2014\\
Year\\
D D D D ) B\\
(\\
For instance scan queries:\\
SELECT *FROM table T\\
can be commonplace rewritten as the following two\\
queries:\end{longtable} \par
 
\caption{\label{tab_0}}\end{figure}
 			\footnote{© 2014 Global Journals Inc. (US) Global Journal of Computer Science and Technology} 			\footnote{© 2014 Global Journals Inc. (US)} 		 		\backmatter  			 \par
instantiating a new machine vm j , the algorithm calculates its NT j Q ' which is using the VM's reading rate (RR j ) and the value of Trema in. Algorithm 4 terminates when there are no more tuples of Q' to be distributed. After that, our partitions Q' (Algorithm 1 discussed in the previous subsection is called) to monitor the performance of each provisioned VM during Q' execution, trying to ensure the Q' execution with in Tremain.\par
From Algorithm 4, the remaining partitions of P i are gathered into a new query Q'. Then NT i Q ' is figured, i.e., the amount of Q's tuples that vm i\par
If there still are tuples to be processed in Q' and S = 0 we have to allocate new VMs. When Suppose that vmi has a set of remaining partitions P i , which should be processed within Tremain units of time without violating the SLO Q . Algorithm 4 recalculates the number of VMs to help vmi to finish the processing of P i within Tremain, aiming at satisfying SLO Q . First, Algorithm 4 recalculates how many tuples vmi may retrieve while satisfying SLO Q . After that, Algorithm 4 necessities a new set of VMs and allocates to each of them an amount of tuples to be processed.\par
At the monitoring stage, Algorithm 4 is called for each vmi that has the possibility of violating SLO Q .			 			  				\begin{bibitemlist}{1}
\bibitem[Sharma et al. (2011)]{b1}\label{b1} 	 		‘A costaware elasticity provisioning system for the cloud’.  		 			U Sharma 		,  		 			P Shenoy 		,  		 			S Sahu 		,  		 			A Shaikh 		.  	 	 		\textit{Proc. the 31stInternational Conference on Distributed Computing Systems},  				 (the 31stInternational Conference on Distributed Computing Systems)  		June 2011.  	 
\bibitem[Rogers et al.]{b3}\label{b3} 	 		‘A generic auto provisioning framework for cloud databases’.  		 			J Rogers 		,  		 			O Papaemmanouil 		,  		 			U Cetintemel 		.  	 	 		\textit{Proc. the 26 th IEEE International},  				 (the 26 th IEEE International)  		 	 
\bibitem[Mian et al. ()]{b2}\label{b2} 	 		‘Provisioning data analytic workloads in a cloud’.  		 			R Mian 		,  		 			P Martin 		,  		 			J Vazquez-Poletti 		.  	 	 		\textit{Future Generation Computer Systems}  		2013.  	 
\bibitem[Da Silva et al. (2012)]{b0}\label{b0} 	 		‘Towards non-intrusive elastic query processing in the cloud’.  		 			Coelho Da Silva 		,  		 			T L 		,  		 			Nascimen 		,  		 			M A De Mace Do J A F 		,  		 			F R C Sousa 		,  		 			J C Machado 		.  	 	 		\textit{Proc. the 4th International Workshop on Cloud Data Management},  				 (the 4th International Workshop on Cloud Data Management)  		Oct. 29-Nov. 2, 2012.  	 
\end{bibitemlist}
 			 		 	 
\end{document}
