Cobo, Cristiane Brandão. Especialização Banco de Dados

UNIVERSIDADE DE RIBEIRÃO PRETO
CENTRO DE CIÊNCIAS EXATAS, NATURAIS E TECNOLÓGICAS
PÓS-GRADUAÇÃO LATO SENSU EM BANCO DE DADOS
CRISTIANE BRANDÃO COBO
NoSQL: Características e Aplicações
Ribeirão Preto
2015

CRISTIANE BRANDÃO COBO
Monografia apresentada ao Centro de Ciências
Exatas, Naturais e Tecnológicas da
Universidade de Ribeirão Preto como parte dos
requisitos para obtenção do título de
Especialista em Banco de Dados.
Orientador: Prof. Dr. Rinaldo Macedo de
Morais
Ribeirão Preto
2015

Ficha catalográfica preparada pelo Centro de Processamento Técnico
da Biblioteca Central da UNAERP
- Universidade de Ribeirão Preto -
Cobo, Cristiane Brandão, 1983-
C657n NoSQL - Características e Aplicações / Cristiane
Brandão
Cobo. - - Ribeirão Preto, 2015.
45f. : il. color.
Orientador: Prof. Dr. Rinaldo Macedo Morais.
Monografia (especialização) - Universidade de
Ribeirão Preto,
UNAERP, Banco de dados. Ribeirão Preto, 2015.
1. Banco de dados. 2. NoSQL. 3. Big data. I.
Título.
CDD 005.1

FOLHA DE APROVAÇÃO
Cristiane Brandão Cobo
Monografia apresentada ao Centro de Ciências
Exatas, Naturais e Tecnológicas da
Universidade de Ribeirão Preto como parte dos
requisitos para obtenção do título de
Especialista em Banco de Dados.
Orientador: Prof. Dr. Rinaldo Macedo de
Morais
Aprovada em: 22/08/2015
Banca Examinadora
Prof. Dr. Rinaldo Macedo de Morais
Instituição: Universidade de Ribeirão Preto – UNAERP
Prof. Dr. Edilson Carlos Caritá
Prof. Marco Aurélio Arantes

DEDICATÓRIA
Aos meus amados pais, que com muito amor e
paciência me deram todo o apoio necessário
para que eu obtivesse tantas conquistas.
À minha querida avó, pelo carinho, pelos
conselhos, elogios e puxões de orelha.
Aos meus primos, tios e amigos, pelos
momentos de alegria, descontração e
constante torcida pela minha realização.

AGRADECIMENTOS
Agradeço à minha querida amiga, Prof. Daniella, por ter me acompanhado durante todo o
curso, inclusive durante o desenvolvimento deste trabalho, me aconselhando, orientando, com
toda paciência, carinho e atenção.
Aos professores do curso de Especialização em Banco de Dados, pela dedicação ao ministrar
as aulas com tanto amor.
Ao meu orientador, Rinaldo Macedo de Morais, pelo apoio e atenção no desenvolvimento
deste trabalho.
Aos colegas de sala, pela receptividade e por terem sido tão prestativos me oferecendo suporte
com o material de metodologia científica.

RESUMO
Esta monografia aborda o NoSQL, banco de dados não relacional, que tem como pontos
principais a escalabilidade que aumenta sua velocidade e capacidade de armazenamento de
dados, a simplicidade de desenvolvimento e manutenção e a ausência de um esquema pré
definido. Atualmente, ele está em grande desenvolvimento e utilização. Grandes empresas
conhecidas mundialmente, como o Google, Amazon, Twitter, Facebook, Ebay e LinkedIn
fazem uso desse tipo de banco. Assim, apresentar sua aplicação, bem como suas principais
características e a importância de os profissionais da área de TI obterem conhecimento sobre
ele, são objetivos desse trabalho. Para isso foi efetuada uma pesquisa bibliográfica sobre o
tema e suas aplicações, bem como consultas sobre sistemas reais de utilização em sites de
alguns fabricantes de bancos de dados não relacionais. Foi também desenvolvida uma
aplicação de Blogs simples, utilizando o MongoDB, apenas para mostrar como funciona seu
desenvolvimento. O PostgreSQL, banco de dados relacional, foi utilizado para comparação de
desempenho caso fosse necessário implementar futuramente consultas que envolvessem um
volume maior de dados, em que neste caso o MongoDB respondeu mais rapidamente e a
complexidade de desenvolvimento foi reduzida. Sendo assim, foi sugerido que os atuais
profissionais de TI necessitam de conhecimento sobre o assunto para que, ao se depararem
com novos requisitos de desenvolvimento, possam avaliar a viabilidade de utilização do
NoSQL, bem como, para que continuem no mercado de trabalho, visto que diversas empresas
estão adotando este tipo de bancos de dados no desenvolvimento de seus sistemas.
Palavras chave: Banco de dados. NoSQL. Não relacional. Big data.

ABSTRACT
This monograph will address the NoSQL, non-relational database, whose main points are the
scalability which increases its speed and storage capacity, the ease of development and
maintenance and the absence of a pre-defined schema. Currently, it is in great development
and use. Large companies known worldwide, such as Google, Amazon, Twitter, Facebook,
Ebay and LinkedIn make use of this type of data base. Thus, present its application, as well as
its main characteristics and the importance of the IT professionals gain knowledge about it are
goals of this work. To achieve these goals, was made a bibliographic research on the subject
and its applications, as well as searches on some manufacturers of non-relational databases’s
sites to find systems that currently use the NoSQL. A simply Blogs application was also
developed using MongoDB, just to show how its development works. PostgreSQL is the
relational database that was used to compare performance if in the future would be necessary
to implement queries that involve a larger volume of data, in which case MongoDB responded
faster and the development complexity was reduced. Thus, it was suggested that today's IT
professionals need to know about it so, when faced with new development requirements, they
will be able to evaluate the feasibility of using NoSQL as well, to continue in the job market,
as that many companies are adopting this kind of databases in their systems development.
Keywords: Data base. NoSQL. Non-relational. Big data.

SUMÁRIO
1 INTRODUÇÃO
1.1 OBJETIVO
1.2 ESTRUTURA DA MONOGRAFIA
2 REVISÃO DE LITERATURA
2.1 CONCEITO DE NOSQL
2.2 NOSQL X BANCO DE DADOS RELACIONAIS
2.3 CARACTERÍSTICAS DO NOSQL
2.3.1 Escalabilidade
2.3.2 Schemaless
2.3.3 Clusterização
2.3.4 Map-Reduce
2.4 TIPOS DE BANCO DE DADOS NOSQL
2.4.1 Bancos de Dados no Esquema Chave/valor (key/value)
2.4.2 Bancos de Dados Orientados a Documentos
2.4.3 Bancos de Dados de Famílias de Colunas
2.4.4 Bancos de Dados de Grafos
2.5 GEOPROCESSAMENTO EM BANCOS DE DADOS NOSQL
2.6 EXEMPLOS REAIS DE UTILIZAÇÃO
2.6.1 MongoDB
2.6.1.1 The Weather Channel
2.6.1.2 Expedia
2.6.1.3 Forbes
2.6.2 Neo4j
2.6.2.1 InfoJobs
2.6.2.2 Walmart
2.6.2.3 Ebay
3 MATERIAIS E MÉTODOS
4 RESULTADOS E DISCUSSÃO
5 CONCLUSÃO
REFERÊNCIAS BIBLIOGRÁFICAS

LISTA DE FIGURAS
Figura 1 – Quadrante Mágico do Gardner
Figura 2 – Empresas Consumidoras do MongoDB.
Figura 3 – Empresas Consumidoras do Neo4J
Figura 4 – Tela de visualização de postagens
Figura 5 – Tela de criação de nova postagem
Figura 6 – Tela de análise de desempenho
Figura 7 – Modelo relacional da aplicação de blogs
Figura 8 – Exemplo de representação de dados da aplicação de blogs no MongoDB
Figura 9 – Resultados das consultas na aplicação de blogs

LISTA DE SIGLAS
ACID Atomicidade, Consistência, Isolamento e Durabilidade
API Application Programming Interface (Interface de Programação de Aplicativos)
BASE Basic Availability, Soft state, Eventual consistency (Basicamente disponível,
Estado leve, Eventualmente consistente)
CAP Consistency, Availability, and Partition tolerance (Consistência,
Disponibilidade, Tolerância a falhas)
CMS Custom Management System (Sistema de Gerenciamento de Conteúdo)
DBMS Database Management System (Sistema de Gerenciamento de Banco de
Dados)
ETL Extract Transform Load (Extração Transformação Carga)
JSON JavaScript Object Notation (Notação de Objeto JavaScript)
NoSQL Not Only SQL (Não só SQL)
OLAP Online Analytical Processing (Processamento Analítico em Tempo Real)
OLTP Online Transaction Processing (Processamento de Transações em Tempo
Real)
RAM Random Access Memory (Memória de Acesso Aleatório)
RDBMS Relational Database Management System (Sistema Relacional de
Gerenciamento de Banco de Dados)
SOA Service-oriented architecture (Arquitetura Orientada a Serviços)
SQL Structured Query Language (Linguagem Estruturada de Consulta)
TI Tecnologia da Informação
XML eXtensible Markup Language (Linguagem de Marcação Extensível)

10
1 INTRODUÇÃO
Os bancos de dados relacionais tem sido a escolha padrão para o armazenamento
de dados, mas depois de um longo período de total dominância, há cerca de uma década, com
o surgimento de grandes aplicações web necessitando de manipulação de dados em grande
escala surgiram os bancos de dados NoSQL que vieram pra suprir em demandas onde os
bancos de dados relacionais não são tão eficientes.
Alguns bancos de dados NoSQL possuem linguagens de consulta similares ao
SQL, tornando-o assim mais fácil de aprender. O resultado mais importante da ascensão do
NoSQL é a persistência poliglota, ou seja, o uso de mais de um banco de dados em uma
mesma aplicação, em que os bancos deixam de ser o gargalo, e se transformam na principal
solução e pode elevar muito o nível de maturidade de qualquer aplicação, independente de sua
natureza.
A maioria dos NoSQL são open-source, característica do MongoDB, principal
banco de dados utilizado neste trabalho para exemplificações do funcionamento do NoSQL.
O MongoDB é um banco de dados não relacional que armazena os dados usando
um modelo de documento de dados flexível de estrutura semelhante ao JSON. Os documentos
contém um ou mais campos incluindo arrays, dados binários e sub-documentos. Os campos
podem variar de documento a documento. Para acessar os documentos, existem drivers
disponíveis na maioria das linguagens de programação. O MongoDB possui o auto-sharding
para escalonamento horizontal e replicação nativa, fazendo uso extensivo de RAM,
proporcionando velocidade na memória e capacidade em disco. Ele também fornece índices
secundários abrangentes, incluindo geoespaciais e de pesquisa de texto, bem como extensas
capacidades de segurança e de agregação. Em 2014, o MongoDB foi avaliado como
challenger, competidor, tradução minha, pelo Gardner, uma das maiores empresas de
auditoria, avaliação e análise de mercado em todo o mundo, que gera dados e números que
influenciam tomadas de decisões importantes em vários pontos do globo, no que se trata de
investimentos e desenvolvimento de novas soluções.

11
Figura 1 – Quadrante Mágico do Gardner
Fonte: Disponível em: <https://www.mongodb.com/lp/misc/gartner-mq-op-db-report>
Acesso em Agosto. 2015.
Por essas características, este foi o banco escolhido para a maioria das
exemplificações deste trabalho.
1.1 OBJETIVO
O objetivo desse trabalho é apresentar as principais características do banco de
dados não relacional – NoSQL, sua aplicação e pontuar a importância de os profissionais da
área de TI obterem conhecimento sobre esse tipo de banco de dados.
1.2 ESTRUTURA DA MONOGRAFIA
No primeiro capítulo da revisão de literatura será apresentado o conceito de
NoSQL, um resumo do seu surgimento e serão citadas algumas de suas características.

12
No segundo capítulo, será efetuado um breve comparativo entre NoSQL e os
bancos de dados relacionais para que o entendimento do NoSQL seja mais facilmente
compreendido, nele, será também brevemente explicado, sobre as transações ACID que são a
base para o sistema de bancos de dados relacionais, e sobre o BASE e Teorema CAP citados,
por vários autores como fundamentação dos bancos de dados não relacionais.
No terceiro capítulo, serão abordadas as características do NoSQL, entre elas,
escalabilidade: vertical, horizontal, replicação e sharding, e também será explicado sobre
schemaless, clusterização e map-reduce.
No quarto capítulo, serão apresentados os tipos de bancos de dados NoSQL, suas
descrições, principais características e exemplos de bancos de dados que os utilizam. Entre
estes exemplos, foram escolhidos alguns para serem descritos brevemente. Os tipos de bancos
NoSQL são: bancos de dados no esquema chave/valor, orientados a documentos, famílias de
colunas e de grafos.
No quinto capítulo, será abordado sobre o geoprocessamento em bancos de dados
NoSQL e citados alguns exemplos.
No sexto capítulo, serão apresentados alguns exemplos reais de utilização, para
esta apresentação foram escolhidos o The Weather Channel, Expedia e Forbes, que são
algumas das empresas consumidoras do MongoDB e o InfoJobs, Walmart e Ebay,
consumidores do Neo4J. MongoDB e o Neo4J são bancos de dados muito utilizados
atualmente, sendo o primeiro um banco de dados orientado a documentos e o segundo, banco
de dados de grafos. E as empresas consumidoras escolhidas são populares e mundialmente
reconhecidas.
Na sessão de materiais e métodos, uma aplicação de blogs desenvolvida na
linguagem Java juntamente com MongoDB será utilizada como exemplo para abordagem
prática do NoSQL. Nesta abordagem será exibido um esquema relacional desta aplicação e
uma exemplificação de armazenamento dos dados no MongoDB para comparação juntamente
com um exemplo de consulta.
Em seguida, os resultados de desempenho de consultas realizadas na aplicação de
blogs utilizando o MongoDB e PostgreSQL serão exibidos e, na discussão, será abordada a
importância dos profissionais de TI obterem conhecimento sobre o NoSQL.
Por fim, a conclusão do trabalho com observações sobre o desenvolvimento e
resultados obtidos.

13
2 REVISAO DE LITERATURA
2.1 CONCEITO DE NOSQL
O termo NoSQL (Not only SQL - Não só SQL) vem do conceito de que o banco
de dados não necessita de normalização e relacionamentos (GONDIM, 2013), ou seja, não
segue normas de tabelas (esquemas) determinadas previamente. Foi inicialmente utilizado, em
1998, como o nome de um banco de dados não relacional de código aberto, criado por Carlos
Strozzi, que acabou alegando que o movimento NoSQL ”é completamente distinto do modelo
relacional e portanto deveria ser mais apropriadamente chamado "NoREL" ou algo que
produzisse o mesmo efeito”. A partir de então, NoSQL passou a ser utilizado para designar os
bancos de dados não relacionais.
Os bancos de dados NoSQL, possuem características muito interessantes como
alta performance, escalabilidade, replicação, suporte a dados estruturados e sub colunas.
Surgiram da necessidade de uma alta escalabilidade e performance superior, pois os atuais
bancos de dados relacionais são muito restritos a isso por utilizarem, em sua maioria, a
distribuição vertical de servidores, ou seja, quanto mais dados, mais memória e mais disco um
servidor precisa.
O NoSQL tem uma grande facilidade na distribuição horizontal, ou seja, mais
dados, mais servidores, não necessariamente de alta performance. O Google é um grande
utilizador desse conceito, que usa computadores de pequeno e médio porte para a distribuição
dos dados, pois essa forma de utilização é muito mais econômica e eficiente. Pode-se dizer
que NoSql apresenta um padrão de armazenamento de dados alternativo ao relacional,
oferecendo melhor robustez e escalabilidade para alguns tipos de sistemas.
Cabe ainda destacar que os bancos de dados NoSQL possuem a característica de
poder trabalhar com dados crus vindos de diversas origens (arquivos de log, web-sites,
arquivos multimídia, entre outros) ou até mesmo dados semi-estruturados e são também muito
tolerantes a erros. No entanto, os bancos de dados NoSQL não têm como objetivo substituir
os bancos de dados relacionais, mas apenas propor algumas soluções que em determinados
cenários são mais adequadas, tais como: escalabilidade, capacidade de armazenamento,
gerenciamento de grandes volumes de dados e baixa latência.

14
2.2 NOSQL X BANCO DE DADOS RELACIONAIS
Um dos pontos de contraste entre os NoSQL e os bancos de dados relacionais é o
suporte a transações ACID (ELSMARI e NAVATHE, 2005), que são o foco dos RDBMS
tradicionais:
- Atomicidade: A transação será executada totalmente ou não será executada.
- Consistência: Uma transação não pode deixar a base de dados em um estado
inconsistente.
- Isolamento: Uma transação não pode interferir em outra.
- Durabilidade: Garante que o que foi salvo não será mais perdido, mesmo após a
aplicação reiniciar.
Segundo Gaurav Vaish (2013), muitos NoSQLs simplesmente não oferecem este
recurso, considerado dispensável em algumas aplicações, principalmente pelo custo
computacional envolvido para provê-las. Sendo assim, ao invés de manter o foco no ACID, o
NoSQL é mais propenso a seguir um teorema chamado BASE, citado pelo cientista da
computação Eric Brewer:
• Basic availability (Basicamente disponível): Uma aplicação funciona
basicamente todo o tempo e uma resposta é sempre garantida para toda requisição, seja de
sucesso ou falha.
• Soft state (Estado leve): O estado do sistema pode alterar ao longo do tempo,
não precisa ser consistente o tempo todo.
• Eventual consistency (Eventualmente consistente): A base de dados pode ser
momentaneamente inconsistente, mas consistente eventualmente, ou seja, o sistema torna-se
consistente no momento necessário.
Eric Brewer também defende o teorema CAP que diz “que é impossível para um
sistema de computador distribuído fornecer consistência, disponibilidade e tolerância ao
particionamento simultaneamente”. Sendo assim, pode-se entender que para sistemas onde
transações são críticas, como bolsa de valores ou bancários o NoSql definitivamente não é
uma solução viável, mas é totalmente indicado para sites de busca ou redes sociais, aplicações
que irão trabalhar com enormes quantidades de dados, que tem exigências de velocidade em
suas consultas e escritas em grande volumes.

15
2.3 CARACTERÍSTICAS DO NOSQL
2.3.1 Escalabilidade
Escalabilidade é uma característica desejável em todo sistema, que indica sua
habilidade de manipular uma porção crescente de trabalho de forma uniforme, ou estar
preparado para crescer.
Em banco de dados, existem duas formas de escalabilidade em que de acordo com
Veras (2011):
Vertical: significa adicionar recursos em um único nó do sistema (mais memória
ou um disco rígido mais rápido).
Horizontal: significa adicionar mais nós ao sistema, tais como um novo
computador com uma aplicação para clusterizar o software.
Os NoSQL estão sendo projetados desde o início para atender a uma maior
escalabilidade horizontal, isto é, fazer com que a adição de novas máquinas ajudem a
melhorar o desempenho do sistema de forma linear. Este tipo de escalabilidade contrasta com
a vertical, onde um servidor precisa ser substituído por outro mais potente para aumentar a
capacidade computacional do sistema. Desta forma, pode-se observar que a horizontal possui
menor custo de expansão.
Replicação é conhecida como um meio de conseguir escalabilidade que consiste
em armazenar cópias dos dados em mais de um lugar. É tradicionalmente implementada
através da criação de uma estrutura master-slave. O banco master é aquele onde são efetuadas
as alterações que são, então, replicadas para o slave. Com isso, as consultas podem ser
executadas agora não só em um, mas em dois nós. Quando as máquinas se sobrecarregarem
de consultas, cria-se um novo nó slave que permite aliviar o trabalho das primeiras. Em uma
arquitetura comum, onde o banco funciona no esquema master-slaves baseado em replicação,
todos os dados estão contidos em todos os nós: a consistência é mantida. Se um nó de leitura
parar de funcionar, não tem problema para as consultas, pois todos os outros nós são capazes
de responder a elas. Mas se o master falhar, as atualizações não funcionam.
Sharding (decomposição) é outra forma de escalar que consiste em dividir a
localização física dos dados, despedaçando-os e colocando seus pedaços em nós distintos. A
escolha de como dividir esses dados é dada através de um algoritmo de Sharding. Dessa

16
maneira, pode-se facilmente distribuir a execução de uma consulta em diversos nós. Porém, se
um dos servidores utilizados nesse Sharding ficar momentaneamente fora do ar, os dados
ficarão indisponíveis. Outro problema pode ocorrer quando uma consulta buscar dados em um
nó e esse resultado envolver executar consultas em outros nós distintos de acordo com cada
resultado original e causar lentidão. Por isso, decidir o algoritmo de Sharding deve depender
das consultas a serem executadas a fim de fazer essa distribuição da melhor forma possível.
Visto estes dois tipos de escalabilidade, uma das melhores soluções é misturar o
sharding com replicação, ganhando maior disponibilidade e deixando ao algoritmo a decisão
de quais nós conterão determinados dados. Mas este é um cenário de alta complexidade e, por
isso mesmo, todo cuidado deve ser tomado para só ser adotado quando realmente necessário.
Alguns sistemas NoSQL, como o “Cassandra”, o “Dynamo”, entre outros,
suportam este cenário pois são descentralizados, ou seja, os dados encontram-se replicados
por várias máquinas, e cada uma delas é autônoma, sendo capaz de responder a qualquer
consulta, fazendo com que a disponibilidade do sistema aumente, uma vez que não existe um
único ponto capaz de comprometer o seu funcionamento. Esta é uma característica que
contrasta com a maior parte das implementações relacionais, onde, geralmente, é empregado
somente um modelo master/slave.
2.3.2 Schemaless
Schemaless ou esquema-free significa, segundo Martin Fowler (2013), “não ter
que definir esquemas”, ou seja, a base de dados permite que qualquer dado estruturado com
campos e estruturas individuais sejam armazenados, sendo assim, podem ser armazenados
todos os dados sem uma definição prévia.
2.3.3 CLUSTERIZAÇÃO
De acordo com Alecrim (2013), Cluster é o nome dado a um sistema que
relaciona dois ou mais computadores para que estes trabalhem de maneira conjunta no intuito
de processar uma tarefa. Estas máquinas dividem entre si as atividades de processamento e
executam este trabalho de maneira simultânea.

17
Cada computador que faz parte do cluster recebe o nome de nó. Teoricamente,
não há limite máximo de nós, mas independentemente da quantidade de máquinas que o
compõe, o cluster deve ser "transparente", ou seja, deve ser visto pelo usuário ou por outro
sistema que necessite deste processamento como um único computador.
Assim, técnicas de clusterização procuram semelhanças e diferenças num
conjunto de dados e agrupam os registros semelhantes em clusters de uma forma automática,
de acordo com algum critério ou métrica. Não é necessário definir os grupos nem os atributos
que devem ser utilizados para segmentar o conjunto de dados.
2.3.4 Map-Reduce
Map-Reduce consiste no framework e modelo de programação introduzido pela
Google, inspirado nas funções map e reduce que trabalham a partir dessas duas fases. O
modelo Map-Reduce é uma abstração criada para oferecer aos implementadores uma interface
que seja poderosa e, ao mesmo tempo, simples, separando os problemas a serem resolvidos
dos problemas de paralelização, buscando uma uniformidade na abordagem dessas questões
de paralelismo.
Assim, o Map-Reduce utiliza conceitos da programação funcional para criar a
abstração em que o usuário deve programar duas funções, map e reduce, que servirão de
interface para uma implementação no sistema distribuído que poderá paralelizar a execução
dessas funções com balanço de carga, tolerância a falhas ou qualquer outra propriedade que o
implementador do sistema distribuído decidir que é importante.
As funções map e reduce funcionam da seguinte forma: map (chave, valor):
recebe um par de entrada de chave e valor e produz um conjunto intermediário de chaves e
valores. Reduce (chave, valores): recebe uma entrada chave e um conjunto de valores
relacionados àquela chave.
Assim, a implementação do Map-Reduce recebe um conjunto inicial de pares
chave e valor e invoca a função map para cada par. Depois, a implementação cria listas, onde
cada uma contém todos os valores intermediários (produzidos quando a função map é
invocada) que estão associados à mesma chave intermediária e chama a função reduce para
cada chave intermediária e a lista associada àquela chave intermediária.

18
O modelo Map-Reduce oferece apenas uma interface entre a implementação de
um sistema distribuído e o usuário desse sistema. Por isso, o sucesso do modelo depende de
uma construção satisfatória de um sistema distribuído que atenda às expectativas de oferecer
uma execução das funções map e reduce. Além disso, ainda devem ser adicionadas
propriedades e atividades como protocolos de comunicação entre processos, tolerância a
falhas, sistemas de arquivos, entre outras.
Existem várias implementações diferentes para o modelo Map-Reduce. É na
implementação que devem ser resolvidas as questões relativas à paralelização, como a
exclusão mútua e a sincronização. Uma boa realização depende também do ambiente onde ela
será executada: máquinas muito velozes conectadas por uma rede muito lenta requerem uma
implementação diferente de um cluster de máquinas mais lentas conectadas por uma rede
muito veloz.
O modelo Map-Reduce traz, de forma simples, uma abordagem para lidar com
problemas de computação distribuída. Sua eficácia reside, justamente, no fato de ele ser capaz
de separar, de forma pouco complexa, as peculiaridades de cada problema das complicações
de operar um sistema distribuído. Por ser simples, o Map-Reduce é um modelo fácil de usar
por programadores que não têm experiência com sistemas distribuídos, já que a
implementação dele encapsula a paralelização.
2.4 TIPOS DE BANCO DE DADOS NOSQL
Há vários tipos de armazenamento NoSQL disponíveis. Nas sessões subseqüentes
serão explorados os principais tipos de armazenamento.
2.4.1 Banco de Dados no Esquema Chave/Valor (Key/Value)
Esse é o tipo de banco de dados NoSQL mais simples, o conceito dele é uma
chave e um valor para essa chave. É também conhecido como tabela de hash dos bancos
NoSql, este é o tipo que aguenta mais carga de dados e possui maior escalabilidade. Alguns
bancos que utilizam esse padrão são: DynamoDb, Couchbase, Riak, Azure Table Storage,
Redis, Tokyo Cabinet, Oracle Berkeley DB, Project Voldemort, MemcacheDB, SimpleBD,
LevelDB, HBase etc.

19
De acordo com Saladage e Fowler (2013), os bancos de dados no esquema
chave/valor são indicados para armazenamento de informações de sessão, perfis e
preferências de usuários, e dados de carrinhos de compras. E não são indicados quando
relacionamento entre diferentes tipos de dados são necessários, ou então à necessidade de
correlacionar os dados entre diferentes conjuntos de chave, também não são indicados em
transações com múltiplas operações, consulta por dados e operações por conjuntos.
2.4.2 Bancos de Dados Orientados a Documentos
Baseado em documentos XML ou JSON, que são coleções de atributos e valores,
onde um atributo pode ser multi-valorado. Em geral, os bancos de dados orientados a
documento não possuem esquema, ou seja, os documentos armazenados não precisam possuir
estrutura em comum. Essa característica faz deles boas opções para o armazenamento de
dados semi-estruturados. Alguns bancos que utilizam esse padrão são: MongoDb, CouchDB,
RavenDb, Riak, MarkLogic Server, BaseX, eXist etc.
Segundo Saladage e Fowler (2013), são apropriados para registros de eventos
(logs), sistemas de gerenciamento de conteúdo (CMS), plataformas de blog, análises web ou
em tempo real (analytics) e aplicativos de comércio eletrônico. Não são apropriados em
situações que exigem transações complexas que abranjam diferentes operações e consultas em
estruturas agregadas variáveis.
2.4.3 Bancos de Dados de Famílias de Colunas
Suportam várias linhas e colunas, além de permitir subcolunas. Por exemplo, caso
se queira guardar id, nome e endereço de usuários em um sistema de cadastro, os registros
seriam:Id1, Nome1, Endereço1; Id2, Nome2, Endereço2. Essa estrutura torna a escrita muito
rápida, pois todos os dados de um registro são colocados no disco com uma única escrita no
banco. Essa estrutura também é eficiente caso se queira ler registros inteiros. Mas, para
situações onde se quer ler algumas poucas colunas de muitos registros, essa estrutura é pouco
eficiente, pois muitos blocos do disco terão de ser lidos.

20
Para esses casos onde se quer otimizar a leitura de dados estruturados, bancos de
dados de famílias de colunas são mais interessantes, pois eles guardam os dados
contiguamente por coluna.
O exemplo anterior em um banco de dados dessa categoria ficaria: Id1, Id2;
Nome1, Nome2; Endereço1, Endereço2. Por esse exemplo é possível perceber a desvantagem
de um banco de dados de famílias de colunas: a escrita de um novo registro é bem mais
custosa do que em um banco de dados tradicional. Assim, num primeiro momento, os bancos
tradicionais são mais adequados a OLTP enquanto os bancos de dados de famílias de colunas
são mais interessantes para OLAP.
O Bigtable é uma implementação da Google dessa categoria de bancos de dados.
Outros bancos de dados que são orientados a coluna: Hadoop, Cassandra,
Hypertable, Amazon SimpleDB, HPBase etc.
O Cassandra faz uso de implementações de tabelas hash distribuídas, em que a
estrutura de índice leva em consideração a replicação e particionamento dos dados em várias
máquinas (nós), além da existência de diversos centros de dados (data centers).
Saladage e Fowler (2013) afirmam que sua utilização é apropriada em registro de
eventos (logs), sistemas de gerenciamento de conteúdo, plataformas de blogs, contadores, e
para funcionalidade que expiram durante o uso, por exemplo, exibir banners de propaganda
em um website durante um tempo específico utilizando colunas que expirem. Não são
recomendados para sistemas que requerem transações ACID para gravações e leituras.
2.4.4 Bancos de Dados de Grafos
Possuem uma complexidade maior, pois esses bancos de dados guardam objetos,
e não registros como os outros tipos de NoSQL. A busca desses itens é feita pela navegação
desses objetos. Diferentemente de outros tipos de bancos de dados NoSQL, esse está
diretamente relacionado a um modelo de dados estabelecido, o modelo de grafos. A ideia
desse modelo é representar os dados e/ou o esquema dos dados como grafos dirigidos, ou
como estruturas que generalizem a noção de grafos.
O modelo de grafos é mais interessante que outros quando informações sobre a
inter-conectividade ou a topologia dos dados são mais importantes, ou tão importantes quanto

21
os dados propriamente ditos. O modelo orientado a grafos possui três componentes básicos:
os nós (são os vértices do grafo), os relacionamentos (são as arestas) e as propriedades (ou
atributos) dos nós e relacionamentos.
Os nós são usados para modelar objetos que existem de forma independente das
ligações. Em geral, não possuem um esquema rígido. Assim, dois objetos representados por
nós de um mesmo grafo podem ter atributos bem distintos. As arestas são usadas para
materializar o relacionamento entre nós. As propriedades podem ser usadas tanto para
descrever atributos de nós quanto de arestas. Neste caso, o banco de dados pode ser visto
como um multigrafo rotulado e direcionado, onde cada par de nós pode ser conectado por
mais de uma aresta. Um exemplo pode ser: “Quais cidades foram visitadas anteriormente
(seja residindo ou viajando) por pessoas que viajaram para São Paulo?”
No modelo relacional esta consulta poderia ser muito complexa devido à
necessidade de múltiplas junções, o que poderia acarretar uma diminuição no desempenho da
aplicação. Porém, por meio dos relacionamentos inerentes aos grafos, estas consultas tornam-
se mais simples e diretas.
Este modelo de dados tem se tornado popular em aplicações web de domínio
social, fornecendo capacidades interessantes para a realização de consultas requeridas por este
tipo de aplicação e com um bom desempenho.
Alguns bancos que utilizam esse padrão são: Neo4J, OrientDB, Infinite Graph,
InfoGrid, HyperGraphDB, BigData, FlockDB, DEX etc.
Para Saladage e Fowler (2013), sua utilização é recomendada em sistemas que
exijam dados conectados, como redes sociais, roteamento e envio de serviços baseados em
localização e mecanismos de recomendação. Não utilizá-los quando o requisito for atualizar
todas as entidades ou um subconjunto delas, como por exemplo, em um aplicativo de análise
no qual todas as entidades precisem ser atualizadas com uma propriedade alterada.
2.5 GEOPROCESSAMENTO EM BANCOS DE DADOS NOSQL
Geoprocessamento é a área do conhecimento que busca o tratamento da informação
geográfica, possibilitando a interpretação dos dados coletados, o cruzamento de
diferentes informações, a previsão de cenários, o apoio à tomada de decisões.
(SCHWANKER, 2013, p.138)

22
Ao longo dos anos, temos estudado e registrado através de mapas ou cartas de
dados sobre o relevo, fauna, rotas comerciais, limites políticos etc. Entretanto, com o avanço
da informática, surgiu a possibilidade de se integrar vários dados e mapas e analisá-los em
conjunto, possibilitando, através de análises complexas e a criação de bancos de dados
georreferenciados, o desenvolvimento de diversas áreas como a cartografia, principalmente, o
planejamento urbano, comunicações, transportes e até a análise de recursos naturais.
Atualmente, grandes volumes de dados geoespaciais são criados, armazenados e
utilizados como nunca foram antes. Nesse cenário, gerenciadores de bancos de dados não
relacionais podem ser, por suas características (capacidade de manipular grandes quantidades
de dados sem a necessidade de definição de um esquema e ainda com alto desempenho),
soluções mais eficientes para as aplicações que utilizam dados geoespaciais de grande
volume.
Algumas soluções NoSQL incluem suporte para dados geoespaciais tanto
nativamente quanto como uma extensão. Outros não foram desenhados para aplicações
geoespaciais, mas estão sendo implementados para suportar dados espaciais. Alguns bancos
de dados NoSQL que atualmente estão sendo utilizados para gerenciar dados espaciais são:
MongoDB (open source), BigTable (desenvolvido pelo Google, usado no Google Earth),
Cassandra (desenvolvido pelo Facebook, que agora é open source e mantido pelo Apache),
CouchDB (open source, Apache).
A seguir, algumas aplicações que utilizam o NoSQL para tarefas geoespaciais:
Foursquare: MongoDB
SimpleGeo: Cassandra
Where: MongoDB
Scrabbly: MongoDB
Google Earth: Google Big Table
PDX API (API para a cidade de Portland, iniciativa de dados abertos do Oregon):
CouchDB (GeoCouch)

23
2.6 EXEMPLOS REAIS DE UTILIZAÇÃO
Serão exemplificadas, a seguir, três empresas consumidoras de cada um dos
bancos de dados populares atualmente, MongoDB e Neo4j. De acordo com consulta realizada
nos sites dos respectivos fabricantes, na data de 18/05/2015, será apresentada uma breve
descrição da aplicação, bem como seu desenvolvimento e utilização. Após as exemplificações
de cada um dos bancos de dados, será exibida uma figura contendo seus consumidores
oficiais.
2.6.1 MongoDB
2.6.1.1 The Weather Channel
Objetivo: Disponibilizar, em tempo real, alertas e informações metereológicas para
os usuários que utilizam aplicativos móveis personalizados.
Em 1982, o The Weather Channel começou uma rede de televisão 24x7 para
atender a demanda de divulgação da informação meteorológica. Vários anos mais tarde,
seguindo a evolução natural de acesso às informações online, desenvolveram o weather.com.
Mas, como o site foi construído utilizando um banco de dados relacional pesado, foi difícil
continuar utilizando a mesma tecnologia para o desenvolvimento de aplicativos móveis. A
equipe do Weather Channel precisou agir rapidamente, com aplicativos responsivos e um
sistema escalável.
Para uma base de usuários de 40 milhões, crescendo rapidamente em
smartphones, a marca Weather Channel precisou ir além de uma abordagem de banco de
dados relacional legado. Então, optou pelo MongoDB para enviar informações aos usuários
rapidamente. Atualizações que costumavam levar semanas podem, agora, ser apresentadas em
horas.
Eles substituíram altos custos e complexidade por escalabilidade simplificada e
velocidade. E agora que eles estão modernizados em uma infraestrutura de nuvem, estão
transmitindo notícias, estilos de vida e conteúdo metereológico das suas propriedades digitais
para o MongoDB.

24
Com uma grande quantidade de aplicações integradas ao MongoDB, os usuários
podem personalizar as suas experiências através de dispositivos móveis, tablets e no site. Eles
podem visualizar rapidamente radares de mapas e receber diversos alertas meteorológicos em
tempo real.
“Como nós trabalhamos com nossa base de usuários para descobrir características
críticas, ciclos de inovação rápidos com o MongoDB são um benefício real.” (LUKE KOLIN,
vice presidente de arquitetura do The Weather Channel, tradução minha).
De acordo com Kolin, os índices secundários e a rápida consulta do MongoDB o
tornam o único produto que pode executar de forma confiável este tipo de pesquisa sobre essa
grande base de usuários em meros segundos.
2.6.1.2 Expedia
Objetivo: Oferecer planejamento de viagem fácil, rápido e altamente
personalizado para milhões de clientes.
O mercado de viagens on-line é dinâmico e complexo. De um lado, os
fornecedores mudam constantemente, nos bastidores, o inventário e informações de preços.
Por outro lado, os consumidores estão interagindo com o site a partir de muitos dispositivos e
navegadores diferentes. Eles precisam escolher as datas, destinos, alinhar vôos, aluguéis de
carros e hotéis. Os preços variam, a disponibilidade altera constantemente, e eles estão
competindo com outros viajantes por um inventário limitado.
Isto cria um enorme volume de dados altamente variáveis. O diretor técnico da
engenharia Murari Gopalan disse: “Online travel is a hard nut to crack”, expressão que possui
o mesmo sentido de, "Viagem on-line é um osso duro de roer".
Um cliente típico irá procurar em diferentes locais antes de reservar seu vôo. Vai
do laptop para o telefone e vice-versa, essa pesquisa pode durar dias. A maioria das pessoas
esquece onde elas já olharam e acabam repetindo as mesmas pesquisas novamente. Alguns
recorrem até mesmo à caneta e papel para fazer anotações, mas continuam sem nenhuma
decisão.

25
Para atender melhor as expectativas de seus clientes, a Expedia decidiu oferecer
uma melhor forma de planejamento de viagem. Um recurso alimentado por MongoDB
chamado Scratchpad (bloco de notas).
O Scratchpad serve para automatizar o processo de tomada de notas, lembrar-se
de forma inteligente das pesquisas, procurar os preços mais baixos e tornar mais fácil fazer
compras em qualquer dispositivo. O cliente pode iniciar a busca em seu laptop e continuá-la
em seu smartphone a qualquer momento, e depois rever as opções em um tablet com o seu
parceiro mais tarde.
Enquanto os requisitos para o aplicativo Scratchpad já existiam há anos, a rigidez
das opções tradicionais dos RDBMS sufocou o seu desenvolvimento. No entanto, com o
MongoDB, a Expedia foi capaz de desenvolve-lo muito mais rápido do que o esperado.
Uma equipe de apenas três desenvolvedores construiu o primeiro protótipo para o
Scratchpad em menos de dois meses, e lançou-o para produção apenas dois meses depois.
“Sem o MongoDB, seria necessário uma equipe muito maior para lançar o
aplicativo tão rapidamente.” (PRASHANTH KOKATI, engenheiro de software sênior da
Expedia, tradução minha).
Com um banco de dados relacional, seria lento e difícil normalizar todos os dados
do cliente, da sessão e de produtos através de um processo de ETL, colocá-lo em um data
warehouse e executar somente consultas prescritas. Esta não era uma opção para Scratchpad.
O armazenamento de documentos flexível do MongoDB e a simples escala
horizontal tornaram possível para a Expedia criar uma ferramenta que dá a cada usuário uma
relevante experiência de compra. Que, em tempo real, coleta informações de clientes
dinamicamente e apresenta ofertas personalizadas. E ainda realiza tudo isso em grande escala.
O modelo de dados flexível do MongoDB tornou mais fácil armazenar qualquer
combinação de pares de cidades, datas e destinos. A Expedia pode continuar comprando para
alguém até mesmo depois de fechada a sessão. Quando o cliente regressa, todos os últimos
preços e disponibilidade para suas buscas são exibidos lado a lado no seu Scratchpad.

26
Os ricos índices do MongoDB são utilizados para poderosas análises que fazem
sugestões personalizadas para usuários enquanto eles fazem compras. A Expedia também
pode analisar os padrões para identificar tendências que oferecem uma melhor compreensão
do que os clientes estão procurando.
O esquema é alterado radicalmente em tempo real – sem efeitos colaterais, os
casos de uso se modificam. A visão evolui. Sem a flexibilidade do banco de dados, a inovação
encontra um obstáculo. Depois de colocar o "Scratchpad" em produção e vendo as
dificuldades e o feedback do cliente, a equipe da Expedia alterou radicalmente a estrutura do
esquema três vezes. Em um negócio que está sempre em rápido movimento, isso não é uma
tarefa fácil - pelo menos para a maioria dos bancos de dados.
Normalmente, a Expedia teria que colocar no ar uma página com o temido "em
manutenção". No entanto, o MongoDB permitiu que a Expedia alterasse radicalmente seus
esquemas durante a execução em produção, com impacto zero sobre a experiência do cliente.
2.6.1.3 Forbes
Objetivo: Entregar um CMS (Sistema de Gerenciamento de Conteúdo)
personalizado em 2 meses, e um novo site móvel em 1 mês.
A Forbes é a principal fonte de notícias de negócios desde 1917, produzindo
sempre conteúdo de qualidade. O que lhes faltava era velocidade. Eles não poderiam manter o
ritmo acelerado do jornalismo com os antigos sistemas fechados. Interrupções eram comuns.
Alterações na arquitetura, difíceis e caras. Era hora de refazer tudo completamente.
A Forbes decidiu fazer uma jogada ousada, reformular toda a sua plataforma e
reconstruir o seu sistema de gerenciamento de conteúdo (CMS) utilizando o MongoDB.
Após esta modificação, o sistema é incrivelmente rápido, aberto a colaboradores a
nível global e fácil de ser modificado sem sair do ar. Tudo na mesma fração de tempo e custo
da antiga abordagem.
A Forbes construiu um CMS personalizado utilizando o MongoDB em apenas
dois meses. Em seguida, eles lançaram um novo site móvel em menos de um mês.

27
Com apenas um engenheiro trabalhando em tempo integral e outro trabalhando
meio período, o time de desenvolvimento de aplicativos móveis era minúsculo. Mas os
resultados foram enormes. Durante a noite o tráfego móvel da Forbes.com saltou de 5% para
um total de 15%, e rapidamente aumentou para 50%.
“Em dois meses, engenheiros que nunca trabalharam com o MongoDB foram
capazes de fazer um produto inovador… qualquer coisa que precisássemos fazer com o
MongoDB, nós apenas extendíamos o esquema.” (STEVEN BOND, diretor da equipe de
desenvolvimento de software da Forbes.com, tradução minha).
Figura 2 – Empresas Consumidoras do MongoDB
Fonte: Elaborada pela autora a partir de informações disponíveis no site oficial do MongoDB,
na sessão de Consumidores.

28
2.6.2 Neo4j
2.6.2.1 InfoJobs
Objetivo: Desenvolver o Portal de Plano de Carreira para identificar os passos e
experiências que os seus candidatos a emprego vivenciaram em suas vidas profissionais, para
que outras pessoas possam usá-los como referência em seu próprio crescimento de carreira.
O InfoJobs é o maior e mais popular site de busca de empregos da Europa que
permite que os funcionários busquem por postagens de empregos, e empregadores postem
novas oportunidades em uma mesma plataforma. Ele conecta funcionários às companhias
através de um portal online e permite que as pessoas que buscam emprego armazenem suas
informações de carreira e encontrem novas oportunidades.
Marc Pou, gerente de produtos do InfoJobs, começou a pesquisar sobre as bases
de dados de grafos quando se tornou difícil modelar e explorar facilmente seus dados. Com 8
milhões de currículos, cada documento continha a experiência profissional específica de cada
candidato.
Além de produzir informações úteis para ajudar os usuários a tomarem decisões
sobre o seu próximo passo na carreira, com base em usuários semelhantes com as mesmas
experiências, o Portal de Plano de Carreira fornece informações abrangentes, como “qual a
probabilidade de eu conseguir esse cargo com base na minha situação atual?”.
Este gerenciamento do Portal necessitava de quantidades enormes de informações,
incluindo 4 milhões de candidatos, resultando em 26098726 nós, 12 milhões de experiências
de trabalho resultando em 171882297 propriedades e 18 milhões de habilidades com 23 tipos
de relacionamentos.
A fim de otimizar o sistema para entregar os resultados interativamente, o
InfoJobs combinou o Neo4j com cache de memória para armazenar os resultados dos
algoritmos, baseados nas métricas de cada mês.
Sem o Neo4j, estes algorítmos teriam exigido uma quantidade excessiva de pré-
cálculos, complexidade e custo.

29
O Neo4j é usado como base de dados para armazenar toda a informação estática e
as informações são atualizadas uma vez por mês. Com base nos relacionamentos e nós, o
sistema é capaz de realizar consultas baseadas nos grafos.
Através da implantação do Neo4j, o InfoJobs descrobriu o valor dos seus dados
através da visibilidade das conexões implícitas e economia de tempo e dinheiro para o projeto.
2.6.2.2 Walmart
Objetivo: Oferecer recomendações, em tempo real, otimizadas e personalizadas.
O Walmart é uma empresa familiar que em pouco mais de 50 anos se tornou a
maior empresa pública do mundo, com mais de 2 milhões de funcionários e rendimentos
anuais de 470 bilhões de dólares. O Walmart se tornou o maior varejista do mundo por
entender as necessidades de seus clientes.
O Walmart lida com quase 250 milhões de clientes semanais através de suas
11.000 lojas em 27 países e através dos seus sites de varejo em 10 países. O Grupo
eCommerce brasileiro do Walmart escolheu o Neo4j para ajudá-lo a entender o
comportamento e as preferências dos compradores on-line com bastante velocidade e em
profundidade suficiente para que isso fosse feito em tempo real, recomendações
personalizadas 'você também pode gostar de', uma forma comprovada para maximizar a
receita.
Como explica o Desenvolvedor de Software do Walmart, Marcos Wada: "O Neo4j
nos ajuda a entender o comportamento dos nossos compradores on-line e as relações entre os
nossos clientes e produtos, proporcionando uma ferramenta perfeita para recomendações de
produtos em tempo real."
Se esforçando para fornecer a melhor experiência web para seus clientes, o
Walmart resolveu otimizar suas recomendações on-line. Nos dias de hoje, os compradores
esperam recomendações altamente afinadas e personalizadas e não reagem tão bem a
quaisquer sugestões. Mas, para conseguir isso, são necessários produtos que podem conectar
massas de dados complexas de compradores e produtos. O Walmart reconheceu o desafio que
enfrentaria se utilizasse a tecnologia de banco de dados relacional tradicional para concretizar
este objetivo.

30
Como Marcos explicou: "Um banco de dados relacional não estava satisfazendo
nossas necessidades sobre o desempenho e simplicidade, devido à complexidade das nossas
consultas." Para resolver isso, a equipe de Marcos decidiu usar banco de dados de grafos, o
Neo4j.
Por padrão, os bancos de dados de grafos podem rapidamente consultar as
compras anteriores dos clientes, bem como capturar instantaneamente quaisquer novos
interesses mostrados na visita online atual dos mesmos – características essenciais para fazer
recomendações em tempo real. Combinar dessa forma dados de histórico e de sessão é trivial
para bancos de dados de grafos como o Neo4j, permitindo facilmente superar os produtos de
dados relacionais e outros "NoSQL" para este objetivo.
O Walmart está agora utilizando o Neo4j para sentir o comportamento dos
compradores on-line, a fim de otimizar e cruzar a venda das principais linhas de produtos nos
principais mercados. Ele implantou o Neo4j em suas aplicações de mercado, executadas pela
equipe de eCommerce de TI da empresa com sede no Brasil.
O Walmart tem usado o Neo4j em produção desde o início de 2013 e este ano
migrou para a versão 2.0. Marcos explicou os benefícios:
"Com o Neo4j nós podemos substituir um processo em lote complexo que
usávamos para preparar o nosso banco de dados relacional por um banco de dados gráfico
simples e em tempo real. Nós pudemos construir um sistema de recomendação simples e em
tempo real com consultas de baixa latência." Ele concluiu: "Sendo o atual líder de mercado
em bases de dados do gráfico, e com características empresariais para escalabilidade e
disponibilidade, o Neo4j foi a escolha certa para atender às nossas demandas."
2.6.2.3 Ebay
Objetivo: Oferecer às pessoas a entrega mais rápida possível de e-commerce de
compras.
O eBay foi criado em 2009, de brinquedos a chinelos, laços ou iPhones, o eBay
está fazendo entrega de encomendas on-line e através de dispositivos móveis rápida e
convenientemente oferecendo a opção de ter o item entregue no mesmo dia. O "eBay Now"

31
serviço de entrega local, está atualmente disponível em quatro mercados norte-americanos,
com planos de expansão para 25 grandes cidades nos EUA e Reino Unido até o final de 2014.
Alcançamos desempenho na consulta utilizando o Neo4j para criar um grafo que é o seu
próprio índice. Isso representa uma flexibilidade de desenvolvimento impressionante. A
implementação foi concluída dentro do prazo de apenas um ano. As consultas são agora
mais fáceis e rápidas. O resultado é uma plataforma escalável que suporta expansão de
negócios, que inclui o crescimento que ele está vivenciando agora com uma plataforma
rodando por trás do "eBay Now". VOLKER PACHER, 2014
O eBay Now coordena entregas entre lojas, transportadores e compradores 24
horas por dias 7 dias por semana. Despachando a partir do ponto-de-venda, o serviço lida com
logística de coleta e entrega com base na preferência do cliente, geralmente dentro de duas
horas, ou dentro de um quadro de hora especifica agendada pelo cliente. O novo serviço do
eBay aumenta o serviço ao cliente e a produtividade entre os parceiros de varejo e entrega.
Todos ganham - clientes possuem opções de entrega, os entregadores não esperam, e os
varejistas são capazes de fornecer um serviço adicional aos seus clientes on-line.
Volker Pacher, desenvolvedor sênior do eBay, faz parte da equipe do núcleo da
plataforma de serviços que oferece uma API para os transportadores e comerciantes. Quando
o crescimento exponencial diminuiu os tempos de resposta da API, a equipe trabalhou para
renovar a inicial plataforma. Ele sabia que um banco de dados de grafos poderia simplificar a
modelagem de domínio de uma forma que não afetaria a estrutura existente. Usando o Neo4j
e uma estrutura de grafo sem esquema, eles criaram um banco de dados que permite que as
consultas permaneçam localizadas dentro do grafo, melhorando o desempenho com facilidade
expressiva.
O serviço de entrega no mesmo dia cresceu exponencialmente, com cobertura
expandindo para 85% do Reino Unido. Sua plataforma de serviço precisou de uma
reformulação para suportar o crescimento explosivo de dados e novas funcionalidades. As
junções MySQL utilizadas criaram uma base de código muito lenta e complexa de manter. As
consultas usadas para escolher a melhor transportadora simplesmente tomavam muito tempo e
eles precisavam de uma solução para manter um serviço competitivo.
Pacher e a equipe de desenvolvimento acreditavam que um banco de dados
gráfico poderia ser adicionado à estrutura de SOA e aos serviços existentes, para resolver os
desafios de desempenho e escalabilidade. A equipe escolheu, então, o Neo4j como a melhor
solução.

32
O Neo4j foi selecionado pela sua flexibilidade, velocidade e facilidade de
utilização. E pelo seu modelo de propriedade gráfica harmonizado com o domínio que está
sendo modelado. A natureza de esquema flexível do banco de dados permitiu uma fácil
extensibilidade, e aceleração de desenvolvimento. E ele superou as limitações de velocidade e
escalabilidade da solução anterior. Diz Volker, "Nossa solução Neo4j é, literalmente, milhares
de vezes mais rápida do que a solução MySQL anterior, com consultas que exigem 10-100
vezes menos código. Ao mesmo tempo, o Neo4j permitiu-nos adicionar funcionalidades que
anteriormente não eram possíveis".
Cypher permitiu que consultas fossem expressadas de uma forma muito compacta
e intuitiva, acelerando o desenvolvimento. A equipe foi capaz de tirar vantagem do código
existente, usando uma biblioteca Ruby para Neo4j que também suporta Cypher.
A nova plataforma usando o jRuby, Sinatra, MongoDB e Neo4j fornece
transações rápidas com desempenho relativamente constante, com um modelo de dados que
permite que as consultas permaneçam localizadas às suas respectivas porções do grafo.
Figura 3 – Empresas Consumidoras do Neo4J

33
Fonte: Elaborada pela autora a partir de informações disponíveis no site oficial do Neo4J, na
sessão de Consumidores.

34
3 MATERIAIS E MÉTODOS
Nesta sessão será apresentado como o NoSQL funciona na prática. Este
desenvolvimento foi baseado na prática do curso online oficial, MongoDB para
Desenvolvedores Java, ministrado pela Universidade MongoDB. Para esta demonstração, foi
desenvolvido um pequeno servidor de Blogs, utilizando o MongoDB como banco de dados
principal de armazenamento, linguagem Java para desenvolvimento, Spark como servidor de
aplicação, Freemarker como framework de interface, Eclipse como ferramenta de
desenvolvimento e MongoChef como ferramenta de administração de dados.
Também foi criada uma simples área para estudo de caso. Esta área é
independente da prática oficial e foi desenvolvida apenas com a finalidade de avaliação prévia
de desempenho e complexidade diante da necessidade de futuras adições de consultas mais
complexas de postagens. Durante o desenvolvimento desta área foi adicionado à aplicação o
PostgreSQL, como banco de dados SQL, e utilizado o pgAdmin como ferramenta de
administração de dados. Tanto para o PostgreSQL quanto para o MongoDB, foram utilizadas
as APIs nativas para acesso ao banco através da aplicação, PostgreSQL JDBC Driver e Java
MongoDB Driver respectivamente.
Este projeto está disponível para download e visualização no GitHub, que pode
ser acessado através do seguinte endereço: https://github.com/CrisCoboQAT/nosql_blog. Os
scripts de inserção de dados também se encontram dentro do projeto. Os seguintes passos
foram realizados para o desenvolvimento desta aplicação:
- Download, instalação e configuração do MongoDB, bem como do driver, das
ferramentas, e frameworks a serem utilizados (Java MongoDB Driver, Eclipse, MongoChef
,Spark e Freemarker);
- Codificação da aplicação utilizando o MongoDB;
- Elaboração e inclusão dos scripts de inserção de dados de teste no MongoDB;
- Execução da aplicação;
- Download, instalação e configuração do PostgreSQL, pgAdmin e PostgreSQL
JDBC Driver;

35
- Elaboração e inclusão dos scripts de inserção de dados de teste no PostgreSQL;
- Desenvolvimento de página de análise comparativa entre o MongoDB e
PostgreSQL;
Nesta aplicação há uma página de cadastro de usuário, outra de login. Ao acessar
a aplicação, o usuário será redirecionado a uma tela de boas vindas onde terá acesso às
seguintes áreas:
- Visualizar Blog: As últimas dez postagens do usuário serão exibidas em ordem
decrescente, com a quantidade total de comentários exibidos em um link que, ao ser acessado,
exibe a postagem detalhadamente com todos os comentários e a opção “Curtir” em cada um
deles, acompanhado da quantidade de curtidas.
Figura 4 – Tela de visualização de postagens
Fonte: Elaborada pela autora.
- Criar Nova Postagem: Um formulário com título, conteúdo e tags será exibido
para que o usuário possa inserir novas postagens.

36
Figura 5 – Tela de criação de nova postagem
- Sair da aplicação
A seguir será exibida a tela utilizada para análise de desempenho, que compara
algumas consultas executadas utilizando o MongoDb e o Postgres, em que para obter os
tempos de execução foi adicionado um timer nos métodos para medir a duração de execução
das consultas. Os resultados serão abordados no capítulo seguinte.
Figura 6 – Tela de análise de desempenho

37

38
4 RESULTADOS E DISCUSSÃO
Na aplicação de Blogs, citada na sessão anterior, podemos também comparar e
observar as diferenças de desempenho entre NoSQL e SQL. Caso fossem necessárias
consultas mais complexas, os seguintes resultados seriam obtidos com as bases de dados
populadas com os mesmos registros (dez mil de postagens com 10 comentários e 3 tags cada):
Figura 7 – Resultados das consultas na aplicação de blogs
Consulta
Tempo de Execução
MongoDB
Tempo de Execução
PostgreSQL
Postagens ordenadas por
data de inserção:
0:02.277 0:9.210
Postagens que contem uma
determinada palavra
("postagem") em seu
conteúdo:
0:00.626 0:08.489
Postagens comentadas por
um determinado usuário
("autor comentario 1"):
0:00.783 0:09.391
Após análise da Figura 7, pode-se observar que o tempo de execução das
consultas utilizando o MongoDB é bastante inferior ao tempo obtido utilizando o
PostgreSQL. Com base nesses resultados, conclui-se que o desempenho das consultas
adicionais seria bastante otimizado com a utilização do MongoDB neste contexto.
A seguir, será exibido o esquema de dados, caso fosse utilizado o modelo
relacional para desenvolvimento desta aplicação.

39
Figura 8 – Modelo relacional da aplicação de blogs
Fonte: Elaborada pela autora a partir de informações disponíveis no curso oficial do
MongoDB.
Como pode ser observado, no modelo relacional acima, seria necessária a criação
de seis tabelas para armazenamento e ligação dos dados. No MongoDB, não são utilizadas
tabelas, mas sim, coleções. Para armazenamento das informações do Blog, no lugar de seis
tabelas, seriam necessárias apenas duas coleções: uma para armazenamento de postagens e
outra para armazenamento de usuários.
Um dos recursos mais importantes do MongoDb é a possibilidade de embutir
coleções dentro de coleções, sendo assim, como as tags e os comentários estarão relacionados
a uma postagem específica, eles podem ser embutidos diretamente dentro das postagens.
Utilizando o NoSQL, não existe um esquema normalizado, mas será exibido abaixo uma
exemplificação de como poderia ser realizado o armazenamento dos dados no MongoDB:

40
Figura 9 – Exemplo de representação de dados da aplicação de blogs no MongoDB
Fonte: Elaborada pela autora a partir de informações disponíveis no curso oficial do
MongoDB.
Além dos ganhos em desempenho, identifica-se também a facilidade de
implementação e, consequentemente, manutenção da aplicação utilizando o MongoDB.
Como no MongoDB foram usadas apenas duas coleções, o número de junções foi
bastante reduzido. Portanto, para a maioria das consultas, apenas a coleção de postagens
deverá ser acessada. Com isso, a quantidade de linhas de codificação necessária é bem
inferior à que seria necessária utilizando o modelo relacional. Consequentemente, a lógica se
tornou mais simples e fácil manter o código. Por exemplo, para retornar as postagens com
nome do autor, tags e comentários em ordem decrescente de inserção utilizando o modelo de
dados relacional (PostgreSQL), seria necessária uma codificação similar à seguinte:

41
1- Recuperar os dados da tabela de postagens fazendo junção com a tabela de
usuários para recuperar também o nome do autor:
SELECT post_id, titulo, conteudo, data, nome, email
FROM postagens p
INNER JOIN usuarios u ON (p.user_id = u.user_id)
ORDER BY data DESC
2- Percorrer o resultado da consulta anterior, fazendo junção com a tabela
relacional post_coments, utilizando o id das postagens para recuperar os dados dos
comentários de cada postagem na tabela de comentários:
SELECT c.coment_id, nome, comentario, data, email
FROM comentarios c
INNER JOIN post_coments pc
ON (post_id = " + postId + " AND c.coment_id = pc.coment_id)
3- Percorrer o resultado da consulta na tabela de postagens, fazendo junção com a
tabela relacional post_tags, utilizando o id das postagens para recuperar os dados das tags de
cada postagem na tabela de tags:
SELECT t.tag_id, nome
FROM tags t
INNER JOIN post_tags pt
ON (post_id = " + postId + " AND t.tag_id = pt.tag_id)
Já utilizando o modelo não relacional (MongoDB), apenas a linha abaixo seria
necessária:
db.postagens.find().sort({"date" : -1});
De acordo com os resultados acima, as características dos bancos de dados não
relacionais descritas neste trabalho e com os casos reais de utilização apresentados, pode-se
identificar que o uso do NoSQL é recomendado para sistemas que não necessitem do controle
de transações ACID efetuado pelo banco, assim como para aplicações com alto número de
acesso e com volume crescente de dados. No entanto, esta afirmação não pode ser
generalizada, cada caso deve ser avaliado criteriosamente antes de decidir qual seria a melhor
tecnologia a ser utilizada.
Mccreary e Kelly (2014), fazem a seguinte analogia, tradução minha:

42
Comprar um carro não é uma tarefa fácil. A pessoa quer um carro que não seja
muito caro, tenha uma grande aceleração, possa acomodar quatro pessoas (mais bagagem de
camping) e receba grande quilometragem. Então, ela percebe que nenhum carro possui tudo
isso e cada carro possui coisas que ela gosta e que não gosta. É obrigação dela, descobrir
quais as características que ela realmente quer e como pesar cada recurso para ajudá-la a
tomar a decisão final. Para encontrar o melhor carro, é importante entender primeiro quais
recursos são mais importantes para a sua necessidade. Uma vez que ela sabe disso, pode
priorizar as necessidades, verificar as especificações do carro e encontrar algum que se adapta
aos seus principais objetivos.
Selecionar a correta arquitetura de banco de dados para determinado problema de
negócio é semelhante à compra de um carro. Deve-se primeiro entender os requisitos e, em
seguida, classificar como cada requisito é importante para o projeto. Em seguida, olhar para as
opções de bancos de dados disponíveis e medir como cada um de seus requisitos funcionará
em cada opção de banco. Uma vez em que é sabido como cada banco de dados funciona, é
possível computar os resultados e pesar os critérios mais importantes com conformidade a um
determinado banco.
Por isso, faz-se necessário que os profissionais de TI possuam conhecimento tanto
dos requisitos do sistema a ser desenvolvido, quanto dos conceitos e tecnologias disponíveis
no mercado, e inclusive, possuam a visão de onde aquela aplicação poderá chegar
futuramente, de quanto ela será mantida e modificada, da quantidade de acessos que ela
possuirá, da necessidade de gerenciamento de transações etc.
Não existe um banco de dados melhor que outro, um framework melhor que
outro, uma linguagem melhor que outra. Enfim, uma tecnologia melhor que outra. Existe a
tecnologia que se adapta melhor às necessidades de cada aplicação.
De acordo com o que foi descrito neste trabalho e na quantidade crescente de
empresas que estão adotando os bancos de dados NoSQL como ferramenta principal ou
complementar dos seus aplicativos, é essencial que os profissionais de TI (desenvolvedores,
engenheiros, arquitetos, analistas, administradores de bancos de dados, professores, entre
outros) tenham conhecimento dos bancos de dados NoSQL, tanto quanto dos bancos de dados
relacionais, para que possam decidir qual a melhor tecnologia a ser utilizada em cada caso,
bem como ser capaz de desenvolver, analisar, manter, atualizar e ensinar sobre os diversos
tipos de sistemas de informação.

43
Nas últimas décadas, o desenvolvimento tecnológico tem sido rápido e
progressivo. Logo, é importante que os profissionais de TI estejam atualizados quanto às
exigências de mercado e recrutamento das empresas. Segundo busca realizada na data de
15/07/2015, na sessão de empregos de TI dos sites divulgadores de vagas e especializados em
recrutamento de profissionais, LinkedIn, InfoJobs e Ceviu, diversas vagas exigiam
conhecimento do conceito de NoSQL ou experiência em, pelo menos, um de seus bancos de
dados. A grande maioria citava esse conhecimento como um diferencial.
Portanto, é de suma importância que o profissional de TI da atualidade,
principalmente os profissionais especializados em banco de dados, possuam conhecimento do
NoSQL e estejam familiarizados com os cenários em que o mesmo possa ser utilizado bem
como a melhor ferramenta de mercado para cada caso.

44
5 CONCLUSÃO
Durante o desenvolvimento deste trabalho foi apresentado que os bancos NoSLQ
se caracterizam principalmente pela capacidade de escalabilidade horizontal, trabalhando bem
em ambientes clusterizados, e também por serem schemaless e utilizarem o map-reduce. Foi
também desenvolvida uma pequena aplicação de Blogs como exemplo de utilização e
executadas algumas consultas comparando o desempenho entre o MongoDB e PostgreSQL.
De acordo com esta apresentação pode-se concluir que as estruturas NoSQL se
aplicam quando grandes volumes de dados devem ser manipulados, para obter desempenho ao
gravá-los nessa quantidade e acessá-los com rapidez, ou quando os dados envolvidos não
podem seguir um esquema claro ou não possuem uma estrutura bem definida.
Por exemplo, suponha um site de buscas como o Google, que cataloga e armazena
informações sobre bilhões de páginas na web em servidores localizados em diversos lugares
do planeta, e, quando alguém faz uma pesquisa, retorna essas informações em questão de
milésimos de segundos e em ordem de relevância para o usuário. Agora, pode-se notar
claramente o ponto chave da questão: essa eficiência seria viável num mundo feito de tabelas,
num paradigma onde os dados se encontram separados e normalizados? Para retornar esses
resultados seriam executadas dezenas de junções.
Visivelmente, a melhor saída é uma desnormalização dos dados, e mais, a
utilização de uma estrutura de persistência de dados que se adapte melhor ao problema
proposto, que torne a sua resolução mais apropriada ao cenário. O que existe não é “a melhor
tecnologia”, mas sim, a tecnologia que melhor se adequa a um determinado cenário.
Por isso é tão importante que os profissionais de TI obtenham conhecimento sobre
os bancos de dados não relacionais para saberem qual tecnologia seria melhor aplicada em
cada caso.

45
REFERÊNCIAS
ALECRIM, Emerson. (2013). Cluster: conceito e características. Disponível em:
<http://www.infowester.com/cluster.php>. Acessado em: 07/02/2015.
ELSMARI, Ramez; NAVATHE Shamkant B.. Sistemas de Bancos de Dados. 4ª Edição. São
Paulo: Pearson Education do Brasil Ltda, 2005. 690p.
FOWLER, Martin. Schemaless Data Structures. Chicago, 2013. Disponível em:
<http://martinfowler.com/articles/schemaless/>. Acesso em: 08/03/2015
GONDIM, Gustavo Simões Pinto. Laboratório NoSQL (Parte 1): Conceitos de NoSQL.
São Paulo, 2013. Disponível em: <http://www.buildando.com.br/p/equipe.html>. Acesso em:
02/06/2014.
MCCREARY, Dan; KELLY Ann. Making Sense of NoSQL. First Edition. Shelter Island:
Manning PublicationsCo, 2014. 286p.
MONGODB. Who uses MongoDB. Disponível em: <https://www.mongodb.com/who-uses-
mongodb/>. Acessado em 18/05/2015.
MONGODB University. MongoDB Online Courses. Disponível em:
<https://university.mongodb.com/>. Acessado em 23/09/2014.
NEO4J. Neo4J Customers. Disponível em: <https://http://neo4j.com/customers//>. Acessado
em 18/05/2015.
SADALAGE, Pramod J.; FOWLER, Martin. NoSQL Essencial: Um Guia Conciso
para o Mundo Emergente da Persistência Poliglota. Primeira Edição. São Paulo: Novatec,
2013. 217p.
SCHWANKE, Cibele. Ambiente: Tecnologias: Série Tekne. Primeira Edição. Porto Alegre:
Bookman Editora, 2013. 143p.
VAISH, Gaurav. Getting Started with NoSQL. First Edition. Birmingham: Packt
Publishing, 2013. 123p.
VERAS, Manoel. Virtualização - Componente Central do Datacenter. . Primeira Edição.
Rio de Janeiro: Brasport Livros e Multimídia Ltda, 2011. 331p.

Cobo, Cristiane Brandão. Especialização Banco de Dados

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (11)

Destacado

Destacado (11)

Similar a Cobo, Cristiane Brandão. Especialização Banco de Dados

Similar a Cobo, Cristiane Brandão. Especialização Banco de Dados (20)

Cobo, Cristiane Brandão. Especialização Banco de Dados