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
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
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
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!
V
“Uma vida sem desafios não vale a pena ser vivida”
Sócrates
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 email. 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
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 email, 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
VIII
SUMÁRIO
1.
INTRODUÇÃO: ......................................................................................................... 15
1.1.
Motivação ................................................................................................................ 15
1.2.
Objetivos .................................................................................................................. 19
1.2.1.
Objetivo Geral...................................................................................................... 19
1.2.2.
Objetivos Específicos ........................................................................................... 19
1.3.
Metodologias ............................................................................................................ 20
1.4.
Organização do Trabalho ....................................................................................... 20
2.
COMPUTAÇÃO NAS NUVENS ............................................................................... 22
2.1.
O que é Computação nas Nuvens?.......................................................................... 22
2.1.1.
Funcionamento da Computação nas Nuvens ...................................................... 23
2.1.2.
Modelos de implantação de Computação nas Nuvens ........................................ 24
2.1.2.1.
Public Cloud ..................................................................................................... 25
2.1.2.2.
Private Cloud .................................................................................................... 26
2.1.2.3.
Community Cloud ............................................................................................ 27
2.1.2.4.
Hybrid Cloud .................................................................................................... 27
2.1.2.5.
Intercloud ......................................................................................................... 28
2.1.3.
Camadas de Arquitetura de Serviços .................................................................. 29
2.1.3.1.
IaaS ................................................................................................................... 30
2.1.3.2.
PaaS .................................................................................................................. 30
2.1.3.3.
SaaS................................................................................................................... 31
2.1.4.
Servidores de Aplicações nas Nuvens .................................................................. 32
2.1.4.1.
App Engine ....................................................................................................... 32
2.1.4.2.
Amazon EC2 ..................................................................................................... 33
IX
2.1.4.3.
Locaweb ............................................................................................................ 35
2.1.4.4.
Azure ................................................................................................................. 36
2.2.
Aplicações web 2.0 ................................................................................................... 38
2.2.1.
Email .................................................................................................................... 38
2.2.2.
Inteligência coletiva por Wikis e Folksonomia ................................................... 39
2.2.3.
Mash-ups, AdSense e RSS ................................................................................... 39
2.2.4.
Redes sociais Flickr, YouTube, Orkut e Twitter ................................................ 40
2.2.5.
Aplicativos nas nuvens ......................................................................................... 41
2.2.5.1.
Photoshop Online ............................................................................................. 41
2.2.5.2.
Google Docs ...................................................................................................... 42
2.2.5.3.
Best Buy Giftag................................................................................................. 43
2.2.5.4.
Onlive ................................................................................................................ 44
2.3.
3.
Considerações Finais ............................................................................................... 45
BANCO DE DADOS NAS NUVENS ......................................................................... 46
3.1.
Ambiente de Armazenamento de Dados do App Engine: ...................................... 46
3.1.1.
Mudança de Paradigma ....................................................................................... 48
3.1.2.
Bigtable................................................................................................................. 48
3.1.3.
Entidades e Modelos ............................................................................................ 49
3.1.3.1.
Interface Model ................................................................................................ 50
3.1.3.2.
Modelo Expando ............................................................................................... 51
3.1.3.3.
Modelo Polimórfico .......................................................................................... 52
3.1.3.4.
Propriedades e Tipos ........................................................................................ 54
3.1.4.
Chaves e Grupos de Entidades ............................................................................ 55
3.1.5.
Consultas e Índices ............................................................................................... 55
3.1.6.
Referência de GQL .............................................................................................. 56
X
3.2.
Ferramentas do App Engine ................................................................................... 59
3.2.1.
Servidor de Desenvolvimento .............................................................................. 59
3.2.2.
Envio de dados em Massa .................................................................................... 61
3.3.
Considerações Finais ............................................................................................... 64
4. ESTUDO DE CASO: DESENVOLVIMENTO DE UMA APLICAÇÃO COM
BANCO DE DADOS EM COMPUTAÇÃO NAS NUVENS ............................................ 65
4.1.
Cenário do Estudo de Caso ..................................................................................... 65
4.2.
Desenvolvimento ...................................................................................................... 67
4.2.1.
Desenvolvimento do Aplicativo ........................................................................... 68
4.2.2.
A Base de Dados ................................................................................................... 71
4.2.3.
Armazenamento de Dados nas Nuvens ............................................................... 72
4.2.3.1.
4.3.
Preparação dos Dados ...................................................................................... 73
Execução .................................................................................................................. 74
4.3.1.
Envio de Dados para as Nuvens .......................................................................... 74
4.3.2.
Envio dos Dados Para as Nuvens ........................................................................ 77
4.3.3.
Realização de Teste .............................................................................................. 81
4.4.
5.
Considerações Finais ............................................................................................... 82
CONCLUSÃO ............................................................................................................. 84
5.1.
Conclusões ............................................................................................................... 84
5.2.
Contribuições ........................................................................................................... 85
5.3.
Trabalhos Futuros ................................................................................................... 85
6.
REFERÊNCIAS BIBLIOGRÁFICAS ....................................................................... 86
XI
LISTA DE FIGURAS
Figura 1 - Arquitetura de uma aplicação Web ................................................................. 16
Figura 2 - Arquitetura do Google App Engine ................................................................. 17
Figura 3 - Ranking das 10 tecnologias estratégicas para 2010 ......................................... 18
Figura 4 - Ilustração de uma Nuvem servindo aplicativos a diversos dispositivos .......... 24
Figura 5 - Public Cloud ...................................................................................................... 25
Figura 6 - Private Cloud .................................................................................................... 26
Figura 7 - Community Cloud ............................................................................................ 27
Figura 8 - Funcionamento da Hybrid Cloud..................................................................... 28
Figura 9 - Camadas de arquitetura de serviço .................................................................. 29
Figura 10 - Console de administração de aplicativos do App Engine .............................. 33
Figura 11 - Linha de serviços oferecidos pela plataforma Azure ..................................... 36
Figura 12 - Comparação entre diferentes plataformas de cloud computing ................... 37
Figura 13 - Foto sendo editada com ferramentas do Photoshop Online .......................... 41
Figura 14 - Imagem da tela do editor de texto do Google Docs ........................................ 42
Figura 15 - Giftag ............................................................................................................... 43
Figura 16 - Pagina web com demonstrativo do funcionamento do sistema Onlive ......... 44
Figura 17 - Publicações: Banco de Dados Relacional vs. Banco de Dados Orientado a
Colunas ............................................................................................................................... 47
Figura 18 - Ilustração de uma entidade ............................................................................ 50
Figura 19 - Código na linguagem Pyhton da entidade Pessoa .......................................... 51
Figura 20 - Demonstração de uma classe Expando .......................................................... 52
Figura 21 - Entidade polimórfica ...................................................................................... 53
Figura 22 - Dados suportados pelo App Engine ............................................................... 54
XII
Figura 23 - Consulta GQL ................................................................................................. 56
Figura 24 - Consulta GQL com valor de filtro alterado ................................................... 56
Figura 25 - Consulta GQL ao banco de dados .................................................................. 57
Figura 26 - Consulta GQL utilizando o operador IN ....................................................... 58
Figura 27 - Entidades resgatadas pela consulta com utilização do operador IN ............. 58
Figura 28 - Launcher de aplicativos do App Engine ........................................................ 60
Figura 29 - Console de administrador do App Engine ..................................................... 61
Figura 30 - Classe modelo .................................................................................................. 62
Figura 31 - Classe carregadora de dados .......................................................................... 63
Figura 32 - Limites diários do App Engine ....................................................................... 66
Figura 33 - Limites diários do App Engine ....................................................................... 66
Figura 34 - Arquivo app.yaml ........................................................................................... 68
Figura 35 - Classe de definição de modelos de entidade ................................................... 69
Figura 36 - Classe carregadora ......................................................................................... 70
Figura 37 - Modelo Entidade-Relacionamento ................................................................. 72
Figura 38 - SQL que converte dados em arquivo CSV..................................................... 73
Figura 39 - Função lambda de conversão de codificação ................................................. 74
Figura 40 - Chamada à função lambda ............................................................................. 74
Figura 41 - Formulário para registro de nova aplicação .................................................. 75
Figura 42 - Envio da aplicação para o App Engine .......................................................... 76
Figura 43 - Conexão com servidor .................................................................................... 76
Figura 44 - Visão do Console Administrativo do App Engine ......................................... 77
Figura 45 - Mapeamento do remote_api ........................................................................... 77
Figura 46 - Comando upload_data .................................................................................... 78
Figura 47 - Uso Máximo de CPU nas Cotas Gratuitas ..................................................... 79
XIII
Figura 48 - Mensagem de Erro ao Tentar Visualizar as Estatísticas ............................... 79
Figura 49 - Gráfico Estatístico Gerado no App Engine .................................................... 80
Figura 50 - Espaço Total Utilizado Pela Aplicação........................................................... 81
Figura 51 - Consulta GQL ................................................................................................. 81
Figura 52 - Recuperação de dados e soma do potencial de lucro ..................................... 82
Figura 53 - Resultado obtido após a realização de teste ................................................... 82
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
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 (http://www.livejournal.com/), 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:
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):
17
Figura 2 - Arquitetura do Google App Engine
Fonte: (CHANEZON, 2009)
O webmail é um exemplo de computação nas nuvens, anteriormente para
visualizar um email, 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.
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.
19
1.2. Objetivos
A seguir serão expostos os objetivos gerais e os objetivos específicos deste
trabalho.
1.2.1. Objetivo Geral
Desenvolver e configurar uma aplicação para ser executada no ambiente “nas
nuvens” utilizando uma grande base de dados real.
1.2.2. Objetivos Específicos
Para alcançarmos o objetivo desse trabalho, as seguintes etapas são
necessárias:
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;
20
1.3. 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.
1.4. 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;
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;
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.
2.1. 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).
23
2.1.1. 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 email, anteriormente era necessário que o software de
emails 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 emails,
não existe mais a necessidade de instalação de um software receptor de emails, os emails 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.
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).
2.1.2. 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).
25
2.1.2.1.
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).
26
2.1.2.2.
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).
27
2.1.2.3.
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)
A Figura 7 ilustra o acesso por diversos usuários a nuvens compartilhadas
pelos mesmos.
2.1.2.4.
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:
28
Figura 8 - Funcionamento da Hybrid Cloud
Fonte: (Johnston, 2009)
Na figura 8 a empresa mantém uma nuvem privada e tem acesso a uma nuvem
publica.
2.1.2.5.
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).
29
2.1.3. 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)
30
2.1.3.1.
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).
2.1.3.2.
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.
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).
2.1.3.3.
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).
32
2.1.4. 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 2.1.4.1 até a Subseção 2.1.4.4 serão apresentados os principais
servidores de computação nas nuvens disponíveis.
2.1.4.1.
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:
33
Figura 10 - Console de administração de aplicativos do App Engine
2.1.4.2.
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).
34
As configurações de instâncias são disponibilizadas em 8 modelos, divididos
por categorias:
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;
Ou então para aplicações que necessitem de mais processamento que memória,
podem utilizar o c1.xlarge:
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;
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.
2.1.4.3.
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;
36
Seus serviços incluem também a Private Cloud, para empresas que necessitam
de servidores totalmente dedicados a seus negócios.
2.1.4.4.
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,
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
38
2.2. 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.
2.2.1. Email
Uma das primeiras aplicações a serem disponibilizadas para os usuários foram
as aplicações de email no próprio browser, pois antes era necessário a utilização de um
39
software instalado no PC do usuário que busca-se nos servidores das empresas os emails
recebidos e assim poder manipulá-los (WIKIPEDIA, 2010c).
O email 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.
2.2.2. 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.
2.2.3. 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).
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.
2.2.4. 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).
41
2.2.5. Aplicativos nas nuvens
A Subseção 2.2.5.1 a Subseção 2.2.5.4 tem por fim apresentar algumas
aplicações populares alocadas no ambiente das nuvens.
2.2.5.1.
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
42
2.2.5.2.
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.
43
2.2.5.3.
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, Email 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
44
2.2.5.4.
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.
45
2.3. 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.
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.
3.1. 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 3.1.1.
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).
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).
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.
3.1.1. 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.
3.1.2. 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
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).
3.1.3. 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 3.1.6. 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.
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 3.2.1 (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.
3.1.3.1.
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).
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).
3.1.3.2.
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).
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 3.1.3.4 (GOOGLE, 2010).
Uma classe de modelo expando é uma subclasse da superclasse Expando.
Enquanto a classe Expando é uma subclasse da superclasse Model (SANDERSON, 2009).
3.1.3.3.
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).
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.
54
3.1.3.4.
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)
55
3.1.4. 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.
3.1.5. 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:
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.
3.1.6. 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
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:
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
59
3.2. 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).
3.2.1. 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.
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
http://localhost:8080/_ah/admin. Onde podem ser visualizadas as entidades do tipo Pessoa,
armazenadas localmente.
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.
3.2.2. 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.
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.
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.
64
3.3. 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.
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.
4.1. 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:
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:
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 64 3800+ 2.41Ghz;
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.
4.2. 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.
68
4.2.1. 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
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
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 4.2.3. 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.
71
4.2.2. 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:
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 4.2.3.1.
4.2.3. 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.
73
4.2.3.1.
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:
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.
4.3. 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 4.3.2.
4.3.1. Envio de Dados para as Nuvens
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 http://appengine.google.com/),
feito o login criamos uma nova aplicação. A Figura 41 demonstra o formulário para registro
de uma nova aplicação nas nuvens:
1
2
3
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
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 (http://appengine.google.com/) e será solicitado o email e a senha de registro do
App Engine. A Figura 43 ilustra a conexão com o servidor e a requisição do email 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.
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.
4.3.2. 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
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 4.3.1.
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 email 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.
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
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:
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
4.3.3. 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
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 831710.00 e 149710 entidades verificadas:
Figura 53 - Resultado obtido após a realização de teste
4.4. Considerações Finais
83
Este capítulo apresentou o cenário do estudo de caso, a preparação dos dados
anteriores ao envio, configurações das ferramentas, o desenvolvimento da aplicação e a
realização de teste do aplicativo.
84
5. CONCLUSÃO
Este capítulo tem por objetivo descrever as principais contribuições,
conclusões e experiências adquiridas ao longo deste trabalho, e esboçar os trabalhos futuros
que podem se estender deste projeto.
Este capítulo está organizado como segue: na Seção 5.1 são apresentadas as
conclusões, a Seção 5.2 apresenta as principais contribuições deste trabalho e a Seção 5.3
apresenta os trabalhos futuros.
5.1. Conclusões
Este trabalho apresentou um modelo para conversão de uma base de dados do
modelo relacional para o modelo orientado a colunas. E foi verificado que apesar de ser uma
nova tecnologia, funciona como uma alternativa aos bancos de dados tradicionais até mesmo
para grandes massas de dados.
Por ser o primeiro modelo estabelecido para conversão de dados de um
datawarehouse poderá ser utilizado como referência para trabalhos futuros.
Os aplicativos disponibilizados nas nuvens de uma maneira geral se tornam
mais acessíveis e preparados para serem utilizados entre diversos tipos de dispositivos, além
de dificultar a cópia e utilização indevida de softwares proprietários. Dessa forma retirando
parte do processamento e armazenamento dos módulos do software antes realizados no
próprio aparelho.
O novo modelo de mercado criado através da Computação nas Nuvens
possibilitara uma integração maior entre os diversos dispositivos eletrônicos que tem acesso a
internet, possibilitando que diversas soluções para problemas antes considerados incorrigíveis
sejam alcançadas, através da colaboração e envolvimento entre clientes e empresas será
possível um enriquecimento das aplicações desenvolvidas que utilizam o conceito do beta
perpetuo, pois sempre será possível melhorar o sistema.
A experiência adquirida durante o processo de desenvolvimento realizado foi
algo além das expectativas, atribuindo isso as diversas etapas decorridas para planejamento,
85
adequação, solução de problemas, desenvolvimento, correção e testes do trabalho, unindo
uma nova maneira de visualizar aquilo que antes aceitávamos como única meio, através do
que muitas vezes nos indagamos “E por que isso tem que ser assim?”, paradigmas existem
não só para serem estudados, mas também quebrados.
5.2. Contribuições
O acesso a base de dados gerada para o desenvolvimento do trabalho será
disponibilizada para fins de estudos da comunidade, através de adição de permissão para
manipulação da base de dados nas nuvens.
Os conhecimentos adquiridos durante a graduação foram plenamente utilizados
no trabalho, se estendendo do planejamento aos testes do trabalho, passando especialmente
dentre o desenvolvimento da aplicação Web e criação do banco de dados, abordando diversas
tecnologias como Python, GQL.
5.3. Trabalhos Futuros
Abaixo são listados alguns projetos futuros:
a) Ampliação da base de dados para testes comparativos;
b) Desenvolvimento de novas aplicações que utilizem da base de dados;
c) Criação de um guia de desenvolvimento de aplicações nas nuvens com
tutoriais através de linguagem simples para iniciantes nessa tecnologia;
d) Desenvolvimento de aplicações ainda não tão exploradas na
Computação
nas
Nuvens,
como
renderização
de
modelos
tridimensionais;
e) Solucionar os diversos problemas hoje enfrentados pela computação
local;
86
6. REFERÊNCIAS BIBLIOGRÁFICAS
AMAZON, 2010a. Disponível em: <http://aws.amazon.com/>.
AMAZON, 2010b. Disponível em: <http://aws.amazon.com/ec2/>.
AMRHEIN, D., et al.; Cloud Computing Use Cases, Open Cloud Manifesto, 2010.
ASSUNÇÃO, M. D., CONSTANZO, A., BUYYA, R.; Evaluating the Cost-Benefit of Using
Cloud Computing to Extend the Capacity of Clusters, Communications of the ACM, Junho de
2009, pg. 141-150.
ARMBRUST, M., FOX, A., GRIFFITH, R., JOSEPH, A. D., KATZ, R., KONWINSKI, A.,
LEE, G., PATTERSON, D., RABKIN, A., STOICA, I., ZAHARIA, M.; A View of Cloud
Computing, Communications of the ACM , Abril de 2010, pg. 50-58.
BARROS, F.; Cloud Computing: Prepare-se para a nova onda em tecnologia,
Computerworld, Abril de 2008.
BUYYA, R., YEO, C. S., VENUGOPAL, S.; Market-Oriented Cloud Computing: Vision,
Hype, and Reality for Delivering IT Services as Computing Utilities, IEEE Computer Society,
2008.
CHA, M., KWAK, H., RODRIGUEZ, P., AHN, Y.Y., MOON, S.; I Tube, You Tube,
Everybody Tubes: Analyzing the World‟s Largest User Generated Content Video System,
Communications of the ACM, Outubro de 2007, pg. 1-14.
CHANEZON, P.; Google App Engine now Serving Java, Google Developers Day, 2009.
CHANG, F., DEAN, J., GHEMAWAT, S., HSIEH, W. C., WALLACH, D. A., BURROWS,
M., CHANDRA, T., FIKES, A., GRUBER, R. E.; Bigtable: A Distributed Storage System for
Structured Data, Communications of the ACM, Junho de 2006, pg. 1-26.
87
CIURANA, E.; Developing With Google App Engine, Editora Apress, 2008.
CREEGER, M.; Cloud Computing: An Overview, Communications of the ACM, Junho de
2009, pg. 3-4.
CUSUMANO, M.; Cloud Computing and SaaS as New Computing Platforms,
Communications of the ACM, Abril de 2010, pg. 27-29.
DELIC, A. K., WALKER, M. A.; Emergence of the Academic Computing Clouds,
Communications of the ACM, Agosto de 2008, pg. 1-4.
DYM, R.; Why Software as a Service? Helping Our Customers Reduce Costs and Increase
Revenue, OpSource, 2009. Disponível em <http://www.opsource.net/saas/wp_why_saas.pdf>.
FITZPATRICK, B.; LiveJournal: Behind the Cenes, 2007. Disponível em:
<http://www.danga.com/words/2007_04_linuxfest_nw/linuxfest.pdf>.
FOUQUET, M., NIEDERMAYER, H., CARLE, G.; Cloud Computing for the Masses,
Communications of the ACM, Dezembro de 2009, pg. 31-36.
FRAGA, R.; Computação nas nuvens: Google quer construir o futuro dos computadores, 8 de
maio de 2008. Disponível em: <http://googlediscovery.com/2008/05/08/computacao-nasnuvens-google-quer-construir-o-futuro-dos-computadores/>.
GARTNER, 2009. Disponível em: <http://www.gartner.com/ >.
GIFTAG, 2010. Disponível em: <http://www.giftag.com/>.
GNU, 2008. Disponível em: <http://www.gnu.org/licenses/licenses.html#GPL>.
GOOGLE, 2010. Disponível em: <http://code.google.com/intl/pt-BR/appengine/docs/>.
HAYES, B.; Cloud Computing, Communications of the ACM, Julho de 2008, pg. 9-11.
88
HOLTZBLATT, L.J., DAMIANOS, L. R., WEISS, D.; Factors Impeding Wiki Use in the
Enterprise: A Case Study, Communications of the ACM, Abril de 2010.
JOHNSTON, S; Cloud Computing Types: Public Cloud, Hybrid Cloud, Private Cloud, 2009.
Disponível em:<http://samj.net/2009/03/cloud-computing-types-public-cloud.html>.
KELLY, K; A Cloudbook for the Cloud, 2007.
KRANGEL, E; IBM Embraces Juniper For Its Smart 'Hybrid Cloud', Disses Cisco (IBM),
2009.
LAPLANTE, P. A.; ZHANG, J.; VOAS, J., What's in a Name? Distinguishing between SaaS
and SOA, IT Professional, vol.10, no.3, pp.46-50, 2008.
LAWTON, G.; Developing Software Online With Platform-as-a-Service Technology, IEEE
Computer Society, 2008.
LEAVITT, N.; Will NoSQL Databases Live Up to Their Promise?, IEEE Computer Society,
2010.
LOCAWEB, 2010. Disponível em: <http://www.locaweb.com.br/produtos/cloudserver.html,2010>.
MICROSOFT, 2010a. Disponível em: <http://www.microsoft.com/windowsazure/>.
MICROSOFT, 2010b. Disponível em:
<download.microsoft.com/download/E/B/0/EB0212B9-D40D-4A82-88C136A99891367C/BuildingConfidence_Cloud_Whitepaper.doc+cloud+computing>. Acesso em
15/01/10.
MORROW, M.; From India to Intercloud, CISCO SP360: Service Provider, 2009. Disponível
em: <http://blogs.cisco.com/sp/comments/from_india_to_intercloud/>.
89
MULHOLLAND, A., et al. The Cloud and SOA: Creating an Architecture for Today and for
the Future, 2008. Disponível em: <
http://www.hp.com/hpinfo/analystrelations/wp_cloudcomputing_soa_capgemini_hp.pdf >.
O'REILLY,T.; What Is Web 2.0: Design Patterns and Business
Models for the Next Generation of Software, Editora O‟Reilly Media, 2007.
ONLIVE, 2010. Disponível em: <http://www.onlive.com/>.
RECUERO, R. C.; Um estudo do Capital Social gerado a partir de Redes Sociais no Orkut e
nos Weblogs, 2005.
REPASS, M.; From Spark Plug to Drive Train: Life on a Request of an App Engine Request,
Google Developers Day Brazil, 2009.
ROSSUM, G. V.; Python Reference Manual, 2008.
SANDERSON, D.; Programming Google App Engine, Editora O‟Reilly Media, 2009.
SAVAGE, N.; New Search Challenges and Opportunities, Communications of the ACM,
Janeiro de 2010, pg. 27-28.
SCHOFIELD, J.; Google angles for business users with 'platform as a service', The Guardian,
Abril de 2008.
STATEN, J.; Is Cloud Computing Ready for The Enterprise?, Forrester Research Inc., Junho
de 2008.
STONEBRAKER, M,; SQL Databases v. NoSQL Databases, Communications of the ACM,
Abril de 2010, pg. 10-11.
TAURION, C.; Computação em Nuvem: Transformando o Mundo da Tecnologia da
Informação, Editora Brasport, 2008.
90
VAQUERO, L. M., RODERO-MERINO, L., CACERES, J., LINDNER, M.; A Break in the
Clouds: Towards a Cloud Definition, Communications of the ACM, Dezembro de 2008, pg.
50-55.
VILARIN, G. O.; Cibercultura, Capitalismo e a Cloud Computing, Universidade Federal da
Bahia, 2009.
WIKIPEDIA, 2010a. Disponível em: <
http://en.wikipedia.org/wiki/Infrastructure_as_a_service#Infrastructure>.
WIKIPEDIA, 2010b. Disponível em: < http://pt.wikipedia.org/wiki/Orkut>.
WIKIPEDIA, 2010c. Disponível em: <http://pt.wikipedia.org/wiki/E-mail>.