Captulo

4Gerenciamento de Dados em Nuvem: Conceitos,Sistemas e Desafios 1 2

Flvio R. C. Sousa, Leonardo O. Moreira, Jos Antnio F. de Macdo eJavam C. Machado

Universidade Federal do Cear (UFC)

Abstract

Infrastructures, platforms and software are being offered as services, in cloud computingenvironments, with companies and users being able to rent computing power and stor-age in a transparent way and on-demand. These companies and users are moving theirdata and applications to the cloud so that they can access them anytime and anywhere.However, this new computing model requires significant changes in data managementsystems, since these systems demand scalability, availability, performance and cost. Thismini-course will introduce the main concepts and technologies in cloud computing, focus-ing on data management and systems, and point research challenges and opportunities inthis context.

Resumo

Infraestruturas, plataformas e software esto sendo disponibilizados como servios, sendoestes fornecidos por ambientes de Computao em Nuvem, onde empresas e usurios po-dem alugar capacidade de computao e armazenamento de forma transparente e sobdemanda. Estas empresas e usurios esto movendo seus dados e aplicaes para anuvem de forma a acess-los a qualquer momento e independente de localizao. En-tretanto, este novo modelo de computao requer grandes mudanas nos sistemas degerenciamento de dados, pois estes sistemas necessitam de escalabilidade, disponibili-dade, desempenho e custo. Este minicurso tem como objetivo apresentar os principaisconceitos e tecnologias de computao em nuvem, destacando o gerenciamento de dadose sistemas, alm de desafios e oportunidades de pesquisa neste contexto.

1Publicado no SWIB 2010. Todos os direitos reservados a Sociedade Brasileira de Computao.2Verso revisada e ampliada em Fevereiro de 2011.

4.1. IntroduoCom o avano da sociedade humana moderna, servios bsicos e essenciais so quasetodos entregues de uma forma completamente transparente. Servios de utilidade pblicacomo gua, eletricidade, telefone e gs tornaram-se fundamentais para nossa vida diria eso explorados por meio do modelo de pagamento baseado no uso [Vecchiola et al. 2009].As infraestruturas existentes permitem entregar tais servios em qualquer lugar e a qual-quer hora, de forma que possamos simplesmente acender a luz, abrir a torneira ou usar ofogo. O uso desses servios , ento, cobrado de acordo com as diferentes polticas detarifao para o usurio final. Recentemente, a mesma ideia de utilidade tem sido aplicadano contexto da informtica e uma mudana consistente neste sentido tem sido feita com adisseminao de Cloud Computing ou Computao em Nuvem.

Computao em nuvem uma tendncia recente de tecnologia cujo objetivo proporcionar servios de Tecnologia da Informao (TI) sob demanda com pagamentobaseado no uso. Tendncias anteriores computao em nuvem foram limitadas a umadeterminada classe de usurios ou focadas em tornar disponvel uma demanda especficade recursos de TI, principalmente de informtica [Buyya et al. 2009]. Computao emnuvem pretende ser global e prover servios para as massas que vo desde o usuriofinal que hospeda seus documentos pessoais na Internet at empresas que terceirizamtoda infraestrutura de TI para outras empresas. Nunca uma abordagem para a utilizaoreal foi to global e completa: no apenas recursos de computao e armazenamento soentregues sob demanda, mas toda a pilha de computao pode ser aproveitada na nuvem.

A computao em nuvem surge da necessidade de construir infraestruturas de TIcomplexas, onde os usurios tm que realizar instalao, configurao e atualizao desistemas de software. Em geral, os recursos de computao e hardware so propensos aficarem obsoletos rapidamente e a utilizao de plataformas computacionais de terceiros uma soluo inteligente para os usurios lidarem com a infraestrutura de TI. Na com-putao em nuvem os recursos de TI so fornecidos como um servio, permitindo queos usurios o acessem sem a necessidade de conhecimento sobre a tecnologia utilizada.Assim, os usurios e as empresas passaram a acessar os servios sob demanda e indepen-dente de localizao, o que aumentou a quantidade de servios disponveis.

Com isso, os usurios esto movendo seus dados e aplicaes para a nuvem eassim acess-los de forma simples e de qualquer local. Isso novamente um caso de uti-lizao de processamento centralizado. Cenrio semelhante ocorreu h aproximadamente50 anos: um servidor de tempo compartilhado acessado por vrios usurios. Contudo,nas ltimas dcadas, quando os computadores pessoais surgiram, os dados e as aplicaescomearam a ser utilizados localmente.

Certamente o paradigma de computao em nuvem no uma repetio da histria.H 50 anos os servidores de tempo compartilhado foram adaptados por questes de lim-itao de recursos. J a computao em nuvem surge da necessidade de construir in-fraestruturas de TI complexas, onde os usurios tm que realizar instalao, configuraoe atualizao de sistemas de software. Alm disso, recursos de computao e hardwareso propensos a ficarem obsoletos rapidamente. Assim, a utilizao de plataformas com-putacionais de terceiros uma soluo inteligente para os usurios lidarem com infra-estrutura de TI. Na computao em nuvem os recursos de TI so fornecidos como um

servio, permitindo que os usurios o acessem sem a necessidade de conhecimento so-bre a tecnologia utilizada. Assim, os usurios e empresas passaram a acessa os serviossob demanda e independente de localizao, o que aumentou a quantidade de serviosdisponveis [Buyya et al. 2009].

Sistemas de gerenciamento de banco de dados (SGBDs) 3 so candidatos poten-ciais para a implantao em nuvem. Isso ocorre porque, em geral, as instalaes destessistemas so complexas e envolvem uma grande quantidade de dados, ocasionando umcusto elevado, tanto em hardware quanto em software. Para muitas empresas, especial-mente para start-ups e mdias empresas, o pagamento baseado no uso do modelo decomputao em nuvem, juntamente com o suporte para manuteno do hardware muitoatraente [Abadi 2009].

No final de 2010, a empresa Embarcadero realizou um survey [Embarcadero 2010]sobre tendncia, principais iniciativas, ferramentas atuais e desafios de banco de dadosrealizado com profissionais de banco de dados de grandes organizaes. Este surveydestacou que as tecnologias de banco de dados em nuvem e virtualizao tero o maiorimpacto na indstria de banco de dados, com 34% e 25% das respostas dos entrevistados,respectivamente. Isso indica uma previso de adoo constante de tecnologias de bancode dados em nuvens.

Embora SGBDs em nuvem tenham reduzido o custo de armazenamento de da-dos e melhorado o acesso, existe uma enorme complexidade envolvida com os serviosde dados que possam escalar quando necessrio garantir operaes consistentes e con-fiveis considerando cargas de trabalho mximas. Alm disso, o ambiente em nuvem temrequisitos tcnicos para controlar centros de dados virtualizados, reduzindo os custos eaumentando a confiabilidade por meio da consolidao de sistemas em nuvem. Desafiostais como consistncia e segurana dos dados so importantes para a computao em nu-vem e acredita-se que futuras aplicaes centradas em dados iro alavancar os servios dedados em nuvem.

Esta seo apresenta as definies, as caractersticas essenciais da computao emnuvem e os modelos de servio e implantao. A seo 4.2 caracteriza o gerenciamentode dados em nuvem e a seo 4.3 apresenta os principais sistemas de gerenciamento dedados em nuvem. A seo 4.4 discute alguns desafios do gerenciamento de dados emnuvem. Finalmente, a seo 4.5 apresenta as concluses finais.

4.1.1. Computao em Nuvem

A computao em nuvem est se tornando uma das palavras chaves da indstria de TI. Anuvem uma metfora para a Internet ou infraestrutura de comunicao entre os compo-nentes arquiteturais, baseada em uma abstrao que oculta complexidade da infraestru-tura. Cada parte desta infraestrutura provida como um servio e, estes so normalmentealocados em centros de dados, utilizando hardware compartilhado para computao e ar-mazenamento [Buyya et al. 2009].

A infraestrutura do ambiente de computao em nuvem normalmente compostapor um grande nmero, centenas ou milhares de mquinas fsicas ou ns fsicos de baixo

3SGBD refere-se um uma classe geral de armazenamento de dados, incluindo sistemas no-relacionais.

custo, conectadas por meio de uma rede como ilustra a Figura 4.1. Cada mquina fsicatem as mesmas configuraes de software, mas pode ter variao na capacidade de hard-ware em termos de CPU, memria e armazenamento em disco [Soror et al. 2010]. Den-tro de cada mquina fsica existe um nmero varivel de mquinas virtuais (VM) ou nsvirtuais em execuo, de acordo com a capacidade do hardware disponvel na mquinafsica.

Figura 4.1. Ambiente de Computao em Nuvem

A computao em nuvem uma evoluo dos servios e produtos de tecnologia dainformao sob demanda, tambm chamada de Utility Computing [Brantner et al. 2008].O objetivo da Utility Computing fornecer componentes bsicos como armazenamento,processamento e largura de banda de uma rede como uma mercadoria atravs de prove-dores especializados com um baixo custo por unidade utilizada. Usurios de serviosbaseados em Utility Computing no precisam se preocupar com escalabilidade, pois acapacidade de armazenamento fornecida praticamente infinita. A Utility Computingprope fornecer disponibilidade total, isto , os usurios podem ler e gravar dados a qual-quer tempo, sem nunca serem bloqueados; os tempos de resposta so quase constantese no dependem do nmero de usurios simultneos, do tamanho do banco de dados oude qualquer parmetro do sistema. Os usurios no precisam se preocupar com backups,pois se os componentes falharem, o provedor responsvel por substitu-los e tornar osdados disponveis em tempo hbil por meio de rplicas [Brantner et al. 2008].

Uma razo importante para a construo de novos servios baseados em UtilityComputing que provedores de servios que utilizam servios de terceiros pagam ape-nas pelos recursos que recebem, ou seja, pagam pelo uso. No so necessrios investi-mentos iniciais em TI e o custo cresce de forma linear e previsvel com o uso. Depen-dendo do modelo do negcio, possvel que o provedor de servios repasse o custo dearmazenagem, computao e de rede para os usurios finais, j que realizada a contabi-lizao do uso.

Existem diversas propostas para definir o paradigma da computao em nuvem[Vaquero et al. 2009]. O National Institute of Standards and Technology (NIST) argu-menta que a computao em nuvem um paradigma em evoluo e apresenta a seguintedefinio: Computao em nuvem um modelo que possibilita acesso, de modo con-veniente e sob demanda, a um conjunto de recursos computacionais configurveis (porexemplo, redes, servidores, armazenamento, aplicaes e servios) que podem ser rapida-mente adquiridos e liberados com mnimo esforo gerencial ou interao com o provedor

de servios [Mell and Grance 2009]. O NIST descreve que a computao em nuvem composta por cinco caractersticas essenciais, trs modelos de servio e quatro modelosde implantao, detalhados a seguir.

4.1.1.1. Caractersticas Essenciais

As caractersticas essenciais so vantagens que as solues de computao em nuvemoferecem. Algumas destas caractersticas, em conjunto, definem exclusivamente a com-putao em nuvem e fazem a distino com outros paradigmas. Por exemplo, a elastici-dade rpida de recursos, amplo acesso e a medio de servio so caractersticas bsicaspara compor uma soluo de computao em nuvem.

Self-service sob demanda: O usurio pode adquirir unilateralmente recurso com-putacional, como tempo de processamento no servidor ou armazenamento na rede,na medida em que necessite e sem precisar de interao humana com os provedoresde cada servio.

Amplo acesso: Recursos so disponibilizados por meio da rede e acessados atravsde mecanismos padronizados que possibilitam o uso por plataformas do tipo thin,tais como celulares, laptops e PDAs.

Pooling de recursos: Os recursos computacionais do provedor so organizados emum pool para servir mltiplos usurios usando um modelo multi-tenant ou multi-inquilino, com diferentes recursos fsicos e virtuais, dinamicamente atribudos eajustados de acordo com a demanda dos usurios. Estes usurios no precisam terconhecimento da localizao fsica dos recursos computacionais, podendo somenteespecificar a localizao em um nvel mais alto de abstrao, tais como o pas,estado ou centro de dados.

Elasticidade rpida: Recursos podem ser adquiridos de forma rpida e elstica, emalguns casos automaticamente, caso haja a necessidade de escalar com o aumentoda demanda, e liberados, na retrao dessa demanda. Para os usurios, os recursosdisponveis para uso parecem ser ilimitados e podem ser adquiridos em qualquerquantidade e a qualquer momento.

Servio medido: Sistemas em nuvem automaticamente controlam e otimizam o usode recursos por meio de uma capacidade de medio. A automao realizada emalgum nvel de abstrao apropriado para o tipo de servio, tais como armazena-mento, processamento, largura de banda e contas de usurio ativas. O uso de recur-sos pode ser monitorado e controlado, possibilitando transparncia para o provedore o usurio do servio utilizado.

4.1.1.2. Modelos de Servios

O ambiente de computao em nuvem composto de trs modelos de servios. Estesmodelos so importantes, pois eles definem um padro arquitetural para solues de com-putao em nuvem.

Software como um Servio (SaaS): O modelo de SaaS proporciona sistemas de soft-ware com propsitos especficos que so disponveis para os usurios por meio daInternet e acessveis a partir de vrios dispositivos do usurio por meio de umainterface thin client como um navegador Web. No SaaS, o usurio no admin-istra ou controla a infraestrutura subjacente, incluindo rede, servidores, sistemaoperacional, armazenamento ou mesmo as caractersticas individuais da aplicao,exceto configuraes especficas. Como exemplos de SaaS podemos destacar osservios de Customer Relationship Management (CRM) da Salesforce e o GoogleDocs.

Plataforma como um Servio (PaaS): O modelo de PaaS fornece sistema opera-cional, linguagens de programao e ambientes de desenvolvimento para as apli-caes, auxiliando a implementao de sistemas de software. Assim como no SaaS,o usurio no administra ou controla a infraestrutura subjacente, mas tem controlesobre as aplicaes implantadas e, possivelmente, as configuraes de aplicaeshospedadas nesta infraestrutura. Google App Engine [Ciurana 2009] e MicrosoftAzure [Azure 2011] so exemplos de PaaS.

Infraestrutura como um Servio (IaaS): A IaaS torna mais fcil e acessvel o fornec-imento de recursos, tais como servidores, rede, armazenamento e outros recursos decomputao fundamentais para construir um ambiente de aplicao sob demanda,que podem incluir sistemas operacionais e aplicativos. Em geral, o usurio no ad-ministra ou controla a infraestrutura da nuvem, mas tem controle sobre os sistemasoperacionais, armazenamento, aplicativos implantados e, eventualmente, selecionacomponentes de rede, tais como firewalls. O Amazon Elastic Cloud Computing(EC2) [Robinson 2008] e o Eucalyptus [Liu et al. 2007] so exemplos de IaaS.

4.1.1.3. Modelos de Implantao

Quanto ao acesso e disponibilidade, h diferentes tipos de modelos de implantao paraos ambientes de computao em nuvem. A restrio ou abertura de acesso depende doprocesso de negcios, do tipo de informao e do nvel de viso desejado.

Nuvem privada: a infraestrutura de nuvem utilizada exclusivamente por uma or-ganizao, sendo esta nuvem local ou remota e administrada pela prpria empresaou por terceiros.

Nuvem pblica: a infraestrutura de nuvem disponibilizada para o pblico emgeral, sendo acessado por qualquer usurio que conhea a localizao do servio.

Nuvem comunidade: fornece uma infraestrutura compartilhada por uma comu-nidade de organizaes com interesses em comum.

Nuvem hbrida: a infraestrutura uma composio de duas ou mais nuvens, quepodem ser do tipo privada, pblica ou comunidade e que continuam a ser entidadesnicas, mas conectadas por meio de tecnologia proprietria ou padronizada quepermite a portabilidade de dados e aplicaes.

4.1.2. Multi-Inquilino

O termo multi-inquilino um dos principais conceitos relacionados a SaaS. Um inquilinoem um cenrio de SaaS um usurio que utiliza SaaS. Ele refere-se ao uso do mesmosoftware e instncias por vrios usurios e empresas de forma simultnea. O objetivodessa abordagem disponibilizar os mesmos recursos de software para um nmero maiorde usurios.

Esta abordagem baseada no conceito da Cauda Longa [Microsoft 2010], uti-lizada por diversas empresas de internet que conseguem obter renda tanto com produtosde nicho como produtos tradicionais. Com o seu artigo The Long Tail, o escritor ChrisAnderson popularizou a idia da longa cauda ao explicar por que os varejistas on-linecomo Amazon.com esto posicionados de uma forma singular para atender uma imensademanda que os varejistas tradicionais no podem atender de uma maneira econmica.Os fornecedores de solues complexas de software de linha de negcios se defrontamcom uma curva de mercado semelhante. A Figura 4.2 mostra este cenrio.

Figura 4.2. Grfico da Cauda Longa

A primeira parte do grfico refere-se a grandes clientes e a segunda parte a clientestpicos. A terceira parte trata-se de um grande quantidade de pequenos clientes que coma diminuio dos custos podem utilizar software como um servio. O grfico demonstraque, conforme diminui-se o custo de adoo, um nmero maior de clientes pode adotaruma soluo, sendo que este nmero tende ao infinito, uma vez que a curva no toca oeixo x. Assim, no modelo SaaS de fornecimento de software, precisa-se desenvolversolues e infraestruturas de baixo custo, com alto aproveitamento de recursos por umnmero muito grande de usurios, para assim atingir um pblico no suportado hoje emdia, devido os custos proibitivos de entrada.

Outro conceito importante do modelo o micro-pagamento. Na cauda longa,um nmero muito grande de usurios poder adotar nossa soluo pagando pelo uso, pordemanda, o que deve gerar um valor muito baixo de pagamento. Neste contexto, procura-se o chamado milhes de mercados de poucos ao invs dos atuais poucos mercados demilhes.

Um ponto importante no modelo de SaaS o apoio para vrios inquilinos. A fimde explorar economias de escala, ou seja, permitir que um provedor ou desenvolvedorde SaaS oferecer a mesma instncia de um aplicativo SaaS para vrios inquilinos, a apli-cao deve ser multi-inquilino consistente. Multi-inquilino consciente significa que cadainquilino pode interagir com o aplicativo como se ele fosse o nico usurio da aplicao.Em especial, um inquilino no pode acessar ou visualizar os dados de um outro inquilino.

A forma de organizao dos inquilinos e das aplicaes ajuda a determinar a qual-idade de uma soluo multi-inquilino. De acordo com o nvel de implementao do con-ceito de multi-inquilino, pode-se definir a maturidade do SaaS. A Figura 4.3 mostra omodelo de maturidade SaaS, sobre a evoluo do suporte multi-inquilino [Microsoft 2010].Em cada quadrante possvel observar as diversas em relao ao suporte multi-inquilino:ad-hoc/personalizado configurvel, configurvel e eficiente para vrios inquilinos e escalonvel,configurvel e eficiente para vrios inquilinos, respectivamente.

Figura 4.3. Modelo de maturidade SaaS, sobre a evoluo do suporte multi-inquilino [Microsoft 2010]

No primeiro quadrante, existe um software destinado para cada inquilino. Issogarante o atendimento das demandas do usurio, mas custo elevado devido a grande cus-tomizao e disponibilidade de recursos individuais. O segundo quadrante apresenta umanica soluo destinada para todos os inquilinos separadamente. Neste caso, no h nen-huma customizao presente, garantindo menor custo de manuteno.

No terceiro quadrante, existe uma nica soluo para todos os inquilinos e, difer-ente do quadrante dois, esse soluo nica e disponivel para todos. Neste caso, umasoluo multi-inquilino, onde ocorre total compartilhamento de recursos.No quarto quad-rante, o atendimento diferenciado para inquilinos que exigem elevada demanda de re-cursos, havendo uma carga balanceada na infra-estrutura do provedor da soluo SaaS.

A fim de permitir aplicaes multi-inquilinos, a aplicao deve ser dividido emduas partes diferentes. A primeira parte da aplicao descreve os artefatos que so fixos

e podem ser usados por todos os inquilinos. A segunda parte descreve a parte flexvel,correspondente as configuraes e denominada metadados. Em relao aos dados, estespodem ser gerenciados de diversas formas, discutidas ao final deste texto.

4.2. Gerenciamento de Dados em NuvemSGBDs em nuvem esto comeando a ser utilizados e tm o potencial de atrair clientes dediversos setores do mercado, desde pequenas empresas com o objetivo de reduzir o custototal, por meio da utilizao de infraestrutura e sistemas de terceiros, at grandes empresasque buscam solues que para gerenciar milhares de mquinas e permitir o atendimentode um aumento inesperado de trfego [Abadi 2009].

A infraestrutura de SGBDs em nuvem possui vrias vantagens para os usurios:(i) previsibilidade e custos mais baixos, proporcional qualidade do servio (QoS) e car-gas de trabalho reais, (ii) complexidade tcnica reduzida, graas a interfaces de acessounificado e a delegao de tuning e administrao de SGBDs e (iii) a elasticidade e es-calabilidade, proporcionando a percepo de recursos quase infinitos. Por outro lado, oprovedor tem que garantir (i) a iluso de recursos infinitos, sob cargas de trabalho dinmi-cas e (ii) minimizar os custos operacionais associados a cada usurio [Curino et al. 2010].

Diversos sistemas e arquiteturas esto sendo desenvolvidos para suprir as novasdemandas de aplicaes com diferentes requisitos de processamento e armazenamento[Abouzeid et al. 2009]. Estes novos sistemas tentam fornecer uma viso de armazena-mento e escalabilidade infinitos, mas tem que tratar o problema de provisionar recursos.Este problema, que em SGBDs tradicionais consiste em determinar quais recursos soalocados para um nico banco de dados, no ambiente em nuvem torna-se um problema deotimizao, onde se tem uma grande quantidade de usurios, mltiplos SGBDs em nuveme grandes centros de dados. Isso fornece uma oportunidade sem precedentes para explorara economia em escala, balanceamento dinmico de carga e gerenciamento de energia.

Esse aumento no nmero de abordagens disponveis de SGBDs em nuvem agravao problema da escolha, implantao e solues de administrao para a gesto de da-dos. Com isso, os SGBDs em nuvem esto sendo disponibilizados como servios, queencapsulam a complexidade do gerenciamento por meio de formas de acesso simples egarantias de acordos de nvel de servio (SLAs).

4.2.1. Requisitos para o Gerenciamento de Dados em Nuvem

A definio dos requisitos fundamental no gerenciamento de dados como um servio.[Curino et al. 2010] apresentam uma lista de requisitos de um SGBD como um servio daperspectiva do usurio, do provedor e requisitos adicionais relacionados nuvem pblicaconforme apresenta a Tabela 4.1.

Da perspectiva do usurio, a principal necessidade um servio de banco de da-dos com uma interface simples que no necessite de ajuste ou administrao. Trata-sede uma melhoria em relao s solues tradicionais que requerem tcnicas para provi-sionar recursos, seleo de SGBDs em nuvem, instalao, configurao e administrao.O usurio quer um desempenho satisfatrio, expresso em termos de latncia e vazo,independente do tamanho da base de dados e das alteraes da carga de trabalho. At-

Requisitos do UsurioU1 API simples com pouca configurao e administrao (ex. sem tuning)U2 Alto desempenho (ex. vazo, escalabilidade)U3 Alta disponibilidade e confiana (ex. hot stand-by, backup)U4 Acesso fcil caractersticas avanadas (ex. snapshot, evoluo de esquema, minerao de dados)

Requisitos do ProvedorP1 Atender o SLA do usurio (ex. potencialmente sob carga de trabalho dinmica)P2 Limitar hardware e custo de energia (ex. multiplexao intensiva)P3 Limitar custo de administrao (ex. custo com pessoal)

Requisitos extra de Nuvem PblicaP1 Esquema de preo: barato, previsvel e proporcional ao uso (elasticidade)P2 Garantias de segurana e privacidadeP3 Baixa latncia (relevante para OLTP e aplicaes Web)

Tabela 4.1. Requisitos para SGBD como um Servio [Curino et al. 2010]

ualmente, esta uma tarefa difcil que exige uma ampla anlise do pessoal de TI, soft-ware caro e atualizaes de hardware. Alta disponibilidade outro requisito fundamental,que normalmente oferecido pelos SGBDs tradicionais, mas exige cuidados de configu-rao e manuteno. Finalmente, as caractersticas avanadas de gerenciamento do bancode dados, tais como snapshot, evoluo de esquema e minerao de dados devem estarprontamente disponveis e simples de utilizar.

Da perspectiva do provedor, necessrio atender aos acordos de nvel de servio,apesar da quantidade de dados e alteraes na carga de trabalho. O sistema deve sereficiente na utilizao dos recursos de hardware. O modelo de servio proporciona aoportunidade de fazer isso, por multiplexao de cargas de trabalho e ajuste dinmicoda alocao de recursos. Finalmente, a quantidade de tarefas de administrao deve serminimizada. Para tanto, ferramentas sofisticadas de anlise de carga de trabalho e cen-tralizao do gerenciamento de muitos bancos de dados devem ser utilizadas. Para prove-dores de servios em nuvem pblica, existem requisitos adicionais, tais como esquemade preo, segurana, privacidade e latncia. Entretanto, estas questes no so especfi-cas de bancos de dados e podem ser abordadas com tcnicas em desenvolvimento pelacomunidade de computao em nuvem.

4.2.2. Banco de Dados como um Servio

Um grande impacto foi causado na indstria de software ao prover um Sistemas de Ban-cos de Dados como um Servios (DaaS) e diversos desafios de pesquisa foram impostosa comunidade de banco de dados, incluindo, por exemplo, segurana, gerenciamento derecursos compartilhados e a extensibilidade. Devido a estas necessidades, os DaaS es-to surgindo como um novo paradigma para a gesto de dados em ambientes corpora-tivos, em que um prestador hospeda um banco de dados e o fornece como um servio[Agrawal et al. 2009].

Neste novo paradigma de gesto de dados, o usurio utiliza o servio de dados por

meio de diversas funcionalidades como por exemplo a configurao das bases de dados,esquemas, carga de dados no servio de dados e interfaces padronizadas de interao coma base. As atividades de gerenciamento dos aplicativos de banco de dados e dos custosso transferidos do usurio para o provedor de servios. A Figura 4.4 exibe a organizaoentre usurios e provedor de DaaS.

Figura 4.4. Banco de Dados como um Servio

De acordo com a figura, cada inquilino contrata os servio fornecido pelo prove-dor. Este provedor mantem um conjunto de banco de dados hospedados, em geral, emcentros de dados.O provedor deve garantir aspectos de disponibilidade, desempenho equalidade do servio definidos em SLA.

Do ponto de vista crtico essa organizao oferece uma srie de benefcios aosusurios, pois estes dispem de um ambiente altamente escalvel, disponvel e rpido.Alm disso, no h preocupao de manter a infra-estrutura de hardware e software parafornecer o servio de dados. Um outro ponto importante que o provedor de serviosgarante a QoS requerida pelo usurio. A prpria arquitetura distribuda fornece confiabil-idade no tocante a replicao de recursos.

Um sistema de banco de dados multi-inquilino deve oferecer esquemas que sejamflexveis em dois aspectos [Aulbach et al. 2008]. Primeiro, deve ser possvel estender oesquema base para suportar mltiplas verses do aplicativo, por exemplo, para regiesgeogrficas distintas. Uma extenso pode ser privada para um inquilino individualmenteou compartilhada por vrios inquilinos. Em segundo lugar, deveria ser possvel evoluirde forma dinmica o esquema base e suas extenses, enquanto o banco de dados est emexecuo. Evoluo de uma extenso deve ser totalmente self-service: o provedor deservio no deve ser envolvido; caso contrrio os custos operacionais sero muito altos.

Jacobs e Aulbach [Jacobs and Aulbach 2007] afirmam que um sistema de bancode dados pode multi-inquilino pode compartilhar mquinas, processos e tabelas. Deacordo com [Hui et al. 2009], existem trs abordagens para a construo de um banco

de dados multi-inquilino de acordo com o tipo de recurso compartilhado. A seguir, cadauma destas abordagens apresentada e as vantagens e desvantagens so discutidas.

Banco de Dados Independentes e Instncia de Banco de Dados Independente

Nesta abordagem os inquilinos compartilham apenas o hardware. O provedor deservios executa instncias do banco de dados independente para servir inquilinos inde-pendentes, de forma similar a instncias de um sistemas de banco de dados convencional.Cada inquilino cria seu prprio banco de dados e armazena seus dados atravs da interaocom uma instncia dedicada do banco de dados. A Figura 4.5 ilustra est abordagem.

Figura 4.5. Banco de Dados Independentes e Instncia de Banco de Dados Independente

Esta abordagem a mais simples de implementar um banco de dados multi-inquilino, sendo inteiramente construda em cima dos atuais banco de dados sem nenhumaextenso. Ela fornece um bom nvel de isolamento dos dados e segurana. No entanto,esta abordagem pode apresentar um alto custo de manuteno. Para gerenciar diversasinstncias de banco de dados, o provedor de servio precisa realizar muito trabalho deconfigurao. Outro ponto importante a escalabilidade, j que o nmero de instncias debanco de dados cresce linearmente com o nmero de inquilinos. Tcnicas de virtualizaopodem ajudar a minimizar alguns problemas destas abordagem, visto que estas tcnicasotimizam os recursos de hardwares e facilitam a configurao e administrao de sistemasde banco de dados.

Tabelas Independentes e Instncia de Banco de Dados Compartilhados

Nesta abordagem, os inquilinos compartilham o hardware e instncias de banco de da-dos. O provedor de servios manter uma grande base de dados compartilhada e servetodos os inquilinos. Cada inquilino utiliza esquemas privados do banco de dados com-partilhado. Cada nome de estrutura privada possui um identificador para indicar quem o proprietrio da tabela. Quando uma consulta submetida, esta reescrita de forma aidentificar o nome das tabelas modificadas e obter as respostas corretas. Esta reescritapode ser feita por um roteador de consultas. A Figura 4.6 mostra esta abordagem.

Figura 4.6. Tabelas Independentes e Instncia de Banco de Dados Compartilhados

Esta abordagem reduz o custo de manuteno de gerenciamento de diferentes in-stncias. Entretanto, o nmero de estruturas privadas no banco de dados compartilhadocresce linearmente com o nmero de inquilinos. Assim, a escalabilidade desta abor-dagem est limitada ao nmero de estruturas que o SGBD pode manipular e da memriadisponvel.

Tabelas Compartilhadas e Instncia de Banco de Dados Compartilhados

Nesta abordagem os inquilinos compartilham tabelas e instncias do banco de dados.Na fase de configurao do servio, o provedor de servios inicializa o banco de da-dos compartilhado criando tabelas vazias de acordo com o esquema base. Os inquilinosarmazenam suas tuplas em tabelas compartilhadas anexando um identificador a cada tu-pla, que indica a qual inquilino a tupla pertence e define os atributos no utilizados comNULL. Para recuperar as tuplas na tabela compartilhada, um roteador de consultas us-ando para reformular as consultas de acordo com o identificador. A Figura 4.7 ilustra estaabordagem.

Nesta abordagem, o provedor de servio mantm apenas uma instncia de bancode dados simples, o que reduz o custo de manuteno. Alm disso, o nmero de tabelasdo banco de dados determinado pelo esquema base, sendo independente do nmero deinquilinos, o que fornece melhor escalabilidade. Entretanto, esta abordagem apresentaalgumas desvantagens, tais como a necessidade de indexao e otimizao, j que osinquilinos compartilham as mesmas tabelas, mas apresentam requisitos diferentes. Tam-bm no existem estudos detalhados referentes aspectos de isolamento do banco de dadose segurana neste contexto.

4.2.3. Caractersticas do Gerenciamento de Dados em Nuvem

O gerenciamento de dados em nuvem pode ser organizado em duas classes de sistemas:(i) para apoiar aplicaes com muitas atualizaes e (ii) para analises dos dados e suporte

Figura 4.7. Tabelas Compartilhadas e Instncia de Banco de Dados Compartilhados

a deciso. Esta primeira classe pode ser dividida em duas subclasses: uma em que oobjetivo do sistema apoiar uma nica aplicao, com grandes quantidades de dados eoutro onde o objetivo do sistema apoiar um grande nmero de aplicaes, cada umacom pequenas quantidades de dados [Agrawal et al. 2010b].

Alguns trabalhos destacam caractersticas especficas do gerenciamento de dadosem nuvem. Segundo [Voicu and Schuldt 2009], no ambiente em nuvem, os dados sogerenciados em poucos centros de dados, utilizando recursos homogneos e, mais recen-temente, recursos heterogneos. Estes dados so acessados por meio de APIs simples,SQL ou variaes. Os SGBDs em nuvem devem suportar atualizaes concorrentes etransaes ACID ou variaes. Em relao replicao, esta deve ser transparente paraos usurios e fornecer garantias de qualidade de servio, obtidas pela criao de rplicasdos dados em um mesmo centro de dados ou em centros de dados diferentes, alm depermitir granulosidade fina dos dados. Na distribuio de dados, os SGBDs em nuvempodem apresentar um controle global central ou distribudo, devem fornecer escalabili-dade e suportar cargas de trabalho inesperadas. A Tabela 4.2 resume estas caractersticas.

Uma caracterstica essencial no ambiente de nuvem o gerenciamento autnomo[Paton et al. 2009]. Hardware e software dentro de nuvens podem ser automaticamentereconfigurados, orquestrados e estas modificaes so apresentadas ao usurio como umaimagem nica. possvel identificar trs diferenas em comparao com os sistemastradicionais: interveno humana limitada, alta alternncia na carga de trabalho e umavariedade de infraestruturas compartilhadas [Agrawal et al. 2008]. Na maioria dos casos,no haver administradores de SGBDs em nuvem ou de sistemas para ajudar os desen-volvedores que acessam um banco de dados em nuvem, fazendo com que a soluo sejaautomatizada ao mximo. Os usurios podem variar a carga de trabalho habitual, neces-sitando de uma infraestrutura eficaz, pois esta ser compartilhada por vrios usurios ouinquilinos.

De forma a possibilitar a consolidao da computao em nuvem e dos SGBDsem nuvem, tcnicas de virtualizao tem se tornando populares para a implantao destes

Distribuio Poucos centros de dadosAmbiente Recursos homogneos em centros de dadosOperaes para acesso aos dados API simples, SQL ou variaesAtualizao Suporte s atualizaes concorrentesTransaes ACID ou variaesReplicao Garantia de QoS e transparnciaGranulosidade da Replicao FinaControle Global Central ou DistribudoAlteraes Dinmicas Escalabilidade e suporte para cargas de trabalho ines-

peradas

Tabela 4.2. Caractersticas do Gerenciamento de Dados em Nuvem[Voicu and Schuldt 2009]

sistemas e de outros sistemas de software [Soror et al. 2010]. A virtualizao apoia a con-solidao dos recursos nas empresas, pois permite que uma variedade de aplicaes quefuncionam com recursos de computao dedicados sejam movidos para um pool de recur-sos compartilhados, o que ajuda a melhorar a utilizao dos recursos fsicos, simplificara administrao e reduzir custos para a empresa. Em [Soror et al. 2010] apresentadoum estudo sobre a sobrecarga de executar SGBDs em ambientes com mquinas virtuais.De acordo com o estudo, a execuo no traz um alto custo de desempenho, visto que avirtualizao introduz pouca sobrecarga para chamadas de sistema, tratamento de falta depginas e operao de E/S no disco e isto no traduzido em alta sobrecarga no tempo deexecuo da consulta. Chamadas de sistema e falta de pginas representam uma pequenafrao no tempo de execuo de uma consulta. Operaes de E/S no disco correspondem auma frao significativa do tempo, mas o retardo no muito. Os resultados apresentadosmostram que a sobrecarga mdia menor do que 10%.

Associado virtualizao, o compartilhamento de infraestruturas entre inquili-nos no gerenciamento de dados possibilita uma utilizao eficiente dos recursos e combaixo custo de operao, alm de permitir que os SGBDs em nuvem possam geren-ciar uma grande quantidade de inquilinos com padres de carga de trabalho irregulares[Elmore et al. 2010]. O conceito de multi-inquilino, uma tcnica para consolidar apli-caes de mltiplos inquilinos em um nico sistema frequentemente utilizada para elim-inar a necessidade de sistemas separados para cada inquilino. Por exemplo, um inquilinopode ser um usurio utilizando uma aplicao que acessa um SGBD ou um SGBD in-stalado em uma infraestrutura. SGBDs multi-inquilino tem sido utilizado para hospedarmltiplos inquilinos dentro de um nico sistema, permitindo o compartilhamento eficazde recursos em diferentes nveis de abstrao e isolamento.

Existem vrios modelos de multi-inquilino e estes podem compartilhar desdemquinas at tabelas. Por exemplo, a empresa Salesforce utiliza o modelo de tabelacompartilhada [Weissman and Bobrowski 2009] enquanto [Soror et al. 2010] utilizam omodelo de mquina virtual compartilhada para melhorar a utilizao dos recursos. Al-gumas caractersticas do gerenciamento de dados em nuvem aumentam a relevncia deoutros modelos de SGBDs multi-inquilino. Para melhorar a compreenso destes modelos,

[Reinwald 2010] prope uma nova classificao, como mostra a Tabela 4.3.

Modo de Compartilhamento Isolamento IaaS PaaS SaaS1. Hardware VM x2. Mquina Virtual Usurio SO x3. Sistema Operacional Instncia do BD x4. Instncia BD x5. Banco de Dados Esquema x6. Tabela Linha x

Tabela 4.3. Modelos de banco de dados multi-inquilino e correspondncia com acomputao em nuvem [Reinwald 2010] [Elmore et al. 2010]

Os modelos correspondentes s linhas 1-3 compartilham recursos nos nveis dasmesmas mquinas fsicas com diferentes nveis de abstrao, por exemplo, mltiplasVMs, contas de usurios diferentes e diferentes instncias do SGBDs. Neste caso noexiste compartilhamento de recursos de banco de dados e as instncias do SGBDs se man-tm independentes. As linhas 4-6 envolvem o compartilhamento de processos de banco dedados em vrios nveis de isolamento, tais como diferentes banco de dados, esquema outablespace e linha. Nos diferentes modelos, os dados dos inquilinos so armazenados devrias formas. O modelo de hardware compartilhado utiliza a virtualizao para chavearvrias VMs na mesma mquina. Cada VM possui apenas um processo de banco de dadose uma VM inteira, em geral, corresponde a um inquilino. J o modelo de tabela compar-tilhada armazena dados de vrios inquilinos em uma mesma tabela e algumas linhas deuma tabela correspondem a um inquilino.

4.2.3.1. Armazenamento e Processamento de Consultas

O armazenamento e processamento de consultas so pontos crticos no contexto da gestode dados em nuvem [Armbrust et al. 2009]. Existem diversas abordagens para gerenciardados em nuvem e cada sistema utiliza uma abordagem especfica para persistir os da-dos. Dentre estas abordagens, podemos destacar novos sistemas de arquivos, frameworkse propostas para o armazenamento e processamento de dados. Google File System (GFS) um sistema de arquivos distribudos proprietrio desenvolvido pelo Google e projetadoespecialmente para fornecer acesso eficiente e confivel aos dados usando grandes clus-ters de servidores [Ghemawat et al. 2003]. Em comparao com os sistemas de arquivostradicionais, o GFS foi projetado e otimizado para ser executado em centros de dados efornecer elevada vazo, baixa latncia e tolerncia a falhas individual de servidores. In-spirado pelo GFS, o projeto de cdigo livre Hadoop File System (HDFS) [Hadoop 2010]armazena grandes arquivos em vrias servidores e obtm a confiabilidade por meio dareplicao de dados. Similar ao GFS, os dados so armazenados em ns geograficamentedistribudos.

Para apoiar o processamento distribudo de grandes conjuntos de dados em clus-ters foi introduzido pelo Google o framework MapReduce [Dean and Ghemawat 2004].No modelo MapReduce cada operao composta por duas funes: Map e Reduce. A

funo Map recebe uma poro do arquivo de entrada e, de acordo com a especificaodo usurio, emite um conjunto de tuplas intermedirias no formato chave-valor. A funoReduce recebe um conjunto de valores associados a cada chave, chamados de blocos. Oprocessamento, definido pelo usurio, realizado sobre cada bloco. Por fim, cada funoReduce emite um conjunto de tuplas que so armazenadas em arquivos de sada. Existemalgumas implementaes de cdigo livre, dentre as quais se destaca o Hadoop MapRe-duce.

Algumas propostas para o armazenamento e processamento utilizam a estruturachave-valor em uma Distributed Hash Table (DHT) [DeCandia et al. 2007]. Este valor ea chave associada so armazenados de forma desnormalizada, o que facilita a distribuiodos dados entre os ns do sistema, onde cada um destes ns possui parte dos dados. AsAPIs bsicas de acesso so simples com operaes tais como get(key) e put(key, value).APIs mais sofisticadas permitem a execuo de funes definidas pelo usurio no am-biente do servidor tais como execute(key, operation, parameters) ou mapreduce(keyList,mapFunc, reduceFunc). Para acessar ou modificar qualquer dado necessrio forneceruma chave, j que a busca realizada utilizando a igualdade. possvel realizar pesquisascom outros critrios, tais como maior ou menor ou expresses booleanas. Neste caso, soutilizadas tcnicas de busca exaustiva e rvores B+ distribudas.

Outra abordagem para armazenar e processar dados em nuvem consiste em utilizaruma estrutura de colunas ou arrays multidimensionais [Chang et al. 2006]. Os dados soorganizados em tabelas e estas possuem diversas colunas. Cada coluna armazena umvalor, acessado por meio de uma chave. Nesta abordagem, todos os valores de uma colunaso serializados em conjunto, os valores da coluna seguinte tambm, e assim por diante.Com isso, os dados semelhantes, de mesmo formato, podem ser agrupados, auxiliando noarmazenamento e na recuperao de informao. Alm disso, diversas tcnicas tais comoa fragmentao de dados e o processamento OLAP tornam-se mais eficientes para dadosgerenciados com esta abordagem.

Outras abordagens para o armazenamento e processamento de consultas geren-ciam os dados de tal sorte a refletir a estrutura de um documento ou tratam os dados naforma de grafos. A abordagem orientada a documento, as tcnicas so desenvolvidas parao armazenamento, modelagem, consulta e apresentao de dados de forma a refletir aestrutura de um documento, que, em geral, no possui um esquema pr-definido. Nestecontexto, o formato JavaScript Object Notation (JSON) tem sido bastante utilizado, j que simples criar e manipular dados neste formato, facilitando a utilizao desta abordagem.

Na abordagem baseada em grafo [Rodriguez and Neubauer 2010], os dados sogerenciados da seguinte forma: (i) n (vrtice): possui o mesmo conceito de uma instnciade um objeto com identificador nico; (ii) relacionamento (arestas): fornece uma ligaoentre dois ns, sendo que estes ns possuem uma direo e um tipo de relacionamento e(iii) propriedade (atributo): so pares de strings chave-valor do objeto que podem existirtanto em um n quanto em um relacionamento. Esta abordagem auxilia na modelagemde estruturas complexas e por meio da representao utilizando grafos, a navegao entreos ns e os relacionamentos apresenta bons resultados.

4.2.3.2. Transaes

Os conceitos de processamento de transaes so de extrema importncia em ambientescentralizados e distribudos, sendo que nestes ltimos comum haver dados replicadose alocados em locais geograficamente distantes. Estes conceitos definem o nvel de con-sistncia e integridade dos dados nestes ambientes. A utilizao de transaes distribudasdefine o controle do processamento de dados em todo ambiente de computao em nuveme tem a responsabilidade de garantir as propriedades ACID ou variaes destas no ambi-ente. Neste sentido, necessita-se utilizar protocolos de replicao de dados, terminaodistribuda e sincronizao de acesso devido natureza compartilhada dos recursos.

Um ponto fundamental na construo de sistemas distribudos e considerado portodos os sistemas em nuvem o teorema Consistency, Availability, Partition Tolerance(CAP) [Brewer 2000] [Gilbert and Lynch 2002]. Este teorema mostra que os sistemasdistribudos no podem assegurar as seguintes propriedades simultaneamente:

Consistncia: todos os ns tem a mesma viso dos dados ao mesmo tempo.

Disponibilidade: falhas em ns no impedem os demais ns de continuar a operar.

Tolerncia a parties: o sistema continua a operar mesmo com a perda arbitrriade mensagens.

Um sistema distribudo pode suportar apenas duas dessas trs propriedades aomesmo tempo. Como uma forma simples de entender um assunto complexo, o teoremaCAP tornou-se um modelo popular para compreender aspectos de sistemas distribudos.No entanto, esta simplicidade pode conduzir a interpretaes incorretas do teorema. Estaspropriedades no devem ser interpretadas no sentido de que o sistema disponvel ou con-sistente, mas que quando ocorre uma falha de rede, necessrio escolher qual propriedadetorna-se mais importante para o sistema.

Em decorrncia deste teorema, algumas abordagens para o gerenciamento de da-dos em nuvem tm utilizado diferentes formas de consistncia. Uma alternativa utilizar aabordagem Basically Available, Soft state, Eventually consistent (BASE) [Pritchett 2008],que caracterizada pelo sistema ser basicamente disponvel, pois este parece estar emfuncionamento todo o tempo; em estado leve, j que o sistema no precisa estar sempreconsistente; e eventualmente consistente, que define que o sistema torna-se consistenteem um determinado momento.

De acordo com [Vogels 2009], existem duas formas de caracterizar a consistncia:do ponto de vista do programador/cliente - como os dados so observados e atualizadose do ponto de vista do servidor - como processado o fluxo das atualizaes por meio dosistema e que garantias este pode fornecer, no que diz respeito s atualizaes. Por exem-plo, podem-se definir alguns tipos de consistncia. A consistncia forte garante que apsuma atualizao ser concluda, qualquer acesso subsequente fornecer o valor atualizado.Por outro lado, na consistncia fraca, o sistema no garante que os acessos subsequentesiro retornar o valor atualizado. O perodo entre uma atualizao e o momento no qual

garantido ao observador que este ir sempre visualizar o valor atualizado denominadojanela de inconsistncia.

A consistncia eventual uma forma especfica de consistncia fraca, na qualo sistema garante que, se nenhuma atualizao for feita ao dado, todos os acessos irodevolver o ltimo valor atualizado. Se no ocorrer nenhum erro, o tamanho mximo dajanela de inconsistncia pode ser determinado com base em fatores tais como os atrasosde comunicao, a carga do sistema e o nmero de rplicas envolvidas do esquema dereplicao. O sistema mais popular que implementa consistncia eventual o DomainName System (DNS).

O modelo de consistncia eventual apresenta um nmero de variaes tais comoconsistncia causal, consistncia leitura/escrita, consistncia de sesso, consistncia deleitura/escrita montona. Estas variaes podem ser combinadas com o objetivo de tornarmais simples a construo de aplicaes e permitir aos sistemas melhorarem a consistn-cia e fornecer maior disponibilidade. Sob o ponto de vista do servidor, o nvel de con-sistncia depende de como as atualizaes so propagadas entre as rplicas dos dados.Isto permite melhorar a taxa de transferncia e fornecer escalabilidade. Contudo, o de-senvolvedor deve estar consciente sobre quais garantias de consistncia so fornecidaspelo sistema na construo de aplicaes.

4.2.3.3. Escalabilidade e Desempenho

A nuvem composta por uma enorme rede de mquinas que necessita ser escalvel. Aescalabilidade deve ser transparente para os usurios, podendo estes armazenar seus dadosna nuvem sem a necessidade de saber a localizao dos dados ou a forma de acesso. Nanuvem, os desenvolvedores dispem de ambientes escalveis, mas eles tm que aceitaralgumas restries sobre o tipo de software que se pode desenvolver, desde limitaesque o ambiente impe na concepo das aplicaes at a utilizao de SGBDs em nuvemdo tipo chave-valor, ao invs de SGBDs relacionais.

De forma geral, possvel identificar duas dimenses de escalabilidade: verticale horizontal. Na escalabilidade vertical melhora-se a capacidade do hardware, incremen-tando individualmente os ns existentes, como por exemplo, por meio da disponibiliza-o de um servidor com mais memria fsica ou da melhoria da largura de banda queconecta dois ns. Isto funciona razoavelmente bem para os dados, mas tem vrias lim-itaes tais como a aquisio constante de hardware de maior capacidade, o que podecriar dependncia de fornecedores, aumentando os custos. A escalabilidade horizontalconsiste em adicionar mais mquinas soluo atual de tal modo que seja possvel dis-tribuir as requisies entre estas mquinas. No caso dos dados, pode-se agrup-los porfunes e distribu-los por vrios SGBDs. Dessa forma, ocorre a fragmentao dos dadosem SGBDs em nuvem e cada um destes sistemas pode ser dimensionado de forma inde-pendente. Este tipo de escalabilidade oferece maior flexibilidade, mas necessita de umplanejamento especfico.

A escalabilidade envolvendo dados uma tarefa complexa, j que a maioria dosSGBDs em nuvem utiliza arquiteturas no compartilhadas, tornando a disposio dosdados um ponto chave. Pode-se pensar que adicionar dinamicamente um novo servidor de

banco de dados to simples como dividir os dados em mais um servidor. Por exemplo,se h dois servidores, cada um com 50% do total dos dados e se adiciona um terceiroservidor, poder-se-ia colocar um tero dos dados em cada servidor, fazendo com que cadaum dos trs servidores ficasse com 33% dos dados. Entretanto, no to simples assim,pois as consultas dos usurios envolvem dados relacionados em diferentes servidores, oque exige o transporte dos dados, diminuindo o desempenho do sistema. Por esta razo, afragmentao dos dados deve ser feita de forma a minimizar o transporte de dados, o qualadiciona um custo relevante ao processamento.

Em relao ao desempenho, as solues de gerenciamento de dados em nuvemdevem lidar com problemas de tempo de resposta, em virtude das diferentes tecnologias eheterogeneidade do hardware utilizado, o que pode influenciar o desempenho. Por exem-plo, uma falha de hardware, tais como problemas no acesso ao ncleo de uma mquinacom mltiplos cores ou a disputa por recursos no virtualizados, causa degradao dodesempenho de uma mquina do sistema. Se a carga de trabalho necessria para execu-tar uma consulta dividida igualmente entre as mquinas com configuraes diferentes,ocasiona um atraso no processamento, visto que o tempo para completar a consulta seraproximadamente igual ao tempo para a execuo da mquina com menor configuraopara completar a tarefa atribuda.

4.2.3.4. Tolerncia a Falhas e Distribuio de Dados

Diferentemente das abordagens anteriores, onde se procurou evitar falhas por meio dautilizao de hardware de custo elevado, as infraestruturas para nuvem so construdasem cima de hardware de baixo custo e com a suposio de que mquinas e redes podemfalhar. Dessa forma, as solues desenvolvidas devem lidar com falhas, j que estas iroocorrer em algum momento [Abadi 2009]. Para tratar as falhas, as solues em nuvemutilizam tcnicas que auxiliam a distribuio dos dados, tais como DHT, que facilita afragmentao dos dados. Por meio da fragmentao dos dados possvel melhorar adisponibilidade e distribuir a carga, tanto para operaes de escrita quanto de leitura. Seapenas uma mquina falhar, os dados pertencentes a essa mquina so afetados, mas noo armazenamento de dados como um todo.

Em relao ao processo de replicao, pode-se criar e iniciar novas rplicas rap-idamente por meio de mquinas virtuais [Soror et al. 2010]. Isso permite manter muitasrplicas por mquina, o que reduz a quantidade total de armazenamento e, portanto, oscustos associados. O processo de replicao pode ser realizado de forma sncrona ouassncrona ou uma combinao destas. Isso determina o nvel de consistncia, confia-bilidade e desempenho do sistema. Dentre os protocolos utilizados na replicao de da-dos pode-se destacar o de cpia primria, rplica ativa, quorum baseado em 2PC, Paxos[Chang et al. 2006] e o Gossip [DeCandia et al. 2007].

4.2.4. Classificao dos Sistemas de Gerenciamento de Dados em Nuvem

Existem diversos SGBDs em nuvem, cada um destes com caractersticas e propsitosespecficos. Com o objetivo de auxiliar o estudo destes sistemas e realizar um compar-ativo entre os mesmos, propomos uma classificao com base nos seguintes parmetros:

modelo relacional e nativo para nuvem. O primeiro parmetro se refere utilizao domodelo relacional pelo sistema e o segundo parmetro est relacionado ao processo deconstruo do sistema, ou seja, se o sistema foi concebido para atender as necessidadesda computao em nuvem. Os sistemas com modelos de dados em comum foram agrupa-dos de forma a facilitar a compreenso. Vale ressaltar que alguns destes sistemas possuemcaractersticas de mais de um modelo de dados. A Figura 4.8 apresenta essa classificaoe destaca alguns sistemas.

Figura 4.8. Classificao dos Sistemas de Gerenciamento de Dados em Nuvem

No primeiro quadrante esto os SGBDs relacionais desenvolvidos nativamentepara nuvem. Estes sistemas esto sendo concebidos considerando as caractersticas dacomputao em nuvem juntamente com aspectos do modelo relacional. O exemplo maisconhecido destes sistemas o Microsoft SQL Azure. No segundo quadrante esto SGBDsrelacionais que no foram concebidos para nuvem, mas que podem ser executados emuma infraestrutura baseada em nuvem. Como exemplo destes sistemas destacam-se oAmazon Relational Database Service (Amazon RDS) [Amazon 2010] e o RelationalCloud [Curino et al. 2010].

No terceiro quadrante esto os sistemas considerados nativos para nuvem que noutilizam o modelo relacional, tais como os sistemas que utilizam o modelo chave-valore baseado em coluna. Dentre os sistemas que utilizam o modelo chave-valor pode-sedestacar o Amazon Dynamo [DeCandia et al. 2007] e o Voldemort. BigTable, HBasee Cassandra so exemplos de sistemas baseados em coluna [NoSQL 2010]. No quartoquadrante esto os sistemas no-nativos que no utilizam o modelo relacional, tais comografo, documento ou XML. Estes sistemas esto sendo desenvolvidos para propsitosespecficos e utilizados em ambientes em nuvem. O Neo4j um exemplo dos sistemasbaseados em grafo e CouchDB e MongoDB so exemplos de sistemas orientados a docu-mento.

Os sistemas no-relacionais, coletivamente, iniciaram um movimento denomi-nado Not only SQL (NoSQL). NoSQL um termo genrico para uma classe definida deSGBDs no-relacionais que foram projetados para gerenciar grandes volumes de dados e,em geral, fornecem garantias de consistncia fraca, como consistncia eventual e utilizamestruturas e interfaces simples. Estes sistemas esto sendo utilizando principalmente emservios de hospedagem de stios, redes sociais e em outros servios especficos.

Segundo [Stonebraker 2010], o desempenho e a flexibilidade so duas razes parautilizar estes novos sistemas. Tratando-se do desempenho, o tempo total do Online Trans-action Processing (OLTP) est relacionando com quatro componentes: logging, bloqueio,latching e gerenciamento de buffer. Eliminando-se qualquer destes componentes de so-brecarga, pode-se melhorar o desempenho em 25%. Os sistemas NoSQL abordam al-guns destes componentes utilizando gerenciamento eficiente de buffer, novas arquiteturade thread, suporte para transaes em um nico registro e consistncia eventual. Dessaforma, o desempenho depende da remoo das sobrecargas e tem pouco a ver com o SQL,razo pela qual o termo NoSQL um equvoco, j que o desempenho est relacionandocom as implementaes tradicionais de transaes ACID, multithreading e o gerencia-mento de disco. Para melhorar o desempenho, as sobrecargas devem ser removidas e isso possvel no contexto SQL ou em qualquer outro contexto.

4.3. Sistemas para o Gerenciamento de Dados em NuvemExiste uma grande quantidade de SGBDs em nuvem e, assim, no possvel destacarcada um destes sistemas [Agrawal et al. 2010a]. A seguir destacamos alguns destes sis-temas e apresentamos uma anlise comparativa considerando diversas caractersticas dogerenciamento de dados.

4.3.1. Microsoft SQL Azure

O Microsoft SQL Azure composto por um conjunto de servios para o armazenamentoe processamento de dados em nuvem [Azure 2011]. O SQL Azure juntamente com oWindows Azure Storage compem a soluo de gerenciamento de dados em nuvem daMicrosoft. O Windows Azure Storage inclui armazenamento persistente por meio deblobs, tables e filas. Um blob um par nome, objeto que permite armazenar objetos deat 50 GB. Tables so diferentes das tabelas relacionais e so compostas de entidades.Elas no so acessadas usando a linguagem SQL, mas por servios de dados. J as filasfornecem um servio de troca de mensagens persistentes e confivel.

O SQL Azure Database (SAD) o principal componente do SQL Azure e foi con-strudo com base na tecnologia do SGBD relacional SQL Server. Para permitir uma inte-grao transparente de aplicaes com SQL Azure, o SAD suporta os principais coman-dos da linguagem Transact-SQL (T-SQL). Esta linguagem possui diversas caractersticas,dentre os quais podemos destacar tabelas, ndices, funes, procedimentos e gatilhos, en-tre outros. O gerenciamento do SQL Azure pode ser realizado por meio da ferramentadenominada Houston.

O SQL Azure implementa alta disponibilidade, tolerncia a falhas e o conceitode multi-inquilino. Cada banco de dados implementado como uma partio de dadosreplicados em mltiplas mquinas em um SQL Azure Datacenter. Com esse tipo de abor-

dagem, SQL Azure fornece um gerenciamento automtico de falhas e balanceamento decarga de trabalho. A estratgia de replicao utiliza trs cpias dos itens de dados parafornecer a disponibilidade e implementa consistncia forte. No SQL Azure Database, umbanco de dados individual possui um tamanho limitado a 50 GB. Para criar solues quearmazenem dados maiores do que este tamanho deve-se fragmentar grandes conjuntos dedados entre mltiplos bancos de dados e utilizar consultas em paralelo para acess-los.Entretanto, a fragmentao dos dados realizada de forma manual.

4.3.2. Amazon S3/SimpleDB

O Amazon Simple Storage Service (S3) um sistema de armazenamento distribudo de-senvolvido com base no Dynamo [DeCandia et al. 2007]. O Dynamo utiliza o modelopar chave-valor armazenados em uma DHT e no possui suporte a associaes ou esque-mas. Para garantir um nvel de escalabilidade e disponibilidade, de acordo com o teoremaCAP, o Dynamo relaxa a consistncia em alguns cenrios de falhas e faz uso de versesde objetos e resoluo de conflitos assistida por meio de uma interface para os desen-volvedores. No Dynamo, as operaes de leitura e escrita utilizam identificadores nicos,sendo realizadas sobre objetos binrios de at 5GB e no existe suporte s operaessobre mltiplos objetos. As propriedades das transaes ACID apresentam as seguintescaractersticas: atomicidade e isolamento so garantidos pela escrita de um nico objeto;durabilidade obtida por meio de escrita replicada e apenas a consistncia no forte. AAPI do Dynamo possui as operaes get() e put().

Escalabilidade, balanceamento de carga e suporte heterogeneidade foram aspec-tos enfatizados na concepo do Dynamo e tornam relativamente simples adicionar ns,distribuir as requisies e suportar ns com caractersticas diferentes. As propriedades desimetria e descentralizao so utilizadas de tal forma que todos os pontos so igualmenteresponsveis e com o objetivo de evitar pontos nicos de falhas. O Dynamo usa a tcnicade hashing consistente para prover a fragmentao e a replicao. Para tratar o problemade balanceamento de carga, decorrente da utilizao de poucos ns ou ns heterogneos, oDynamo utiliza a estratgia de ns virtuais, onde cada n fsico pode ter vrios ns virtuaisassociados. Dessa forma, mquinas com maior capacidade de processamento e armazena-mento podem ter uma maior quantidade de ns, sendo estes distribudos aleatoriamente.O Dynamo utiliza o protocolo Gossip para verificar se um n pertence ao sistema e paradeteco de falhas.

O Amazon S3 utiliza o conceito de objeto, entidade fundamental que consiste dedados, metadados e um identificador nico. Os objetos so organizados em buckets eestes servem para agrupar objetos ou espao de nomes. Para tratar a ocorrncia de falhas,os dados so propagados entre os centros de dados de forma postergada e o usurio podeespecificar a localizao geogrfica de um buckets. No S3, as operaes de escrita soatmicas, mas podem ser executadas sobre mltiplas chaves. Entretanto, este sistema nofornece mecanismos de bloqueio.

O SimpleDB um sistema de armazenamento hierrquico de dados construdopara superar as limitaes do S3. O SimpleDB possui atributos mltiplos, indexao esuporte a consultas. O armazenamento de dados livre de esquema, escalvel e eficientepara cenrios onde as operaes de leituras so predominantes, tais como fruns de dis-

cusso e backup. O modelo de dados do SimpleDB utiliza o conceito de domnios, quepodem ser comparados a uma tabela em SGBDs relacionais, com a diferena que umdomnio pode conter um conjunto diferente de atributos para cada item. Cada item podeter vrios valores para cada atributo. Os itens so identificados por domnio e os atributosso organizados na forma de par chave-valor, sem definio de tipo, ou seja, uma cadeiade caracteres indexados automaticamente. Para criar relacionamentos no SimpleDB, o de-senvolvedor pode desnormalizar seus dados ou tratar as relaes na camada de aplicao.O SimpleDB possui um linguagem de consultas semelhante ao SQL e suporta seleo,operadores, ordenao e contagens, mas uma consulta pode ser processada apenas emum domnio. O SimpleDB tem algumas restries em relao ao tamanho e nmero dedomnios, tempo da consulta, no permite junes e comparaes de itens dentro de umaconsulta, suporte a transaes, entre outros.

4.3.3. Bigtable/Google App Engine datastore

O BigTable um sistema de armazenamento de dados distribudo em larga escala. Elefunciona como um SGBDs orientado a colunas e utiliza o GFS para gerenciar os dados,podendo ser utilizado juntamente com o MapReduce para distribuir o processamento dosdados [Chang et al. 2006]. O BigTable no suporta um modelo relacional, mas forneceum modelo simples e flexvel. No modelo de dados do BigTable, uma tabela um mapaesparso, distribudo, persistente e multidimensional, organizado em trs dimenses: linha,coluna e timestamp, formando uma clula. Linhas com chaves consecutivas so agrupadasem tablets, que so unidades de distribuio e balanceamento de carga. As linhas so aunidade bsica de atomicidade e alteraes de uma nica linha so sempre transacionais.As colunas so agrupadas em famlias que formam a unidade de controle. Vrias versesde uma mesma clula podem ser armazenadas e indexadas pelo timestamp. BigTable nosuporta nenhum tipo de juno e relaes so gerenciadas na camada de aplicao.

O Bigtable tem trs componentes principais: uma biblioteca comum aos clientes,um servidor mestre e vrios servidores de tablets. O servidor mestre responsvel pordesignar tablets para os servidores de tablets, balanceamento de cargas e por gerenciaralteraes nos esquemas dos dados. Cada servidor de tablet responde s requisies deleituras e escritas nas tabelas e o servio de bloqueio denominado Chubby usado paraadministrar os servidores. O servio Chubby utiliza o protocolo baseado em quorumPaxos para resolver o problema de consenso distribudo e fornecer bloqueios exclusivospara os arquivos gerenciados. O BigTable fornecer consistncia forte, mas no replica obanco de dados diretamente, pois um tablet pode ser atribudo para apenas um servidorde tablet por vez. A replicao dos dados realizada por meio do GFS, que gerencia oarmazenamento dos tablets e dos arquivos de log.

O Google App Engine (GAE) datastore uma soluo de gerenciamento de dadosbaseado no BigTable. O GAE datastore utiliza um modelo de dados livre de esquema,suporta tipos de dados primitivos e armazena os objetos de forma serializada no BigTable.O GAE datastore suporta transaes realizadas sobre vrias entidades, mas exige que to-dos os objetos em uma transao estejam dentro do mesmo grupo de entidade. O GAEdatastore utiliza consistncia forte, similar ao BigTable. Muitos tipos de dados comunsso suportados no armazenamento de dados, incluindo String, int, float, e DateTime. OGAE datastore utiliza uma chave como identificador nico para atributos como linha,

links, entre outros e pode ser acessado com a linguagem de consulta Google Query Lan-guage (GQL), um subconjunto da linguagem SQL. A linguagem GQL possui suporte aseleo, ordenao e alguns operadores. A instruo de seleo pode ser realizada emuma nica tabela, ou seja, no suporta junes, assim como associaes ou chaves com-postas em decorrncia do modelo de dados utilizado. Dessa forma, associaes devemser implementadas na camada de aplicao.

4.3.4. CouchDB

O CouchDB um SGBD orientado a documento e livre de esquema [Apache 2010]. OCouchDB possui uma srie de caractersticas que torna sua utilizao vivel em servi-dores que possuem hardware de baixo desempenho e utiliza tcnicas de armazenamento econtrole de concorrncia baseadas na estrutura do documento. Este sistema foi implemen-tado utilizando a plataforma Erlang OTP devido nfase desta plataforma em tolernciaa falhas e oferece escalabilidade, disponibilidade e confiabilidade, mesmo ao executar emhardware que est sujeito falhas.

O CouchDB organizada os dados em documentos e cada um destes possui umidentificador nico. Cada documento pode ter qualquer quantidade de atributos e cadaatributo pode conter listas ou objetos. Os documentos so armazenados e acessados comoobjetos JavaScript Object Notation (JSON). Operaes de atualizao so executadas so-bre todo o documento e o CouchDB gerencia as alteraes por meio de um identificadorde reviso contido em cada documento. O CouchDB utiliza uma estrutura de arquivobaseada em rvores B+ para persistir os dados.

O CouchDB no utiliza os conceitos de tabela, chave, relacionamento ou juno.O modelo de consulta do CouchDB consiste nos conceitos de vises, que so construdasutilizando funes MapReduce e de uma API de consultas via http. Uma viso basi-camente uma coleo de pares chave-valor que, juntamente com o MapReduce permiteao usurio criar um programa de mapeamento e outro de reduo para filtrar e agregardados em uma base de documentos. O CouchDB implementa o protocolo de controlede concorrncia multi-verso (MVCC) adaptado para documento e utiliza o modelo deconsistncia eventual. Adicionalmente, o CouchDB possui um mecanismo incrementalde replicao com deteco e gerenciamento bi-direcional de conflitos.

4.3.5. Cassandra

Cassandra um sistema de armazenamento distribudo para o gerenciamento de grandesquantidades de dados espalhados por centenas de mquinas [Lakshman and Malik 2010].Este sistema foi desenvolvido para ter uma alta disponibilidade, consistncia eventual,escalabilidade incremental, replicao otimista e com baixo custo de administrao. Osistema Cassandra pode funcionar em hardware de baixo custo e lida com alta taxa deescrita sem sacrificar a eficincia na leitura. Por utilizar uma arquitetura distribuda, Cas-sandra no possui um ponto nico de falha. Este sistema tolerante a falhas e, com isso,aumenta a confiabilidade do sistema, j que os dados so automaticamente replicados emvrios ns de um ou mais centros de dados e o protocolo Gossip utilizado para tratar sfalhas. A vazo de operaes de leitura e escrita no sistema pode crescer linearmente enovas mquinas so adicionadas sem nenhum custo ou interrupo para as aplicaes.

Cassandra um hbrido que combina a arquitetura descentralizada do Dynamocom o modelo de dados do BigTable e possui uma API simples como meio de acessoaos dados. Cassandra possui um modelo de dados na forma de um hash de quatro oucinco dimenses: espao de chave, famlia de colunas, coluna, chave e super-coluna. Oespao de chave um local para as famlias de colunas e, tipicamente, definido umapor aplicao. Uma famlia de colunas o local para agrupar as colunas, assim comouma tabela em um SGBD relacional e acessada por meio de uma chave. Uma chave similar aos outros sistemas de armazenamento chave-valor. Uma super-coluna pode sercomparada a uma coluna que possui sub-colunas e utilizada para modelar tipos de dadoscomplexos.

A coluna a menor unidade de dados existente no modelo de dados do Cassandrae formada por uma tripla que contm um nome, um valor e um timestamp. Todos osvalores so fornecidos pelo usurio, incluindo o timestamp. Neste caso, os relgios dosusurios devem ser sincronizados, pois estes timestamps so usados para resoluo deconflitos. Uma famlia de colunas contm uma lista ordenada de colunas, que o usuriopode fazer referncia ao nome da coluna. Cada famlia de coluna armazenada em umarquivo separado e este arquivo classificado por uma chave, que determina qual dado armazenado na mquina. Cassandra determina os ns responsveis pelos dados e, quandoum usurio submete uma solicitao de escrita para um n aleatrio, as operaes deescrita so registradas e ento aplicadas a uma verso na mquina. Um log com as oper-aes consolidadas armazenado em um disco dedicado para a mquina. Para operaesde escrita no existem bloqueios e a atomicidade garantida pelo acesso por meio de umachave. Alm disso, as escritas so aceitas durante cenrios de falhas, o que aumenta adisponibilidade.

Cassandra no fornece ndices automaticamente e o usurio precisa definir soluespara melhorar o desempenho. Uma alternativa utilizar estratgias que envolvam famliade colunas por consulta. Com isso, possvel melhorar a organizao dos dados e min-imizar o esforo no acesso e no processamento de consultas. Cassandra tambm possuialgumas limitaes, como por exemplo, todos os dados de um nico registro devem per-tencer ao disco de uma mquina do cluster. Isso porque as chaves dos registros so uti-lizadas para determinar os ns responsveis por replicar dados. Outra limitao que ovalor de uma coluna no pode ultrapassar 2GB.

4.3.6. Relational Cloud

Relational Cloud um SGBD como um servio concebido com o objetivo de consolidaras funcionalidades de gesto de dados para grandes empresas e outsourcing do gerenci-amento de dados em nuvem para pequenas e mdias empresas [Curino et al. 2010]. ORelational Cloud prove disponibilidade por meio de replicao transparente, gerencia-mento automtico das cargas de trabalho e migrao de dados em tempo de execuo,alm de oferecer suporte a transaes distribudas serializveis.

O Relational Cloud foca na fragmentao e alocao dos dados, migrao de da-dos em tempo de execuo e anlise de carga de trabalho. Em relao fragmentao, oRelational Cloud prope um novo algoritmo com o objetivo de minimizar a probabilidadede uma determinada operao ter que acessar mltiplos ns para fornecer uma resposta.

A migrao em tempo de execuo obtida por meio de uma estratgia que prev quandouma adaptao ser necessria antes que algum n do sistema seja sobrecarregado. Paratanto, o deslocamento de pequenos conjuntos de dados realizada durante a execuo.A alocao e anlise de carga de trabalho so realizadas por meio de tcnicas estticas edinmicas de caracterizao da carga de trabalho, seleo de SGBDs, atribuio de cargasde trabalho para as instncias de banco de dados e atribuio de instncias de banco dedados para ns fsicos.

O Relational Cloud foi projetado para ser executado em mquinas em um nicocentro de dados. Cada mquina fsica executa vrias instncias de um SGBDs. Estasinstncias podem utilizar sistemas de armazenamento diferentes, visto que sistemas es-pecializados, em geral, so eficientes para tarefas especficas. Cada banco de dados dividido em parties lgicas por meio de tcnicas de fragmentao. Essas parties soarmazenadas em grupos de rplicas com o objetivo de garantir a disponibilidade e tolern-cia a falhas. Um grupo de rplica consiste de vrias instncias do banco de dados sendoque cada uma armazena cpia dos dados de uma partio lgica. A fragmentao dosdados e alocao dos grupos de rplicas nas mquinas so controladas pelo analisador decarga de trabalho.

A comunicao entre as aplicaes e o Relational Cloud realizada por meio deinterfaces padro ou protocolos conhecidos, tais como a interface JDBC. As consultasSQL recebidas so enviadas para um roteador, responsvel por analisar e verificar osmetadados do banco de dados e determinar o plano de execuo. Por fim, o sistema detransaes distribudas distribui a carga de trabalho, assegurando a serializabilidade e otratamento de falhas. Por meio do monitoramento constante de desempenho e carga detrabalho, o Relational Cloud ajusta a fragmentao dos dados e as opes de localizaoem tempo de execuo. Falhas no sistema e alteraes de carga de trabalho exigem aevoluo do esquema de fragmentao e alocao em tempo de execuo. Para tanto, necessria a migrao dos dados baseada nas instncias do mecanismo de armazena-mento, o que melhora o desempenho do sistema.

4.3.7. Outros Sistemas de Gerenciamento de Dados em Nuvem

4.3.7.1. Yahoo PNUTS

PNUTS um SGBD distribudo para aplicaes web desenvolvido pelo Yahoo. Este sis-tema apresenta diferentes nveis de consistncia, replicao para reas geograficamentedistantes, escalabilidade, tolerncia a falhas, alta disponibilidade e baixa latncia para umgrande nmero de requisies simultneas [Cooper et al. 2008]. Este sistema utiliza ummodelo de dados relacional simplificado, onde os dados so organizados em tabelas deregistros com atributos e permite uma estrutura arbitraria dentro de um registro, tais comblobs. O esquema de dados flexvel, j que um novo atributo pode ser adicionado semsuspender consultas ou atualizaes ativas e ter atributos vazios em um registro. PNUTSso possui integridade referencial, junes ou agregao. A linguagem de consulta su-porta seleo e projeo em uma tabela simples e atualizaes e excluses so realizadasapenas pela chave primria.

As rplicas so geograficamente distribudas em diversas regies. As tabelas so

fragmentadas horizontalmente, criando tablets, que apenas um grupo de registros deuma determinada tabela. Uma cpia de um tablet alocada em cada regio. As unidadesde armazenamento podem utilizar um sistema de arquivo ou MySQL. Roteadores de-finem mantem copia em cache dos mapeamentos internos para os tablets e controladoresde tablets gerenciam intervalo de mapeamento, tabelas fragmentadas e o balanceamentode carga. PNUTS fornece novas garantias de consistncia por registro, denominada con-sistncia timeline, um tipo de consistncia entre serializabilidade e consistncia eventual.Neste caso, todas as rplicas so atualizadas para um registro na mesma ordem. Uma r-plica sempre escolhida, por registro, como primria. As atualizaes so executadas narplica primria e propagadas de forma assncrona para as outras rplicas utilizando ummecanismo publish-subscribe. Operaes de leitura podem ser executadas em qualqueruma das rplicas ou na rplica primria, que contem informaes sobre as verses.

4.3.7.2. Neo4j

SGBD baseado na estrutura em grafo, com transaes ACID, ndices e integrao comlinguagens de programao. Este sistema permite gerenciar dados complexos e navegarentre os dados de forma simples e eficiente [Neo 2010].

4.3.7.3. Amazon Relational Database Service (RDS)

SGBD como um servio desenvolvido pela Amazon que disponibiliza todas as funcionali-dades de um SGBD relacional. Com o Amazon RDS, no necessrio instalar, configurare manter o sistema e pode-se escolher diferentes tamanhos de instncias [Amazon 2010].

4.3.8. Anlise Comparativa

Novos servios de dados em nuvem, como o GAE datastore, Amazon S3, SimpleDBe Cassandra utilizam modelos simplificados de dados baseados em par chave-valor ouorientados a coluna. Os dados so armazenados em estruturas otimizadas e acessados pormeio de APIs simples. GAE datastore, S3/SimpleDB, CouchDB no possuem suporte atransaes ACID. Cassandra utiliza um conceito simplificado de transaes para linhas[Candan et al. 2009]. Estes sistemas suportam apenas consistncia eventual, exceto oGAE datastore e todos apresentam alta escalabilidade e alta disponibilidade, menos oCouchDB que possui mdia escalabilidade, em decorrncia do modelo de dados utilizado.

GAE datastore, Amazon S3, SimpleDB e Cassandra apresentam bons resultadosna manipulao de grandes volumes de dados, pois os modelos de dados utilizados porestes sistemas favorecem a fragmentao dos dados. Contudo, em geral, estes sistemasno suportam operaes como junes, possuem apenas garantias de consistncia fraca efornecem suporte limitado a transaes. Alm disso, utilizando um modelo de dados maissimples, a complexidade empurrada para as demais camadas da aplicao, exigindo dosdesenvolvedores a adio de funcionalidades mais complexas nas camadas superiores.

CouchDB e sistemas baseados em grafo optaram por modelos mais ricos de dados.Com isso, eles apresentam abstraes poderosas que tornam mais fcil modelar domnioscomplexos. Estes modelos de dados mais ricos introduzem maior quantidade de ligao

entre os dados, o que prejudicar a escalabilidade. Vale ressaltar que estes sistemas aindaso muito recentes e existem poucos estudos detalhados sobre os mesmos, assim comoferramentas e tecnologias de apoio para sua ampla utilizao.

Caracterstica S3 Sim-pleDB

BigTableGAE

Cassandra CouchDB SQLAzure

RelationalCloud

Modelo Chave-valor Coluna Coluna Documento Relacional RelacionalArmazenamento Hash

consistentendices ndices rvore B+ Tabela Tabela

Linguagem deConsulta

API simples API simples API simples API simples SQL SQL

Transaes No No Sim simpli-ficada

No Sim Sim

Consistncia Eventual Forte Eventual Eventual Forte ForteEscalabilidade Alta Alta Alta Mdia Mdia BaixaDisponibilidade Alta Alta Alta Alta Alta Mdia

Tabela 4.4. Comparativo entre os Sistemas de Ger. de Dados em Nuvem

Os sistemas SQL Azure e Relational Cloud utilizam o modelo de dados relacional,que fornece grande flexibilidade no acesso aos dados, tais como agregao e consultascom junes. Eles implementam transaes ACID e garantia de consistncia forte, o quefacilita no desenvolvimento de aplicaes. Em relao escalabilidade e disponibilidade,SQL Azure e Relational Cloud apresentam caractersticas diferentes. O SQL Azure pos-sui mdia escalabilidade, j que no oferece suporte a transaes distribudas ou consul-tas atravs de mltiplas parties de dados localizados em diferentes ns, mas apresentaalta disponibilidade. O sistema Relational Cloud apresenta baixa escalabilidade e mdiadisponibilidade, pois se trata de um sistema em desenvolvimento e que no considera as-pectos de elasticidade e ambientes virtualizados, caractersticas essenciais da computaoem nuvem. O SQL Azure no possui suporte a fragmentao automtica de dados, essen-cial para melhorar a escalabilidade, mas o Relational Cloud apresenta iniciativas nestesentido. A Tabela 4.4 mostra um resumo deste comparativo.

importante ressaltar que os modelos de dados utilizados pelos sistemas de geren-ciamento de dados em nuvem so compatveis, ou seja, pode-se expressar um conjuntode dados em qualquer um deles. Por exemplo, possvel decompor todos os dados deum banco de dados relacional em uma coleo de par chave-valor. Dessa forma, exis-tem contextos onde cada um destes modelos de dados mais apropriado. De acordo com[Kossmann et al. 2010], os principais provedores tem adotado diferentes arquiteturas paraseus servios e o custo e o desempenho destes servios variam significativamente depen-dendo da carga de trabalho.

4.4. Desafios e Oportunidades de PesquisaA computao em nuvem apresenta diversas vantagens, mas tambm possui uma srie dedesafios que devem ser superados para sua ampla utilizao. A seguir destacamos algunsdestes desafios no contexto do gerenciamento de dados. Outros desafios envolvendo as-pectos gerais da computao em nuvem podem ser encontrados em [Armbrust et al. 2009]

[Sousa et al. 2009] [Zhang et al. 2010] .

4.4.1. Armazenamento e Processamento de Consultas

Com o aumento no volume de dados e dos requisitos para extrair valores a partir destes da-dos, empresas necessitam gerenciar e analisar uma grande quantidade de dados e forneceralto desempenho. Alm disso, os dados so gerenciados em vrias parties, o que difi-culta garantias transacionais, tais como atomicidade e isolamento. Para tratar estes proble-mas, diferentes solues tem sido desenvolvidas combinando tecnologias como o MapRe-duce ou SGBDs paralelos [Abouzeid et al. 2009]. Um desafio definir uma arquiteturapara paralelizar o processamento de consultas com nfase em consultas On Line Analyti-cal Processing (OLAP) expressas em SQL ou em novas linguagens [Olston et al. 2008].Esta arquitetura deve focar na interao entre o mecanismo de processamento de consul-tas e os sistemas de arquivos paralelos, tais como o HDFS e proporcionar diferentes nveisde isolamento.

O framework MapReduce e suas diversas implementaes como o Hadoop e oDrayd foram projetados para o processamento distribudo de tarefas e geralmente utilizamsistemas de arquivos como o GFS e o HDFS. Estes sistemas de arquivos so diferentes dossistemas de arquivos distribudos tradicionais em sua estrutura de armazenamento, padrode acesso e interface de programao. Em particular, eles no implementam a interfacepadro POSIX, e, portanto, apresentam problemas de compatibilidade com aplicaes esistemas de arquivos legados [Zhang et al. 2010]. Um ponto importante desenvolversolues para tratar a compatibilidade com os sistemas de arquivos distribudos tradi-cionais, tais como mtodos para suportar o framework MapReduce usando sistemas dearquivos para cluster e tcnicas para o acesso concorrente aos dados.

Em relao ao acesso aos servios de dados em nuvem, os provedores fornecemlinguagens com restries, APIs simples e estas apresentam muitas limitaes, tais comoa ausncia de consultas com junes, permitem apenas consultas por uma chave e nosuportam mltiplas chaves. Considerando a grande quantidade de servios de dadosem nuvem, os desenvolvedores necessitam utilizar APIs diferentes para cada servio.Isso exige mais esforo dos desenvolvedores e aumenta a complexidade na camada deaplicao. Um desafio fornecer uma API comum para vrios servios, assim comouma linguagem de consulta robusta e com diversas caractersticas dos SGBDs relacionais[Cooper et al. 2009]. Outros aspectos relevantes neste contexto esto relacionados otimiza-o e tuning de SGBDs em nuvem [Agrawal et al. 2008].

4.4.2. Escalabilidade e Consistncia

As solues em nuvem focam em escalabilidade e, em geral, oferecem consistnciafraca de dados, por exemplo, consistncia eventual. Este tipo de consistncia no per-mite a construo de uma ampla gama de aplicaes, tais como servios de pagamento eleiles online, que no podem trabalhar com dados inconsistentes [Wei et al. 2009]. Nestecontexto, aspectos de armazenamento de dados, processamento de consultas e controletransacional tm sido flexibilizados por algumas abordagens para garantir a escalabili-dade, mas ainda no existem solues que combinem estes aspectos de forma a melhoraro desempenho sem comprometer a consistncia dos dados [Abadi 2009]. De acordo com

[Armbrust et al. 2009], o desenvolvimento de um sistema de armazenamento que com-bine os diversos aspectos de computao em nuvem, de forma a aumentar a escalabili-dade, a disponibilidade e a consistncia dos dados um problema de pesquisa em aberto.Dessa forma, um desafio desenvolver solues escalveis e com consistncia forte.

Em [Wei et al. 2009] apresentado uma soluo com suporte a transaes ACIDe sem comprometer a escalabilidade mesmo na presena de falhas. Contudo, esta soluonecessita utilizar tcnicas de desnormalizao de esquemas, o que pode dificultar sua uti-lizao. [Yang et al. 2009] propem uma plataforma para o gerenciamento de dados quepode escalar para uma grande quantidade de pequenas aplicaes e fornecer consistnciaforte. Para tanto, vrias tcnicas de SGBDs, tais como replicao, migrao e gerencia-mento de SLA para garantir vazo e disponibilidade foram desenvolvidas.

4.4.3. SGBDs Virtualizados

A tecnologia de virtualizao tornou-se comum em modernos centros de dados e sis-temas de clusters [Soror et al. 2010]. Enquanto muitos SGBDs j esto sendo utilizadosem ambientes virtualizados, questes relacionadas utilizao destes sistemas ainda per-manecem em aberto [Rogers et al. 2010]. Uma vez que o uso de mquinas virtuais podeauxiliar a provisionar recursos, um desafio explorar a possibilidade de escalar SGBDspara tratar com cargas de trabalho inesperadas por meio da utilizao de novas rplicas emmquinas virtuais recm-provisionadas [Soror et al. 2010]. Com isso, necessrio garan-tir o acesso consistente ao SGBD durante e aps o processo de replicao, coordenarsolicitaes de roteamento para as mquinas virtuais antigas e novas, desenvolver polti-cas para a proviso de novas rplicas e modelos mais abrangentes para o planejamentoda capacidade necessria para a nuvem [Aboulnaga et al. 2009]. Tambm importantedesenvolver solues para otimizar as consultas em SGBDs executados em ambientesvirtualizados e ajustar os parmetros do banco de dados com a mquina virtual visandomelhorar a interao entre estes sistemas [Soror et al. 2010].

Outro ponto fundamental a alocao de recursos, j que as mquinas fsicastrabalham com apenas parte de sua capacidade. Estas mquinas poderiam ser melhor uti-lizadas, permitindo a reduo de custos. Uma questo relevante determinar a melhoralocao das aplicaes para as mquinas virtuais de acordo com mtricas que maxi-mizem a utilizao dos recursos. Em [Rogers et al. 2010] proposto uma soluo para aalocao de SGBDs em ambientes virtualizados. Entretanto, no so abordados aspectosrelacionados replicao dos dados.

4.4.4. Qualidade dos Servios de Dados

Em ambientes de computao em nuvem, a qualidade do servio uma caractersticadefinida entre o provedor e o usurio e expressa por meio de SLA. Com isso, o usuriodo servio tem algumas garantias, tais como desempenho e disponibilidade. Apesar daslimitaes de rede e segurana, as solues em nuvem devem fornecer elevado desem-penho, alm de serem flexveis para se adaptar diante de uma determinada quantidade derequisies. Como, em geral, os ambientes de computao em nuvem possuem acessopblico, torna-se imprevisvel e varivel a quantidade de requisies realizadas, dificul-tando fazer estimativas e fornecer garantias de QoS. As solues em nuvem necessitam

estimar mtricas de qualidade tendo como base o estado global do sistema e o histricode processamentos do mesmo. Entretanto, estimar mtricas de qualidade um fator de-safiador nestes ambientes, pois os recursos gerenciados esto, freqentemente, sendo ex-pandidos ou realocados com o intuito de melhorar o desempenho.

Uma questo relevante para garantir a qualidade em qualquer infraestrutura com-partilhada isolar o desempenho de aplicaes diferentes. Aplicaes podem adicionaruma carga varivel sobre a nuvem e necessrio verificar como esta carga de trabalhoir afetar as outras aplicaes que compartilham o mesmo hardware. Algumas abor-dagens para este problema utilizam quotas de recursos ou compartilhamento ponderado[Cooper et al. 2009]. Independente da abordagem utilizada, esta ter que garantir a qual-idade de servio, mesmo em condies extremas e com diferentes componentes da nu-vem. Tambm importante garantir a qualidade do servio de dados independente daforma de acesso. Por exemplo, o provedor deve fornecer um servio com garantias paraum usurio que acessa este servio por meio de um desktop ou de um dispositivo mvel.Para tanto, necessrio identificar a requisio e, caso necessrio, alocar mais recursosde forma a garantir o SLA com o usurio. Tcnicas adaptativas e dinmicas devero serdesenvolvidas para tornar os SGBDs em nuvem viveis [Aboulnaga et al. 2009], almde ferramentas e processos que automatizem tarefas tais como a alocao de recursos[Agrawal et al. 2008].

4.4.5. SGBDs Multi-Inquilino

No SGBD como um servio, os inquilinos acessam o sistema e compartilham recursos, oque pode interferir no desempenho do sistema. Dessa forma, o provisionamento de recur-sos deve ser eficiente, j que as cargas de trabalho dos SGBDs como um servio so muitovariveis, visto que os inquilinos podem acessar o sistema com maior freqncia em de-terminados momentos. Com a ampla utilizao de ambientes virtualizados, altamentecompartilhados, a questo do provisionamento torna-se determinante. A distribuio dosdados realizada por meio da fragmentao e da replicao e deve garantir que os dadosdos inquilinos no sejam perdidos e que a recuperao seja simples. Para tratar a recuper-ao, pode-se estender a linguagem de consulta de forma a permitir o acesso considerandoa distribuio