Shashikant Mahadu Bankar/ (IJCSIT) Intrnational Journal of Computr Scinc and Information Tchnologis, Vol. (3), 2015, 218-2191 Scalabl Transactions for Wb Applications in th Cloud using Customizd CloudTPS Shashikant Mahadu Bankar Dpartmnt of Computr scinc and Enginring GECA, Dr Babasahb Ambdkar Marathwada univrsity Auranagabad, India Abstract--Data consistncy is big issu whil using NoSQL Cloud data stors. Thy nsur scalability and high availability proprtis for wb applications, but whil providing ths thy sacrific data consistncy. Som availabl applications cannot afford data inconsistncy. To achiv Data consistncy in multi-itm transactions on wb applications, CloudTPS is bst solution. CloudTPS acts as a scalabl transaction managr which guarants full ACID proprtis for multi-itm transactions on wb applications. It dos not dpnd on th prsnc of srvr failurs and ntwork partitions. Thr is no ffct of failurs and ntwork partitions on functionality of CloudTPS. HBas and Hadoop provids scalabl data layrs. Hnc w prform this approach on top of this scalabl data layrs. Kywords Scalability, Wb applications, cloud computing, transactions, NoSQL. I. INTRODUCTION HBas and Hadoop ar NoSQL cloud databas srvics which provid a scalabl data tir for applications dployd in th cloud. Ths availabl systms partition th application data to provid additional scalability and rproduc th partitiond data to tolrat srvr failurs [1]. Cloud computing provids vision of a virtually infinit pool of computing, storag and ntworking rsourcs, in which w can dploy scalabl applications. A transaction is a st of quris to b xcutd on a singl consistnt viw of a databas. Th main challng for transactions is to provid th ACID proprtis of Atomicity, Consistncy, Isolation and Durability without ngotiating th scalability proprtis of th cloud. Howvr, th lmntal cloud data storag srvics provid only conditional consistncy [1]. Any cntralizd transaction managr would look at two scalability problms: 1) A singl transaction managr must xcut all incoming transactions and would finally bcom th prformanc and availability barrir; 2) A singl transaction managr must control a copy of all data accssd by transactions and would finally run out of storag spac. To support scalabl transactions, w propos to split th transaction managr into any numbr of Local Transaction Managrs (LTMs) and to partition th application data and th load of transaction procssing across LTMs [2]. CloudTPS advntur thr proprtis of Wb applications to allow fficint and scalabl oprations. First, w obsrv that in Wb applications, all transactions ar short-trm bcaus ach transaction is covrd in th procssing of a particular rqust from a usr. Scond, Wb applications contribut to issu transactions that intrval a rlativly small numbr of wll-idntifid data itms. This mans that th commit protocol for any givn transaction can b rstrictd to a rlativly small numbr of srvrs holding th accssd data itms. Third, many rad-only quris of Wb applications can produc usful rsults by accssing an oldr still prsistnt vrsion of data. This allows xcution of complx rad quris dirctly in th cloud data srvic, rathr than in LTMs. W must hav to considr two important issus to handl CloudTPS convnintly: 1) Thr is larg availability of diffrnt typs of cloud srvics. CloudTPS must hav to b portabl across availabl cloud srvics. Currnt cloud data srvics us diffrnt data modls and intrfacs but proposd systm constructs CloudTPS dpnding on thir common faturs. Our mthod is implmntd using ky-valu pairs. Our implmntation claims a simpl primary-ky-basd "GET/PUT" intrfac from cloud data srvics. 2) Loading of a whol copy of application into systms mmory may ovrflow mmory of LTM's. This will rsult into on application may us svral LTMs according to thir storag capacity. This is not ncssary condition that only latst accssd itms maintain ACID proprtis. If w rtriv currnt stord vrsions of unaccssd data itms, thn thy can b jctd from th LTMs. Wb applications dscribs tmporary locations whr only som portion of data is actually accssd at any tim. To nsur robust data consistncy, w can construct activ mmory managmnt schm to rduc th numbr of in-mmory data itms in LTMs [1]. CloudTPS must hav to maintain th ACID proprtis vn in th cas of srvr brakdowns. For this, w rproduc data itms and transaction stats to multipl LTMs, and annually chckpoint consistnt data snapshots to th cloud storag srvic. Consistncy corrctnss dpnds on th final consistncy and high availability proprtis of Cloud computing storag srvics [3].CloudTPS supports both rad-writ and rad-only transactions.w chck out our prototyp in a workload dvlopd from th TPC-W -commrc bnchmark [9]. W applid CloudTPS on th top of Hbas and Hadoop, which is scalabl data layr. CloudTPS tolrats srvr brak downs, which rsults into a fw abortd transactions and a tmporary dcras in throughput whil transaction rcovry and data rorganization. Daling with ntwork sparations, CloudTPS may rfus incoming transactions to manag data consistncy. As soon as, th ntwork is rbuilds, transactions ar rcovrd and bcoms availabl. www.ijcsit.com 218
Shashikant Mahadu Bankar/ (IJCSIT) Intrnational Journal of Computr Scinc and Information Tchnologis, Vol. (3), 2015, 218-2191 II. RELATED WORK A. Data Storag Simplst tchniqu to stor structurd data in to cloud is to dploy a rlational databas such as MySQL or Oracl. Th rlational data modl nforcd through th SQL languag, rsults into grat flxibility in accssing data. It supports practical data accss oprations such as aggrgation, rang quris, join quris, tc. Prson can fficintly dploy a classical RDBMS in th cloud and thus gt support for transactional consistncy. Ths flxibl qury languag and robust data consistncy avoids partitioning of data, which introduc scalability. Ths systms dpnds on rproduction tchniqus and thrfor do not dlivr xtra scalability improvmnt compard to a non-cloud dploymnt. Som cloud databas srvics as Bigtabl, SimplDB, uss abridgd data modls basd consisting attribut-valu pairs. All application data is arrangr into tabls. Data itms of th tabls ar gnrally accssd through GET/ PUT intrfac. All oprations ar rstrictd to prformd within tabl, non of thm supports oprations across multipl tabls such as join quris. Ths systm allows any numbr of tabls to sparat application data [5]. B. Distributd Transactional Systms Larg numbr of rsarch fforts hav bn activly applying to distributd transactions for distributd databas systms. Diffrnt typs of commit protocols and concurrncy control mchanisms ar invntd to cultivat th ACID proprtis of distributd transactions. Still, som distributd databas mak us of RDBMS. Thy lack in scalability as thy ar unabl to sparat application data automatically. But w can us 2-Phas Commit (2PC) for assuring Atomicity and on timstamp-ordring to maintain concurrncy control. H-Stor is a distributd main mmory OLTP databas. It supports transactions accssing multipl data rcords with SQL smantics, applid as prdfind stord procdurs. It rproduc data rcords to tolrat machin failurs. H-Stors scalability dpnds on th data sparation across xcutor nods. H-Stor dos not maintain constant logs or kp any data in th non-volatil storag of ithr th xcutor nods or any backing stor. CloudTPS chckpoints rturn updats back to th cloud data srvics to assur durability for ach transaction [2]. Anothr systm is th Scalaris transactional DHT systm. It distribut data across any numbr of DHT nods. It provids accss to any data itms by using primary ky. It do not support durability for stord data as it is purly an in-mmory systm. CloudTPS rsults into durability for transactions by chck pointing data updats into th cloud data srvic. Scalaris dpnds on th Paxos transactional algorithm, which can addrss Byzantin failurs, but rsults into high costs for ach transaction. Googl Prcolator implmnts multirow ACID transactions on top of Bigtabl. To administrat transaction managmnt, Prcolator applis Bigtabl as a shard mmory for all instancs of its clint-sid library []. Th data updats and transaction administration information, as locks and primary nod of a transaction, ar straightly writtn into Bigtabl. Prcolator can atomically prform many actions on a singl row using singl rows transactions of Bigtabl such as lock a data itm and mark th primary nod of th transaction. In advrs, CloudTPS continu with th data updats, transaction stats and quu of transactions all in th mmory of LTMs. Th basic cloud data stor dos not participat in th transaction administration. LTMs chckpoint data updats back to th cloud data stor only aftr th transaction has bn committd. Th dsign diffrncs of CloudTPS and Prcolator aris from thir distinct focuss. CloudTPS targts rspons-tim snsitiv Wb applications, whil Prcolator is dsignd for incrmntal procssing of massiv data procssing tasks which typically hav a rlaxd latncy rquirmnt. III. PROPOSED SYSTEM Following figur shows th complt organization of CloudTPS. Fig 1: organization of CloudTPS systm Clints concrn HTTP rqusts to a Wb application, which conscutivly concrn transactions to a Transaction Procssing Systm (TPS). Th TPS b adjunct with any numbr of LTMs, ach of which is authoritativ for a subst of all data itms. Th Wb application can submit a transaction to any on LTM that is authoritativ for on of th accssd data itms. This LTM thn acts as th administrator of th transaction across all LTMs. Thn LTM act on an inmmory copy of th ntir data itms which gts loadd from th cloud storag srvic. Updats of data transactions ar placd in mmory of LTMs. To avoid data loss rsulting from brakdown of LTM srvr, th data updats ar clon to multipl LTM srvrs. LTMs also rgularly chckpoint th updats back to th cloud storag srvic which is considrd to b highly-availabl and constant. W applid transactions using th 2-Phas Commit protocol. In th vry first phas, th administrator rqusts all involvd LTMs and chck whthr th opration can asily xcutd corrctly or not. If working of LTMs is propr, thn scond phas starts. In rality, scond phas commits th transaction. Othrwis, th transaction is intrruptd. Most of all cloud transactions ar of short duration and can accss wll analyzd data itms only. CloudTPS confss only srvr sid transactions carrid out as prdfind procdurs stord at all LTMs. Each transaction consists of on or mor sub-transactions, which oprat on a singl data itm ach. Whn it issus a transaction, th application must provid th primary kys of all accssd data itms. www.ijcsit.com 2188
Shashikant Mahadu Bankar/ (IJCSIT) Intrnational Journal of Computr Scinc and Information Tchnologis, Vol. (3), 2015, 218-2191 Gnrally, a transaction is carrid out as a Java objct containing a list of sub-transaction instancs. All sub-transactions ar implmntd as sub-classs of th Sub Transaction abstract Java class. Each sub-transaction consists of a uniqu class nam to idntify itslf, a tabl nam and primary ky, input paramtrs. Alrady bytcod of all sub-transactions is dployd at all LTMs. A Wb application concrn a transaction by submitting th nams of includd sub-transactions and thir paramtrs. LTMs thn build up th corrsponding sub-transaction instancs to xcut th transaction. W first clustr data itms into virtual nods, and thn attach virtual nods to LTMs. This rsults into balancd assignmnt of virtual nods to LTMs. Multipl virtual nods can b allowd to th sam LTM for transactions. To prmit LTM brak downs, virtual nods and transaction stats ar duplicatd to on or mor LTMs. Aftr th LTM srvr failur, th currnt updats can thn b rbornd and damagd transactions can continu xcution whil satisfying ACID proprtis. W now structur th dsign of th TPS to assur th Atomicity, Consistncy, Isolation and Durability proprtis. Each of th proprtis is discussd individually as follows: 1. Atomicity Whn ithr all oprations of a transactions ar succssfully xcutd or whn non of thm is xcutd thn th proprty atomicity rsults out. CloudTPS carrid out two-phas commit across all th LTMs which ar chargabl for all data itms accssd to assur atomicity for ach transactions. Th transaction administrator can concurrntly rturn th rsult to th wb application and complt th scond phas, whn an agrmnt to COMMIT is arrivd [1].If th srvr brak downs thn all transactions stats and all data itms must hav to rflct on on or mor LTMs.LTMs rproduc th data itms to kp backup of LTMs whil xcution of th scond phas of transaction.whn scond phas complts xcution succssfully duplicats of th accssd data itms ar bcoms consistnt. 2. Consistncy Th condition for consistnt proprty is that whn a transaction xcuts on an intrnally consistnt databas thn it should lav th databas in consistnt stag. Th trm Consistncy is commonly dfind as a st of informativ intgrity constraints. So whn transactions ar compltd corrctly, th Consistncy proprty is fulfilld [1]. 3. Isolation Th isolation proprty rsults out whn th bhavior of a transaction is not changd by th xistnc of othr transaction which also simultanously accss th sam data itms simultanously. CloudTPS is rsponsibl for th braking down of th transaction into it s of subtransactions. If two transactions accssing th sam data itms thn thir sub transactions must b xcutd in squnc, vn if th sub-transactions ar xcutd on multipl LTMs simultanously. For that w us timstamp ordring to rgulat transactions on LTMs. Each transaction has its univrsal xclusiv timstamp ordr numbr. Sub transactions having lowr timstamp ordring ar xcutd first than sub transactions having youngr timstamp ordring. Th cas may aris whr procssing of a transaction gts slow, and that a conflicting subtransaction having youngr timstamp has committd alrady. In such cas, arlir transaction will intrruptd, gts nw timstamp ordr numbr and thn starts rxcution [1]. 4. Durability Durability proprty ariss whn outcoms of th transactions cannot b accomplishd and must hav to xists whn srvr brakdowns. Updats of all data of committd transactions must b writtn to th backnd cloud storag srvic. Main problm is to support LTM brak down without dropping data.straightforwardly, th commit opration of a transaction dos not updat data in th cloud storag srvic but only updat data in-mmory, to incras prformanc. All data itms gt savd in to LTMs. Tim priod btwn commit opration of a transaction and upcoming chckpoints assurs durability proprty by rproducing data itms on diffrnt LTMs [1]. IV. RESULTS AND ANALYSIS W prform valuations on top of Hbas 0.20. and Hadoop v0.20.2. W us Tomcat Apach v.0.41 as application srvr to valuat CloudTPS prformanc. W xpos th scalability of CloudTPS by valuating th prformanc of a prototyp implmntationon top of two diffrnt familis of scalabldata layrs: HBas and Hadoop running on cloud.w dmonstrat that proposd CloudTPS can convnintly rconstruct from srvr brak down and ntwork sparation by considring throughput of CloudTPS undr brak downs.w also achiv scalability valuation by calculatingth maximum fasibl throughput of th systm including givn numbr of LTMs bfor th constraintgts brach. At bginning stag, w start with on LTM and 5 HBas srvrs and thn w incras th numbr of LTM and HBas srvrs. Undr crtain numbr of EB's, w prform on round of th valuation for 30 minuts to calculat th prformanc of th systm. In all cass, w purposly allocat mor numbr of HBas srvrs and clint machins to assur prformanc barrir of th CloudTPS []. Fig 2 shows th fficint rspons tim. Fig 2: Graph for avrag Rspons tim for Clint Transactions www.ijcsit.com 2189
Shashikant Mahadu Bankar/ (IJCSIT) Intrnational Journal of Computr Scinc and Information Tchnologis, Vol. (3), 2015, 218-2191 Prformanc of wb srvr mtrics dpnds on two things as th HTTP byts/sc data and CPU utilization. By knowing th HTTP byts/sc data, w can asily calculat th Mbyts/sc or Mbits/sc ntwork traffic for ach srvr and CPU. Considr a cas whr 2 procssor Wb Srvr running at 8% CPU utilization with a HTTP byts/sc valu of 4,10,450, on can calculat, (4,10,450 / (1024*1024)), a ntwork throughput rat of 3.9 Mbyts/sc or 31. Mbits/sc assists by th 2P Wb Srvr at 8% utilization. On can asily find if th wb srvrs has any hug hadroom s or wb srvr is configurd nar its maximum capabilitis [8]. Fig 3 and Fig 4 shows scalability illustrations by calculating throughput. Fig 3: Graph for Total Systm Throughput Fig 4: Graph for Throughput undr Writ Opration Th numbr of mulatd usrs supportd by ach wb Srvr is calculatd by Th Numbr of Usrs / Numbr of Wb Srvrs. To protct th duration of th usr sssion, th TPC-W bnchmark allows kp-aliv connctions. Contribution of Kp-aliv connctions is to curtail th CPU ovrhad rquird to procss a connction. Each usr prcivs on protctd and on non-protctd connction, thus w can calculat total numbr of connctions supportd by a wb Srvr by 2 * (Numbr of Browsrs / Wb Srvrs). For xampl givn a rsult of 4,800 WIPS with 30,000 mulatd browsrs in a configuration of 15 Wb Srvrs, ach Wb Srvr is supporting 2 * (30,000 / 15)= 4,000 intrnt connctions [9]. W can divid Wb Srvr ntwork traffic and kp-aliv connctions by total numbr of procssors is srvr to gt th ntwork traffic pr procssor and th numbr of supportd connctions pr procssor. This rsult is vry advantagous during comparison of diffrnt Wb Srvr procssors or comparison of wb Srvrs with diffrnt numbr of procssors. Emulatd Browsrs (EB s) gnrats data by crating and populating six tabls. EB S ar th mulatd browsrs which is simulatd to clint by snding th rqust through http [].Tabl shown blow dscribs th prformanc analysis of clint transactions which valuatd by Emulatd Browsrs. Sr.No updatitminf o DltCartLin gtshoppingc art gtshortordr RfrshCartLi n NwShopping Cart gtitmanda uthr gtordr gtshoppingc art_inpurchas Purchas gtcustomr gtrlatdit m updatrlatd ItmInfo Avrag rspons tim 1.331343 28358209 2.18943 8421052 3.1333 3333 2 30.222429 9054205 4.03308 518539 Avrag accssd itm Total numb r of transa ctions Tot al rsp ons tim Tot al acc ssd itm 1.0 92 2.0 95 20 190.0530303 03030303 11.11588 850429 1.395 2808988 528 535 35 15 11 9 143 32 4 594 48 8.94114 058823 1.0 34 304 34 1.329433 109 2239488 2.0 54 51 4 2 18.4111 108 413 5129035.0 591 81 5 3.2058823 9.8235294 529411 1140 34 109 334 42.235294 18.088235 143 34 1140 294115 15 8.8314 41 208 4.0 522 5095854 3 8 1.0584905 10 2.0 530 51 033 0 2.3333 2.9999 3333 9999 15 19 8 Tabl 1: Ovrviw of clint transactions for prformanc analysis log gnratd by EB S Following tabl 2 and figur 5 shows th ovrall clustr analysis of th proposd systm.tabl 2 illustrats th avrag accss tim, domain writ tim, tim latncy and tim slic by considring svral clint transactions. Domain Accss Tim 25.839195998994 ms Procss Tim 11.233855185909981 ms Total throughput 14.44453388901 ms Domain Writ Tim 11.233855185909981 ms Writ Latncy 10 ms Tim Slic 10 ms Tabl 2: Clustr Analysis www.ijcsit.com 2190
Shashikant Mahadu Bankar/ (IJCSIT) Intrnational Journal of Computr Scinc and Information Tchnologis, Vol. (3), 2015, 218-2191 Fig 5: Clustr Analysis V. CONCLUSION For corrct xcution, products nd strong data consistncy. Cloud provid good platform to host wb contnt to achiv high scalability and availability. Proposd schm provids ACID transactions without ngotiating th scalability proprty of th cloud for Wb applications. This work dpnds on fw simpl logics. First, w load data into th transactional layr from th cloud storag systm. Scondly, w can split th data across any numbr of LTMs, and rproduc thm only for fault tolranc. Wb applications can accss only fw partitions of data in any transactions, which rsults into CloudTPS linar scalability. Evn in th prsnc of srvr failurs and ntwork partitions, CloudTPS supports full ACID proprtis. Rcovring from a failur only causs a tmporary drop-in throughput and a fw abortd transactions. Rcovring from a ntwork partition may possibly caus tmporary unavailability of CloudTPS. Data partitioning also mntiond that transactions can only accss data by primary ky. CloudTPS allows Wb applications with strong data consistncy dmands to b scalabl dploymnt in th cloud. This mans Wb applications in th cloud do not nd to compromis consistncy for scalability. FUTURE SCOPE Hadoop has bcom backbon of big data platforms but holds diffrnt, sophisticatd architctur as compard to DBMS. Hadoop must hav to combin with raltim xtnsiv data collction and transmission which rsults into fastr procssing of data. Somtims Hadoop hids som complx background whil providing concis usr intrfac which causs poor prformanc of systm. So, w can implmnt advanc intrfac similar to DBMS to nhanc prformanc of Hadoop from ach and vry angl. Larg-scal Hadoop clustr includs vry hug numbr of srvrs which ar mainly rsponsibl for nrgy consumption. Hadoop should b widly dployd dpnding on nrgy fficincy. In th ra of big data, th trms as privacy and scurity has lots of importanc. Th big data platform should find a good balanc btwn nforcing data accss control and facilitating data procssing. REFERENCES [1] Zhou Wi, Guillaum Pirr, Chi-Hung Chi, CloudTPS: Scalabl Transactions for wb applications in th cloud, IEEE Transactions on Srvics Computing, Spcial Issu on Cloud Computing, 2011. [2] B. Hays, Cloud computing, Communications of th ACM, vol. 51, no., pp. 9 11, Jul. 2008. [3] Transaction Procssing Prformanc Council, TPC bnchmark C standard spcification, rvision 5, Dcmbr 200, http://www.tpc.org/tpcc/. [4] S. Gilbrt and N. Lynch, Brwr s conjctur and th fasibility of consistnt, availabl, partition-tolrant wb srvics, SIGACT Nws, vol. 33, no. 2, pp. 51 59, 2002. [5] HBas, An opn-sourc, distributd, column-orintd stor modld aftr th Googl Bigtabl papr, 200, http://hadoop. apach.org/hbas/. [] Amazon.com, EC2 lastic comput cloud, 2010, http://aws.amazon.com/c2. [] Z. Wi, G. Pirr, and C.-H. Chi, Scalabl transactions for wb applications in th cloud, in Proc. Euro-Par, 2009. [8] W. Vogls, Data accss pattrns in th Amazon.com tchnology platform, in Proc. VLDB, Kynot Spch, 200. [9] D. A. Mnasc, TPC-W: A bnchmark for -commrc, IEEE Intrnt Computing, vol., no. 3, 2002. [10] F. Chang, J. Dan, S. Ghmawat, W. C. Hsih, D. A. Wallach, M. Burrows, T. Chandra, A. Fiks, and R. E. Grubr, Bigtabl : a distributd storag systm for structurd data, in Proc. OSDI, 200. [11] S. Das, D. Agrawal, and A. E. Abbadi, Elastras: An lastic transactional data stor in th cloud, in Proc. HotCloud, 2009. www.ijcsit.com 2191