Captulo

4
Gerenciamento de Dados em Nuvem: Conceitos, Sistemas e Desaos 1 2
Flvio R. C. Sousa, Leonardo O. Moreira, Jos Antnio F. de Macdo e Javam C. Machado Universidade Federal do Cear (UFC)

Abstract Infrastructures, platforms and software are being offered as services, in cloud computing environments, with companies and users being able to rent computing power and storage in a transparent way and on-demand. These companies and users are moving their data and applications to the cloud so that they can access them anytime and anywhere. However, this new computing model requires signicant changes in data management systems, since these systems demand scalability, availability, performance and cost. This minicourse will introduce the main concepts and technologies in cloud computing, focusing on data management and systems, and point research challenges and opportunities in this context. Resumo Infraestruturas, plataformas e software esto sendo disponibilizados como servios, sendo estes fornecidos por ambientes de Computao em Nuvem, no qual empresas e usurios podem alugar capacidade de computao e armazenamento de forma transparente e sob demanda. Estas empresas e usurios esto movendo seus dados e aplicaes para a nuvem de forma a acess-los a qualquer momento e independente de localizao. Entretanto, este novo modelo de computao requer grandes mudanas nos sistemas de gerenciamento de dados, pois estes sistemas necessitam de escalabilidade, disponibilidade, desempenho e custo. Este minicurso tem como objetivo apresentar os principais conceitos e tecnologias de computao em nuvem, destacando o gerenciamento de dados e sistemas, alm de desaos e oportunidades de pesquisa neste contexto.
1 Publicado 2 Verso

no SWIB 2010. Todos os direitos reservados a Sociedade Brasileira de Computao. revisada e ampliada em Dezembro de 2011.

4.1. Introduo
Com o avano da sociedade humana moderna, servios bsicos e essenciais so quase todos entregues de uma forma completamente transparente. Servios de utilidade pblica como gua, eletricidade, telefone e gs tornaram-se fundamentais para nossa vida diria e so 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 qualquer hora, de forma que possamos simplesmente acender a luz, abrir a torneira ou usar o fogo. O uso desses servios , ento, cobrado de acordo com as diferentes polticas de tarifao para o usurio nal. Recentemente, a mesma ideia de utilidade tem sido aplicada no contexto da informtica e uma mudana consistente neste sentido tem sido feita com a disseminao 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 pagamento baseado no uso. Tendncias anteriores computao em nuvem foram limitadas a uma determinada classe de usurios ou focadas em tornar disponvel uma demanda especca de recursos de TI, principalmente de informtica [Buyya et al. 2009]. Computao em nuvem pretende ser global e prover servios para as massas que vo desde o usurio nal que hospeda seus documentos pessoais na Internet at empresas que terceirizam toda infraestrutura de TI para outras empresas. Nunca uma abordagem para a utilizao real foi to global e completa: no apenas recursos de computao e armazenamento so entregues sob demanda, mas toda a pilha de computao pode ser aproveitada na nuvem. A computao em nuvem surge da necessidade de construir infraestruturas de TI complexas, onde os usurios tm que realizar instalao, congurao e atualizao de sistemas de software. Em geral, os recursos de computao e hardware so propensos a carem obsoletos rapidamente e a utilizao de plataformas computacionais de terceiros uma soluo inteligente para os usurios lidarem com a infraestrutura 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 sobre a tecnologia utilizada. Desse modo, os usurios e as empresas passaram a acessar os servios sob demanda e independente de localizao, o que aumentou a quantidade de servios disponveis. Com isso, os usurios esto movendo seus dados e aplicaes para a nuvem e assim podem acess-los de forma simples e de qualquer local. Isso novamente um caso de utilizao de processamento centralizado. Cenrio semelhante ocorreu h aproximadamente 50 anos: um servidor de tempo compartilhado acessado por vrios usurios. Contudo, nas ltimas dcadas, quando os computadores pessoais surgiram, os dados e as aplicaes comearam 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 limitao de recursos. J a computao em nuvem surge da necessidade de construir infraestruturas de TI complexas, onde os usurios tm que realizar instalao, congurao e atualizao de sistemas de software. Alm disso, recursos de computao e hardware so propensos a carem obsoletos rapidamente. Assim, a utilizao de plataformas computacionais de terceiros uma soluo inteligente para os usurios lidarem com infraestrutura 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 sobre a tecnologia utilizada. Assim, os usurios e empresas passaram a acessa os servios sob demanda e independente de localizao, o que aumentou a quantidade de servios disponveis [Buyya et al. 2009]. Sistemas de gerenciamento de banco de dados (SGBDs) 3 so candidatos potenciais para a implantao em nuvem. Isso ocorre porque, em geral, as instalaes destes sistemas so complexas e envolvem uma grande quantidade de dados, ocasionando um custo elevado, tanto em hardware quanto em software. Para muitas empresas, especialmente para start-ups e mdias empresas, o pagamento baseado no uso do modelo de computao em nuvem, juntamente com o suporte para manuteno do hardware muito atraente [Abadi 2009]. No nal de 2010, a empresa Embarcadero realizou um survey [Embarcadero 2010] sobre tendncia, principais iniciativas, ferramentas atuais e desaos de banco de dados realizado com prossionais de banco de dados de grandes organizaes. Este survey destacou que as tecnologias de banco de dados em nuvem e virtualizao tero o maior impacto 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 banco de dados em nuvens. Embora SGBDs em nuvem tenham reduzido o custo de armazenamento de dados e melhorado o acesso, existe uma enorme complexidade envolvida com os servios de dados que possam escalar quando necessrio garantir operaes consistentes e conveis considerando cargas de trabalho mximas. Alm disso, o ambiente em nuvem tem requisitos tcnicos para controlar centros de dados virtualizados, reduzindo os custos e aumentando a conabilidade por meio da consolidao de sistemas em nuvem. Desaos tais como consistncia e segurana dos dados so importantes para a computao em nuvem e acredita-se que futuras aplicaes centradas em dados iro alavancar os servios de dados em nuvem. Esta seo apresenta as denies, as caractersticas essenciais da computao em nuvem e os modelos de servio e implantao. A seo 4.2 caracteriza o gerenciamento de dados em nuvem e a seo 4.3 apresenta os principais sistemas de gerenciamento de dados em nuvem. A seo 4.4 discute alguns desaos do gerenciamento de dados em nuvem. Finalmente, a seo 4.5 apresenta as concluses nais. 4.1.1. Computao em Nuvem A computao em nuvem est se tornando uma das palavras chaves da indstria de TI. A nuvem uma metfora para a Internet ou infraestrutura de comunicao entre os componentes arquiteturais, baseada em uma abstrao que oculta complexidade da infraestrutura. Cada parte desta infraestrutura provida como um servio e, estes so normalmente alocados em centros de dados, utilizando hardware compartilhado para computao e armazenamento [Buyya et al. 2009]. A infraestrutura do ambiente de computao em nuvem normalmente composta por um grande nmero, centenas ou milhares de mquinas fsicas ou ns fsicos de baixo
3 SGBD

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 fsica tem as mesmas conguraes de software, mas pode ter variao na capacidade de hardware em termos de CPU, memria e armazenamento em disco [Soror et al. 2010]. Dentro de cada mquina fsica existe um nmero varivel de mquinas virtuais (VM) ou ns virtuais em execuo, de acordo com a capacidade do hardware disponvel na mquina fsica. Os dados so persistidos, geralmente, em sistemas de armazenamento distribudos.

Figura 4.1. Ambiente de Computao em Nuvem

A computao em nuvem uma evoluo dos servios e produtos de tecnologia da informao 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 provedores especializados com um baixo custo por unidade utilizada. Usurios de servios baseados em Utility Computing no precisam se preocupar com escalabilidade, pois a capacidade de armazenamento fornecida praticamente innita. A Utility Computing prope fornecer disponibilidade total, isto , os usurios podem ler e gravar dados a qualquer tempo, sem nunca serem bloqueados; os tempos de resposta so quase constantes e no dependem do nmero de usurios simultneos, do tamanho do banco de dados ou de 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 os dados disponveis em tempo hbil por meio de rplicas [Brantner et al. 2008]. Uma razo importante para a construo de novos servios baseados em Utility Computing que provedores de servios que utilizam servios de terceiros pagam apenas pelos recursos que recebem, ou seja, pagam pelo uso. No so necessrios investimentos iniciais em TI e o custo cresce de forma linear e previsvel com o uso. Dependendo do modelo do negcio, possvel que o provedor de servios repasse o custo de armazenagem, computao e de rede para os usurios nais, j que realizada a contabilizao do uso. Existem diversas propostas para denir o paradigma da computao em nuvem [Vaquero et al. 2009]. O National Institute of Standards and Technology (NIST) argumenta que a computao em nuvem um paradigma em evoluo e apresenta a seguinte denio: Computao em nuvem um modelo que possibilita acesso, de modo conveniente e sob demanda, a um conjunto de recursos computacionais congurveis (por exemplo, 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 modelos de implantao, detalhados a seguir. 4.1.1.1. Caractersticas Essenciais As caractersticas essenciais so vantagens que as solues de computao em nuvem oferecem. Algumas destas caractersticas, em conjunto, denem exclusivamente a computao em nuvem e fazem a distino com outros paradigmas. Por exemplo, a elasticidade rpida de recursos, amplo acesso e a medio de servio so caractersticas bsicas para compor uma soluo de computao em nuvem. Self-service sob demanda: O usurio pode adquirir unilateralmente recurso computacional, como tempo de processamento no servidor ou armazenamento na rede, na medida em que necessite e sem precisar de interao humana com os provedores de cada servio. Amplo acesso: Recursos so disponibilizados por meio da rede e acessados atravs de 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 em um pool para servir mltiplos usurios usando um modelo multi-tenant ou multiinquilino, com diferentes recursos fsicos e virtuais, dinamicamente atribudos e ajustados de acordo com a demanda dos usurios. Estes usurios no precisam ter conhecimento da localizao fsica dos recursos computacionais, podendo somente especicar 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, em alguns casos automaticamente, caso haja a necessidade de escalar com o aumento da demanda, e liberados, na retrao dessa demanda. Para os usurios, os recursos disponveis para uso parecem ser ilimitados e podem ser adquiridos em qualquer quantidade e a qualquer momento. Servio medido: Sistemas em nuvem automaticamente controlam e otimizam o uso de recursos por meio de uma capacidade de medio. A automao realizada em algum nvel de abstrao apropriado para o tipo de servio, tais como armazenamento, processamento, largura de banda e contas de usurio ativas. O uso de recursos pode ser monitorado e controlado, possibilitando transparncia para o provedor e o usurio do servio utilizado. 4.1.1.2. Modelos de Servios O ambiente de computao em nuvem composto de trs modelos de servios. Estes modelos so importantes, pois eles denem um padro arquitetural para solues de com-

putao em nuvem. Software como um Servio (SaaS): O modelo de SaaS proporciona sistemas de software com propsitos especcos que so disponveis para os usurios por meio da Internet e acessveis a partir de vrios dispositivos do usurio por meio de uma interface thin client como um navegador Web. No SaaS, o usurio no administra ou controla a infraestrutura subjacente, incluindo rede, servidores, sistema operacional, armazenamento ou mesmo as caractersticas individuais da aplicao, exceto conguraes especcas. Como exemplos de SaaS podemos destacar os servios de Customer Relationship Management (CRM) da Salesforce e o Google Docs. Plataforma como um Servio (PaaS): O modelo de PaaS fornece sistema operacional, linguagens de programao e ambientes de desenvolvimento para as aplicaes, auxiliando a implementao de sistemas de software. Assim como no SaaS, o usurio no administra ou controla a infraestrutura subjacente, mas tem controle sobre as aplicaes implantadas e, possivelmente, as conguraes de aplicaes hospedadas nesta infraestrutura. Google App Engine [Ciurana 2009] e Microsoft Azure [Azure 2011] so exemplos de PaaS. Infraestrutura como um Servio (IaaS): A IaaS torna mais fcil e acessvel o fornecimento de recursos, tais como servidores, rede, armazenamento e outros recursos de computao fundamentais para construir um ambiente de aplicao sob demanda, que podem incluir sistemas operacionais e aplicativos. Em geral, o usurio no administra ou controla a infraestrutura da nuvem, mas tem controle sobre os sistemas operacionais, armazenamento, aplicativos implantados e, eventualmente, seleciona componentes de rede, tais como rewalls. 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 para os ambientes de computao em nuvem. A restrio ou abertura de acesso depende do processo de negcios, do tipo de informao e do nvel de viso desejado. Nuvem privada: a infraestrutura de nuvem utilizada exclusivamente por uma organizao, sendo esta nuvem local ou remota e administrada pela prpria empresa ou por terceiros. Nuvem pblica: a infraestrutura de nuvem disponibilizada para o pblico em geral, sendo acessado por qualquer usurio que conhea a localizao do servio. Nuvem comunidade: fornece uma infraestrutura compartilhada por uma comunidade de organizaes com interesses em comum. Nuvem hbrida: a infraestrutura uma composio de duas ou mais nuvens, que podem ser do tipo privada, pblica ou comunidade e que continuam a ser entidades

nicas, mas conectadas por meio de tecnologia proprietria ou padronizada que permite a portabilidade de dados e aplicaes. 4.1.2. Multi-Inquilino O termo multi-inquilino um dos principais conceitos relacionados a SaaS. Um inquilino em um cenrio de SaaS um usurio que utiliza SaaS. Ele refere-se ao uso do mesmo software e instncias por vrios usurios e empresas de forma simultnea. O objetivo dessa abordagem disponibilizar os mesmos recursos de software para um nmero maior de usurios. Esta abordagem baseada no conceito da Cauda Longa [Microsoft 2010], utilizada por diversas empresas de internet que conseguem obter renda tanto com produtos de nicho como produtos tradicionais. Com o seu artigo The Long Tail, o escritor Chris Anderson popularizou a idia da longa cauda ao explicar por que os varejistas on-line como Amazon.com esto posicionados de uma forma singular para atender uma imensa demanda que os varejistas tradicionais no podem atender de uma maneira econmica. Os fornecedores de solues complexas de software de linha de negcios se defrontam com uma curva de mercado semelhante. A Figura 4.2 mostra este cenrio.

Figura 4.2. Grco da Cauda Longa

A primeira parte do grco refere-se a grandes clientes e a segunda parte a clientes tpicos. A terceira parte trata-se de uma grande quantidade de pequenos clientes que devido diminuio dos custos podem utilizar software como um servio. O grco demonstra que, conforme diminui-se o custo de adoo, um nmero maior de clientes pode adotar uma soluo, sendo que este nmero tende ao innito, uma vez que a curva no toca o eixo x. Assim, no modelo SaaS de fornecimento de software, precisa-se desenvolver solues e infraestruturas de baixo custo, com alto aproveitamento de recursos por um nmero muito grande de usurios, para assim atingir um pblico no suportado hoje em dia, 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, por

demanda, o que deve gerar um valor muito baixo de pagamento. Neste contexto, procurase o chamado milhes de mercados de poucos ao invs dos atuais poucos mercados de milhes. Um ponto importante no modelo de SaaS o apoio para vrios inquilinos. A m de explorar economias de escala, ou seja, permitir que um provedor ou desenvolvedor de SaaS oferea a mesma instncia de um aplicativo SaaS para vrios inquilinos, a aplicao deve ser multi-inquilino consistente. Multi-inquilino consciente signica que cada inquilino 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 qualidade de uma soluo multi-inquilino. De acordo com o nvel de implementao do conceito de multi-inquilino, pode-se denir a maturidade do SaaS. A Figura 4.3 mostra o modelo de maturidade SaaS, sobre a evoluo do suporte multi-inquilino [Microsoft 2010]. Em cada quadrante possvel observar as diferenas em relao ao suporte multi-inquilino: ad-hoc/personalizado congurvel, congurvel e eciente para vrios inquilinos e escalonvel, congurvel e eciente para vrios inquilinos, respectivamente.

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

No primeiro quadrante, existe um software destinado para cada inquilino. Isso garante o atendimento das demandas do usurio, mas custo elevado devido a grande customizao e disponibilidade de recursos individuais. O segundo quadrante apresenta uma nica soluo destinada para todos os inquilinos separadamente. Neste caso, no h nenhuma customizao presente, garantindo menor custo de manuteno. No terceiro quadrante, existe uma nica soluo para todos os inquilinos e, diferente do quadrante dois, esse soluo nica e disponivel para todos. Neste caso, uma soluo multi-inquilino, onde ocorre total compartilhamento de recursos.No quarto quadrante, o atendimento diferenciado para inquilinos que exigem elevada demanda de

recursos, havendo uma carga balanceada na infra-estrutura do provedor da soluo SaaS. A m de permitir aplicaes multi-inquilinos, a aplicao deve ser dividida em duas partes diferentes. A primeira parte da aplicao descreve os artefatos que so xos e podem ser usados por todos os inquilinos. A segunda parte descreve a parte exvel, correspondente s conguraes e denominada metadados. Em relao aos dados, estes podem ser gerenciados de diversas formas, discutidas ao nal deste texto.

4.2. Gerenciamento de Dados em Nuvem

SGBDs em nuvem esto comeando a ser utilizados e tm o potencial de atrair clientes de diversos setores do mercado, desde pequenas empresas com o objetivo de reduzir o custo total, por meio da utilizao de infraestrutura e sistemas de terceiros, at grandes empresas que buscam solues que para gerenciar milhares de mquinas e permitir o atendimento de 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 cargas de trabalho reais, (ii) complexidade tcnica reduzida, graas a interfaces de acesso unicado e a delegao de tuning e administrao de SGBDs e (iii) a elasticidade e escalabilidade, proporcionando a percepo de recursos quase innitos. Por outro lado, o provedor tem que garantir (i) a iluso de recursos innitos, sob cargas de trabalho dinmicas e (ii) minimizar os custos operacionais associados a cada usurio [Curino et al. 2010]. Diversos sistemas e arquiteturas esto sendo desenvolvidos para suprir as novas demandas de aplicaes com diferentes requisitos de processamento e armazenamento [Abouzeid et al. 2009]. Estes novos sistemas tentam fornecer uma viso de armazenamento e escalabilidade innitos, mas tem que tratar o problema de provisionar recursos. Este problema, que em SGBDs tradicionais consiste em determinar quais recursos so alocados para um nico banco de dados, no ambiente em nuvem torna-se um problema de otimizao, onde se tem uma grande quantidade de usurios, mltiplos SGBDs em nuvem e grandes centros de dados. Isso fornece uma oportunidade sem precedentes para explorar a economia em escala, balanceamento dinmico de carga e gerenciamento de energia. Esse aumento no nmero de abordagens disponveis de SGBDs em nuvem agrava o problema da escolha, implantao e solues de administrao para a gesto de dados. Com isso, os SGBDs em nuvem esto sendo disponibilizados como servios, que encapsulam a complexidade do gerenciamento por meio de formas de acesso simples e garantias de acordos de nvel de servio (SLAs). 4.2.1. Requisitos para o Gerenciamento de Dados em Nuvem A denio 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 da perspectiva do usurio, do provedor e requisitos adicionais relacionados nuvem pblica conforme apresenta a Tabela 4.1. Da perspectiva do usurio, a principal necessidade um servio de banco de dados com uma interface simples que no necessite de ajuste ou administrao. Trata-se de uma melhoria em relao s solues tradicionais que requerem tcnicas para provi-

U1 U2 U3 U4 P1 P2 P3 P1 P2 P3

Requisitos do Usurio API simples com pouca congurao e administrao (ex. sem tuning) Alto desempenho (ex. vazo, escalabilidade) Alta disponibilidade e conana (ex. hot stand-by, backup) Acesso fcil caractersticas avanadas (ex. snapshot, evoluo de esquema, minerao de dados) Requisitos do Provedor Atender o SLA do usurio (ex. potencialmente sob carga de trabalho dinmica) Limitar hardware e custo de energia (ex. multiplexao intensiva) Limitar custo de administrao (ex. custo com pessoal) Requisitos extra de Nuvem Pblica Esquema de preo: barato, previsvel e proporcional ao uso (elasticidade) Garantias de segurana e privacidade Baixa latncia (relevante para OLTP e aplicaes Web) Tabela 4.1. Requisitos para SGBD como um Servio [Curino et al. 2010]

sionar recursos, seleo de SGBDs em nuvem, instalao, congurao 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. Atualmente, esta uma tarefa difcil que exige uma ampla anlise do pessoal de TI, software caro e atualizaes de hardware. Alta disponibilidade outro requisito fundamental, que normalmente oferecido pelos SGBDs tradicionais, mas exige cuidados de congurao e manuteno. Finalmente, as caractersticas avanadas de gerenciamento do banco de dados, tais como snapshot, evoluo de esquema e minerao de dados devem estar prontamente 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 ser eciente na utilizao dos recursos de hardware. O modelo de servio proporciona a oportunidade de fazer isso, por multiplexao de cargas de trabalho e ajuste dinmico da alocao de recursos. Finalmente, a quantidade de tarefas de administrao deve ser minimizada. Para tanto, ferramentas sosticadas de anlise de carga de trabalho e centralizao do gerenciamento de muitos bancos de dados devem ser utilizadas. Para provedores de servios em nuvem pblica, existem requisitos adicionais, tais como esquema de preo, segurana, privacidade e latncia. Entretanto, estas questes no so especcas de bancos de dados e podem ser abordadas com tcnicas em desenvolvimento pela comunidade 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 Bancos de Dados como um Servios (DaaS) e diversos desaos de pesquisa foram impostos comunidade de banco de dados, incluindo, por exemplo, segurana, gerenciamento de recursos compartilhados e a extensibilidade. Devido a estas necessidades, os DaaS esto surgindo como um novo paradigma para a gesto de dados em ambientes corporativos, 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 congurao das bases de dados, esquemas, carga de dados no servio de dados e interfaces padronizadas de interao com a base. As atividades de gerenciamento dos aplicativos de banco de dados e dos custos so transferidos do usurio para o provedor de servios. A Figura 4.4 exibe a organizao entre usurios e provedor de DaaS.

Figura 4.4. Banco de Dados como um Servio

De acordo com a gura, cada inquilino contrata os servio fornecido pelo provedor. Este provedor mantem um conjunto de banco de dados hospedados, em geral, em centros de dados.O provedor deve garantir aspectos de disponibilidade, desempenho e qualidade do servio denidos em SLA. Do ponto de vista crtico essa organizao oferece uma srie de benefcios aos usurios, 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 para fornecer o servio de dados. Um outro ponto importante que o provedor de servios garante a QoS requerida pelo usurio. A prpria arquitetura distribuda fornece conabilidade no tocante replicao de recursos. Um sistema de banco de dados multi-inquilino deve oferecer esquemas que sejam exveis em dois aspectos [Aulbach et al. 2008]. Primeiro, deve ser possvel estender o esquema base para suportar mltiplas verses do aplicativo, por exemplo, para regies geogrcas distintas. Uma extenso pode ser privada para um inquilino individualmente ou compartilhada por vrios inquilinos. Em segundo lugar, deveria ser possvel evoluir de forma dinmica o esquema base e suas extenses, enquanto o banco de dados est em execuo. Evoluo de uma extenso deve ser totalmente self-service: o provedor de servio no deve ser envolvido; caso contrrio os custos operacionais sero muito altos. Jacobs e Aulbach [Jacobs and Aulbach 2007] armam que um sistema de banco

de dados multi-inquilino pode compartilhar mquinas, processos e tabelas. De acordo 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, cada uma 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 de servios executa instncias do banco de dados independente para servir inquilinos independentes, 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 interao com 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 multiinquilino, sendo inteiramente construda em cima dos atuais banco de dados sem nenhuma extenso. Ela fornece um bom nvel de isolamento dos dados e segurana. No entanto, esta abordagem pode apresentar um alto custo de manuteno. Para gerenciar diversas instncias de banco de dados, o provedor de servio precisa realizar muito trabalho de congurao. Outro ponto importante a escalabilidade, j que o nmero de instncias de banco de dados cresce linearmente com o nmero de inquilinos. Tcnicas de virtualizao podem ajudar a minimizar alguns problemas destas abordagem, visto que estas tcnicas otimizam os recursos de hardwares e facilitam a congurao e administrao de sistemas de banco de dados. Tabelas Independentes e Instncia de Banco de Dados Compartilhados Nesta abordagem, os inquilinos compartilham o hardware e instncias de banco de dados. O provedor de servios mantm uma grande base de dados compartilhada e serve todos os inquilinos. Cada inquilino utiliza esquemas privados do banco de dados compartilhado. Cada nome de estrutura privada possui um identicador para indicar quem o proprietrio da tabela. Quando uma consulta submetida, esta reescrita de forma a

identicar o nome das tabelas modicadas e obter as respostas corretas. Esta reescrita pode 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 instncias. Entretanto, o nmero de estruturas privadas no banco de dados compartilhado cresce linearmente com o nmero de inquilinos. Assim, a escalabilidade desta abordagem est limitada ao nmero de estruturas que o SGBD pode manipular e da memria disponvel. Tabelas Compartilhadas e Instncia de Banco de Dados Compartilhados Nesta abordagem os inquilinos compartilham tabelas e instncias do banco de dados. Na fase de congurao do servio, o provedor de servios inicializa o banco de dados compartilhado criando tabelas vazias de acordo com o esquema base. Os inquilinos armazenam suas tuplas em tabelas compartilhadas anexando um identicador a cada tupla, que indica a qual inquilino a tupla pertence e dene os atributos no utilizados com NULL. Para recuperar as tuplas na tabela compartilhada, um roteador de consultas usado para reformular as consultas de acordo com o identicador. A Figura 4.7 ilustra esta abordagem. Nesta abordagem, o provedor de servio mantm apenas uma instncia de banco de dados simples, o que reduz o custo de manuteno. Alm disso, o nmero de tabelas do banco de dados determinado pelo esquema base, sendo independente do nmero de inquilinos, o que fornece melhor escalabilidade. Entretanto, esta abordagem apresenta algumas desvantagens, tais como a necessidade de indexao e otimizao, j que os inquilinos compartilham as mesmas tabelas, mas apresentam requisitos diferentes. Tambm no existem estudos detalhados referentes aos aspectos de isolamento do banco de dados e segurana neste contexto.

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

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 anlises dos dados e suporte a deciso. Esta primeira classe pode ser dividida em duas subclasses: uma em que o objetivo do sistema apoiar uma nica aplicao, com grandes quantidades de dados e outro no qual o objetivo do sistema apoiar um grande nmero de aplicaes, cada uma com pequenas quantidades de dados [Agrawal et al. 2010b]. Alguns trabalhos destacam caractersticas especcas do gerenciamento de dados em nuvem. Segundo [Voicu and Schuldt 2009], no ambiente em nuvem, os dados so gerenciados em poucos centros de dados, utilizando recursos homogneos e, mais recentemente, recursos heterogneos. Estes dados so acessados por meio de APIs simples, SQL ou variaes. Os SGBDs em nuvem devem suportar atualizaes concorrentes e transaes ACID ou variaes. Em relao replicao, esta deve ser transparente para os usurios e fornecer garantias de qualidade de servio, obtidas pela criao de rplicas dos dados em um mesmo centro de dados ou em centros de dados diferentes, alm de permitir granulosidade na dos dados. Na distribuio de dados, os SGBDs em nuvem podem apresentar um controle global central ou distribudo, devem fornecer escalabilidade 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 automaticamente recongurados, orquestrados e estas modicaes so apresentadas ao usurio como uma imagem nica. possvel identicar trs diferenas em comparao com os sistemas tradicionais: interveno humana limitada, alta alternncia na carga de trabalho e uma variedade de infraestruturas compartilhadas [Agrawal et al. 2008]. Na maioria dos casos, no haver administradores de SGBDs em nuvem ou de sistemas para ajudar os desenvolvedores que acessam um banco de dados em nuvem, fazendo com que a soluo seja automatizada ao mximo. Os usurios podem variar a carga de trabalho habitual, necessitando de uma infraestrutura ecaz, pois esta ser compartilhada por vrios usurios ou

Distribuio Ambiente Operaes para acesso aos dados Atualizao Transaes Replicao Granulosidade da Replicao Controle Global Alteraes Dinmicas

Poucos centros de dados Recursos homogneos em centros de dados API simples, SQL ou variaes Suporte s atualizaes concorrentes ACID ou variaes Garantia de QoS e transparncia Fina Central ou Distribudo Escalabilidade e suporte para cargas de trabalho inesperadas

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

inquilinos. De forma a possibilitar a consolidao da computao em nuvem e dos SGBDs em nuvem, tcnicas de virtualizao tm se tornando populares para a implantao destes sistemas e de outros sistemas de software [Soror et al. 2010]. A virtualizao apoia a consolidao dos recursos nas empresas, pois permite que uma variedade de aplicaes que funcionam com recursos de computao dedicados sejam movidos para um pool de recursos compartilhados, o que ajuda a melhorar a utilizao dos recursos fsicos, simplicar a administrao e reduzir custos para a empresa. Em [Soror et al. 2010] apresentado um 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 a virtualizao introduz pouca sobrecarga para chamadas de sistema, tratamento de falta de pginas e operao de E/S no disco e isto no traduzido em alta sobrecarga no tempo de execuo da consulta. Chamadas de sistema e falta de pginas representam uma pequena frao no tempo de execuo de uma consulta. Operaes de E/S no disco correspondem a uma frao signicativa do tempo, mas o retardo no muito. Os resultados apresentados mostram que a sobrecarga mdia menor do que 10%. Associado virtualizao, o compartilhamento de infraestruturas entre inquilinos no gerenciamento de dados possibilita uma utilizao eciente dos recursos e com baixo custo de operao, alm de permitir que os SGBDs em nuvem possam gerenciar 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 aplicaes de mltiplos inquilinos em um nico sistema frequentemente utilizada para eliminar a necessidade de sistemas separados para cada inquilino. Por exemplo, um inquilino pode ser um usurio utilizando uma aplicao que acessa um SGBD ou um SGBD instalado em uma infraestrutura. SGBDs multi-inquilino tem sido utilizado para hospedar mltiplos inquilinos dentro de um nico sistema, permitindo o compartilhamento ecaz de recursos em diferentes nveis de abstrao e isolamento. Existem vrios modelos de multi-inquilino e estes podem compartilhar desde mquinas at tabelas. Por exemplo, a empresa Salesforce utiliza o modelo de tabela compartilhada [Weissman and Bobrowski 2009] enquanto [Soror et al. 2010] utilizam o mo-

delo de mquina virtual compartilhada para melhorar a utilizao dos recursos. Algumas caractersticas do gerenciamento de dados em nuvem aumentam a relevncia de outros modelos de SGBDs multi-inquilino. Para melhorar a compreenso destes modelos, [Reinwald 2010] prope uma nova classicao, como mostra a Tabela 4.3.
Modo de Compartilhamento 1. Hardware 2. Mquina Virtual 3. Sistema Operacional 4. Instncia 5. Banco de Dados 6. Tabela Isolamento VM Usurio SO Instncia do BD BD Esquema Linha IaaS PaaS SaaS

x x x x x x

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

Os modelos correspondentes s linhas 1-3 compartilham recursos nos nveis das mesmas mquinas fsicas com diferentes nveis de abstrao, por exemplo, mltiplas VMs, contas de usurios diferentes e diferentes instncias do SGBDs. Neste caso no existe compartilhamento de recursos de banco de dados e as instncias do SGBDs se mantm independentes. As linhas 4-6 envolvem o compartilhamento de processos de banco de dados em vrios nveis de isolamento, tais como diferentes banco de dados, esquema ou tablespace e linha. Nos diferentes modelos, os dados dos inquilinos so armazenados de vrias formas. O modelo de hardware compartilhado utiliza a virtualizao para chavear vrias VMs na mesma mquina. Cada VM possui apenas um processo de banco de dados e uma VM inteira, em geral, corresponde a um inquilino. J o modelo de tabela compartilhada armazena dados de vrios inquilinos em uma mesma tabela e algumas linhas de uma 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 gesto de dados em nuvem [Armbrust et al. 2009]. Existem diversas abordagens para gerenciar dados em nuvem e cada sistema utiliza uma abordagem especca para persistir os dados. Dentre estas abordagens, podemos destacar novos sistemas de arquivos, frameworks e propostas para o armazenamento e processamento de dados. Google File System (GFS) um sistema de arquivos distribudos proprietrio desenvolvido pelo Google e projetado especialmente para fornecer acesso eciente e convel aos dados usando grandes clusters de servidores [Ghemawat et al. 2003]. Em comparao com os sistemas de arquivos tradicionais, o GFS foi projetado e otimizado para ser executado em centros de dados e fornecer elevada vazo, baixa latncia e tolerncia a falhas individuais de servidores. Inspirado pelo GFS, o projeto de cdigo livre Hadoop File System (HDFS) [Hadoop 2010] armazena grandes arquivos em vrias servidores e obtm a conabilidade por meio da replicao de dados. Similar ao GFS, os dados so armazenados em ns geogracamente distribudos.

Para apoiar o processamento distribudo de grandes conjuntos de dados em clusters 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 especicao do usurio, emite um conjunto de tuplas intermedirias no formato chave-valor. A funo Reduce recebe um conjunto de valores associados a cada chave, chamados de blocos. O processamento, denido pelo usurio, realizado sobre cada bloco. Por m, cada funo Reduce emite um conjunto de tuplas que so armazenadas em arquivos de sada. Existem algumas implementaes de cdigo livre, dentre as quais se destaca o Hadoop MapReduce. Algumas propostas para o armazenamento e processamento utilizam a estrutura chave-valor em uma Distributed Hash Table (DHT) [DeCandia et al. 2007]. Este valor e a chave associada so armazenados de forma desnormalizada, o que facilita a distribuio dos dados entre os ns do sistema, onde cada um destes ns possui parte dos dados. As APIs bsicas de acesso so simples com operaes tais como get(key) e put(key, value). APIs mais sosticadas permitem a execuo de funes denidas pelo usurio no ambiente do servidor tais como execute(key, operation, parameters) ou mapreduce(keyList, mapFunc, reduceFunc). Para acessar ou modicar qualquer dado necessrio fornecer uma chave, j que a busca realizada utilizando a igualdade. possvel realizar pesquisas com outros critrios, tais como maior ou menor ou expresses booleanas. Neste caso, so utilizadas tcnicas de busca exaustiva e rvores B+ distribudas. Outra abordagem para armazenar e processar dados em nuvem consiste em utilizar uma estrutura de colunas ou arrays multidimensionais [Chang et al. 2006]. Os dados so organizados em tabelas e estas possuem diversas colunas. Cada coluna armazena um valor, acessado por meio de uma chave. Nesta abordagem, todos os valores de uma coluna so 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 no armazenamento e na recuperao de informao. Alm disso, diversas tcnicas tais como a fragmentao de dados e o processamento OLAP tornam-se mais ecientes para dados gerenciados com esta abordagem. Outras abordagens para o armazenamento e processamento de consultas gerenciam os dados de tal sorte a reetir a estrutura de um documento ou tratam os dados na forma de grafos. A abordagem orientada documento, as tcnicas so desenvolvidas para o armazenamento, modelagem, consulta e apresentao de dados de forma a reetir a estrutura de um documento, que, em geral, no possui um esquema pr-denido. Neste contexto, 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 so gerenciados da seguinte forma: (i) n (vrtice): possui o mesmo conceito de uma instncia de um objeto com identicador nico; (ii) relacionamento (arestas): fornece uma ligao entre 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 existir tanto em um n quanto em um relacionamento. Esta abordagem auxilia na modelagem de estruturas complexas e por meio da representao utilizando grafos, a navegao entre

os ns e os relacionamentos apresenta bons resultados. 4.2.3.2. Transaes Os conceitos de processamento de transaes so de extrema importncia em ambientes centralizados e distribudos, sendo que nestes ltimos comum haver dados replicados e alocados em locais geogracamente distantes. Estes conceitos denem o nvel de consistncia e integridade dos dados nestes ambientes. A utilizao de transaes distribudas dene o controle do processamento de dados em todo ambiente de computao em nuvem e tem a responsabilidade de garantir as propriedades ACID ou variaes destas no ambiente. Neste sentido, necessita-se utilizar protocolos de replicao de dados, terminao distribuda e sincronizao de acesso devido natureza compartilhada dos recursos. Um ponto fundamental na construo de sistemas distribudos e considerado por todos os sistemas em nuvem o teorema Consistency, Availability, Partition Tolerance (CAP) [Brewer 2000] [Gilbert and Lynch 2002]. Este teorema mostra que os sistemas distribudos 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 arbitrria de mensagens. Um sistema distribudo pode suportar apenas duas dessas trs propriedades ao mesmo tempo. Como uma forma simples de entender um assunto complexo, o teorema CAP tornou-se um modelo popular para compreender aspectos de sistemas distribudos. No entanto, esta simplicidade pode conduzir a interpretaes incorretas do teorema. Estas propriedades no devem ser interpretadas no sentido de que o sistema disponvel ou consistente, mas que quando ocorre uma falha de rede, necessrio escolher qual propriedade torna-se mais importante para o sistema. Em decorrncia deste teorema, algumas abordagens para o gerenciamento de dados em nuvem tm utilizado diferentes formas de consistncia. Uma alternativa utilizar a abordagem Basically Available, Soft state, Eventually consistent (BASE) [Pritchett 2008], que caracterizada pelo sistema ser basicamente disponvel, pois este parece estar em funcionamento todo o tempo; em estado leve, j que o sistema no precisa estar sempre consistente; e eventualmente consistente, que dene que o sistema torna-se consistente em 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 atualizados e do ponto de vista do servidor - como processado o uxo das atualizaes por meio do sistema e que garantias este pode fornecer, no que diz respeito s atualizaes. Por exemplo, podem-se denir alguns tipos de consistncia. A consistncia forte garante que aps uma atualizao ser concluda, qualquer acesso subsequente fornecer o valor atualizado.

Por outro lado, na consistncia fraca, o sistema no garante que os acessos subsequentes iro 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 denominado janela de inconsistncia. A consistncia eventual uma forma especca de consistncia fraca, na qual o sistema garante que, se nenhuma atualizao for feita ao dado, todos os acessos iro devolver o ltimo valor atualizado. Se no ocorrer nenhum erro, o tamanho mximo da janela de inconsistncia pode ser determinado com base em fatores tais como os atrasos de comunicao, a carga do sistema e o nmero de rplicas envolvidas do esquema de replicao. O sistema mais popular que implementa consistncia eventual o Domain Name System (DNS). O modelo de consistncia eventual apresenta um nmero de variaes tais como consistncia causal, consistncia leitura/escrita, consistncia de sesso, consistncia de leitura/escrita montona. Estas variaes podem ser combinadas com o objetivo de tornar mais simples a construo de aplicaes e permitir aos sistemas melhorarem a consistncia e fornecer maior disponibilidade. Sob o ponto de vista do servidor, o nvel de consistncia depende de como as atualizaes so propagadas entre as rplicas dos dados. Isto permite melhorar a taxa de transferncia e fornecer escalabilidade. Contudo, o desenvolvedor deve estar consciente sobre quais garantias de consistncia so fornecidas pelo 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. A escalabilidade deve ser transparente para os usurios, podendo estes armazenar seus dados na nuvem sem a necessidade de saber a localizao dos dados ou a forma de acesso. Na nuvem, os desenvolvedores dispem de ambientes escalveis, mas eles tm que aceitar algumas restries sobre o tipo de software que se pode desenvolver, desde limitaes que o ambiente impe na concepo das aplicaes at a utilizao de SGBDs em nuvem do tipo chave-valor, ao invs de SGBDs relacionais. De forma geral, possvel identicar duas dimenses de escalabilidade: vertical e horizontal. Na escalabilidade vertical melhora-se a capacidade do hardware, incrementando individualmente os ns existentes, como por exemplo, por meio da disponibilizao de um servidor com mais memria fsica ou da melhoria da largura de banda que conecta dois ns. Isto funciona razoavelmente bem para os dados, mas tem vrias limitaes tais como a aquisio constante de hardware de maior capacidade, o que pode criar dependncia de fornecedores, aumentando os custos. A escalabilidade horizontal consiste em adicionar mais mquinas soluo atual de tal modo que seja possvel distribuir as requisies entre estas mquinas. No caso dos dados, pode-se agrup-los por funes e distribu-los por vrios SGBDs. Dessa forma, ocorre a fragmentao dos dados em SGBDs em nuvem e cada um destes sistemas pode ser dimensionado de forma independente. Este tipo de escalabilidade oferece maior exibilidade, mas necessita de um planejamento especco. A escalabilidade envolvendo dados uma tarefa complexa, j que a maioria dos SGBDs em nuvem utiliza arquiteturas no compartilhadas, tornando a disposio dos

dados 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 terceiro servidor, poder-se-ia colocar um tero dos dados em cada servidor, fazendo com que cada um dos trs servidores casse com 33% dos dados. Entretanto, no to simples assim, pois as consultas dos usurios envolvem dados relacionados em diferentes servidores, o que exige o transporte dos dados, diminuindo o desempenho do sistema. Por esta razo, a fragmentao dos dados deve ser feita de forma a minimizar o transporte de dados, o qual adiciona um custo relevante ao processamento. Em relao ao desempenho, as solues de gerenciamento de dados em nuvem devem lidar com problemas de tempo de resposta, em virtude das diferentes tecnologias e heterogeneidade do hardware utilizado, o que pode inuenciar o desempenho. Por exemplo, uma falha de hardware, tais como problemas no acesso ao ncleo de uma mquina com mltiplos cores ou a disputa por recursos no virtualizados, causa degradao do desempenho de uma mquina do sistema. Se a carga de trabalho necessria para executar uma consulta dividida igualmente entre as mquinas com conguraes diferentes, ocasiona um atraso no processamento, visto que o tempo para completar a consulta ser aproximadamente igual ao tempo para a execuo da mquina com menor congurao para 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 da utilizao de hardware de custo elevado, as infraestruturas para nuvem so construdas em cima de hardware de baixo custo e com a suposio de que mquinas e redes podem falhar. Dessa forma, as solues desenvolvidas devem lidar com falhas, j que estas iro ocorrer em algum momento [Abadi 2009]. Para tratar as falhas, as solues em nuvem utilizam tcnicas que auxiliam a distribuio dos dados, tais como DHT, que facilita a fragmentao dos dados. Por meio da fragmentao dos dados possvel melhorar a disponibilidade e distribuir a carga, tanto para operaes de escrita quanto de leitura. Se apenas uma mquina falhar, os dados pertencentes a essa mquina so afetados, mas no o armazenamento de dados como um todo. Em relao ao processo de replicao, pode-se criar e iniciar novas rplicas rapidamente por meio de mquinas virtuais [Soror et al. 2010]. Isso permite manter muitas rplicas por mquina, o que reduz a quantidade total de armazenamento e, portanto, os custos associados. O processo de replicao pode ser realizado de forma sncrona ou assncrona ou uma combinao destas. Isso determina o nvel de consistncia, conabilidade e desempenho do sistema. Dentre os protocolos utilizados na replicao de dados 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. Classicao dos Sistemas de Gerenciamento de Dados em Nuvem Existem diversos SGBDs em nuvem, cada um destes com caractersticas e propsitos especcos. Com o objetivo de auxiliar o estudo destes sistemas e realizar um compara-

tivo entre os mesmos, propomos uma classicao com base nos seguintes parmetros: modelo relacional e nativo para nuvem. O primeiro parmetro se refere utilizao do modelo relacional pelo sistema e o segundo parmetro est relacionado ao processo de construo do sistema, ou seja, se o sistema foi concebido para atender as necessidades da computao em nuvem. Os sistemas com modelos de dados em comum foram agrupados de forma a facilitar a compreenso. Vale ressaltar que alguns destes sistemas possuem caractersticas de mais de um modelo de dados. A Figura 4.8 apresenta essa classicao e destaca alguns sistemas.

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

No primeiro quadrante esto os SGBDs relacionais desenvolvidos nativamente para nuvem. Estes sistemas esto sendo concebidos considerando as caractersticas da computao em nuvem juntamente com aspectos do modelo relacional. O exemplo mais conhecido destes sistemas o Microsoft SQL Azure. No segundo quadrante esto SGBDs relacionais que no foram concebidos para nuvem, mas que podem ser executados em uma infraestrutura baseada em nuvem. Como exemplo destes sistemas destacam-se o Amazon Relational Database Service (Amazon RDS) [Amazon 2010] e o Relational Cloud [Curino et al. 2010]. No terceiro quadrante esto os sistemas considerados nativos para nuvem que no utilizam o modelo relacional, tais como os sistemas que utilizam o modelo chave-valor e baseado em coluna. Dentre os sistemas que utilizam o modelo chave-valor pode-se destacar o Amazon Dynamo [DeCandia et al. 2007] e o Voldemort. BigTable, HBase e Cassandra so exemplos de sistemas baseados em coluna [NoSQL 2010]. No quarto quadrante esto os sistemas no-nativos que no utilizam o modelo relacional, tais como grafo, documento ou XML. Estes sistemas esto sendo desenvolvidos para propsitos especcos e utilizados em ambientes em nuvem. O Neo4j um exemplo dos sistemas baseados em grafo e CouchDB e MongoDB so exemplos de sistemas orientados a documento.

Os sistemas no-relacionais, coletivamente, iniciaram um movimento denominado Not only SQL (NoSQL). NoSQL um termo genrico para uma classe denida de SGBDs no-relacionais que foram projetados para gerenciar grandes volumes de dados e, em geral, fornecem garantias de consistncia fraca, como consistncia eventual e utilizam estruturas e interfaces simples. Estes sistemas esto sendo utilizado principalmente em servios de hospedagem de stios, redes sociais e em outros servios especcos. Segundo [Stonebraker 2010], o desempenho e a exibilidade so duas razes para utilizar estes novos sistemas. Tratando-se do desempenho, o tempo total do Online Transaction Processing (OLTP) est relacionado com quatro componentes: logging, bloqueio, latching e gerenciamento de buffer. Eliminando-se qualquer destes componentes de sobrecarga, pode-se melhorar o desempenho em 25%. Os sistemas NoSQL abordam alguns destes componentes utilizando gerenciamento eciente de buffer, novas arquitetura de thread, suporte para transaes em um nico registro e consistncia eventual. Dessa forma, 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 relacionando com as implementaes tradicionais de transaes ACID, multithreading e o gerenciamento 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 Nuvem

Existe uma grande quantidade de SGBDs em nuvem e, assim, no possvel destacar cada um destes sistemas [Agrawal et al. 2010a]. A seguir destacamos alguns destes sistemas e apresentamos uma anlise comparativa considerando diversas caractersticas do gerenciamento de dados. 4.3.1. Microsoft SQL Azure O Microsoft SQL Azure composto por um conjunto de servios para o armazenamento e processamento de dados em nuvem [Azure 2011]. O SQL Azure juntamente com o Windows Azure Storage compem a soluo de gerenciamento de dados em nuvem da Microsoft. O Windows Azure Storage inclui armazenamento persistente por meio de blobs, tables e las. Um blob um par nome, objeto que permite armazenar objetos de at 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 las fornecem um servio de troca de mensagens persistentes e convel. O SQL Azure Database (SAD) o principal componente do SQL Azure e foi construdo com base na tecnologia do SGBD relacional SQL Server. Para permitir uma integrao transparente de aplicaes com SQL Azure, o SAD suporta os principais comandos da linguagem Transact-SQL (T-SQL). Esta linguagem possui diversas caractersticas, dentre os quais podemos destacar tabelas, ndices, funes, procedimentos e gatilhos, entre outros. O gerenciamento do SQL Azure pode ser realizado por meio da ferramenta denominada Houston. O SQL Azure implementa alta disponibilidade, tolerncia a falhas e o conceito de multi-inquilino. Cada banco de dados implementado como uma partio de dados replicados em mltiplas mquinas em um SQL Azure Datacenter. Com esse tipo de abor-

dagem, SQL Azure fornece um gerenciamento automtico de falhas e balanceamento de carga de trabalho. A estratgia de replicao utiliza trs cpias dos itens de dados para fornecer a disponibilidade e implementa consistncia forte. No SQL Azure Database, um banco de dados individual possui um tamanho limitado a 50 GB. Para criar solues que armazenem dados maiores do que este tamanho deve-se fragmentar grandes conjuntos de dados 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 desenvolvido com base no Dynamo [DeCandia et al. 2007]. O Dynamo utiliza o modelo par chave-valor armazenados em uma DHT e no possui suporte a associaes ou esquemas. Para garantir um nvel de escalabilidade e disponibilidade, de acordo com o teorema CAP, o Dynamo relaxa a consistncia em alguns cenrios de falhas e faz uso de verses de objetos e resoluo de conitos assistida por meio de uma interface para os desenvolvedores. No Dynamo, as operaes de leitura e escrita utilizam identicadores nicos, sendo realizadas sobre objetos binrios de at 5GB e no existe suporte s operaes sobre mltiplos objetos. As propriedades das transaes ACID apresentam as seguintes caractersticas: atomicidade e isolamento so garantidos pela escrita de um nico objeto; durabilidade obtida por meio de escrita replicada e apenas a consistncia no forte. A API do Dynamo possui as operaes get() e put(). Escalabilidade, balanceamento de carga e suporte heterogeneidade foram aspectos enfatizados na concepo do Dynamo e tornam relativamente simples adicionar ns, distribuir as requisies e suportar ns com caractersticas diferentes. As propriedades de simetria e descentralizao so utilizadas de tal forma que todos os pontos so igualmente responsveis e com o objetivo de evitar pontos nicos de falhas. O Dynamo usa a tcnica de hashing consistente para prover a fragmentao e a replicao. Para tratar o problema de balanceamento de carga, decorrente da utilizao de poucos ns ou ns heterogneos, o Dynamo utiliza a estratgia de ns virtuais, onde cada n fsico pode ter vrios ns virtuais associados. Dessa forma, mquinas com maior capacidade de processamento e armazenamento podem ter uma maior quantidade de ns, sendo estes distribudos aleatoriamente. O Dynamo utiliza o protocolo Gossip para vericar se um n pertence ao sistema e para deteco de falhas. O Amazon S3 utiliza o conceito de objeto, entidade fundamental que consiste de dados, metadados e um identicador nico. Os objetos so organizados em buckets e estes 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 pode especicar a localizao geogrca de um buckets. No S3, as operaes de escrita so atmicas, mas podem ser executadas sobre mltiplas chaves. Entretanto, este sistema no fornece mecanismos de bloqueio. O SimpleDB um sistema de armazenamento hierrquico de dados construdo para superar as limitaes do S3. O SimpleDB possui atributos mltiplos, indexao e suporte a consultas. O armazenamento de dados livre de esquema, escalvel e eciente para 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, que podem ser comparados a uma tabela em SGBDs relacionais, com a diferena que um domnio pode conter um conjunto diferente de atributos para cada item. Cada item pode ter vrios valores para cada atributo. Os itens so identicados por domnio e os atributos so organizados na forma de par chave-valor, sem denio de tipo, ou seja, uma cadeia de caracteres indexados automaticamente. Para criar relacionamentos no SimpleDB, o desenvolvedor 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 em um domnio. O SimpleDB tem algumas restries em relao ao tamanho e nmero de domnios, tempo da consulta, no permite junes e comparaes de itens dentro de uma consulta, 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. Ele funciona 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 dos dados [Chang et al. 2006]. O BigTable no suporta um modelo relacional, mas fornece um modelo simples e exvel. No modelo de dados do BigTable, uma tabela um mapa esparso, distribudo, persistente e multidimensional, organizado em trs dimenses: linha, coluna e timestamp, formando uma clula. Linhas com chaves consecutivas so agrupadas em tablets, que so unidades de distribuio e balanceamento de carga. As linhas so a unidade 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 verses de uma mesma clula podem ser armazenadas e indexadas pelo timestamp. BigTable no suporta 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 por designar tablets para os servidores de tablets, balanceamento de cargas e por gerenciar alteraes nos esquemas dos dados. Cada servidor de tablet responde s requisies de leituras e escritas nas tabelas e o servio de bloqueio denominado Chubby usado para administrar os servidores. O servio Chubby utiliza o protocolo baseado em quorum Paxos para resolver o problema de consenso distribudo e fornecer bloqueios exclusivos para os arquivos gerenciados. O BigTable fornece consistncia forte, mas no replica o banco de dados diretamente, pois um tablet pode ser atribudo para apenas um servidor de tablet por vez. A replicao dos dados realizada por meio do GFS, que gerencia o armazenamento dos tablets e dos arquivos de log. O Google App Engine (GAE) datastore uma soluo de gerenciamento de dados baseado 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 todos os objetos em uma transao estejam dentro do mesmo grupo de entidade. O GAE datastore utiliza consistncia forte, similar ao BigTable. Muitos tipos de dados comuns so suportados no armazenamento de dados, incluindo String, int, oat, e DateTime. O GAE datastore utiliza uma chave como identicador nico para atributos como linha,

links, entre outros e pode ser acessado com a linguagem de consulta Google Query Language (GQL), um subconjunto da linguagem SQL. A linguagem GQL possui suporte a seleo, ordenao e alguns operadores. A instruo de seleo pode ser realizada em uma nica tabela, ou seja, no suporta junes, assim como associaes ou chaves compostas em decorrncia do modelo de dados utilizado. Dessa forma, associaes devem ser implementadas na camada de aplicao. 4.3.4. CouchDB O CouchDB um SGBD orientado a documento e livre de esquema [Apache 2010]. O CouchDB possui uma srie de caractersticas que torna sua utilizao vivel em servidores que possuem hardware de baixo desempenho e utiliza tcnicas de armazenamento e controle de concorrncia baseadas na estrutura do documento. Este sistema foi implementado utilizando a plataforma Erlang OTP devido nfase desta plataforma em tolerncia a falhas e oferecer escalabilidade, disponibilidade e conabilidade, mesmo ao executar em hardware que est sujeito falhas. O CouchDB organiza os dados em documentos e cada um destes possui um identicador nico. Cada documento pode ter qualquer quantidade de atributos e cada atributo pode conter listas ou objetos. Os documentos so armazenados e acessados como objetos JavaScript Object Notation (JSON). Operaes de atualizao so executadas sobre todo o documento e o CouchDB gerencia as alteraes por meio de um identicador de reviso contido em cada documento. O CouchDB utiliza uma estrutura de arquivo baseada 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 construdas utilizando funes MapReduce e de uma API de consultas via http. Uma viso basicamente uma coleo de pares chave-valor que, juntamente com o MapReduce permite ao usurio criar um programa de mapeamento e outro de reduo para ltrar e agregar dados em uma base de documentos. O CouchDB implementa o protocolo de controle de concorrncia multi-verso (MVCC) adaptado para documento e utiliza o modelo de consistncia eventual. Adicionalmente, o CouchDB possui um mecanismo incremental de replicao com deteco e gerenciamento bi-direcional de conitos. 4.3.5. Cassandra Cassandra um sistema de armazenamento distribudo para o gerenciamento de grandes quantidades 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. O sistema Cassandra pode funcionar em hardware de baixo custo e lida com alta taxa de escrita sem sacricar a ecincia na leitura. Por utilizar uma arquitetura distribuda, Cassandra no possui um ponto nico de falha. Este sistema tolerante a falhas e, com isso, aumenta a conabilidade do sistema, j que os dados so automaticamente replicados em vrios ns de um ou mais centros de dados e o protocolo Gossip utilizado para tratar s falhas. A vazo de operaes de leitura e escrita no sistema pode crescer linearmente e novas mquinas so adicionadas sem nenhum custo ou interrupo para as aplicaes.

Cassandra um hbrido que combina a arquitetura descentralizada do Dynamo com o modelo de dados do BigTable e possui uma API simples como meio de acesso aos dados. Cassandra possui um modelo de dados na forma de um hash de quatro ou cinco dimenses: espao de chave, famlia de colunas, coluna, chave e super-coluna. O espao de chave um local para as famlias de colunas e, tipicamente, denido uma por aplicao. Uma famlia de colunas o local para agrupar as colunas, assim como uma 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 ser comparada a uma coluna que possui sub-colunas e utilizada para modelar tipos de dados complexos. A coluna a menor unidade de dados existente no modelo de dados do Cassandra e formada por uma tripla que contm um nome, um valor e um timestamp. Todos os valores so fornecidos pelo usurio, incluindo o timestamp. Neste caso, os relgios dos usurios devem ser sincronizados, pois estes timestamps so usados para resoluo de conitos. Uma famlia de colunas contm uma lista ordenada de colunas, que o usurio pode fazer referncia ao nome da coluna. Cada famlia de coluna armazenada em um arquivo separado e este arquivo classicado por uma chave, que determina qual dado armazenado na mquina. Cassandra determina os ns responsveis pelos dados e, quando um usurio submete uma solicitao de escrita para um n aleatrio, as operaes de escrita so registradas e ento aplicadas a uma verso na mquina. Um log com as operaes consolidadas armazenado em um disco dedicado para a mquina. Para operaes de escrita no existem bloqueios e a atomicidade garantida pelo acesso por meio de uma chave. Alm disso, as escritas so aceitas durante cenrios de falhas, o que aumenta a disponibilidade. Cassandra no fornece ndices automaticamente e o usurio precisa denir solues para melhorar o desempenho. Uma alternativa utilizar estratgias que envolvam famlia de colunas por consulta. Com isso, possvel melhorar a organizao dos dados e minimizar o esforo no acesso e no processamento de consultas. Cassandra tambm possui algumas limitaes, como por exemplo, todos os dados de um nico registro devem pertencer ao disco de uma mquina do cluster. Isso porque as chaves dos registros so utilizadas para determinar os ns responsveis por replicar dados. Outra limitao que o valor de uma coluna no pode ultrapassar 2GB. 4.3.6. Relational Cloud Relational Cloud um SGBD como um servio concebido com o objetivo de consolidar as funcionalidades de gesto de dados para grandes empresas e outsourcing do gerenciamento de dados em nuvem para pequenas e mdias empresas [Curino et al. 2010]. O Relational Cloud prove disponibilidade por meio de replicao transparente, gerenciamento 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 dados em tempo de execuo e anlise de carga de trabalho. Em relao fragmentao, o Relational Cloud prope um novo algoritmo com o objetivo de minimizar a probabilidade de 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 quando uma adaptao ser necessria antes que algum n do sistema seja sobrecarregado. Para tanto, 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 e dinmicas de caracterizao da carga de trabalho, seleo de SGBDs, atribuio de cargas de trabalho para as instncias de banco de dados e atribuio de instncias de banco de dados para ns fsicos. O Relational Cloud foi projetado para ser executado em mquinas em um nico centro de dados. Cada mquina fsica executa vrias instncias de um SGBDs. Estas instncias podem utilizar sistemas de armazenamento diferentes, visto que sistemas especializados, em geral, so ecientes para tarefas especcas. Cada banco de dados dividido em parties lgicas por meio de tcnicas de fragmentao. Essas parties so armazenadas em grupos de rplicas com o objetivo de garantir a disponibilidade e tolerncia a falhas. Um grupo de rplica consiste de vrias instncias do banco de dados sendo que cada uma armazena cpia dos dados de uma partio lgica. A fragmentao dos dados e alocao dos grupos de rplicas nas mquinas so controladas pelo analisador de carga de trabalho. A comunicao entre as aplicaes e o Relational Cloud realizada por meio de interfaces padro ou protocolos conhecidos, tais como a interface JDBC. As consultas SQL recebidas so enviadas para um roteador, responsvel por analisar e vericar os metadados do banco de dados e determinar o plano de execuo. Por m, o sistema de transaes distribudas distribui a carga de trabalho, assegurando a serializabilidade e o tratamento de falhas. Por meio do monitoramento constante de desempenho e carga de trabalho, o Relational Cloud ajusta a fragmentao dos dados e as opes de localizao em tempo de execuo. Falhas no sistema e alteraes de carga de trabalho exigem a evoluo do esquema de fragmentao e alocao em tempo de execuo. Para tanto, necessria a migrao dos dados baseada nas instncias do mecanismo de armazenamento, 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 sistema apresenta diferentes nveis de consistncia, replicao para reas geogracamente distantes, escalabilidade, tolerncia a falhas, alta disponibilidade e baixa latncia para um grande nmero de requisies simultneas [Cooper et al. 2008]. Este sistema utiliza um modelo de dados relacional simplicado, onde os dados so organizados em tabelas de registros com atributos e permite uma estrutura arbitraria dentro de um registro, tais como blobs. O esquema de dados exvel, j que um novo atributo pode ser adicionado sem suspender consultas ou atualizaes ativas e ter atributos vazios em um registro. PNUTS possui integridade referencial, junes ou agregao. A linguagem de consulta suporta seleo e projeo em uma tabela simples e atualizaes e excluses so realizadas apenas pela chave primria. As rplicas so geogracamente distribudas em diversas regies. As tabelas so

fragmentadas horizontalmente, criando tablets, que apenas um grupo de registros de uma determinada tabela. Uma cpia de um tablet alocada em cada regio. As unidades de armazenamento podem utilizar um sistema de arquivo ou MySQL. Roteadores mantem copia em cache dos mapeamentos internos para os tablets e os controladores de tablets gerenciam o intervalo de mapeamento, tabelas fragmentadas e o balanceamento de carga. PNUTS fornece novas garantias de consistncia por registro, denominada consistncia timeline, um tipo de consistncia entre serializabilidade e consistncia eventual. Neste caso, todas as rplicas so atualizadas para um registro na mesma ordem. Uma rplica sempre escolhida, por registro, como primria. As atualizaes so executadas na rplica primria e propagadas de forma assncrona para as outras rplicas utilizando um mecanismo publish-subscribe. Operaes de leitura podem ser executadas em qualquer uma 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 com linguagens de programao. Este sistema permite gerenciar dados complexos e navegar entre os dados de forma simples e eciente [Neo 2010]. 4.3.7.3. Amazon Relational Database Service (RDS) SGBD como um servio desenvolvido pela Amazon que disponibiliza todas as funcionalidades de um SGBD relacional. Com o Amazon RDS, no necessrio instalar, congurar e 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, SimpleDB e Cassandra utilizam modelos simplicados de dados baseados em par chave-valor ou orientados a coluna. Os dados so armazenados em estruturas otimizadas e acessados por meio de APIs simples. GAE datastore, S3/SimpleDB, CouchDB no possuem suporte a transaes ACID. Cassandra utiliza um conceito simplicado de transaes para linhas [Candan et al. 2009]. Estes sistemas suportam apenas consistncia eventual, exceto o GAE datastore e todos apresentam alta escalabilidade e alta disponibilidade, menos o CouchDB que possui mdia escalabilidade, em decorrncia do modelo de dados utilizado. GAE datastore, Amazon S3, SimpleDB e Cassandra apresentam bons resultados na manipulao de grandes volumes de dados, pois os modelos de dados utilizados por estes sistemas favorecem a fragmentao dos dados. Contudo, em geral, estes sistemas no suportam operaes como junes, possuem apenas garantias de consistncia fraca e fornecem suporte limitado a transaes. Alm disso, utilizando um modelo de dados mais simples, a complexidade empurrada para as demais camadas da aplicao, exigindo dos desenvolvedores 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 domnios complexos. Estes modelos de dados mais ricos introduzem maior quantidade de ligao

entre os dados, o que prejudica a escalabilidade. Vale ressaltar que estes sistemas ainda so muito recentes e existem poucos estudos detalhados sobre os mesmos, assim como ferramentas e tecnologias de apoio para sua ampla utilizao.
Caracterstica Modelo Armazenamento Linguagem Consulta Transaes de S3 SimpleDB
Chave-valor Hash consistente API simples No Eventual Alta Alta

BigTable GAE
Coluna ndices API simples No Forte Alta Alta

Cassandra
Coluna ndices API simples Sim simplicada Eventual Alta Alta

CouchDB
Documento rvore B+ API simples No Eventual Mdia Alta

SQL Azure
Relacional Tabela SQL Sim Forte Mdia Alta

Relational Cloud
Relacional Tabela SQL Sim Forte Baixa Mdia

Consistncia Escalabilidade Disponibilidade

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 exibilidade no acesso aos dados, tais como agregao e consultas com junes. Eles implementam transaes ACID e garantia de consistncia forte, o que facilita no desenvolvimento de aplicaes. Em relao escalabilidade e disponibilidade, SQL Azure e Relational Cloud apresentam caractersticas diferentes. O SQL Azure possui mdia escalabilidade, j que no oferece suporte a transaes distribudas ou consultas atravs de mltiplas parties de dados localizados em diferentes ns, mas apresenta alta disponibilidade. O sistema Relational Cloud apresenta baixa escalabilidade e mdia disponibilidade, pois se trata de um sistema em desenvolvimento e que no considera aspectos de elasticidade e ambientes virtualizados, caractersticas essenciais da computao em nuvem. O SQL Azure no possui suporte a fragmentao automtica de dados, essencial para melhorar a escalabilidade, mas o Relational Cloud apresenta iniciativas neste sentido. A Tabela 4.4 mostra um resumo deste comparativo. importante ressaltar que os modelos de dados utilizados pelos sistemas de gerenciamento de dados em nuvem so compatveis, ou seja, pode-se expressar um conjunto de dados em qualquer um deles. Por exemplo, possvel decompor todos os dados de um banco de dados relacional em uma coleo de par chave-valor. Dessa forma, existem contextos onde cada um destes modelos de dados mais apropriado. De acordo com [Kossmann et al. 2010], os principais provedores tem adotado diferentes arquiteturas para seus servios e o custo e o desempenho destes servios variam signicativamente dependendo da carga de trabalho.

4.4. Desaos e Oportunidades de Pesquisa

A computao em nuvem apresenta diversas vantagens, mas tambm possui uma srie de desaos que devem ser superados para sua ampla utilizao. A seguir destacamos alguns destes desaos no contexto do gerenciamento de dados. Outros desaos envolvendo aspectos 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 dados, empresas necessitam gerenciar e analisar uma grande quantidade de dados e fornecer alto desempenho. Alm disso, os dados so gerenciados em vrias parties, o que diculta garantias transacionais, tais como atomicidade e isolamento. Para tratar estes problemas, diferentes solues tem sido desenvolvidas combinando tecnologias como o MapReduce ou SGBDs paralelos [Abouzeid et al. 2009]. Um desao denir uma arquitetura para paralelizar o processamento de consultas com nfase em consultas On Line Analytical 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 consultas e os sistemas de arquivos paralelos, tais como o HDFS e proporcionar diferentes nveis de isolamento. O framework MapReduce e suas diversas implementaes como o Hadoop e o Drayd foram projetados para o processamento distribudo de tarefas e geralmente utilizam sistemas de arquivos como o GFS e o HDFS. Estes sistemas de arquivos so diferentes dos sistemas de arquivos distribudos tradicionais em sua estrutura de armazenamento, padro de acesso e interface de programao. Em particular, eles no implementam a interface padro POSIX, e, portanto, apresentam problemas de compatibilidade com aplicaes e sistemas de arquivos legados [Zhang et al. 2010]. Um ponto importante desenvolver solues para tratar a compatibilidade com os sistemas de arquivos distribudos tradicionais, tais como mtodos para suportar o framework MapReduce usando sistemas de arquivos para cluster e tcnicas para o acesso concorrente aos dados. Em relao ao acesso aos servios de dados em nuvem, os provedores fornecem linguagens com restries, APIs simples e estas apresentam muitas limitaes, tais como a ausncia de consultas com junes, permitem apenas consultas por uma chave e no suportam mltiplas chaves. Considerando a grande quantidade de servios de dados em nuvem, os desenvolvedores necessitam utilizar APIs diferentes para cada servio. Isso exige mais esforo dos desenvolvedores e aumenta a complexidade na camada de aplicao. Um desao fornecer uma API comum para vrios servios, assim como uma linguagem de consulta robusta e com diversas caractersticas dos SGBDs relacionais [Cooper et al. 2009]. Outros aspectos relevantes neste contexto esto relacionados otimizao 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 consistncia fraca de dados, por exemplo, consistncia eventual. Este tipo de consistncia no permite a construo de uma ampla gama de aplicaes, tais como servios de pagamento e leiles online, que no podem trabalhar com dados inconsistentes [Wei et al. 2009]. Neste contexto, aspectos de armazenamento de dados, processamento de consultas e controle transacional tm sido exibilizados por algumas abordagens para garantir a escalabilidade, mas ainda no existem solues que combinem estes aspectos de forma a melhorar o desempenho sem comprometer a consistncia dos dados [Abadi 2009]. De acordo com

[Armbrust et al. 2009], o desenvolvimento de um sistema de armazenamento que combine os diversos aspectos de computao em nuvem, de forma a aumentar a escalabilidade, a disponibilidade e a consistncia dos dados um problema de pesquisa em aberto. Dessa forma, um desao desenvolver solues escalveis e com consistncia forte. Em [Wei et al. 2009] apresentado uma soluo com suporte a transaes ACID e sem comprometer a escalabilidade mesmo na presena de falhas. Contudo, esta soluo necessita utilizar tcnicas de desnormalizao de esquemas, o que pode dicultar sua utilizao. [Yang et al. 2009] propem uma plataforma para o gerenciamento de dados que pode escalar para uma grande quantidade de pequenas aplicaes e fornecer consistncia forte. Para tanto, vrias tcnicas de SGBDs, tais como replicao, migrao e gerenciamento 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 sistemas de clusters [Soror et al. 2010]. Enquanto muitos SGBDs j esto sendo utilizados em ambientes virtualizados, questes relacionadas utilizao destes sistemas ainda permanecem em aberto [Rogers et al. 2010]. Uma vez que o uso de mquinas virtuais pode auxiliar a provisionar recursos, um desao explorar a possibilidade de escalar SGBDs para tratar com cargas de trabalho inesperadas por meio da utilizao de novas rplicas em mquinas virtuais recm-provisionadas [Soror et al. 2010]. Com isso, necessrio garantir o acesso consistente ao SGBD durante e aps o processo de replicao, coordenar solicitaes de roteamento para as mquinas virtuais antigas e novas, desenvolver polticas para a proviso de novas rplicas e modelos mais abrangentes para o planejamento da capacidade necessria para a nuvem [Aboulnaga et al. 2009]. Tambm importante desenvolver solues para otimizar as consultas em SGBDs executados em ambientes virtualizados e ajustar os parmetros do banco de dados com a mquina virtual visando melhorar a interao entre estes sistemas [Soror et al. 2010]. Outro ponto fundamental a alocao de recursos, j que as mquinas fsicas trabalham com apenas parte de sua capacidade. Estas mquinas poderiam ser melhor utilizadas, permitindo a reduo de custos. Uma questo relevante determinar a melhor alocao das aplicaes para as mquinas virtuais de acordo com mtricas que maximizem a utilizao dos recursos. Em [Rogers et al. 2010] proposto uma soluo para a alocao de SGBDs em ambientes virtualizados. Entretanto, no so abordados aspectos relacionados replicao dos dados. 4.4.4. Qualidade dos Servios de Dados Em ambientes de computao em nuvem, a qualidade do servio uma caracterstica denida entre o provedor e o usurio e expressa por meio de SLA. Com isso, o usurio do servio tem algumas garantias, tais como desempenho e disponibilidade. Apesar das limitaes de rede e segurana, as solues em nuvem devem fornecer elevado desempenho, alm de serem exveis para se adaptar diante de uma determinada quantidade de requisies. Como, em geral, os ambientes de computao em nuvem possuem acesso pblico, torna-se imprevisvel e varivel a quantidade de requisies realizadas, dicultando 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 histrico de processamentos do mesmo. Entretanto, estimar mtricas de qualidade um fator desaador nestes ambientes, pois os recursos gerenciados esto, freqentemente, sendo expandidos ou realocados com o intuito de melhorar o desempenho. Muitas empresas dependem de SLA, por exemplo, para exibir uma pgina web dentro de um determinado intervalo de tempo. Essas empresas esperam que os provedores de nuvem forneam garantias de qualidade utilizando SLAs com base em caractersticas de desempenho. Contudo, em geral, os provedores baseiam seus SLAs apenas na disponibilidade dos servios oferecidos, ao passo que os servios em nuvem apresentam uma variabilidade de desempenho bastante elevada. Portanto, essencial que os provedores ofeream SLAs baseados em desempenho para os usurios [Schad et al. 2010]. Para muitos sistemas, a maior parte do tempo de processamento das requisies est associada ao SGBD (em vez do servidor web ou servidor de aplicao). Dessa forma, importante que a qualidade seja aplicada no SGBD para controlar o tempo de processamento [Schroeder et al. 2006]. Uma questo relevante para garantir a qualidade em qualquer infraestrutura compartilhada isolar o desempenho de aplicaes diferentes. Aplicaes podem adicionar uma carga varivel sobre a nuvem e necessrio vericar como esta carga de trabalho ir afetar as outras aplicaes que compartilham o mesmo hardware. Algumas abordagens para este problema utilizam quotas de recursos ou compartilhamento ponderado [Cooper et al. 2009]. Independente da abordagem utilizada, esta ter que garantir a qualidade de servio, mesmo em condies extremas e com diferentes componentes da nuvem. Tambm importante garantir a qualidade do servio de dados independente da forma de acesso. Por exemplo, o provedor deve fornecer um servio com garantias para um usurio que acessa este servio por meio de um desktop ou de um dispositivo mvel. Para tanto, necessrio identicar a requisio e, caso necessrio, alocar mais recursos de forma a garantir o SLA com o usurio. Tcnicas adaptativas e dinmicas devero ser desenvolvidas para tornar os SGBDs em nuvem viveis [Aboulnaga et al. 2009], alm de 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, o que pode interferir no desempenho do sistema. Dessa forma, o provisionamento de recursos deve ser eciente, j que as cargas de trabalho dos SGBDs como um servio so muito variveis, visto que os inquilinos podem acessar o sistema com maior freqncia em determinados momentos. Com a ampla utilizao de ambientes virtualizados, altamente compartilhados, a questo do provisionamento torna-se determinante. A distribuio dos dados realizada por meio da fragmentao e da replicao e deve garantir que os dados dos inquilinos no sejam perdidos e que a recuperao seja simples. Para tratar a recuperao, pode-se estender a linguagem de consulta de forma a permitir o acesso considerando a distribuio dos dados dos inquilinos. Outro aspecto importante a falta de suporte para a arquitetura multi-inquilino. A maioria dos SGBDs foi projetada para escalar para um ou para poucos bancos de dados

grandes e eles no fornecem suporte multi-inquilino para vrias aplicaes executadas em hardware compartilhado. Embora seja relativamente fcil de controlar o SLA para um ou poucos bancos de dados pela adio de recursos, isto se torna um problema complexo de gerenciamento quando se necessita cumprir SLAs para milhares de aplicaes que utilizam recursos compartilhados, visto que utilizar recursos dedicados no uma opo economicamente vivel devido grande quantidade de aplicaes [Yang et al. 2009]. Muitas solues para construir SGBDs multi-inquilino necessitam de reescrita da consulta [Hui et al. 2009]. Isso ocasiona um esforo adicional para o sistema, o que pode comprometer a escalabilidade. Novas propostas tais como o BigTable permitem fornecer alternativas para a construo de SGBDs multi-inquilino e podem ser incorporadas aos sistemas existentes, melhorando o suporte multi-inquilino. Dessa forma, um desao desenvolver uma arquitetura multi-inquilino para SGBDs e tcnicas para maximizar a quantidade de inquilinos, com baixo custo e garantias de desempenho. 4.4.6. Segurana dos Servios de Dados A computao em nuvem um modelo que utiliza a Internet para disponibilizar seus servios. Isso se torna complexo, visto que os recursos computacionais utilizam diferentes domnios de redes, sistemas operacionais, software, criptograa, polticas de segurana, entre outros. Questes de segurana devem ser consideradas para prover a autenticidade, condencialidade e integridade. No que diz respeito conabilidade e responsabilidade, o provedor deve fornecer recursos conveis, especialmente se a computao a ser realizada crtica e deve existir uma delimitao de responsabilidade entre o provedor e o usurio. Dessa forma, devem-se ter meios para impedir o acesso no autorizado a informaes e que os dados sensveis permaneam privados, pois estes podem ser processados fora das empresas [Agrawal et al. 2009]. Em geral, cada sistema tem seu prprio modelo de dados e poltica de privacidade destes dados [Cooper et al. 2009]. Quando ocorre a movimentao de dados entre sistemas, deve-se garantir a privacidade dos dados mesmo com a mudana entre modelo de dados diferente e que aplicaes multi-inquilino acessem dados de outras aplicaes apenas de acordo com as polticas denidas. Tcnicas de criptograa podem ser utilizadas para garantir a privacidade dos dados. No entanto, estas tcnicas tm implicaes signicativas de desempenho de consultas em SGBDs. Dessa forma, alternativas para a integrao de tcnicas de criptograa com SGBDs devem ser investigadas e desenvolvidas, j que a complexidade computacional da criptograa de dados aumenta o tempo de resposta da consulta. Em [Agrawal et al. 2009] apresentado uma abordagem segura e escalonvel para preservar a privacidade. Em vez de utilizar a criptograa, que computacionalmente caro, utilizada uma estratgia de distribuio dos dados em vrios stios do provedor e tcnicas para acessar as informaes de forma secreta e compartilhada. 4.4.7. Descrio, Descoberta e Integrao de Servios de Dados Na computao em nuvem, vrios modelos evoluram rapidamente para aproveitar as tecnologias de software, plataformas de programao, armazenamento de dados e infraestrutura de hardware como servios [Youseff et al. 2008]. Enquanto estes modelos se referem ao ncleo dos servios de computao em nuvem, suas inter-relaes tm sido ambguas

e a viabilidade de sua interoperabilidade questionvel. Alm disso, cada servio da nuvem tem interfaces e protocolos diferentes e complexo para os usurios encontrar e compor servios, visto que os diversos servios esto dispersos na Internet e possuem caractersticas distintas. Dessa forma, um desao desenvolver tcnicas ecazes para descrever, descobrir e compor servios na nuvem de forma a auxiliar os usurios em suas tarefas. Ontologias podem ser utilizadas para a organizao do domnio de conhecimento de computao em nuvem, seus componentes e suas relaes, ajudando na descrio e descoberta de servios em nuvem [Youseff et al. 2008], assim como na composio de novos servios a partir dos servios existentes. Isso ajudar no projeto de servios com interoperabilidade entre diferentes provedores, proporcionando melhorias na qualidade dos servios. Com a evoluo da computao em nuvem, as empresas necessitam integrar os diferentes ambientes de TI, pois estas empresas utilizam modelos hbridos, nos quais os sistemas instalados possam interagir com diversos provedores. Contudo, no existem padres de integrao de sistemas de computao em nuvem [OpenCloud 2010]. O formato XML pode ser uma alternativa para mover dados entre ambientes em nuvem, mas os sistemas tambm precisam gerenciar dados localmente. A utilizao de APIs pode auxiliar neste processo de integrao. Por exemplo, as APIs da Amazon esto se tornando um padro de fato para servios sob demanda. Contudo, a quantidade de tecnologias envolvidas muito grande, tornando-se um desao padronizar as diversas interfaces e servios, bem como fornecer interoperabilidade entre recursos heterogneos. Desempenho e a evoluo dos servios so aspectos importantes na integrao de nuvem, pois as aplicaes possuem requisitos de QoS e as evolues so constantes. Dessa forma, o uso de tecnologias de integrao de dados, servios e linguagens devem ser utilizadas e adaptadas no contexto da computao em nuvem. 4.4.8. Avaliao de Servios de Dados em Nuvem A avaliao de servios de dados em nuvem apresenta diferenas signicativas em relao aos SGBDs tradicionais. Sistemas tradicionais pressupem a existncia de conguraes xas de recursos, tratam exclusivamente da otimizao de desempenho e tem como objetivo minimizarem o tempo de resposta para cada requisio. Essa viso no considera os custos operacionais do sistema. Entretanto, o modelo de pagamento baseado no uso da computao em nuvem requer que custos operacionais sejam considerados juntamente com o desempenho. No ambiente em nuvem, o objetivo minimizar a quantidade de recursos necessrios para garantir uma meta de tempo de resposta para cada requisio [Florescu and Kossmann 2009]. Para garantir a disponibilidade e a tolerncia a falhas, os servios de dados em nuvem fornecem diferentes garantias de consistncia. Consistncia forte implica em alto custo por transao e, em algumas situaes, reduz a disponibilidade. Consistncia fraca apresenta menor custo, mas resulta em alto custo operacional, por exemplo, overselling de um produto em uma loja virtual. Em [Kraska et al. 2009] apresentado um novo paradigma que permite aos desenvolvedores denir garantias de consistncia e o chaveamento automtico destas garantias em tempo de execuo com o objetivo de minimizar os custos. Existem algumas iniciativas para a avaliao de servios de dados em nuvem.

[Florescu and Kossmann 2009] destacam que sistemas de benchmarks para gerenciamento de dados devem tratar de aspectos de custo, tempo de resposta, vazo, escalabilidade, consistncia, exibilidade e discutem como estes aspectos podem impactar na arquitetura dos SGBDs. [Binnig et al. 2009] discutem porque benchmarks tradicionais no so sucientes para analisar os novos servios em nuvem e apresentam idias para o desenvolvimento de um novo benchmark. Em [Cooper et al. 2010] apresentado um framewok com o objetivo de facilitar a avaliao de diferentes SGBDs em nuvem. Este framewok trata caractersticas de desempenho e escalabilidade, mas ainda no aborda aspectos de disponibilidade e replicao.

4.5. Concluso
A computao como um servio est nalmente emergindo e as empresas podem prestar servios diretamente aos usurios por meio da Internet de acordo com as suas necessidades. Neste contexto, a computao em nuvem um paradigma que est cada vez mais popular. Diversas empresas apresentaram suas iniciativas na promoo da computao em nuvem. A comunidade cientca tambm tem apresentado algumas iniciativas, principalmente com foco em suas necessidades. Este trabalho apresentou os principais aspectos de computao em nuvem, destacando o gerenciamento de dados. Foi possvel perceber que a computao em nuvem ainda no tem uma denio clara e completa na literatura, mas existe um grande esforo neste sentido. No gerenciamento de dados, SGBDs esto evoluindo rapidamente e os desenvolvedores podem escolher o modelo de dados mais adequado para suas aplicaes. No futuro, as infraestruturas sero compostas tanto por SGBDs relacionais como tambm por sistemas baseados nos modelos chave-valor, coluna, documento, grafo, entre outros. Por m, foram discutidos alguns desaos importantes no gerenciamento de dados, tais como escalabilidade, segurana, qualidade do servio de dados, entre outros. importante ressaltar que, vrias solues, existentes em outros modelos computacionais, que solucionem ou atenuem estes desaos, podem ser aplicadas em ambientes de computao em nuvem. Estes desaos geram oportunidades de pesquisa que devem ser superados, de forma que computao em nuvem seja amplamente aceita e utilizada por todos.

Referncias
[Abadi 2009] Abadi, D. J. (2009). Data management in the cloud: Limitations and opportunities. IEEE Data Eng. Bull., 32:312. [Aboulnaga et al. 2009] Aboulnaga, A., Salem, K., Soror, A. A., Minhas, U. F., Kokosielis, P., and Kamath, S. (2009). Deploying database appliances in the cloud. IEEE Data Eng. Bull., 32(1):1320. [Abouzeid et al. 2009] Abouzeid, A., Bajda-Pawlikowski, K., Abadi, D. J., Rasin, A., and Silberschatz, A. (2009). Hadoopdb: An architectural hybrid of mapreduce and dbms technologies for analytical workloads. PVLDB, 2(1):922933. [Agrawal et al. 2010a] Agrawal, D., Abbadi, A. E., Antony, S., and Das, S. (2010a). Data management challenges in cloud computing infrastructures. In Databases in Networ-

ked Information Systems, 6th International Workshop, DNIS 2010, volume 5999 of Lecture Notes in Computer Science, pages 110. Springer. [Agrawal et al. 2009] Agrawal, D., Abbadi, A. E., Emekci, F., and Metwally, A. (2009). Database management as a service: Challenges and opportunities. Data Engineering, International Conference on, 0:17091716. [Agrawal et al. 2010b] Agrawal, D., Das, S., and Abbadi, A. E. (2010b). Big data and cloud computing: New wine or just new bottles? PVLDB, 3(2):16471648. [Agrawal et al. 2008] Agrawal, R., Garcia-Molina, H., Gehrke, J., Gruenwald, L., Haas, L. M., Halevy, A. Y., Hellerstein, J. M., Ioannidis, Y. E., Korth, H. F., Kossmann, D., Madden, S., Ailamaki, A., Magoulas, R., Ooi, B. C., OReilly, T., Ramakrishnan, R., Sarawagi, S., Stonebraker, M., Szalay, A. S., Weikum, G., Bernstein, P. A., Brewer, E. A., Carey, M. J., Chaudhuri, S., Doan, A., Florescu, D., and Franklin, M. J. (2008). The claremont report on database research. ACM SIGMOD Record, 37:9. [Amazon 2010] Amazon (2010). Amazon Relational Database Service (Amazon RDS). http://aws.amazon.com/rds/. [Apache 2010] Apache (2010). Apache CouchDB. http://couchdb.apache.org. [Armbrust et al. 2009] Armbrust, M., Fox, A., Grifth, R., Joseph, A. D., Katz, R. H., Konwinski, A., Lee, G., Patterson, D. A., Rabkin, A., Stoica, I., and Zaharia, M. (2009). Above the clouds: A berkeley view of cloud computing. Technical report, EECS Department, University of California, Berkeley. [Aulbach et al. 2008] Aulbach, S., Grust, T., Jacobs, D., Kemper, A., and Rittinger, J. (2008). Multi-tenant databases for software as a service: schema-mapping techniques. In SIGMOD 08: Proceedings of the 2008 ACM SIGMOD international conference on Management of data, pages 11951206, New York, NY, USA. ACM. [Azure 2011] Azure (2011). Microsoft Azure. http://www.microsoft.com/azure/. [Binnig et al. 2009] Binnig, C., Kossmann, D., Kraska, T., and Loesing, S. (2009). How is the weather tomorrow?: towards a benchmark for the cloud. In DBTest 09: Proceedings of the Second International Workshop on Testing Database Systems, pages 16, New York, NY, USA. ACM. [Brantner et al. 2008] Brantner, M., Florescu, D., Graf, D., Kossmann, D., and Kraska, T. (2008). Building a database on s3. In Proceedings of the 2008 ACM SIGMOD international conference on Management of data - SIGMOD 08, page 251, New York. ACM Press. [Brewer 2000] Brewer, E. A. (2000). Towards robust distributed systems (abstract). In PODC, page 7. ACM. [Buyya et al. 2009] Buyya, R., Yeo, C. S., Venugopal, S., Broberg, J., and Brandic, I. (2009). Cloud computing and emerging it platforms: Vision, hype, and reality for delivering computing as the 5th utility. Future Gener. Comput. Syst., 25(6):599616.

[Candan et al. 2009] Candan, K. S., Li, W.-S., Phan, T., and Zhou, M. (2009). Frontiers in information and software as services. In ICDE 09: Proceedings of the 2009 IEEE International Conference on Data Engineering, pages 17611768, Washington, DC, USA. IEEE Computer Society. [Chang et al. 2006] Chang, F., Dean, J., Ghemawat, S., Hsieh, W. C., Wallach, D. A., Burrows, M., Chandra, T., Fikes, A., and Gruber, R. E. (2006). Bigtable: a distributed storage system for structured data. In OSDI 06: Proceedings of the 7th USENIX Symposium on Operating Systems Design and Implementation, pages 1515, Berkeley, CA, USA. USENIX Association. [Ciurana 2009] Ciurana, E. (2009). Developing with Google App Engine. Apress, Berkely, CA, USA. [Cooper et al. 2009] Cooper, B. F., Baldeschwieler, E., Fonseca, R., Kistler, J. J., Narayan, P. P. S., Neerdaels, C., Negrin, T., Ramakrishnan, R., Silberstein, A., Srivastava, U., and Stata, R. (2009). Building a cloud for yahoo! IEEE Data Eng. Bull., 32(1):36 43. [Cooper et al. 2008] Cooper, B. F., Ramakrishnan, R., Srivastava, U., Silberstein, A., Bohannon, P., Jacobsen, H.-A., Puz, N., Weaver, D., and Yerneni, R. (2008). Pnuts: Yahoo!s hosted data serving platform. PVLDB, 1(2):12771288. [Cooper et al. 2010] Cooper, B. F., Silberstein, A., Tam, E., Ramakrishnan, R., and Sears, R. (2010). Benchmarking cloud serving systems with ycsb. In SoCC 10: Proceedings of the 1st ACM symposium on Cloud computing, pages 143154, New York, NY, USA. ACM. [Curino et al. 2010] Curino, C., Jones, E., Zhang, Y., Wu, E., and Madden, S. (2010). Relational cloud: The case for a database service. Technical report, MIT-CSAIL-TR2010-014. Computer Science and Articial Intelligence Laboratory, MIT, USA. [Dean and Ghemawat 2004] Dean, J. and Ghemawat, S. (2004). Mapreduce: simplied data processing on large clusters. In OSDI04: Proceedings of the 6th conference on Symposium on Opearting Systems Design & Implementation, pages 1010, Berkeley, CA, USA. USENIX Association. [DeCandia et al. 2007] DeCandia, G., Hastorun, D., Jampani, M., Kakulapati, G., Lakshman, A., Pilchin, A., Sivasubramanian, S., Vosshall, P., and Vogels, W. (2007). Dynamo: amazons highly available key-value store. SIGOPS Oper. Syst. Rev., 41(6):205 220. [Elmore et al. 2010] Elmore, A., Das, S., Agrawal, D., and Abbadi, A. E. (2010). Whos driving this cloud? towards efcient migration for elastic and autonomic multitenant databases. Technical Report CS 2010-05, University of California, Santa Barbara, CA, USA. [Embarcadero 2010] Embarcadero (2010). Database Trends Survey Report. http://www.embarcadero.com/images/dm/technical-papers/database-survey-report.pdf .

[Florescu and Kossmann 2009] Florescu, D. and Kossmann, D. (2009). Rethinking cost and performance of database systems. SIGMOD Rec., 38(1):4348. [Ghemawat et al. 2003] Ghemawat, S., Gobioff, H., and Leung, S.-T. (2003). The google le system. SIGOPS Oper. Syst. Rev., 37(5):2943. [Gilbert and Lynch 2002] Gilbert, S. and Lynch, N. (2002). Brewers conjecture and the feasibility of consistent, available, partition-tolerant web services. SIGACT News, 33(2):5159. [Hadoop 2010] Hadoop (2010). Apache Hadoop. http://hadoop.apache.org. [Hui et al. 2009] Hui, M., Jiang, D., Li, G., and Zhou, Y. (2009). Supporting database applications as a service. In ICDE 09: Proceedings of the 2009 IEEE International Conference on Data Engineering, pages 832843, Washington, DC, USA. IEEE Computer Society. [Jacobs and Aulbach 2007] Jacobs, D. and Aulbach, S. (2007). Ruminations on multitenant databases. In BTW, volume 103 of LNI, pages 514521. GI. [Kossmann et al. 2010] Kossmann, D., Kraska, T., and Loesing, S. (2010). An evaluation of alternative architectures for transaction processing in the cloud. In SIGMOD 10: Proceedings of the 2010 international conference on Management of data, pages 579 590, New York, NY, USA. ACM. [Kraska et al. 2009] Kraska, T., Hentschel, M., Alonso, G., and Kossmann, D. (2009). Consistency rationing in the cloud: Pay only when it matters. PVLDB, 2(1):253264. [Lakshman and Malik 2010] Lakshman, A. and Malik, P. (2010). Cassandra: a decentralized structured storage system. SIGOPS Oper. Syst. Rev., 44(2):3540. [Liu et al. 2007] Liu, S., Liang, Y., and Brooks, M. (2007). Eucalyptus: a web serviceenabled e-infrastructure. In CASCON 07: Proceedings of the 2007 conference of the center for advanced studies on Collaborative research, pages 111, New York, NY, USA. ACM. [Mell and Grance 2009] Mell, P. and Grance, T. (2009). Draft NIST Working Denition of Cloud Computing. National Institute of Standards and Technology. http://csrc.nist.gov/groups/SNS/cloud-computing. [Microsoft 2010] Microsoft (2010). Architecture Strategies for Catching the Long Tail. http://msdn.microsoft.com/en-us/library/aa479069.aspx. [Neo 2010] Neo (2010). Neo4j - Graph Database. http://neo4j.org. [NoSQL 2010] NoSQL (2010). NoSQL East. http://nosqleast.com. [Olston et al. 2008] Olston, C., Reed, B., Srivastava, U., Kumar, R., and Tomkins, A. (2008). Pig latin: a not-so-foreign language for data processing. In SIGMOD 08: Proceedings of the 2008 ACM SIGMOD international conference on Management of data, pages 10991110, New York, NY, USA. ACM.

[OpenCloud 2010] OpenCloud (2010). http://www.opencloudmanifesto.org.

The

Open

Could

Manifesto.

[Paton et al. 2009] Paton, N. W., Arago, M. A. T., Lee, K., Fernandes, A. A. A., and Sakellariou, R. (2009). Optimizing utility in cloud computing through autonomic workload execution. IEEE Data Eng. Bull., 32(1):5158. [Pritchett 2008] Pritchett, D. (2008). Base: An acid alternative. Queue, 6(3):4855. [Reinwald 2010] Reinwald, B. (2010). Database support for multi-tenant applications. In IEEE Workshop on Information and Software as Services (WISS). Co-located with ICDE. [Robinson 2008] Robinson, D. (2008). Amazon Web Services Made Simple: Learn how Amazon EC2, S3, SimpleDB and SQS Web Services enables you to reach business goals faster. Emereo Pty Ltd, London, UK, UK. [Rodriguez and Neubauer 2010] Rodriguez, M. A. and Neubauer, P. (2010). Constructions from dots and lines. Bulletin of the American Society for Information Science and Technology, 36(6):3541. [Rogers et al. 2010] Rogers, J., Papaemmanouil, O., and Cetintemel, U. (2010). A generic auto-provisioning framework for cloud databases. In IEEE 26th International Conference on Data Engineering Workshops (ICDEW), pages 63 68. [Schad et al. 2010] Schad, J., Dittrich, J., and Quian-Ruiz, J.-A. (2010). Runtime measurements in the cloud: Observing, analyzing, and reducing variance. PVLDB, 3(1):460471. [Schroeder et al. 2006] Schroeder, B., Harchol-Balter, M., Iyengar, A., and Nahum, E. (2006). Achieving class-based qos for transactional workloads. In Proceedings of the 22nd International Conference on Data Engineering, ICDE 06, pages 153, Washington, DC, USA. IEEE Computer Society. [Soror et al. 2010] Soror, A. A., Minhas, U. F., Aboulnaga, A., Salem, K., Kokosielis, P., and Kamath, S. (2010). Automatic virtual machine conguration for database workloads. ACM Trans. Database Syst., 35(1):147. [Sousa et al. 2009] Sousa, F. R. C., Moreira, L. O., and Machado, J. C. (2009). Computao em Nuvem: Conceitos, Tecnologias, Aplicaes e Desaos. In: MOURA, R. S. (Org.) ; SOUZA, F. V. (Org.) ; OLIVEIRA, A. C. (Org.). Escola Regional de Computao (Cear, Maranho e Piau, ERCEMAPI 2009, 1. ed. EDUFPI, Piau. [Stonebraker 2010] Stonebraker, M. (2010). Sql databases v. nosql databases. Commun. ACM, 53(4):1011. [Vaquero et al. 2009] Vaquero, L. M., Rodero-Merino, L., Caceres, J., and Lindner, M. (2009). A break in the clouds: towards a cloud denition. SIGCOMM Comput. Commun. Rev., 39(1):5055.

[Vecchiola et al. 2009] Vecchiola, C., Chu, X., and Buyya, R. (2009). Aneka: A Software Platform for .NET-based Cloud Computing, pages 267295. In: W. Gentzsch, L. Grandinetti, G. Joubert (Eds.). High Speed and Large Scale Scientic Computing. IOS Press, Amsterdam, Netherlands. [Vogels 2009] Vogels, W. (2009). Eventually consistent. Commun. ACM, 52(1):4044. [Voicu and Schuldt 2009] Voicu, L. C. and Schuldt, H. (2009). How replicated data management in the cloud can benet from a data grid protocol: the re:gridit approach. In CloudDB 09: Proceedings of the First International Workshop on Cloud Data Management, pages 4548, New York, NY, USA. ACM. [Wei et al. 2009] Wei, Z., Pierre, G., and Chi, C.-H. (2009). Scalable transactions for web applications in the cloud. In Euro-Par, pages 442453. [Weissman and Bobrowski 2009] Weissman, C. D. and Bobrowski, S. (2009). The design of the force.com multitenant internet application development platform. In SIGMOD 09: Proceedings of the 35th SIGMOD international conference on Management of data, pages 889896, New York, NY, USA. ACM. [Yang et al. 2009] Yang, F., Shanmugasundaram, J., and Yerneni, R. (2009). A scalable data platform for a large number of small applications. In CIDR 2009, Fourth Biennial Conference on Innovative Data Systems Research, Asilomar, CA, USA, Online Proceedings, pages 110. [Youseff et al. 2008] Youseff, L., Butrico, M., and Da Silva, D. (2008). Toward a unied ontology of cloud computing. In Grid Computing Environments Workshop, 2008. GCE 08, pages 110. [Zhang et al. 2010] Zhang, Q., Cheng, L., and Boutaba, R. (2010). Cloud computing: state-of-the-art and research challenges. Journal of Internet Services and Applications, 1:718.