FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS DANIEL DA SILVA NAITO EDER VINÍCIUS ROSA

Transcrição

1 FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS DANIEL DA SILVA NAITO EDER VINÍCIUS ROSA UTILIZAÇÃO DE BANCO DE DADOS EM COMPUTAÇÃO NAS NUVENS SÃO JOSÉ DOS CAMPOS 2010

2 II DANIEL DA SILVA NAITO EDER VINÍCIUS ROSA UTILIZAÇÃO DE BANCO DE DADOS EM COMPUTAÇÃO NAS NUVENS Trabalho de graduação apresentado à Faculdade de Tecnologia de São José dos Campos, como parte dos requisitos necessários para obtenção de título de Tecnólogo em Banco de Dados. Orientador: Msc. Fernando Masanori Ashikaga SÃO JOSÉ DOS CAMPOS 2010

3 III DANIEL DA SILVA NAITO EDER VINÍCIUS ROSA UTILIZAÇÃO DE BANCO DE DADOS EM COMPUTAÇÃO NAS NUVENS Trabalho de graduação apresentado à Faculdade de Tecnologia de São José dos Campos, como parte dos requisitos necessários para obtenção de título de Tecnólogo em Banco de Dados. MSC. ÉRICA FERREIRA DE SOUZA DR. REINALDO GEN ICHIRO ARAKAKI MSC. FERNANDO MASANORI ASHIKAGA / / DATA DE APROVAÇÃO

4 IV AGRADECIMENTOS Agradecemos a todos os docentes e colaboradores da FATEC São José dos Campos, em especial ao nosso professor e orientador Fernando Masanori Ashikaga que sempre com entusiasmo e novas idéias, nos motivou durante a construção deste trabalho, não esquecendo também do nosso professor Giuliano Araujo Bertoti pela amizade e apoio dado. Dedicamos esse trabalho a nossos familiares e amigos, que nos motivaram e apoiaram nessa importante fase de nossas vidas. Obrigado!

5 V Uma vida sem desafios não vale a pena ser vivida Sócrates

6 VI RESUMO Na era da Web 2.0 a massa de dados cresce consideravelmente a cada dia e a dependência da grande rede de computadores aumenta, tornando o acesso à informação algo extremamente necessário. Com a necessidade de aplicações cada vez mais portáveis, que possam ser acessadas e utilizadas por dispositivos com diferentes arquiteturas como smartphones, notebooks ou qualquer aparelho que possua conexão com a rede, surge o conceito de cloud computing, ou computação nas nuvens, que propõe a utilização remota de aplicativos e dados através de qualquer dispositivo conectado a Internet, sendo estes dados processados e armazenados em servidores remotos. Um exemplo do paradigma da computação em nuvens é o . Anteriormente para sua utilização era necessário a instalação de um software que realizava o recebimento das mensagens no computador local, agora é possível visualizar e editar as mensagens diretamente da web sem necessidade de algum software adicional, sendo os dados armazenados em servidores remotos. Com grande quantidade de dados armazenados nas nuvens, surge a necessidade de um novo modelo de banco de dados, focando seu desempenho na busca de dados, surgindo assim os bancos de dados orientados a colunas, os chamados NOSQL. Este trabalho tem por fim apresentar o desenvolvimento de uma aplicação utilizando o banco de dados orientado a colunas, padrão em diversas plataformas de computação nas nuvens, utilizando uma base de dados real com uma grande quantidade de dados. Palavras-Chave: computação nas nuvens, web 2.0, nosql, banco de dados colunar, desenvolvimento web

7 VII ABSTRACT In the 2.0 Web age the data mass grows every day substantially and dependency on large interconnected computer networks increases making access to information a very necessary benefit. With the need for increasingly portable applications which can be accessed and used by devices with different architectures such as smartphones, laptops or any other device with a network connection, the concept of cloud computing arises proposing the use of remote applications and data via any device connected to the Internet, this data being processed and stored on remote servers. An example of the cloud computing paradigm is the , on it s early stages the installation of a software to perform the receipt of messages was necessary locally, nowadays you can view and edit messages directly from the web with no need for any additional software and with data stored on remote servers. With large amounts of data being stored in the clouds, the need for a new type of database appears with it s focus on data searching performance, thus creating the column-oriented databases, known as NOSQL. This paper aims to present the development of an application using the column-oriented database, a standard on several cloud computing platforms, using a real data-source with a large amount of data. Key-Words: cloud computing, web 2.0, nosql, column database, web development

8 VIII SUMÁRIO 1. INTRODUÇÃO: Motivação Objetivos Objetivo Geral Objetivos Específicos Metodologias Organização do Trabalho COMPUTAÇÃO NAS NUVENS O que é Computação nas Nuvens? Funcionamento da Computação nas Nuvens Modelos de implantação de Computação nas Nuvens Public Cloud Private Cloud Community Cloud Hybrid Cloud Intercloud Camadas de Arquitetura de Serviços IaaS PaaS SaaS Servidores de Aplicações nas Nuvens App Engine Amazon EC

9 IX Locaweb Azure Aplicações web Inteligência coletiva por Wikis e Folksonomia Mash-ups, AdSense e RSS Redes sociais Flickr, YouTube, Orkut e Twitter Aplicativos nas nuvens Photoshop Online Google Docs Best Buy Giftag Onlive Considerações Finais BANCO DE DADOS NAS NUVENS Ambiente de Armazenamento de Dados do App Engine: Mudança de Paradigma Bigtable Entidades e Modelos Interface Model Modelo Expando Modelo Polimórfico Propriedades e Tipos Chaves e Grupos de Entidades Consultas e Índices Referência de GQL... 56

10 X 3.2. Ferramentas do App Engine Servidor de Desenvolvimento Envio de dados em Massa Considerações Finais ESTUDO DE CASO: DESENVOLVIMENTO DE UMA APLICAÇÃO COM BANCO DE DADOS EM COMPUTAÇÃO NAS NUVENS Cenário do Estudo de Caso Desenvolvimento Desenvolvimento do Aplicativo A Base de Dados Armazenamento de Dados nas Nuvens Preparação dos Dados Execução Envio de Dados para as Nuvens Envio dos Dados Para as Nuvens Realização de Teste Considerações Finais CONCLUSÃO Conclusões Contribuições Trabalhos Futuros REFERÊNCIAS BIBLIOGRÁFICAS... 86

11 XI LISTA DE FIGURAS Figura 1 - Arquitetura de uma aplicação Web Figura 2 - Arquitetura do Google App Engine Figura 3 - Ranking das 10 tecnologias estratégicas para Figura 4 - Ilustração de uma Nuvem servindo aplicativos a diversos dispositivos Figura 5 - Public Cloud Figura 6 - Private Cloud Figura 7 - Community Cloud Figura 8 - Funcionamento da Hybrid Cloud Figura 9 - Camadas de arquitetura de serviço Figura 10 - Console de administração de aplicativos do App Engine Figura 11 - Linha de serviços oferecidos pela plataforma Azure Figura 12 - Comparação entre diferentes plataformas de cloud computing Figura 13 - Foto sendo editada com ferramentas do Photoshop Online Figura 14 - Imagem da tela do editor de texto do Google Docs Figura 15 - Giftag Figura 16 - Pagina web com demonstrativo do funcionamento do sistema Onlive Figura 17 - Publicações: Banco de Dados Relacional vs. Banco de Dados Orientado a Colunas Figura 18 - Ilustração de uma entidade Figura 19 - Código na linguagem Pyhton da entidade Pessoa Figura 20 - Demonstração de uma classe Expando Figura 21 - Entidade polimórfica Figura 22 - Dados suportados pelo App Engine... 54

12 XII Figura 23 - Consulta GQL Figura 24 - Consulta GQL com valor de filtro alterado Figura 25 - Consulta GQL ao banco de dados Figura 26 - Consulta GQL utilizando o operador IN Figura 27 - Entidades resgatadas pela consulta com utilização do operador IN Figura 28 - Launcher de aplicativos do App Engine Figura 29 - Console de administrador do App Engine Figura 30 - Classe modelo Figura 31 - Classe carregadora de dados Figura 32 - Limites diários do App Engine Figura 33 - Limites diários do App Engine Figura 34 - Arquivo app.yaml Figura 35 - Classe de definição de modelos de entidade Figura 36 - Classe carregadora Figura 37 - Modelo Entidade-Relacionamento Figura 38 - SQL que converte dados em arquivo CSV Figura 39 - Função lambda de conversão de codificação Figura 40 - Chamada à função lambda Figura 41 - Formulário para registro de nova aplicação Figura 42 - Envio da aplicação para o App Engine Figura 43 - Conexão com servidor Figura 44 - Visão do Console Administrativo do App Engine Figura 45 - Mapeamento do remote_api Figura 46 - Comando upload_data Figura 47 - Uso Máximo de CPU nas Cotas Gratuitas... 79

13 XIII Figura 48 - Mensagem de Erro ao Tentar Visualizar as Estatísticas Figura 49 - Gráfico Estatístico Gerado no App Engine Figura 50 - Espaço Total Utilizado Pela Aplicação Figura 51 - Consulta GQL Figura 52 - Recuperação de dados e soma do potencial de lucro Figura 53 - Resultado obtido após a realização de teste... 82

14 XIV LISTA DE ABREVIATURAS E SIGLAS AMI - Amazon Machine Image ASCII - American Standard Code for Information Interchange API - Application Programming Interface AWS - Amazon Web Services CPU - Central Processing Unit CRM - Customer Relationship Management CSS - Cascading Style Sheets CSV - Comma Separated Values DNA - Deoxyribonucleic acid EC2 - Elastic Cloud Computing GB - Gigabyte GNU - GNU is Not Unix GPL - General Public license GQL - Google Query Language HTML - HyperText Markup Language IAAS - Infrastructure as a Service JVM - Java Virtual Machine NOSQL - Not Only Structured Query Language PAAS - Platform as a Service PC - Personal Computer RSS - Really Simple Syndication SAAS - Software as a Service SDK - Software Development Kit SGBD - Sistema Gerenciador de Banco de Dados SQL - Structured Query Language URL - Uniform Resource Locator UTF-8-8-bit Unicode Transformation Format XML - Extensible Markup Language YAML - YAML Ain't Markup Language

15

16 15 1. INTRODUÇÃO: 1.1. Motivação Na era em que vivemos o acesso a informação é algo extremamente necessário, imagine se ao fazer uma viagem de negócios ou para uma apresentação você percebe que se esqueceu de uma planilha de dados salvo no seu computador de mesa que está a quilômetros de distância, ou então, por alguma razão, você necessite de um software para edição de uma imagem, mas não tem o mesmo instalado no seu computador portátil. Esses são só alguns exemplos, mas possivelmente muitas pessoas passam por situações assim no cotidiano. Com a necessidade de aplicações e dados cada vez mais portáveis, surge então o conceito de Computação nas Nuvens, que promete mudar o paradigma de comercialização e utilização de softwares (HAYES, 2008). O conceito aplica-se a idéia de que o computador uma vez conectado a rede possa requisitar acesso e utilização de aplicativos disponíveis em servidores remotos, provendo assim economia de recursos tanto de armazenamento quanto processamento por parte do usuário (CUSUMANO, 2010). O desenvolvimento de aplicações web possui uma arquitetura complicada, pois são desenvolvidas visando uma única máquina ou processo (REPASS, 2009). Porém cada máquina possui limitações físicas e para resolver este problema é necessária a adição de novas máquinas, assim gerando complexidade no desenvolvimento. A Figura 1 mostra a arquitetura do web site LiveJournal ( o retângulo vermelho apresenta os frontends.os retângulos em verde apresentam os servidores de aplicativos, o localizado no inferior do diagrama apresenta os servidores de aplicativos estáticos (HTML, CSS, etc) e o superior apresenta arquivos dinâmicos. Os retângulos em azul apresentam a camada de dados, apresentando a divisão de clusters de usuários em vários dispositivos, a definição do banco de dados central:

17 16 Figura 1 - Arquitetura de uma aplicação Web Fonte: (FITZPATRICK, 2007) Para simplificar o processo, algumas soluções na computação nas nuvens propõem uma maneira simplificada para o desenvolvimento do aplicativo web. Como exemplo disto o Google App Engine. A Figura 2 apresenta a arquitetura do App Engine, com os frontends que comunicam com servidores de aplicação, que por sua vez se comunicam com serviços disponíveis no Google App Engine, entre eles a Bigtable, o banco de dados utilizado em diversas aplicações da Google (CHANEZON, 2009):

18 17 Figura 2 - Arquitetura do Google App Engine Fonte: (CHANEZON, 2009) O webmail é um exemplo de computação nas nuvens, anteriormente para visualizar um , o usuário necessitava utilizar um software específico para baixar as mensagens recebidas e visualizá-las. Hoje as mensagens são armazenadas diretamente em um servidor nas nuvens e podem ser visualizadas por qualquer dispositivo com acesso a rede (computadores domésticos, celulares, etc.) (VILARIN, 2009). As vantagens dos serviços de computação nas nuvens para empresas são inúmeras, como por exemplo, a redução de custos da compra de servidores (VAQUERO, 2008), o custo que uma empresa teria para contratar e treinar funcionários para manter esses servidores, além da energia elétrica e espaço físico utilizados, a reparação de peças que venham dar defeito, o backup dos arquivos, já na computação nas nuvens isso tudo fica a cargo da fornecedora do serviço, custando ao cliente somente a cobrança pelo plano de serviços, que é cobrado em muitos casos por somente o que ele utilizar (FOUQUET, 2009), como é o caso dos serviços básicos de água, luz e gás e ainda de forma elástica e escalável os recursos podem aumentar e diminuir conforme a demanda.

19 18 A pirataria é outro ponto que pode ser atacado por essa tendência, pois o software pode ser disponibilizado como serviço e não como produto, não podendo ser copiado e vendido no mercado paralelo, assim você teria acesso aos recursos pela sua conta, em qualquer dispositivo conectado a internet (MICROSOFT, 2010b). Segundo a Gartner o setor de Computação nas Nuvens até 2013 movimentará uma receita de US$ 150 bilhões, sendo atualmente um dos itens de maior prioridade na pauta dos CIOs de todo mundo como mostra a Figura 3 (GARTNER, 2009). Figura 3 - Ranking das 10 tecnologias estratégicas para 2010 Fonte: (GARTNER, 2009) Em uma pesquisa realizada pela empresa de consultoria Gartner, o tema Cloud Computing apareceu em primeiro lugar para tecnologias estratégicas para 2010.

20 Objetivos trabalho. A seguir serão expostos os objetivos gerais e os objetivos específicos deste Objetivo Geral Desenvolver e configurar uma aplicação para ser executada no ambiente nas nuvens utilizando uma grande base de dados real Objetivos Específicos necessárias: Para alcançarmos o objetivo desse trabalho, as seguintes etapas são a) Transformar uma densa base de dados de arquitetura relacional para orientação colunar; b) Transferir esses dados para um servidor nas nuvens da Google; c) Utilizar GQL (Google Query Language) para realização de testes no banco de dados; d) Desenvolver um aplicativo para uso da base de dados;

21 Metodologias O servidor de computação nas nuvens que será utilizado no projeto é o App Engine, da empresa Google, que nos permite hospedar gratuitamente aplicações que sejam processadas em seus servidores com limite de aplicações e largura de banda. O Google App Engine nos proporciona um servidor de aplicações nas nuvens alocado na infra-estrutura da Google, com possibilidade de aumento de capacidade de processamento por demanda. Um dos pontos onde a Google aposta ser o diferencial da App Engine é a sua facilidade de uso, depois de enviado o aplicativo para o Google App Engine, não é necessário se preocupar em administrar o sistema, produzir instâncias do aplicativo, particionar o banco de dados ou comprar máquinas, o serviço já é disponibilizado pela Google (GOOGLE, 2010). Para novos aplicativos é também disponibilizado um período de avaliação sem riscos, onde o desenvolvedor pode divulgar o aplicativo para teste que as pessoas utilizarão sem nenhum custo ou compromisso. Um ponto forte fornecido pelo App Engine é a escalabilidade automática, onde usuários podem utilizar tecnologias desenvolvidas para aplicativos do Google, como a Bigtable. O escalamento é automático e realizado pelo Google App Engine, independente do tamanho do aplicativo ou do número de acessos Organização do Trabalho A seguir serão apresentados os demais capítulos deste trabalho: a) O Capítulo 2 apresenta uma visão da Computação em Nuvens e da Web 2.0 e suas principais tecnologias; b) O Capítulo 3 apresenta uma visão do Ambiente de Armazenamento de Dados do App Engine e ferramentas disponíveis na SDK do App Engine;

22 21 c) O Capítulo 4 apresenta o cenário do estudo de caso e desenvolvimento do protótipo; d) O Capítulo 5 apresenta a conclusão deste trabalho de graduação;

23 22 2. COMPUTAÇÃO NAS NUVENS Este capítulo apresentará a definição de computação nas nuvens, o seu funcionamento, os seus modelos de implementação, aplicações alocadas nas nuvens, camadas de arquitetura e serviços e suas definições e servidores mais utilizados atualmente. O capítulo também apresentará uma visão sobre a web 2.0 e suas aplicações. Este capítulo está organizado como segue: na Seção 2.1 é apresentado o conceito de Computação nas Nuvens e suas tecnologias e na Seção 2.2 é apresentado o conceito de Web 2.0 e suas tecnologias O que é Computação nas Nuvens? A Computação nas Nuvens é um termo utilizado para descrever a disponibilização de aplicações via web que são processadas diretamente em servidores além do armazenamento dos dados, tendo como a única necessidade para o usuário a conexão com a Internet, pois não será mais necessária a instalação de softwares no computador. A internet se tornará uma grande plataforma completa de aplicações que fornecerá ao usuário, por demanda, o software necessário para realização da atividade que necessita (FRAGA, 2008). A definição de Computação nas Nuvens é divergente, muitos definem que será a próxima geração da internet, onde na verdade é somente um conjunto adicional de serviços que complementam a forma de distribuição, para aumentar sua abrangência. Alguns autores definem como uma fonte de recursos gratuitos, onde na verdade por estar na rede, não significa que será necessariamente gratuito, poderá baratear o custo de utilização por demanda, porém poderá ainda não ser completamente gratuito (TAURION, 2009).

24 Funcionamento da Computação nas Nuvens O termo Computação nas Nuvens torna-se cada vez mais popular, onde é criado um ambiente de armazenamento em servidores remotos segundo BARROS(2008), causando a ilusão da disponibilidade de recursos infinitos para os usuários, visto que os mesmos não conseguem visualizar onde estão armazenados estes recursos (TAURION, 2009) surgindo daí o termo armazenamento em nuvens computacionais (BARROS, 2008). Computação em Nuvens é agregada de diferentes redes (acadêmicas e comerciais), e existem centenas de milhares de usuários e desenvolvedores que armazenam ou utilizam de arquivos alocados na nuvem computacional (DELIC, 2008). Um exemplo disto é o , anteriormente era necessário que o software de s estivesse instalado no computador para o recebimento das mensagens, o destinatário recebia as mensagens e as armazenava em seus computadores. Com o surgimento dos s, não existe mais a necessidade de instalação de um software receptor de s, os s são enviados e armazenados em servidores remotos, a visualização pode ser realizada diretamente pela internet (VILARIN, 2009). Outro exemplo de aplicações nas nuvens é o denominado Google Docs que permite ao usuário digitar, formatar e editar documentos, inteiramente via web. Os aplicativos editores de documentos há pouco tempo atrás eram somente executados em computadores locais, o Google Docs permite a utilização deste recurso via web, com armazenamento em servidores remotos (HAYES, 2008). No modelo tradicional de computação, cada software necessita de configuração e instalação e a cada atualização do sistema operacional, gerando em cascata diversas revisões do software. Com a computação nas nuvens esse modelo é quebrado, como o programa utiliza a infra-estrutura do servidor nas nuvens somente será revisado se esta tiver modificações, gerando assim ao usuário final vantagens em termos de mobilidade (HAYES, 2008). Para os desenvolvedores de software, que movem suas aplicações para a nuvem, a vantagem que o modelo fornece é similar aos do usuário final. Quando um software é desenvolvido, o aplicativo é vendido como um produto a ser instalado no computador do usuário, ou seja, devem-se criar versões para diversos sistemas operacionais e infra-estruturas. Com o modelo em nuvens, basta que o desenvolvedor crie uma aplicação, teste e rode a aplicação na plataforma que escolher e disponibilizar na nuvem para que usuários a utilizem, a Figura 4 ilustra esta exemplificação.

25 24 Figura 4 - Ilustração de uma Nuvem servindo aplicativos a diversos dispositivos Na figura acima diversos dispositivos acessam uma nuvem computacional para ter acesso aos dados e aplicativos que desejam utilizar. Portanto a computação nas nuvens pode ser um promissor paradigma na área de computação (STATEN, 2008) Modelos de implantação de Computação nas Nuvens Atualmente são consideradas quatro formas para implantação e disponibilização dos serviços de Computação nas Nuvens, além de uma quinta possibilidade futura, a seguir são descritos esses modelos (AMRHEIN, 2010).

26 Public Cloud Esse é o modelo padrão disponível, no qual o acesso é aberto ao público de uma maneira geral, sendo vendido como um serviço cobrado por uso de espaço de armazenamento ou processamento, podendo ser disponibilizado gratuitamente (ARMBRUST, 2010). Figura 5 - Public Cloud Fonte: (Amrhein, 2010) A Figura 5 ilustra o acesso a uma nuvem computacional compartilhada entre usuários comuns e empresas. O termo público, não significa que os dados de um usuário ficam disponíveis a todos os outros e sim que compartilham a mesma nuvem para armazenamento e processamento (AMRHEIN, 2010).

27 Private Cloud A Private Cloud é o modelo de nuvem que opera somente dentro de uma organização, não disponibilizando os recursos de forma externa, esse modelo é utilizado muitas vezes para segurança de dados, tendo uma infra-estrutura dedicada (ARMBRUST, 2010). Figura 6 - Private Cloud Fonte: (Amrhein, 2010) A Figura 6 ilustra uma Private Cloud sendo utilizada unicamente pela empresa, a qual outros usuários não possuem acesso. Não significando necessariamente que a mesma esteja alocada fisicamente dentro da empresa, podendo ser vendida como serviço de servidores totalmente dedicados (AMRHEIN, 2010).

28 Community Cloud O modelo Community é utilizado por empresas ou grupos que queiram compartilhar os recursos de suas nuvens entre si (AMRHEIN, 2010). Figura 7 - Community Cloud Fonte: (Amrhein, 2010) pelos mesmos. A Figura 7 ilustra o acesso por diversos usuários a nuvens compartilhadas Hybrid Cloud Uma forma de manter o controle dos dados e mesmo assim disponibilizar o acesso de serviços pode ser utilizando a Nuvem Híbrida, que une a Private Cloud com a Public Cloud ou Community Cloud (AMRHEIN, 2010), criando uma nuvem com servidores dedicados ao publico e a empresa garantindo segurança a seus dados (KRANGEL, 2009), a Figura 8 mostra o conceito do seu funcionamento:

29 28 Figura 8 - Funcionamento da Hybrid Cloud Fonte: (Johnston, 2009) publica. Na figura 8 a empresa mantém uma nuvem privada e tem acesso a uma nuvem Intercloud A Intercloud é um termo utilizado para definir o possível futuro da Computação nas Nuvens, se referindo a nuvem de nuvens, ou união de diversas nuvens para compartilhamento de recursos entre os servidores, tornando assim quase infinita a quantidade de recursos disponíveis (KELLY, 2007).

30 Camadas de Arquitetura de Serviços Para compreendermos a computação nas nuvens é necessário o conhecimento de suas camadas. A mais baixa é a camada de hardware, onde temos dispositivos de armazenamento e processamento. A segunda camada, a de plataforma, é o ambiente que será disponibilizado para o desenvolvimento do aplicativo. Enquanto a terceira camada, a de software, mais próxima do usuário, disponibiliza o software por demanda, atendendo assim as necessidades de cada usuário (MULHOLLAND, 2008). A Figura 9 representa para cada tipo de serviço, suas principais aplicações: Figura 9 - Camadas de arquitetura de serviço Fonte: (GARTNER, 2009)

31 IaaS IaaS (Infrastructure as a Service ou Infraestrutura como Serviço) é representada pela infraestrutura disponibilizada por demanda. Ao invés do usuário comprar ou alugar grandes plataformas de servidores, ou montar grandes Data Centers, para armazenamento de seus aplicativos, ele somente paga pelo uso dos recursos conforme a necessidade (WIKIPEDIA, 2010a). A infraestrutura como serviço também propõe os dados centralizados de forma transparente em um serviço, levando como exemplo a Amazon (CREEGER, 2009). Este tipo de serviço é oferecido por empresas como a Amazon com o EC2 (Elastic Compute Cloud), onde conforme a demanda, o cliente pode solicitar a utilização de uma infraestrutura maior, pagando somente pelo que é solicitado, com possibilidade de execução em computação paralela, reduzindo assim o custo da alocação do aplicativo (AMAZON, 2010a). Quando usuários apresentam uma grande demanda, não é necessário o investimento em novos equipamentos de hardware, podem somente solicitar os recursos nas nuvens, customizando o ambiente de acordo com a necessidade da aplicação. A utilização da infraestrutura como serviço torna-se uma alternativa de economia, pois o usuário paga somente pelo que é utilizado (ASSUNÇÃO, 2009) PaaS PaaS (Plataform as a Service ou Plataforma como Serviço) é a camada intermediária da arquitetura de Computação nas Nuvens. Esta arquitetura define o ambiente onde será desenvolvida a aplicação (LAWTON, 2008). O modelo também fornece API s por demanda, à medida que necessária, fornecendo assim um ambiente de alto nível para aplicações customizadas alocadas na nuvem.

32 31 Uma plataforma que utiliza o modelo PaaS é o Google App Engine, que disponibiliza gratuitamente, com algumas limitações, um ambiente com API s on demand. (SCHOFIELD, 2008) A vantagem no desenvolvimento de aplicativos nas plataformas como serviço é de que a própria plataforma se encarrega de determinar o comportamento em diferentes sistemas operacionais, lidar com linguagem de programação e acesso a recursos específicos. Deixando o desenvolvedor livre desta tarefa (LAWTON, 2008) SaaS A arquitetura SaaS (Software as a Service), é a terceira camada de computação nas nuvens onde o software é oferecido como serviço. É o modelo que se aplica a programas desenvolvidos em diversas linguagens que rodam em servidores web e são acessados via internet (VAQUERO, 2008). Esta camada vem a cada dia sendo mais utilizada por empresas. Voltado para pequenas e médias empresas o modelo vem também sendo utilizado cada vez mais por grandes empresas (DYM, 2009). O modelo SaaS propõe que o usuário somente pague o serviço que utilizar, não é necessária a compra do produto, à partir do momento em que o software é hospedado na nuvem, o usuário terá acesso aos recursos sob demanda. Existe também a vantagem de que o software não necessitará de novas atualizações a cada nova configuração do sistema operacional, uma vez alocada no servidor, o próprio fabricante do software realizará esta tarefa. O modelo promete acabar com o modelo atual de softwares instalados no desktop e dominar o mercado com flexibilidade, menor custo e menor manutenção. A arquitetura SaaS foi proposta primeiramente pela empresa americana Salesforce.com ao desenhar toda estratégia na entrega de software pela web (LAPLANTE, 2010).

33 Servidores de Aplicações nas Nuvens Diversos data centers de computação nas nuvens vem sendo desenvolvidos em diversas localidades, abrindo espaço para desenvolvedores alocarem aplicativos na nuvem computacional (ARMBRUST, 2009). Na Subseção até a Subseção serão apresentados os principais servidores de computação nas nuvens disponíveis App Engine O App Engine é a plataforma da Google para Computação nas Nuvens, que utiliza a infra-estrutura da própria empresa para armazenamento e processamento de aplicativos. Sua base de armazenamento baseia-se na Bigtable, uma arquitetura de dados orientada a colunas proprietária, desenvolvida para armazenar uma quantidade gigantesca de dados, na ordem dos petabytes e ainda ter um ótimo desempenho, a linguagem utilizada para consultas é o GQL (GOOGLE, 2010). O Google fornece uma série de API s que facilitam o desenvolvimento dos aplicativos, além de disponibilizar uma conta gratuita com uma limitada quantidade de armazenamento e processamento, porém o suficiente para aplicações que utilizem até 5 milhões de page views por mês (BUYYA, 2008). As linguagens atualmente aceitas pela AppEngine são Python na versão 2.5 e Java, mas a segunda ainda não possui o mesmo suporte, os frameworks de Python aceitos são Django, CherryPy, Pylons, e web2py, já os que utilizam da tecnologia JVM são Groovy, JRuby, Scala e Clojure. O App Engine tem como foco a plataforma como serviço, disponibilizando um console de administração de aplicações web, como visto na Figura 10:

34 33 Figura 10 - Console de administração de aplicativos do App Engine Amazon EC2 Em 2002 a empresa de e-commerce Amazon.com criou o Amazon Web Services (AWS), com serviços de computação nas nuvens (AMAZON, 2010a), recebendo o nome de Elastic Cloud Computing (Computação nas Nuvens Elástica), ou seja, ele pode se expandir e diminuir conforme a demanda, pois seu serviço é realizado através de instâncias conhecidas como AMI (Amazon Machine Image) (ARMBRUST, 2010), que são na verdade máquinas virtuais, possibilitando que mais AMIs sejam utilizadas caso aumente o numero de requisições dos usuários, além disso é utilizado o Amazon Simple Storage Service (Amazon S3, Serviço de Armazenamento Simples) que facilita a elasticidade do armazenamento de dados do sistema (BUYYA, 2008). Cada unidade de computação EC2 equivale a um processador com 1.0 a 1.2 GHz 2007 Opteron ou 2007 Xeon (AMAZON, 2010b).

35 34 por categorias: As configurações de instâncias são disponibilizadas em 8 modelos, divididos a) Padrão: m1.small, m1.large, m1.xlarge; b) Memória: m2.xlarge, m2.2xlarge, m2.4xlarge; c) CPU: c1.medium, c1.xlarge; O modelo inicial de AMI, m1.small possui a seguinte configuração: a) 1,7 GB memória; b) 1 unidade de computação EC2; c) 160 GB para armazenamento (sendo 10 GB reservados para partição raiz); d) Plataforma 32-bit; e) Recursos de I/O: Moderado; Para usuários que necessitem de máquinas mais poderosas, para aplicações que possuam grande vazão de dados como banco de dados, podem optar pelo modelo m2.4xlarge: a) 68.4 GB de memória; b) 26 unidades de computação EC2 (8 núcleos virtuais com 3.25 unidades de computação EC2 cada); c) 1690 GB de armazenamento; d) Plataforma 64-bit; e) Recursos de I/O: Alto; podem utilizar o c1.xlarge: Ou então para aplicações que necessitem de mais processamento que memória, a) 7 GB de memória; b) 20 unidades de computação EC2 (8 núcleos virtuais com 2.5 unidades de computação cada); c) 1690 GB de armazenamento; d) Plataforma 64-bit;

36 35 e) Recursos de I/O : Alto; O foco principal da Amazon é a infra-estrutura como serviço, cabendo ao cliente a configuração do sistema, dando assim um maior controle sobre a utilização dos recursos disponibilizados, que tem como base o sistema operacional Linux Locaweb A Locaweb é uma empresa brasileira que iniciou como hospedagem de sites em 1998 e atualmente foi a pioneira em oferecer serviços de computação nas nuvens no Brasil e aposta massivamente nessa tendência, tanto no marketing quanto na estrutura (LOCAWEB, 2010). A empresa possui uma linha de 8 modelos de servidores nas nuvens, abaixo segue a configuração da máquina padrão e da máquina mais robusta: Cloud Mini I: a) 2 núcleos de 300 MHz; b) Memória de 300 MB; c) 20 GB para armazenamento; d) Largura de banda de 2 Mbps; e) Transferência de 300 GB; Cloud Server IV: a) 4 núcleos de 2 GHz; b) Memória de 6 GB; c) 400 GB para armazenamento; d) Largura de banda de 12 Mbps; e) Transferência de 1800 GB;

37 36 Seus serviços incluem também a Private Cloud, para empresas que necessitam de servidores totalmente dedicados a seus negócios Azure A Microsoft decidiu entrar na Computação nas Nuvens com a plataforma Azure, disponibilizando diversos serviços como visto na Figura 11: Figura 11 - Linha de serviços oferecidos pela plataforma Azure Fonte: (MICROSOFT, 2010a) O Live Services inclui o Live Mesh que é a ferramenta utilizada para sincronização de dados de aplicativos disponibilizados para diversos aparelhos conectados a rede Windows Live, presente desde Smartphones até vídeo-games como o Xbox 360. Para os desenvolvedores é disponibilizado o AppFabric, para construção de aplicativos.net, juntamente com o SQL Services para armazenamento e consulta de dados,

38 37 que tem como base o SGBD SQL Server, mas não disponibiliza toda funcionalidade do modelo relacional no banco, por fins de desempenho dos servidores. Já a SharePoint Services é destinada ao desenvolvimento intranet de forma colaborativa, através do compartilhamento entre os usuários e o Dynamic CRM Services é um serviço de Customer Relationship Management (Gestão de Relacionamento com o Cliente) totalmente disponibilizado nas nuvens. A Figura 12 mostra a comparação entre os serviços oferecidos pela Amazon EC2, Google App Engine e Microsoft Live Mesh: Figura 12 - Comparação entre diferentes plataformas de Computação nas Nuvens

39 Aplicações web 2.0 A idéia de rede mundial de computadores surgiu do conceito de intercomunicação global para disseminação de conhecimento e como um novo meio de comunicação, porém na prática essa filosofia não se estendia a todos, já que na web como a conhecíamos somente alguns grupos ou pessoas detinham o poder de decidir o que podia ser publicado, dessa mesma forma não existia uma relação mais pessoal ou uma interatividade entre os usuários e esses grupos (O'REILLY, 2007). A partir do momento em que o número de pessoas utilizando a web cresceu exponencialmente e o seu uso tornou-se algo indispensável, novas formas de utilização dessa rede foram sendo criadas para que as páginas da web pudessem ser mais úteis, ao invés de serem estáticas, com o advento de novas tecnologias e conceitos hoje os usuários podem participar realmente da filosofia de intercomunicação global, sendo parte indispensável no desenvolvimento e aprimoramento das paginas na web. Por esta percepção Tim O'Reilly, fundador do O Reilly Media e apoiador do código e software livre, criou o conceito de Web 2.0. Com uma nova visão de possibilidades e tendo um potencial de acesso praticamente irrestrito, a web consegue chegar a lugares onde seria improvável a instalação de empresas, isso de forma imediata, sendo assim o que antes era distribuído na forma de mídia física, como programas e jogos para serem instalados e rodados na máquina do usuário agora são disponibilizados como serviço, pois os mesmos rodam em servidores onde também são armazenados os dados, dessa forma a web torna-se uma nova plataforma. A tendência da web 2.0 é tornar-se cada vez mais dinâmica, pois o usuário nesse momento passa a ser também colaborador e organizador do conteúdo Uma das primeiras aplicações a serem disponibilizadas para os usuários foram as aplicações de no próprio browser, pois antes era necessário a utilização de um

40 39 software instalado no PC do usuário que busca-se nos servidores das empresas os s recebidos e assim poder manipulá-los (WIKIPEDIA, 2010c). O tornou-se uma aplicação praticamente completa, pois as mensagens são guardadas no próprio servidor e é possível manipulá-las do browser possibilitando dessa maneira que uma pessoa possa acessar sua conta independentemente do local ou plataforma que ela usa Inteligência coletiva por Wikis e Folksonomia Todas as pessoas detêm o conhecimento de um determinado assunto, ou tem uma visão e opinião sobre os mesmos, tal informação é interessantíssima para crescimento do conhecimento e entendimento do ser humano (O REILLY, 2007). Os Wikis podem transmitir de forma fácil e acessível informações geradas pelos próprios usuários do serviço, sendo o mesmo responsável pela construção, manutenção e classificação da notícia de forma colaborativa (HOLTZBLATT, 2010). A folksonomia é a indexação e classificação do conteúdo através de tags feita pela comunidade, sendo uma maneira eficaz para a recuperação da informação desejada de forma rápida e intuitiva (O'REILLY, 2007). O conhecimento transmitido pelo indivíduo é compartilhado por pessoas de diferentes realidades, crenças, idades e opiniões, criando uma tendência de idéias que são consideras com inteligência coletiva Mash-ups, AdSense e RSS A utilização das ferramentas da web 2.0 como serviço traz possibilidades infinitas, como visto nos Mash-ups, que são a mistura ou nova utilização de um aplicativo disponibilizado, seria algo como agregar funcionalidades, derivando seu serviço, um exemplo é a junção dos mapas online com um serviço de viagens para mostrar onde estão localizados os principais pontos turísticos do destino escolhido (O'REILLY, 2007).

41 40 O AdSense seria uma espécie de Mash-up criado pelo Google, o qual gera renda para páginas que o utilizem, sua receita aumenta a cada clique que o AdSense recebe. Como existe uma grande necessidade de sempre a pessoa saber a informação atualizada, foi criado o RSS (Really Simple Syndication, Distribuição Realmente Simples ), que repassa as ultimas informações atualizadas ao usuário Redes sociais Flickr, YouTube, Orkut e Twitter O que mostra mais claramente o conceito de Web 2.0 são seus aplicativos de maior sucesso, que possivelmente também são algumas das páginas da web mais visitadas, pois permitem uma interação intra-usuários nunca antes vista. O Flickr é um serviço de compartilhamento de imagens que permite ao usuário hospedar e classificar suas imagens (O'REILLY, 2007). Um dos maiores sites da web é o YouTube, esse gerou uma grande revolução no cotidiano da humanidade, criando uma serie de novas possibilidades através do compartilhamento de vídeos feitos pelos próprios usuários, trazendo pessoas até então desconhecidas para se tornarem famosos mundialmente (CHA, 2007). A rede social Orkut é um grande portal de amizades virtuais, com a possibilidade de utilizar álbum de fotos, troca de recados, perfil pessoal, debates em comunidades de determinados temas (RECUERO, 2005), originalmente foi criado para atender o público dos Estados Unidos, mas foi no Brasil e na Índia que o Orkut mais fez sucesso (WIKIPEDIA, 2010b). Sem dúvida a página de maior sucesso atualmente é o Twitter, onde o usuário publica o que está fazendo no exato momento tendo apenas 140 caracteres para sua postagem (SAVAGE, 2010).

42 Aplicativos nas nuvens A Subseção a Subseção tem por fim apresentar algumas aplicações populares alocadas no ambiente das nuvens Photoshop Online A Adobe apostando nesse novo mercado disponibilizou a versão de seu software de maior sucesso nas nuvens, porém com menos ferramentas para edição da imagens. O Photoshop Online disponibiliza aos usuários a possibilidade de criar álbuns e compartilhar com outras pessoas suas fotos. A Figura 13 mostra uma foto sendo editada no aplicativo da Adobe (PHOTOSHOP ONLINE, 2009). Figura 13 - Foto sendo editada com ferramentas do Photoshop Online

43 Google Docs O editor de documentos da Google permite a criação de arquivos de texto, planilhas, apresentações, formulários e um editor para desenhos simples, um exemplo de arquivo de texto pode ser visto na Figura 14. Todos os documentos podem ser compartilhados entre diversos usuários, com modificações sendo mostradas em tempo-real (GOOGLE DOCS, 2009). Figura 14 - Imagem da tela do editor de texto do Google Docs No Docs cada conta de usuário pode conter um limite de 5000 documentos, mas não é especificado o tamanho total de armazenamento disponível.

44 Best Buy Giftag Alocado nas nuvens pelo App Engine, o Giftag, desenvolvido pela Best Buy é uma rede social onde é possível criar relações com outros usuários e publicar listas de objetos desejados (GIFTAG, 2010). Giftag possui padrão de código aberto e começou a ser desenvolvido em 2008 em sua versão beta. A aplicação também permite que a lista de desejos seja compartilhada no Facebook, Twitter, e em outras redes sociais. A Figura 15 mostra a aplicação Giftag da Best Buy que está alocada no App Engine: Figura 15 - Giftag

45 Onlive Como um projeto ambicioso o Onlive pretende oferecer grandes títulos do mundo dos jogos totalmente processados nos servidores da empresa e transmitidos ao usuário via vídeo stream, sendo necessário ao usuário ter uma conexão de no mínimo 2MB para não haver demora na transmissão de comandos e ação do jogo (ONLIVE, 2010). O sistema pode funcionar normalmente em computadores, laptops ou em televisores que podem ser conectados via um dispositivo desenvolvido pela empresa para acesso a rede, como no exemplo da Figura 16. Figura 16 - Pagina web com demonstrativo do funcionamento do sistema Onlive Dessa forma mesmo com um computador com configurações simples será possível jogar títulos que exigem máquinas muito poderosas, aumentando a gama de clientes dos fabricantes de jogos virtuais.

46 Considerações Finais Este capítulo apresentou a definição de computação nas nuvens, o seu funcionamento, os seus modelos de implementação, aplicações alocadas nas nuvens, camadas de arquitetura e serviços e suas definições e servidores mais utilizados atualmente. O capítulo também apresentou uma visão sobre a Web 2.0 e suas aplicações.

47 46 3. BANCO DE DADOS NAS NUVENS Neste capítulo será apresentada uma visão geral do ambiente de armazenamento de dados nas nuvens, a mudança de paradigma de banco de dados, a Bigtable e as ferramentas disponíveis no App Engine. Este capítulo está organizado como segue: na Seção 3.1 é apresentada a visão geral do ambiente de armazenamento de dados do App Engine e suas tecnologias e na Seção 3.2 são apresentadas as ferramentas disponíveis no App Engine Ambiente de Armazenamento de Dados do App Engine: O sistema de armazenamento de dados do App Engine utiliza uma arquitetura distribuída que apesar de ser consistente, não é um banco de dados relacional, embora tenha recursos similares ao mesmo. Suas características exclusivas exigem uma maneira diferente de gerenciar e projetar dados (GOOGLE, 2010). O Google App Engine utiliza a Bigtable, um banco de dados orientado a colunas desenvolvido pela Google, criado para o gerenciamento de grandes massas de dados estruturados (CHANG, 2006). O gráfico da Figura 17 mostra a comparação do número de consultas no buscador Google entre banco de dados relacional e o NOSQL, termo definido para banco de dados orientado a colunas. Este assunto será abordado com mais detalhes na Subseção Abaixo o comparativo entre as publicações entre os bancos de dados, observa-se que tanto o número de publicações como as consultas vem se equiparando com o banco de dados relacional (GOOGLE, 2010).

48 47 Figura 17 - Publicações: Banco de Dados Relacional vs. Banco de Dados Orientado a Colunas Os dados de uma aplicação podem estar distribuídos em dezenas de máquinas e em diferentes localidades, possivelmente em diferentes lugares ao redor do mundo. Armazenar dados em um ambiente distribuído pode acarretar em grandes complicações para o desenvolvimento da aplicação, porém graças ao Google App Engine esta tarefa não é de preocupação do desenvolvedor, pois a API disponibilizada gratuitamente pela Google se encarrega de realizar toda a distribuição, replicação e carga de dados e ainda oferece um poderoso mecanismo de consulta e transações. O armazenamento de dados no Google App Engine armazena e executa consultas sobre objetos de dados conhecidos como entidades. No modelo de dados do ambiente são definidos os tipos que categorizam as entidades para uma consulta. Uma entidade tem uma ou mais propriedades, que se caracterizam por ser um dos diversos tipos de dados suportados pelo ambiente de armazenamento. Uma propriedade pode ser referência de outra entidade. Realizando uma comparação com o modelo de banco de dados tradicional (banco de dados relacional), os tipos seriam as tabelas, as entidades seriam as linhas, enquanto as propriedades seriam os campos ou colunas de uma tabela (SANDERSON, 2009). O ambiente possui um esquema para armazenamento de objetos e conta com um mecanismo de consulta e transações atômicas. Fornecendo um armazenamento dimensionável e robusto de dados para aplicações web, com ênfase no desempenho da leitura e consulta. (GOOGLE, 2010).

49 48 A API de armazenamento de dados conta com uma linguagem de consulta parecida com o SQL (Structured Query Language), o GQL (Google Query Language). Nos próximos tópicos será explicado o funcionamento da API de armazenamento de dados do Google App Engine Mudança de Paradigma Organizações armazenam grandes quantidades de dados para futura análise, a maioria delas em banco de dados relacionais. Recentemente surgiu um novo paradigma de banco de dados, os chamados bancos de dados NOSQL (STONEBRAKER, 2010). Atualmente existem diversos bancos de dados NoSQL desenvolvidos principalmente por empresas que possuem grandes quantidades de dados, exemplos são a Google e a Amazon, que desenvolveram respectivamente a Bigtable e o DynamoDB. Diferentes bancos de dados NOSQL possuem características peculiares, porém todos possuem a característica em comum de serem banco de dados não-relacionais (LEAVITT, 2010). Bancos de dados não-relacionais começaram a ser desenvolvidos nos anos 60, incluindo banco de dados hierárquico, de grafos e orientados a objeto. Porém novos bancos de dados não-relacionais surgiram, e somente agora começaram a ter visibilidade no mercado, surgindo assim o conceito de NOSQL Bigtable Bigtable é um banco de dados distribuído designado para o gerenciamento de grandes quantidades de dados estruturados. Suporta massas de dados na casa dos Petabytes através de milhares de servidores espalhados pelo mundo (CHANG, 2008). O desenvolvimento da Bigtable se iniciou em 2004 com o objetivo do uso interno para atender a necessidade de acesso a grandes massas de dados em alta velocidade. A sua utilização se iniciou em fevereiro de 2005 utilizado em projetos internos da Google, hoje

50 49 mais de 60 aplicações da empresa utilizam a tecnologia. Exemplos de projetos que utilizam a Bigtable são o Google Earth & Maps, Google Search, Orkut, Youtube e Blogger. A Bigtable é uma tecnologia proprietária, criada pela Google Inc., e diferentemente dos bancos de dados relacionais permite um número infinito de linhas e colunas. (CIURANA, 2008) Entidades e Modelos Uma entidade possui uma chave que a identifica através de todo o sistema, uma parte desta chave, que será discutida detalhadamente na Seção 3.1.4, é a identificação da aplicação designada para que a entidade não seja confundida com nenhuma outra aplicação dentro do App Engine. Outra parte da chave é o tipo, que é designado para categorizar a entidade e facilitar a busca através de queries GQL, que será discutida com mais detalhes na Seção Dentro de uma entidade também há uma ou mais propriedades, que são os dados armazenados dentro desta entidade (SANDERSON, 2009). A Figura 18 descreve visualmente uma entidade, onde Key é a chave, composta pela identificação da aplicação e o tipo ( Player ). Level e Score são as propriedades da entidade.

51 50 Figura 18 - Ilustração de uma entidade Fonte: (SANDERSON, 2009) Um aplicativo utiliza a API de armazenamento de dados para definir modelos de dados que são instanciados para serem armazenados como entidades. Estes modelos fornecem a estrutura da entidade e são representados na linguagem de programação Python através de uma classe Model, que será discutida na Seção (GOOGLE, 2010). Existem modelos que podem ser definidos através da classe Model, cada modelo com sua peculiaridade. Estes modelos serão discutidos nos próximos tópicos Interface Model A Interface Model define o tipo da entidade de armazenamento de dados e as propriedades que este tipo irá assumir. Cada propriedade utiliza de atributos pertencentes à classe Model da API de armazenamento de dados, que se utiliza de subclasses da classe Property, que definem a configuração de cada propriedade (GOOGLE, 2010).

52 51 Cada atributo da classe Model são instâncias da classe Property, isto assegura que não existam propriedades com valores inválidos. A Figura 19 retrata um exemplo de definição de um modelo para a entidade Pessoa na linguagem de programação Python, utilizando a API de armazenamento de dados do App Engine. A modelo possui três propriedades, nome, peso_em_kilos e data_nascimento, sendo a primeira no tipo String, a segunda Integer e a terceira Date. Figura 19 - Código na linguagem Pyhton da entidade Pessoa db.model é a superclasse da modelagem de dados na API de armazenamento de dados do App Engine e nela também existe a subclasse db.expando que herda todas as suas funções, porém possui peculiaridades úteis no desenvolvimento do sistema (SANDERSON, 2009) Modelo Expando No desenvolvimento de uma aplicação, em certos casos, é interessante que uma entidade não só possua propriedades fixas, mas possua também propriedades dinâmicas. O modelo Expando, permite que o aplicativo crie novas propriedades dinâmicas a qualquer momento, assim que for atribuídos valores a elas (GOOGLE, 2010).

53 52 A Figura 20 ilustra a definição de uma classe expando e a persistência de dados de propriedades fixas e dinâmicas. As propriedades fixas são definidas utilizando subclasses da superclasse Property, e as dinâmicas definidas pelo aplicativo ( segundo_nome, hobbies ), uma do tipo String e a segunda do tipo StringList. O método put() é o responsável pela persistência de dados. Figura 20 - Demonstração de uma classe Expando Como as propriedades dinâmicas não são definidas pelo modelo, elas não são validadas, portanto podem possuir qualquer um dos tipos de armazenamento de dados, que será discutido na Seção (GOOGLE, 2010). Uma classe de modelo expando é uma subclasse da superclasse Expando. Enquanto a classe Expando é uma subclasse da superclasse Model (SANDERSON, 2009) Modelo Polimórfico O modelo polimórfico é um modelo que permite o desenvolvedor criar hierarquias em suas entidades. Em consultas podem ser retornados dados da entidade pai quanto os dados de entidades filhas (GOOGLE, 2010).

54 53 A Figura 21 ilustra a criação de modelos de entidades polimórficas. O modelo de entidade Pessoa_Juridica é uma subclasse de Pessoa e herda todas as suas propriedades e é adicionada uma nova propriedade fixa ( cnpj ). O modelo de entidade pessoa herda atributos da superclasse PolyModel presente no pacote google.appengine.ext.db.polymodel na API de armazenamento de dados do App Engine. Figura 21 - Entidade polimórfica O modelo polimórfico não suporta propriedades dinâmicas, como no modelo Expando. Apesar de as subclasses poderem definir novas propriedades, elas não podem ignorar as definições das propriedades estabelecidas na classe pai.

55 Propriedades e Tipos O armazenamento de dados do App Engine suporta um conjunto fixo de tipos de valores para as propriedades das entidades. Os tipos de dados são definidos dentro da classe Property da API de armazenamento de dados (GOOGLE, 2010). Abaixo a Figura 22 ilustra os tipos de dados suportados pela API de armazenamento de dados do App Engine. Figura 22 - Dados suportados pelo App Engine Fonte: (GOOGLE, 2010)

56 Chaves e Grupos de Entidades Toda entidade armazenada na base de dados do App Engine possui uma chave de identificação única, que a difere das demais entidades, essa chave é como o DNA, pode possuir algumas características semelhantes, mas um campo a diferenciará das outras. Isso ocorre geralmente para entidades do mesmo tipo que possuam as mesmas propriedades (GOOGLE, 2010). As chaves são compostas de um ID numérico gerado automaticamente durante a inserção do registro ou um nome exclusivo dado pela aplicação a entidade, não podendo ser iniciado com número ex."1nome" ou estar entre linhas sublinhadas ex."_nome_", possui ainda o tipo dessa entidade e a referência da relação pai-filho que a mesma possua com outra entidade, após a inclusão na base de dados nenhuma dessas características pode ser alterada Consultas e Índices As consultas realizadas na base de dados do Google App Engine são feitas utilizando GQL, cada consulta possui um índice usado para retornar mais rapidamente os resultados. Os índices são criados a partir do conjunto de requisições estabelecidas, como o tipo da entidade, a propriedade de filtro, o operador e a ordem de classificação, entretanto as consultas que possuam a mesma estrutura, mas valores de filtro diferentes podem utilizar o mesmo índice (GOOGLE, 2010). A Figura 23 e a Figura 24 representam duas consultas que possuem a mesma estrutura porem valores de filtro diferentes:

57 56 Figura 23 - Consulta GQL Figura 24 - Consulta GQL com valor de filtro alterado O App Engine possui índices para consultas simples, no entanto as consultas para qual o mesmo não possui índices são especificadas e armazenadas no arquivo index.yaml automáticamente. Consultas que não possuem índices não retornam resultados Referência de GQL GQL (Google Query Language) é uma linguagem para consultas em banco de dados com sintaxe muito similar a SQL, a mesma não oferece todas as funcionalidades do SQL, como excluir, alterar e inserir, sendo assim toda query começa com SELECT, mas isso

58 57 dever ser encarado como uma característica e não como um defeito, já que as alterações podem ser realizadas via código Python (GOOGLE, 2010). A GQL não realiza consultas com a cláusula JOIN, isso pode parecer estranho para quem está acostumado a trabalhar com SQL, mas existe uma razão, se pensarmos que estamos lidando com dados distribuídos em diversos servidores, muitas vezes separados por grande distância física, e precisamos cruzar esses dados, fica claro que é muito custoso o trabalho para os servidores, então essa junção sendo realizada no código do aplicativo, a partir das consultas comuns realizadas no banco, não gera transtornos tão impactantes no desempenho dos servidores. A Figura 25 ilustra um exemplo de consulta: Figura 25 - Consulta GQL ao banco de dados Onde "dim_website" é o modelo da entidade e website_id é o nome de uma propriedade da entidade "dim_website, após a clausula WHERE foi declarado o nome de uma propriedade, um operador de comparação, que poderia ser <, <=, =, >=, >,!= ou IN e um valor, no caso de usar o operador de comparação IN a consulta ficaria da seguinte forma como retrata a Figura 26:

59 58 Figura 26 - Consulta GQL utilizando o operador IN A consulta irá gerar resultados semelhantes à imagem a seguir, todos os registros no banco, onde o valor da propriedade website_id possuem valores maiores que 1 e menores que 5, ordenados em ordem crescente como retrata a Figura 27: Figura 27 - Entidades resgatadas pela consulta com utilização do operador IN Os tipos de valores para serem comparados a propriedade da entidade podem ser, String, Integer ou Float, Boolean, Date-time, EntityKey, UserObject ou GeoPtObject

60 Ferramentas do App Engine O SDK do App Engine inclui um servidor de desenvolvimento para testar a aplicação no computador local, simulando os serviços com restrições das tarefas sendo executadas localmente. Também é disponibilizada uma ferramenta para envio de dados em massa para o ambiente de armazenamento do aplicativo no App Engine denominado Bulkloader (GOOGLE, 2010) Servidor de Desenvolvimento O Servidor de Desenvolvimento é uma ferramenta disponibilizada pela SDK do App Engine na linguagem de programação Python. O Servidor de desenvolvimento permite que o desenvolvedor simule a aplicação localmente, antes de ser enviada para as nuvens. Para auxiliar a utilização das ferramentas é disponibilizada uma interface do Servidor de Desenvolvimento, chamada Google App Engine Launcher (GOOGLE, 2010). A Figura 28 retrata a visão do usuário do Google App Engine Launcher que fornece as ferramentas disponíveis no Servidor de Desenvolvimento.

61 60 Figura 28 - Launcher de aplicativos do App Engine O Servidor de Desenvolvimento disponibiliza um console administrativo da aplicação local, contando com a visualização dos tipos de armazenamento presentes na aplicação e interação com aplicação. Por padrão o console é executado na porta 8080, porém existe uma forma para que esta porta seja alterada. A Figura 29 retrata a visão do console administrativo, presente em Onde podem ser visualizadas as entidades do tipo Pessoa, armazenadas localmente.

62 61 Figura 29 - Console de administrador do App Engine A ferramenta simula a aplicação nas nuvens localmente, porém com algumas limitações, como o tempo de limite ou cotas de solicitação Envio de dados em Massa O SDK do App Engine em Python conta com uma ferramenta que permite que o desenvolvedor envie dados em massa para o armazenamento de dados do aplicativo nas nuvens. Com apenas algumas configurações é possível que dados sejam enviados a partir de um arquivo CSV (Comma Separated Values), que é gerado pela maioria dos aplicativos de planilha (GOOGLE, 2010). Para que seja possível o aplicativo traduzir as linhas do arquivo CSV é necessário que se crie uma classe carregadora de dados a partir da classe modelo. Na Figura 30 temos a definição do modelo do tipo dim_customer que é o modelo que será enviada com dados em massa para a aplicação nas nuvens.

63 62 Figura 30 - Classe modelo Após a definição do modelo, será necessária a definição da classe carregadora na ordem em que os dados são definidos no arquivo CSV. Na Figura 31 é ilustrada a definição da classe carregadora, na ordem em que os dados são definidos no arquivo CSV e com todas as propriedades definidas no modelo do tipo dim_customer. A função lambda é utilizada para converter dados para codificação UTF-8 que é aceita no ambiente de armazenamento de dados no App Engine.

64 63 Figura 31 - Classe carregadora de dados Após a definição dos modelos de dados a ferramenta bulk_loader é encarregada de enviar os dados para o ambiente de armazenamento do App Engine.

65 Considerações Finais Este capítulo apresentou uma visão geral do ambiente de armazenamento de dados nas nuvens, a mudança de paradigma de banco de dados, a Bigtable e as ferramentas disponíveis no App Engine.

66 65 4. ESTUDO DE CASO: DESENVOLVIMENTO DE UMA APLICAÇÃO COM BANCO DE DADOS EM COMPUTAÇÃO NAS NUVENS Este capítulo tem como objetivo apresentar o ambiente, a preparação dos dados, configuração das ferramentas e o desenvolvimento da aplicação. Este capítulo está organizado como segue: na Seção 4.1 é apresentado o cenário do estudo de caso, na Seção 4.2 é apresentado o desenvolvimento do aplicativo e na Seção 4.3 é apresentada a execução do aplicativo Cenário do Estudo de Caso Para a realização do estudo de caso foi necessário reunir uma densa base de dados para que fosse gerado uma aplicações com dados reais nas nuvens, a base de dados utilizada foi a do software de datawarehouse Pentaho, com aproximadamente 1 gigabyte de tamanho, e aproximadamente 400 mil registros, esses mesmos dados estavam adequados para uso em um banco de dados relacional, então foi necessário a remodelação dos registros para poderem ser alocados em um ambiente de dados orientado a colunas, para extração dos dados foi utilizado o Sistema Gerenciador de Banco de Dados MySql, e foram gerados arquivos CSV (Commas Separeted Values), para que os dados fossem adaptados e remodelá-los para persisti-los na Bigtable, que segue uma orientação de dados colunar. A conta utilizada para realização dos testes foi o padrão gratuito, que oferecia: a) 1 Gigabyte de espaço para armazenamento; b) Limite de 10 aplicativos alocados nas nuvens; c) Ciclo de 24 horas para atualização de recursos; A Figura 32 e a Figura 33 ilustram a tabela com os limites diários com a cota gratuita e com o padrão de faturamento ativado:

67 66 Figura 32 - Limites diários do App Engine Fonte: (GOOGLE, 2010) Figura 33 - Limites diários do App Engine Fonte: (GOOGLE, 2010) Após preparar a base foi necessária a instalação e configuração do ambiente de desenvolvimento, para isso foi utilizado o SDK do App Engine nos computadores que utilizados para o desenvolvimento do aplicativo, as maquinas utilizadas foram: Computador 1:

68 67 a) Intel Dual Core 2.0 Ghz; b) 2 Gigabytes de Memória RAM; c) 180 Gigabytes de Disco Rígido; d) Windows 7 64 bits; e) Conexão com a internet ADSL 1 MB; Computador 2: a) Amd Athlon Ghz; b) 1 Gb Ram c) 500 GB HD d) Windows 7 64 bits e) Conexão com a internet ADSL 2 MB No inicio do desenvolvimento do aplicativo foi utilizada a linguagem de programação Java, mas devido a inúmeras barreiras e dificuldades estabelecida pelo App Engine que não oferece total suporte a linguagem de programação, foi decidido então o uso de outra linguagem, no caso Python na versão 2.5, o qual já possuía um suporte mais avançado para as etapas de criação pela Google Desenvolvimento O desenvolvimento da aplicação no ambiente nas nuvens utilizando a plataforma App Engine se deu com o intuito de realizar a utilização de uma base de dados real adaptada no MySQL, transcrevendo esta mesma base de dados na Google Bigtable. A linguagem de programação utilizada foi o Python, uma linguagem de programação de alto nível orientada a objetos (ROSSUM, 2008). Para que fosse possível a realização de testes, foi utilizada uma grande base de dados sob licença livre, que adequamos para utilização em uma estrutura de dados diferente.

69 Desenvolvimento do Aplicativo A aplicação desenvolvida na linguagem de programação Python tem a função de criar um ambiente nas nuvens para que seja possível realizar o envio de dados em massa para o ambiente de armazenamento de dados do App Engine, sendo assim possível a realização de testes nas consultas de dados. O aplicativo fornece os modelos de entidades para o ambiente de armazenamento de dados do App Engine definindo suas chaves e propriedades. Isso foi possível graças a API de armazenamento de dados do App Engine. Para o desenvolvimento da aplicação que foi utilizada no projeto, foi necessária a criação de arquivos na linguagem de programação Python e arquivos de serialização YAML descritos a seguir: a) Arquivo app.yaml : Possui a finalidade de descrever quais scripts devem ser utilizados para cada URL, a identificação da aplicação, a versão da aplicação e a descrição do ambiente de execução e sua versão. A Figura 34 representa o arquivo de configuração YAML utilizado no projeto, apresentando a identificação do aplicativo como pentahobase em sua primeira versão, o ambiente de execução Python e as URLs para cada arquivo a ser executado: Figura 34 - Arquivo app.yaml

70 69 b) Arquivo index.yaml: Possui a funcionalidade de configurar índices para consultas no ambiente de armazenamento de dados do App Engine. O arquivo é gerado automaticamente, porém também existe a opção de configurar os índices manualmente; c) Arquivo models.py: Possui classes de definição de modelos de entidades, entre elas as classes: dim_customer, dim_dvd_release, dim_demography, dim_website, facts_table, entre outras. Cada classe presente dentro do arquivo models.py possui a função de definir o modelo da entidade para o ambiente de armazenamento de dados do App Engine, e estas classes implementam a interface models da API de armazenamento de dados. A Figura 35 retrata a definição do modelo da entidade dim_dvd_release com suas propriedades e tipos de propriedade: Figura 35 - Classe de definição de modelos de entidade

71 70 d) Arquivo bulkloader.py: Possui a classe carregadora que define a leitura do arquivo CSV e envia para o ambiente de armazenamento de dados do App Engine. Para cada modelo de entidade foi implementada uma classe carregadora, a fim de definir a ordem em que os dados são definidos no arquivo CSV e carregá-los nas nuvens. Na classe carregadora também foi definida a função lambda para conversão da codificação de ASCII para UTF-8, que será demonstrada com mais detalhes na Seção A Figura 36 demonstra definição da classe carregadora para o modelo de entidade dim_customer: Figura 36 - Classe carregadora e) Arquivo prefs.py: Arquivo onde possui a classe principal do aplicativo, a MainPage. A classe possui a finalidade de tratar requisições, porém não foi necessária a utilização em nosso projeto.

72 A Base de Dados A base de dados utilizada no projeto é disponibilizada pelo software Pentaho, sob licença GPL General Public License (Licença Pública Geral) que permite a liberdade para utilização em qualquer propósito (GNU, 2008). A base de dados utilizada possui aproximadamente 1 Gigabyte de tamanho em disco, aproximadamente quatrocentos mil registros entre onze tabelas. A Figura 37 mostra o modelo entidade-relacionamento obtido a partir da base de dados utilizada no projeto:

73 72 Figura 37 - Modelo Entidade-Relacionamento A base de dados por padrão está definida no banco de dados MySQL, para que o armazenamento destes dados nas nuvens fosse possível, foi necessária a preparação dos dados, que será descrito na Seção Armazenamento de Dados nas Nuvens Para que o envio dos dados para as nuvens pudesse ser realizado, foi necessária a preparação dos dados para adequação do padrão do ambiente de armazenamento de dados do App Engine.

74 Preparação dos Dados Com a base de dados definida no MySQL, foi necessário ajustá-la para o padrão da Bigtable. Como a inserção de dados no ambiente de armazenamento do App Engine não é feita por SQL, foi necessário exportar os dados já armazenados no MySQL em arquivos no formato CSV. Para isso foi utilizado uma função no MySQL que realiza a importação e formatação dos dados presentes no banco de dados relacional para um arquivo externo. A Figura 38 representa o SQL responsável pela extração dos dados presentes na tabela dim_customer gravados no MySQL e os envia para o arquivo externo dim_customer.csv, formatando os campos separando-os por vírgula e terminando as linhas da tabela com quebra de linha ( \n ). Figura 38 - SQL que converte dados em arquivo CSV Os dados extraídos do MySQL para o arquivo CSV geraram um documento com a codificação ASCII, enquanto no ambiente de armazenamento de dados do App Engine o padrão de codificação é o UTF-8 (GOOGLE, 2010). Portanto fez-se necessária a conversão dos dados para o padrão UTF-8 através da função lambda que possui a mesma finalidade dos métodos, porém utilizado para expressões curtas (ROSSUM, 2008). A Figura 39 ilustra a declaração da função lambda para conversão da codificação:

75 74 Figura 39 - Função lambda de conversão de codificação Depois de declarada a função, toda declaração de strings na classe carregadora realizava uma chamada a lambda, como ilustra a Figura 40 para a propriedade customer_last_name: Figura 40 - Chamada à função lambda Após a execução destas etapas os dados já estão prontos para serem enviados para o ambiente de armazenamento de dados do App Engine Execução Após o desenvolvimento da aplicação e preparação dos dados no padrão da Bigtable, o próximo passo é o envio da aplicação para as nuvens, que será demonstrado detalhadamente na Subseção 4.3.1, o seguinte passo será o envio dos dados para o ambiente de armazenamento do App Engine, que será descrito na Subseção Envio de Dados para as Nuvens

76 75 O envio do aplicativo para o ambiente das nuvens foi realizado utilizando a ferramenta appcfg.py presente no SDK do App Engine para Python, porém antes do envio do aplicativo foi necessário executar alguns passos. O primeiro passo necessário para o envio do aplicativo foi o registro da aplicação dentro do App Engine (disponível pelo endereço feito o login criamos uma nova aplicação. A Figura 41 demonstra o formulário para registro de uma nova aplicação nas nuvens: Figura 41 - Formulário para registro de nova aplicação O formulário solicita a identificação da aplicação (1) que será o endereço para acesso via web, o título da aplicação (2) que será o nome de exibição ao usuário ao acessar a aplicação e por fim o botão Create Application (3) que finaliza o processo de criação do aplicativo nas nuvens. Depois de criada a aplicação no App Engine, definimos o identificador da aplicação no arquivo app.yaml na marcação application. Realizados os passo, podemos enviar a aplicação para o App Engine, ao acessar o prompt de comando, executamos a ferramenta appcfg.py e passamos como

77 76 parâmetro update que cria ou atualiza a aplicação e o endereço de onde o arquivo app.yaml está localizado no computador. A Figura 42 demonstra o uso da ferramenta appcfg.py: Figura 42 - Envio da aplicação para o App Engine Após a execução da ferramenta será realizada automaticamente a conexão com o servidor ( e será solicitado o e a senha de registro do App Engine. A Figura 43 ilustra a conexão com o servidor e a requisição do e senha: Figura 43 - Conexão com servidor Após a validação do usuário a aplicação será enviada automaticamente para o App Engine e estará disponível o console administrativo para o desenvolvedor da aplicação descrevendo as cotas e utilizações de recursos da aplicação, logs administrativos, visualização dos dados armazenados e gráficos de utilização de recursos. A Figura 44 demonstra o console administrativo da aplicação enviada para as nuvens.

78 77 Figura 44 - Visão do Console Administrativo do App Engine Já com a aplicação no ambiente das nuvens, o próximo passo será enviar os dados obtidos após a preparação, que foi descrito na Seção 4.2.3, para o banco de dados da aplicação no ambiente de armazenamento de dados do App Engine Envio dos Dados Para as Nuvens O recurso de carregamento de dados realiza a comunicação com o aplicativo que esta sendo executado no App Engine através de um manipulador de solicitações incluído na SDK do App Engine para Python, denominado remote_api (GOOGLE, 2010). O primeiro passo para o envio dos dados é mapear o remote_api no app.yaml, passando uma URL com o caminho da biblioteca do remote_api. A Figura 45 ilustra o mapeamento do remote_api para a aplicação, dentro da seção handlers do arquivo de configuração app.yaml. Figura 45 - Mapeamento do remote_api

79 78 O mapeamento do remote_api deve ser o primeiro mapeamento da lista de handlers, caso contrário ao tentar realizar o envio dos dados, será lançado erro de autenticação. No desenvolvimento do projeto obtivemos este problema. Após o mapeamento do remote_api no arquivo de configuração app.yaml, é necessário realizar a atualização da aplicação que está sendo executada no App Engine através da ferramenta appcfg.py, detalhada na Seção Com a aplicação atualizada no App Engine, podemos realizar acesso a URL mapeada com o remote_api, porém somente administradores da aplicação possuem permissão para realizar acesso, será solicitado e senha ao tentar acessar a URL. O próximo passo para realização do envio dos dados para o ambiente de armazenamento de dados do App Engine, será utilizar novamente a ferramenta appcfg.py porém com o argumento upload_data que permite o envio de dados através de arquivos CSV (GOOGLE, 2010). O argumento upload_data utiliza como argumento config_file que possui o diretório do arquivo de definição do upload de dados, filename que possui o diretório do arquivo CSV, kind que possui o tipo do modelo de dados e o diretório da aplicação no computador local. A Figura 46 demonstra o comando appcfg.py upload_data para envio de dados a partir de um arquivo CSV. Figura 46 - Comando upload_data Após a execução do comando upload_data a ferramenta conectará com o servidor automaticamente e solicitará a validação do usuário. Ao longo do envio de dados obtivemos erros de importação (ImportError) no upload de dados e foi verificado que o ambiente de armazenamento de dados do App Engine não aceita dados com acentos ortográficos e caracteres especiais.

80 79 Ao longo do envio dos dados, o uso do limite de CPU diário das cotas gratuitas foi excedido, portanto tivemos que aguardar 24 horas para que terminássemos de realizar o envio dos dados. A Figura 47 mostra o limite de CPU excedido no console administrativo. Figura 47 - Uso Máximo de CPU nas Cotas Gratuitas Com o limite de CPU excedido, ficamos impossibilitados de realizar qualquer ação dentro da aplicação e do console administrativo, inclusive a visualização de estatísticas e entidades dentro do armazenamento. A Figura 48 mostra a mensagem de erro após o limite de CPU ter excedido ao tentar visualizar as estatísticas da aplicação. Figura 48 - Mensagem de Erro ao Tentar Visualizar as Estatísticas

81 80 Após a liberação de uso de CPU, o envio de dados foi retomado com sucesso. Após o envio dos dados foi possível visualizar as entidades no console administrativo e as estatísticas referentes ao armazenamento de dados. A Figura 49 representa o gráfico estatístico informando o número total de entidades, a última atualização e a porcentagem dos tipos de dados armazenados. Pode-se verificar que entre todas as propriedades 59% são String, 9% Inteiros, 7% Chaves, 7% Text e 19% Metadados: Figura 49 - Gráfico Estatístico Gerado no App Engine Também é possível visualizar a quantidade total armazenada nas nuvens através do console administrativo. A Figura 50 apresenta a quantidade total armazenada nas nuvens dentro da aplicação em Gigabytes e a quantidade de espaço ainda disponível:

82 81 Figura 50 - Espaço Total Utilizado Pela Aplicação O console administrativo também disponibiliza um console de consulta de entidades através do GQL, podendo assim realizar consultas com restrições definidas. A Figura 51 demonstra uma consulta utilizando GQL no tipo dim_website com a propriedade website_id maior que 1 e menor que 4 e os resultados: Figura 51 - Consulta GQL Realização de Teste O teste realizado foi a criação de uma consulta geralmente efetuada em rotinas de data warehouses, a soma do potencial de lucro de uma lista de produtos. No caso do banco

83 82 de dados utilizado, a consulta foi realizada na tabela de DVD identificado pelo modelo de entidade dim_dvd_release. O GQL, como dito na Seção 3.1.6, não possui funções de soma como no SQL tradicional, foi então criado um trecho no código que recupera os dados presentes na query GQL através de um laço for, armazenando o resultado da consulta em uma variável auxiliar e o convertendo para float. A Figura 52 retrata o trecho de código descrito para realização do teste: Figura 52 - Recuperação de dados e soma do potencial de lucro Após a execução do código, obtivemos o seguinte resultado retratado na Figura 53, apresentando um potencial de lucro de e entidades verificadas: Figura 53 - Resultado obtido após a realização de teste 4.4. Considerações Finais