Armazenamento de Dados Aplicado à Computação em Nuvem. Perguntas, sugestões ou críticas: danielrossi88@gmail.com

1. Armazenamento de Dados Aplicado à Computação em
Nuvem
Daniel Luan Rossi1
, Jorge Rafael Assmann1
, Mateus Wagner Rigo1
1
Universidade Regional do Noroeste do Estado do Rio Grande do Sul (UNIJUI)
Rod RS 344, Km 39 - CEP 98900-000 – Santa Rosa – RS – Brasil
danielrossi88@gmail.com, jorge.assmann89@hotmail.com,
mateusrigo@hotmail.com
Resumo. A Computação em Nuvem vem sendo apontada nos últimos anos
como um dos temas de maior importância relacionados à portabilidade. Com
o acelerado crescimento na utilização de dispositivos móveis, como tablets e
smartphones, surgiu a necessidade de fornecer recursos computacionais
através serviços por uma conexão de rede. Com este cenário, surge a
necessidade de analisar como os dados devem ser armazenados na
Computação em Nuvem, de forma a permitir o acesso de qualquer local e
dispositivo. Este artigo apresenta uma visão geral desse tema, apontando suas
características e vantagens, também abordando as principais ferramentas
disponíveis atualmente para o gerenciamento dos dados armazenados na
Nuvem.
Palavras-chave. Banco de Dados em Nuvem, Gerenciamento de Dados,
NoSQL, escalabilidade.
1. Introdução
A consolidação da expressão Computação em Nuvem, e a sua ascensão nos últimos
anos, têm atraído a atenção do público em geral, mas especialmente de grandes
empresas. Estas costumam investir pesado em recursos computacionais e segurança da
informação. Segundo Abadi (2009), assim como a rede elétrica revolucionou o acesso à
eletricidade a uma centena de anos atrás, liberando as empresas de ter de gerar sua
própria energia e possibilitando-as focar em seus diferenciais de negócios, a
Computação em Nuvem é saudada como um fator revolucionário da Tecnologia da
Informação, libertando as companhias de grandes investimentos de capital, e permitindo
às mesmas estarem conectadas através de recursos computacionais extremamente
poderosos na rede. Como o acesso à nuvem somente requer que o usuário possua uma
conexão de rede, seja via cabo ou sem fio, essa tecnologia apresenta muita praticidade, e
representa uma redução considerável nos custos relacionados com Tecnologia da
Informação. Os serviços são disponibilizados através de software, infraestruturas e
plataformas, os quais podem ser adquiridos sob demanda. Porém, mesmo que possa
representar o fim do armazenamento local de informações, ainda enfrenta resistência
devido à preocupação dos usuários quanto ao gerenciamento e segurança dos dados
armazenados em nuvem.
O volume de dados produzidos e armazenados no mundo aumenta
constantemente, e as unidades de medidas as quais estamos acostumados, como giga ou
terabytes, vão se tornando antiquadas, pois passamos a nos deparar com palavras como

2. peta, exa e até mesmo zettabytes. A previsão é que a quantidade de dados na Internet
chegue a oito zettabytes em 2015 (GANTZ, J., REINSEL, D., 2010). As razões que
justificam tal crescimento são a permanente conectividade dos usuários à Internet, o
armazenamento de informações de clientes, fornecedores e operações comerciais por
parte de empresas, além dos milhões de sensores, câmeras, celulares e veículos.
O Banco de Dados em Nuvem tem como proposta solucionar as dificuldades
impostas pelo crescimento e manutenção de bancos de dados convencionais, com o
consequente investimento em imensos Data Centers, com altos custos de refrigeração e
demais atividades de manutenção dos dados (SANTOS, F., QUEIROZ H., 2012). Além
disso, será importante analisar o desempenho e segurança, especialmente em aplicações
de grande porte, observando que não se sabe onde realmente estão armazenados os
dados.
2. Computação em Nuvem
O termo nuvem refere-se a uma camada conceitual que possui toda a infraestrutura para
funcionamento e promoção dos recursos como serviço, chamado de pay-per-use (pagar
por uso), onde é pago apenas o que é consumido. Dessa forma a nuvem, representada na
Figura 01, apresenta uma interface padronizada que aloca todos os serviços disponíveis
de forma dinâmica e com abstração da complexidade.
Segundo Taurion (2009), a computação em nuvem é um modelo de tecnologia
baseado no uso compartilhado de recursos de software e hardware através da rede
internet, de forma configurável, sob demanda.
O termo Cloud Computing surgiu em 2006 através das grandes empresas Google
e Amazon, implementando uma tecnologia para gerenciamento dos seus próprios Data
Centers, disponibilizando os recursos computacionais como serviço. A Amazon lançou
pouco depois um dos primeiros instrumentos de computação em nuvem, chamado de
EC2 (Elastic Cloud Computing) que oferece basicamente um ambiente virtualizado.
Figura 01: Ilustração da nuvem como camada de abstração da infraestrutura ao
usuário. Fonte: Adaptada de Brado Networks (2009).
Conforme Chirigati (2009), esse novo paradigma computacional transporta todos
os recursos computacionais para a rede, reduzindo o custo com hardware e software.
Desta forma, o computador será apenas uma fonte de acesso às aplicações através da

3. grande nuvem, a Internet.
Adicionalmente, existem algumas características próprias que definem a
Computação em Nuvem:
 Alta disponibilidade de recursos – é possível aumentar a quantidade de
recursos oferecidos pelo servidor, criando a impressão de disponibilidade
infinita de recursos.
 Não há necessidade de alocar recursos previamente – os recursos podem
ser inseridos conforme a demanda. Esta medida permite reduzir
consideravelmente o custo.
 Elasticidade – permite a alocação de recursos de forma dinâmica,
aumentando ou diminuindo sua quantidade, conforme houver a
necessidade.
 Pay-per-use (pagamento pelo uso) – o pagamento dos recursos obtidos
em nuvem é feito com base nos recursos utilizados.
 Abstração da complexidade – o usuário não necessita preocupar-se com a
complexidade da infraestrutura e expansão geográfica, pois os recursos
estão disponíveis em qualquer local onde houver acesso à internet.
 Heterogeneidade – é possível utilizar ambientes heterogêneos, ou seja, os
sistemas componentes da nuvem podem utilizar diferentes tipos de
tecnologia, e ainda assim estar abstraído ao usuário.
 Escalabilidade – permite o crescimento ou redução da disposição de
recursos, conforme a demanda.
3. Modelos de Serviço na Nuvem
Conforme abordado anteriormente, a Computação em Nuvem traz os recursos ao
usuário final através de serviços, os quais podem ser classificados em três modelos
principais. A camada de infraestrutura é a mais baixa. Através dela, os prestadores de
infraestrutura disponibilizam os serviços de rede e armazenamento da nuvem. A camada
de plataforma possui uma abstração mais elevada e provê serviços para que as
aplicações possam ser desenvolvidas, testadas e mantidas no ambiente da nuvem pelos
prestadores de serviços. A camada com mais alto nível de abstração é a de aplicação, a
qual oferece diversas aplicações como serviços para os usuários (CHIRIGATI, 2009).
Abaixo abordamos, de forma mais detalhada, cada uma destas camadas:
3.1 Software como Serviço (SaaS)
No modelo SaaS (Software as a Service), o fornecedor mantém as aplicações de
software instaladas e disponíveis através da internet para fins específicos, dentro da sua
infraestrutura de nuvem. O cliente possui todo o controle administrativo da aplicação,
porém o fornecedor fica responsável pelo controle dos recursos necessários para a
manutenção das aplicações, garantindo a disponibilidade das mesmas. Dessa forma, o
cliente fica alheio à responsabilidade de controle da infraestrutura do software, o que é
observado nos modelos tradicionais.
Devido ao serviço (software) ser disponibilizado através da Web, este pode ser
acessado em qualquer lugar e ainda ser atualizado com novos recursos sem que o

4. usuário final perceba a ação. Podemos destacar a redução de custos, pois não há
necessidade de aquisição de licenças para utilização desses softwares. Esse modelo
permite que seus usuários mantenham o foco no objetivo do seu projeto, retirando a
preocupação com a infraestrutura. Como grandes exemplos de SaaS, podemos citar o
Google Docs e Gmail.
3.2 Plataforma como Serviço (PaaS)
Para Chirigati (2009), a PaaS (Platform as a Service) fornece uma plataforma de
desenvolvimento, onde é realizado o encapsulamento da camada de software e
disponibilizada como serviço através da nuvem, possibilitando a implementação de
serviços de alto nível, sem se preocupar com a infraestrutura. Essa plataforma pode ser
considerada uma camada de integração entre a aplicação, como uma API (Application
Program Interface). Utilizando esta tecnologia, elimina-se a necessidade de manutenção
nos hardwares e softwares disponibilizados como serviço, sendo uma solução altamente
adaptável e de larga escalabilidade, e diminuindo o risco com possíveis investimentos.
3.3 Infraestrutura como Serviço (IaaS)
A IaaS (Infrastructure as a Service) pode ser interpretada como a camada primária de
uma nuvem, sendo a camada estrutural da qual provêm os recursos necessários para o
funcionamento do PaaS e SaaS, como servidores, sistemas de armazenamento, rede,
roteadores, entre outros. Os recursos desta camada são disponibilizados através de
virtualização – ambientes virtuais que abstraem as características do hardware – e
podem ser configuradas dinamicamente, elevando ou reduzindo a quantidade de
recursos conforme a demanda de aplicações.
Chirigati (2009) demonstra na Figura 02 um exemplo de interação entre ambos
os modelos já citados, criando dois IaaS, um como servidor e outro para sistema de
armazenamento, servindo como infraestrutura necessária para um PaaS. Através do
PaaS são produzidas as aplicações SaaS A e B, as quais são consumidas pelo usuário
final.
Figura 02: Ilustração da interdependência entre os serviços da nuvem.
Fonte: Chirigati (2009)

5. 4. Banco de Dados em Nuvem (BDN)
Através da Computação em Nuvem, surge a necessidade de utilização de Banco de
Dados em Nuvem (BDN). Segundo Arruda (2012), não há na literatura uma definição
formal para o termo, apesar do uso cada vez mais generalizado do mesmo. Ainda
segundo ele, em geral podemos definir um BDN como uma coleção de dados inter-
relacionados que estão armazenados na web, e que podem ser gerenciados e
manipulados através de Sistemas de Gerenciamento de Dados em Nuvem (SGDN). De
acordo com a pesquisa Database Trends Survey Report, realizada pela Embarcadero
Technologies (2010), Banco de Dados em Nuvem é considerado o tema de maior
impacto na comunidade de Banco de Dados para os próximos anos, superando até
mesmo o tema Virtualização.
Os BDN compartilham das mesmas características dos demais componentes da
nuvem, no que compete ao potencial de atração de clientes de diversos setores do
mercado, devido à redução de custos e a escalabilidade, que dá ao usuário a impressão
de uma disponibilidade infinita de espaço para armazenamento de seus dados.
A maior questão que deve ser observada nos BDN diz respeito ao
provisionamento de recursos, pois ao contrário do que temos em um SGBD
convencional (com a alocação de recursos feita individualmente para cada banco de
dados), em um ambiente de nuvem a alocação pode ser feita simultaneamente para
vários SGBDs.
4.1 Banco de Dados como Serviço (DaaS)
Além dos serviços apresentados anteriormente, existe um em particular que comporta a
administração e gerência de banco de dados em nuvem – o Banco de Dados como
Serviço (DaaS). O uso deste serviço geralmente ocorre sob demanda, sendo custeado
pela empresa contratante apenas a quantidade de dados trafegados ou armazenados na
nuvel, não sendo cobrada a capacidade ociosa. Neste caso, a redução de custos ocorre
pois não são utilizados alguns procedimentos muito comuns em modelos tradicionais,
como a manutenção de softwares e execução de backups. Ainda, proporciona uma
elasticidade de recursos adequada ao uso, aumentando ou diminuindo o volume de
dados armazenados ou trafegados.
A criação do DaaS trouxe alguns desafios relacionados a privacidade, gerência e
escalabilidade dos dados, devido ao fato de que os locais onde são armazenados os
dados não são totalmente conhecidos. Estes desafios colocaram em questão o DaaS aos
olhos de grandes organizações, devido a confiabilidade no armazenamento de dados
sensíveis com segurança e desempenho.
Existem três modelos que ditam a forma de utilização do serviço em conjunto
com o software:
 Modelo de Container – as tabelas são disponibilizadas através de
entidades heterogêneas reunidas em um container, que as representa para
acesso pela aplicação. As entidades representam as tabelas existentes em
bancos de dados tradicionais.
 Modelo de cópia compartilhada – vários clientes compartilham a
infraestrutura computacional e uma mesma cópia do software
gerenciador de banco de dados disponível pela nuvem, porém cada

6. usuário possui um perfil de acesso particular para visualizar os dados.
 Modelo de cópia exclusiva – uma cópia exclusiva do SGBD disponível
na nuvem é disponibilizada ao cliente, compartilhando apenas a
infraestrutura.
5. Gerenciamento de Dados em Nuvem
Conforme Arruda (2012), o gerenciamento dos dados é um fator muito importante
dentro do contexto de computação em nuvem, dada a importância da segurança desses
dados. Os sistemas de Gerenciamento de Banco de Dados (SGDBs) relacionais não
possuem escalabilidade quando atingem uma grande quantidade de dados, além da
complexidade em suas instalações, ocasionando custos elevados em hardware e
software. Estes fatores os tornam candidatos potenciais para implantação em nuvem.
Com esses dados na nuvem, alguns aspectos de armazenamento de dados,
consultas e transações têm sido modificados para garantir a escalabilidade, porém ainda
não existem soluções que combinem estes aspectos para melhorar o desempenho sem
que a consistência dos dados seja comprometida.
A escalabilidade dos sistemas deve ser transparente aos olhos dos usuários, uma
vez que seus dados estão armazenados na nuvem, sem informações a respeito da
localização ou forma de acesso aos mesmos. Conforme a demanda de uso, os sistemas
tornam-se escaláveis.
O serviço deve possuir ampla disponibilidade, de forma que os usuários possam
acessar os dados quando e onde quiserem ou precisar. SGBDs devem possuir um alto
grau de disponibilidade, levando em conta que o ambiente da internet pode possibilitar
atrasos e indisponibilidade do sistema.
Também é necessário que, por exemplo, ao atualizar um determinado dado,
todos os nós do sistema também sejam atualizados, mantendo a integridade, coerência e
consistência dos dados.
6. Sistemas de Gerenciamento de Dados em Nuvem (SGDN)
De acordo com Arruda (2012), um SGDN pode ser definido como um programa que
possibilita a criação, manipulação e gerenciamento de Bancos de Dados em Nuvem.
Segundo Sousa (2011), a infraestrutura de SGDN possui várias vantagens para seus
usuários, como: previsibilidade e custos mais baixos, proporcional à qualidade do
serviço (QoS) e cargas de trabalho reais, complexidade técnica reduzida, graças a
interfaces de acesso unificado e a delegação de tuning e administração de SGBDs, além
da elasticidade e escalabilidade, proporcionando a percepção de recursos quase
infinitos.
De acordo com um artigo escrito por Mitch Pronchinske para o site Dzone,
existe certa polêmica acerca de qual padrão de gerenciamento de dados é mais eficiente
– NoSQL ou Bancos de Dados Relacionais. As discussões mais úteis se dedicam em
determinar as forças e fraquezas de cada solução, e então identificar qual ferramenta
cabe melhor para cada situação. Alguns apoiadores do movimento NoSQL tentaram
esfriar a combatividade e falta de informação ao renomear o acrônimo “NoSQL”, para
“Not Only SQL” (Não Somente SQL). O mesmo artigo realizou uma enquete com
profissionais da área de Bancos de Dados, e identificou quais são os sistemas NoSQL

7. mais utilizados, ou que mais despertam interesse. Podemos verificar, conforme a Figura
03, que a pesquisa destaca entre os SGDN mais comuns o Cassandra, CouchDB, HBase
e MongoDB.
Figura 03: Enquete realizada pelo site Dzone destaca os SGDN que mais des-
pertam interesse dos profissionais. Fonte: Dzone (2010).
A partir destes dados, apresentamos algumas características destes principais
sistemas, e consequentemente estabelecemos alguns critérios para comparação dos
mesmos.
6.1 Projeto Cassandra
O Cassandra é um sistema de armazenamento distribuído de dados, orientado a colunas,
e desenvolvido em Java. Foi inicialmente desenvolvido pela equipe do Facebook em
2008, e sua licença de código aberto foi liberada e incubada pela Fundação Apache,
contando com a empresa DataStax como parceira.
O modelo de dados do Cassandra é do tipo Wide Columns Store, ou seja, é
projetado para trabalhar com arquiteturas distribuídas e em uma escala muito grande
(DataStax, 2011). Segundo Silva (2011), o projeto foi criado através da junção da
arquitetura do Dynamo - banco de dados da Amazon - aplicado ao modelo de dados do
BigTable – banco de dados orientado a colunas criado pelo Google para gerenciar
Petabyte de informações. De acordo com a ACM (2007), o Dynamo apresenta
vantagens importantes com relação à consistência, durabilidade e desempenho,
mantando sempre alta disponibilidade.
Utiliza a linguagem JSON (JavaScript Object Notation), estruturada através de
uma coleção de nomes (das colunas) e valores, conforme o exemplo a seguir:
Tabela 1. Exemplo de notação JSON no Cassandra. Fonte: Laux (2012).
empresas = {
1: {
cep: {name: “cep”, value: “98900-000”, timestamp: 123459678},
bairro: {name: “bairro”, value: “Timbaúva”, timestamp: 125437669},
razao_social: {name: “razão_social”, value: “Unijuí”, timestamp: 125437779},
cnpj: {name: “cnpj”, value: “95845620001”, timestamp: 125437669},
email: {name: “email”, value: “atendimento@unijui.edu.br”, timestamp:
123465835},
}
}
O Projeto Cassandra possui dois aplicativos para administração dos bancos de
21%
15%
15%
33%
8%
8%
SGDN Mais Utilizados
Apache CouchDB
Apache HBase
MongoDB
Apache Cassandra
Neo4J
Outros

8. dados: Cassandra-Cli (nativo do Cassandra) e CQL (Cassandra Query Language) – este
último semelhante aos bancos de dados relacionais em sua operabilidade, pois trabalha
com comandos de sintaxe semelhantes ao SQL (DataStax, 2012). Isso faz com que o
CQL largue na frente do Cassandra-Cli quanto às questões de manipulação de registros
e da estrutura do banco de dados.
Figura 04: Interface do Cassandra-Cli. Fonte: DataStax.
Figura 05: Interface do Cassandra CQL. Fonte: DataStax.
Dentre os principais recursos do Cassandra, destaca-se o Clustering, permitindo
assim a adição gradativa de recursos computacionais para atender as necessidades
crescentes de processamento (Laux, 2012).
6.2 Apache CouchDB
Focado na facilidade de uso e focado na aplicação à Web, o Apache CouchDB é um
banco de dados de código-aberto orientado a documentos (não-relacional). Utiliza
JSON para armazenar os dados, JavaScript como linguagem de consulta e HTTP para
acesso ao API chamado RESTful e ao aplicativo da Web chamado Futon. O termo
“Couch” é um acrônimo para “Cluster of Unreliable Commodity Hardware”, que reflete
a meta do CouchDB de ser extremamente escalável, oferecendo alta disponibilidade e
confiabilidade, mesmo ao ser executado em hardware sujeito a falhas (IBM, 2009).

9. Figura 06: Utilitário Futon do CouchDB. Fonte: IBM.
Como característica deste tipo de banco de dados, os documentos não estão
ligados entre si a um esquema rígido, como ocorre nos bancos de dados relacionais.
Cada documento contém metadados, como um ID exclusivo e números de revisão. A
cada alteração nos dados do documento, uma nova versão deste é criada (chamada
Revisão). Dessa forma, um histórico completo de alterações é registrado
automaticamente pelo banco de dados.
Figura 07: Exemplo da criação de um documento no Futon. O campo “_id”
mostra o nome do documento, enquanto o campo “_rev” contém o número da
revisão.
O CouchDB depende do uso sob demanda das chamadas Views, para criar
relacionamentos arbitrários entre documentos, fornecer recursos de agregação e obter
relatórios de dados.
Os SGBDs relacionais muitas vezes utilizam bloqueio para gerenciar
simultaneidade entre as transações, impedindo que clientes acessem dados enquanto
outro cliente estiver atualizando estes dados. Desta forma, é comum ocorrer
travamentos ao determinar qual cliente deve receber o bloqueio e manter a ordem da fila
de bloqueio. No CouchDB, utiliza-se o método chamado Multiversion Concurrency
Control (MVCC). Neste, cada cliente recebe uma captura instantânea da versão mais
recente do banco de dados, e nenhuma mudança é vista pelos outros usuários até que a
transação tenha sido finalizada (IBM, 2009). Atualmente, a maioria dos bancos de dados
modernos, incluindo os relacionais, já utiliza o bloqueio para MVCC.

10. Conforme Lennon (2009), apesar da constante discussão acerca de qual modelo
é melhor (relacional ou orientado a documentos), o CouchDB nunca foi alegadamente
uma substituição aos bancos de dados relacionais ou um novo padrão de
desenvolvimento de bancos de dados. A proposta é atrair a atenção dos desenvolvedores
para sua simplicidade necessária em muitos projetos nos quais a escolha por bancos
relacionais acaba prejudicando o desempenho dos sistemas.
6.3 Apache HBase
Originalmente criado para uso com o Apache Hadoop (um framework de software com
suporte a aplicações distribuídas com uso intensivo de dados), o Apache HBase é um
banco de dados distribuído, de código aberto, orientado a colunas. Foi modelado
inicialmente basendo-se no BigTable, do Google, pela empresa Powerset (de
propriedade da Microsoft), em 2007, e então doado à Apache.
Segundo Spiegelberg (2011), as principais razões para uso do HBase são:
 Armazenamento de grandes quantidades de dados;
 Alto rendimento na gravação;
 Capacidade de acesso eficiente a grandes conjuntos de dados;
 Altamente escalável;
 Livre de recursos dos bancos relacionais (transações entre tabelas, joins,
etc.).
O HBase suporta dados não estruturados e parcialmente estruturados. Os dados
são organizados em famílias de colunas. Um registro individual, chamado de “célula”, é
endereçado com uma combinação de Row Key, Column Family, Cell Qualifier e Time
Stamp. Ao contrário dos bancos de dados relacionais, nos quais devemos definir a tabela
com antecedência, esta organização permite a flexibilidade da célula de forma a
possibilitar a atribuição da mesma a uma família de colunas, de acordo com o tempo de
execução.
Desde o início de 2011, o Facebook tem sido o grande divulgador do HBase,
aplicando o mesmo no seu sistema de Mensagens, anteriormente baseada no Cassandra.
O fato curioso é que, com 1 Petabyte de capacidade online, o serviço de mensagens do
Facebook é talvez a maior instalação do HBase no mundo.
6.4 Apache MongoDB
O Apache MongoDB é um banco de dados orientado a documentos, de código aberto,
livre de esquemas (não há a definição de tabelas ou campos e relacionamentos, junções
ou transações entre estes), escrito em C++, cuja principal característica é a alta
performance. Segundo Nascimento (2010), é uma mistura entre os repositórios
escaláveis baseados em chave/valor e as funcionalidades de bancos relacionais.
As consultas ao MongoDB produzem resultados muito simples, sendo muito
mais fáceis de escrever e ajustar. Assim como no CouchDB, os documentos são criados
basicamente utilizando a linguagem JSON.
Quanto à escalabilidade, engloba muitas funções que também são importantes
em bancos de dados relacionais, como índices, consultas dinâmicas e atualizações.

11. O MongoDB também trabalha com Sharding, que é basicamente a capacidade de
divisão de dados entre várias máquinas, através de processos e comunicação sobre IP.
Figura 08: Arquitetura de Sharding do MongoDB. Fonte: iMasters (2010).
O MongoDB também trabalha com Sharding, que é basicamente a capacidade de
divisão de dados entre várias máquinas, através de processos e comunicação sobre IP.
Basta adicionar mais shards para a capacidade de armazenamento e desempenho
aumentarem, característica que acompanha bem os objetivos do armazenamento de
dados na nuvem.
6.5 Apache Neo4j
O Neo4j é um banco de dados de código aberto, orientado a grafos. Seus dados e
estruturas são representados pelos conceitos matemáticos da Teoria de Grafos.
Um grafo é desenhado para armazenar dados que naturalmente podem ser
estruturados em forma gráfica. Uma rede social é um exemplo típico, onde temos
usuários que se conectam entre si de várias maneiras (amigo, seguidor, etc.), e se
conectam com outras coisas como ideias, posts, produtos (curtir, seguir, etc.).
Os bancos de dados relacionais não permitem que os dados sejam representados
através de grafos de maneira natural. Com isso, algumas pesquisas tornam-se
extremamente complexas, ou até mesmo impraticáveis. Através da navegação na
estrutura de grafos, podemos executar as mesmas pesquisas de forma muito menos
custosa.
O servidor do Neo4j pode ser manipulado através de várias ferramentas, como
Neo4j Shell, Gremlin ou HTTP.

12. Figura 09: Acesso HTTP ao API do Neo4j. Fonte: TI Selvagem (2013).
7. Conclusão
De acordo com as referências utilizadas no desenvolvimento da pesquisa, pudemos
identificar uma expansão contínua da utilização e desenvolvimento dos bancos de dados
NoSQL, especialmente no âmbito do armazenamento de dados na nuvem.
Devido às suas características gerais de escalabilidade, disponibilidade de
recursos e confiabilidade, os bancos de dados NoSQL vem atraindo as atenções de
grandes empresas, como Facebook, Google, Amazon. O fato de a grande maioria destes
possuírem licença de código aberto é um grande incentivador para que continuem sendo
fortalecidos e consequentemente acabem entrando também nos planos de empresas de
menor porte.
O estudo dos bancos de dados NoSQL nos mostra que, apesar de ainda haver
uma certa desconfiança, os bancos de dados relacionais estão perdendo espaço, na
medida que a oferta de recursos cresce e passa a ser conhecido no mercado não mais
como uma alternativa, mas como uma opção sólida.

13. 8. Referências Bibliográficas
ABADI, Daniel J. “Data Management in the Cloud: Limitations and Opportunities”
(2009). Disponível em: <ftp://131.107.65.22/pub/debull/A09mar/abadi.pdf>. Data de
acesso: 02 de maio de 2013.
ACM. “Amazon’s Dynamo” (2007).
Disponível em:
<http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html>. Data de
acesso: 23 de junho de 2013.
ALMEIDA, A. In: Caelum – “Trabalhando com Relacionamentos: Bancos de Dados
Baseados em Grafos e o Neo4j”.
Disponível em:
<http://blog.caelum.com.br/trabalhando-com-relacionamentos-bancos-de-dados-
baseados-em-grafos-e-o-neo4j/>. Data de acesso: 25 de Junho de 2013.
COSTA, L., DUARTE, O. In: CHIRIGATI, F. “Computação em Nuvem” (2009). Dis-
ponível em:
<http://www.gta.ufrj.br/ensino/eel879/trabalhos_vf_2009_2/seabra/index.html>.
Acesso em 05 de maio de 2013.
COSTA, L., AMORIM, M., CAMPISTA, M., RUBINSTEIN, M., FLORISSI, P., DU-
ARTE, O. “Grandes Massas de Dados na Nuvem: Desafios e Técnicas para Inova-
ção” (2012). Disponível em: <www.gta.ufrj.br/ensino/cpe728/CAC12.pdf>. Data de
acesso: 10 de maio de 2013.
DZONE, “NoSQL DZone Poll Results”.
Disponível em: <http://java.dzone.com/articles/nosql-dzone-poll-results>. Acessado
em: 14 de Junho de 2013.
GANTZ, J., REINSEL, D. “The Digital Universe Decade – Are You Ready?” (2010).
Disponível em: <http://www.emc.com/collateral/analyst-reports/idc-digital-universe-
are-you-ready.pdf>. Data de acesso: 05 de maio de 2013.
HUI, J. “Cassandra-Cli Client” (2011).
Disponível em: <http://jonathanhui.com/cassandra-cli-client>. Data de acesso: 23 de
Junho de 2013.
NASCIMENTO, Jean C. In: iMasters - “3 Razões Para Usar MongoDB” (2010) – Dis-
ponível em: <http://imasters.com.br/artigo/18334/mongodb/3-razoes-para-usar-
mongodb/>. Data de acesso: 23 de Junho de 2013.
NETWORKS, Brado. “Cloud Computing: Entenda como funciona este novo modelo de
computação”. In: SANTOS, F., QUEIROZ H. (2012).
SANTOS, F., QUEIROZ H. “Estudo Comparativo Entre Bancos de Dados em Servido-
res Convencionais e Bancos de Dados em Nuvem” (2012). Disponível em: <
http://info.ucsal.br/banmon/Arquivos/Mono1_0164.pdf>. Data de acesso: 02 de maio
de 2013.

14. TAURION, C. “Cloud Computing: Computação em Nuvem: Transformando o Mundo
da Tecnologia da Informação”. Rio de Janeiro: Brasport, 2009.
SILVA, E. “Introdução a Bancos NoSQL e Apache Cassandra” (2011). Disponível em:
<http://javacomfarinha.blogspot.com/2011/04/introducao-bancos-nosql-e-
apache.html>. Data de acesso: 23 de Junho de 2013.
LENNON, J. In: IBM – “Explorando o CouchDB” (2009). Disponível em:
<http://www.ibm.com/developerworks/br/library/os-couchdb/>. Data de acesso: 24
de Junho de 2013.
SPIEGELBERG, N. In: SlideShare – “Facebook Messages &HBase” (2011). Dis-
ponível em: <http://www.slideshare.net/brizzzdotcom/facebook-messages-hbase>.
Data de acesso: 24 de Junho de 2013.
VARDANYAN, M. In: Monitis – “The NoSQL Databases – A Look at HBase” (2011).
Disponível em: <http://blog.monitis.com/index.php/2011/05/31/the-nosql-databases-
a-look-at-hbase/>. Data de acesso: 24 de Junho de 2013.