Análise comparativa entre bancos de dados relacionais e NoSQL

1
O NoSQL e o Relacional: Uma Análise
Marcio Ballem de Souza, Fabio Aiub Sperotto
Especialização em Aplicações para Web – Universidade Federal do Rio Grande (FURG)
Santa Maria – RS – Brazil
{romarcio,fabio.aiub}@gmail.com
Abstract. From the 2000s a new scenario began to be displayed to web
applications with a large number of applications now available to many users
connected almost 24 hours per day. Social networks are a great example of
this scenario, users are connected the whole time and every time new
information is saved or retrieved. Thus, troubles to keep these applications
online have appeared as well as financial costs have increased. Relational
databases have been identified as one of the causes of these problems, and
thus one of the solutions was accept a new database's movement, the NoSQL.
Among them, MongoDB has already achieved a strong position and will be
object of study this TCC.
Resumo. A partir dos anos 2000 um novo cenário começou a ser apresentado
as aplicações web. Um grande número de aplicações passou a estar
disponível com muitos usuários conectados quase que 24 horas por dia. As
redes sociais são um grande exemplo deste cenário, usuários conectados a
todo o tempo e a cada instante novas informações são salvas ou consultadas.
Assim, os problemas para manter as aplicações on-line apareceram e os
custos financeiros aumentaram. Os bancos de dados relacionais foram
apontados como uma das causas destes problemas, e assim, uma das soluções
encontradas foi aderir a um novo movimento de banco de dados, os NoSQL.
Entre eles, o MongoDB vem se destacando e será objeto de estudo neste TCC.
1. Introdução
Os primeiros bancos de dados surgiram no inicio dos anos 1960 e as informações eram
armazenadas em fitas magnéticas. A ideia era criar um sistema de armazenamento de
dados que separasse os dados dos programas computacionais. Com o passar dos anos e
com o desenvolvimento de novos hardwares, os bancos de dados passaram a ter o
armazenamento das informações em discos rígidos [Juravich 2012].
Nos anos 1970, Edgar Codd propôs o conceito do modelo de dados relacionais, o
qual permitiria o uso de instruções da linguagem SQL para a consulta e escrita de dados
em tabelas. Entretanto, foi apenas a partir da metade dos anos 1980 que este conceito se
tornou amplamente aplicável devido as novas tecnologias de hardwares lançadas
naquela época. E nos anos 1990, os então chamados bancos de dados relacionais se
tornaram dominantes no cenário de armazenamento de informações, surgindo diversos
sistemas de gerenciamento de banco de dados relacionais como: Oracle, MySQL,
Microsoft SQL, PostgreSQL [Juravich 2012].

2
No final dos anos 1990, mais precisamente em 1998, surgiu um novo conceito
sobre banco de dados, que tinha como objetivo um modelo de banco de dados relacional
sem o uso da linguagem SQL. Carlo Strozzi, autor desta ideia, a nomeou como NoSQL
[Brito 2010].
A partir dos anos 2000, houve um grande aumento na quantidade de dados que
eram produzidos pelas aplicações, que também, se tornavam cada vez mais complexas.
As redes sociais chegaram, e o número de usuários conectados as aplicações aumentava
a cada dia, se fazendo necessário um alto investimento em hardwares. As empresas
passaram a ter a necessidade de conhecer mais profundamente os usuários que
utilizavam suas aplicações, assim, exigiam demais de seus sistemas atuais. Com este
novo cenário, sérias preocupações ligadas a estrutura de dados, escalabilidade e
disponibilidade de dados que o modelo relacional parecia não estar conseguindo lidar
precisavam ser resolvidas. Assim, se buscou uma nova forma de armazenamento de
dados, e o conceito NoSQL reapareceu como um ponto de partida [Juravich 2012].
Segundo Strozzi, o atual movimento NoSQL (Not Only SQL) não tem nada
haver com o seu modelo NoSQL (non-SQL), ele sugere até, que o nome do atual
movimento fosse NoREL, ou seja, não relacional. Isto porque, seu modelo é baseado em
bancos de dados relacionais que não usam o SQL como interface de interação com a
base de dados, já o modelo atual do NoSQL, além de não usar o SQL, também não faz
uso do modelo relacional de dados.
Os principais problemas encontrados nos modelos relacionais foram o grande
consumo de espaço em disco, a escalabilidade vertical, o conceito ACID e um modelo
de dados não dinâmico [Juravich 2012]. O modelo não relacional surge então com
diversas características que podem reduzir estes problemas como: menor consumo de
espaço em disco; escalabilidade horizontal, considerada melhor que a vertical; modelo
de dados dinâmicos; e o conceito BASE substituindo o conceito ACID [Araújo e Guizzo
2012].
Mas seguindo ou não o modelo proposto por Carlo Strozzi, os atuais bancos de
dados NoSQL aparecem como uma solução aos pontos considerados fracos entre os
modelos relacionais no atual cenário de aplicações para web.
Alguns trabalhos relacionados a comparações entre o modelo relacional de
banco de dados com os não relacionais (NoSQL) já foram publicados. É possível citar
Issa (2011) que descreve um estudo comparativo entre o modelo relacional e não
relacional com foco em aplicações de Business Intelligence. Em outra linha de pesquisa,
Fernandes (2013) cita as diferenças principais entre os conceitos ACID do modelo
relacional e o conceito BASE do modelo não relacional. Outro trabalho relevante é uma
analise comparativa entre a escalabilidade vertical, do modelo relacional e a
escalabilidade horizontal do modelo não relacional citadas por Brito (2010). Toth (2012)
segue a mesma linha de pesquisa de Brito (2010) e realiza um estudo comparativo e de
desempenho entre as escalabilidades do modelo relacional e não relacional.
Nesta pesquisa o estudo será direcionado em apresentar alguns dos problemas
referentes a web atual e como estes problemas, ligados aos bancos de dados relacionais,
estão sendo solucionados com a chegada dos bancos de dados não relacionais (NoSQL).

3
Uma abordagem sobre os conceitos gerais dos modelos relacionais e não relacionais de
banco de dados também será realizada para um entendimento mais amplo entre suas
características distintas. O banco de dados MongoDB será usado como foco principal
desta pesquisa. O qual se pretende apresentar os pontos fracos dos bancos relacionais
que foram supostamente suprimidos por este banco de dados NoSQL. O estudo vai
ainda citar três casos de usos do MongoDB em aplicações web que já estão em produção
e quais os resultados desta escolha para tais projetos.
O MongoDB, foi lançado em 2009 pela empresa Norte Americana 10gen, que
atualmente usa a marca MongoDB Inc. Este é um banco de dados orientado a
documentos, que em menos de 10 anos de existência, já alcançou a 4ª posição entre os
bancos de dados mais utilizados no mundo, ficando atrás apenas do Oracle, MySQL e
SQL Server. O que o torna o principal banco de dados não relacional.
2. Objetivos
2.1. Objetivo Geral
O objetivo deste estudo é apresentar uma pesquisa científica que cite alguns bancos de
dados não relacionais que estão sendo utilizados atualmente e como eles estão
solucionando os problemas enfrentados pelos bancos de dados relacionais.
2.2. Objetivos Específicos
O estudo vai focar em alguns pontos, considerados problemáticos dos bancos de dados
relacionais na atual realidade de aplicações web, e como o MongoDB focou em
soluções para tentar contornar tais problemas para melhorar a performance das
aplicações quando se trata de acesso a dados.
Desta forma, pretende-se que o estudo apresentado possa vir a ser utilizado
como um material de apoio na tomada de decisões de desenvolvedores, que têm
dificuldades em definir qual o modelo de banco de dados, relacional ou não relacional, é
mais apropriado para suas aplicações. Os seguintes objetivos são o foco principal deste
estudo:
 Apresentar os mais importantes bancos de dados não relacionais na
atualidade;
 Identificar os problemas enfrentados pelos bancos de dados relacionais
no atual momento da web;
 Identificar como o banco de dados MongoDB resolveu os mais
importantes problemas enfrentados pelos bancos de dados relacionais;
 Citar três casos reais nos quais o MongoDB foi a solução escolhida frente
a um banco de dados relacional e quais os resultados obtidos.
3. Bancos de Dados Relacionais
No início dos anos 1960 aparece pela primeira vez o termo Banco de Dados, que seria
uma camada simples para separar os dados ou registros dos sistemas computacionais. O
conceito era simples e motivou a possibilidade de tornar as aplicações mais robustas.

4
Naquela época os bancos de dados foram criados como dispositivos em fitas magnéticas
e em breve seriam substituídos por discos rígidos [Juravich 2012].
Nos anos 1970, Edgar Codd, propôs o conceito de modelo relacional de dados, o
qual tinha também o SQL como forma de acesso os registros armazenados em tabelas.
Embora o modelo relacional tenha sido amplamente aceito pela comunidade de
tecnologia da informação, os hardwares da época eram ainda limitados para que o
modelo fosse amplamente utilizado. Foi só a partir de meados dos anos 1980 que os
hardwares ofereceram suporte capaz para a utilização dos bancos de dados relacionais.
No início dos anos 1990 o modelo relacional se tornou então dominante na questão de
armazenamento de dados [Juravich 2012].
Surgiu também uma grande concorrência entre empresas que criaram os seus
próprios sistemas de armazenamento de dados, os chamados Sistemas de
Gerenciamento de Banco de Dados Relacionais (SGBDR). Alguns deles são
amplamente conhecidos como o Oracle, SQL Microsoft Server, PostgreSQL, MySQL,
IBM DBII, entre outros [Juravich 2012].
3.1. O Modelo Relacional
O modelo relacional de dados possui características muito importantes como a restrição
de integridade para garantir a consistência dos registros armazenados no banco de
dados. Esta restrição é realizada a partir do uso de chaves primárias (PK) e também de
chaves estrangeiras (FK) [Kokay 2012].
Outro ponto muito importante para o modelo relacional é o processo chamado
Normalização. A normalização possui uma sequência de passos que separa os tipos de
dados em tabelas especificas que os representem mais apropriadamente. Desta forma
são criados os relacionamentos entre tabelas, outra característica muito marcante do
modelo relacional. Com a normalização é possível garantir um armazenamento mais
consistente, reduzir a redundância e criar um eficiente acesso aos dados por meio dos
relacionamentos, evitando assim, problemas no processo de inserção, exclusão e
atualização dos dados [Kokay 2012].
O acesso aos dados é realizado por meio de SQL, uma linguagem padrão criada
pela IBM e inspirada em álgebra relacional. Embora os SGBDs adotem o SQL, como
linguagem padrão do modelo relacional, existem comandos que podem ser específicos
para cada marca de SGBD, fazendo com que instruções, como de consultas aos dados,
percam a portabilidade entre SGBDs distintos [Kokay 2012].
3.2 ACID
Uma característica que não pode ser deixada de lado, em se tratando de banco de dados
relacionais, é o modelo ACID. Este modelo é baseado em processos que verificam o
resultado de uma transação.
O conceito de transação remete a uma unidade lógica de trabalho que deve ser
bem sucedida, ou então, ter uma falha em sua totalidade. Cada transação vai envolver
uma ou mais operação de inserção (INSERT), atualização (UPDATE), ou exclusão
(DELETE). E no final, se houver sucesso, há uma mudança permanente no banco de

5
dados. Mas, em caso de falha, há um rollback para o estado anterior, do banco de dados,
a transação executada. Assim, o ACID tem como objetivo preservar a integridade de
uma transação e é dividido em quadro processos que são [Greenwald 2007]:
 Atomicidade – verifica se uma transação foi bem sucedida ou não. Em
caso negativo será realizado um rollback total da transação.
 Consistência – garante que depois de uma transação bem sucedida, os
dados afetados são mantidos em um estado consistente;
 Isolamento – cada transação deve ser executada de forma isolada, sem
afetar o estado de outras transações;
 Durabilidade – o resultado de uma transação é permanente, assim, há a
garantia do que foi salvo não será perdido.
4. Bancos de Dados Não Relacionais
Os bancos de dados não relacionais, ou simplesmente NoSQL, são modelos de
armazenamento que não utilizam o conceito relacional.
O termo NoSQL foi criado em 1998 por Carlo Strozzi, quando desenvolveu um
sistema de banco de dados relacional que não utilizava o SQL como linguagem de
acesso a dados. Por isso, foi chamado de NoSQL, que naquela ocasião significava “sem
SQL” (no SQL) [Strozzi].
A partir da segunda metade dos anos 2000, as aplicações web ser tornaram mais
robustas, o número de acesso a dados e quantidade de informações armazenadas,
aumentou drasticamente quase que diariamente. Assim, se notou que os bancos de dados
relacionais não estavam suportando este novo cenário e, em busca por soluções, se
reencontrou o NoSQL [Juravich 2012].
Porém, os bancos de dados NoSQL atuais não são os mesmos desenvolvidos por
Carlo Strozzi em 1998, embora levem o mesmo nome. Segundo Strozzi, o nome da
atual geração de bancos de dados NoSQL deveria ser NoREL, ou seja, “sem
relacionamento”. Isto porque, enquanto o NoSQL de Strozzi era baseado em um
conceito do modelo relacional sem o uso do SQL, o NoSQL atual é baseado em bancos
que não utilizam nem o SQL e nem o modelo relacional.
Sendo assim, a atual geração NoSQL passou a não significar “sem SQL” mas,
“não apenas SQL”. Então a sigla NoSQL, do idioma Inglês, seria uma abreviação para
Not Only SQL [Juravich 2012].
4.1 Classificação de Bancos de Dados NoSQL
Os bancos de dados relacionais, embora existam diversos modelos de SGBDs no
mercado, possuem um conceito padrão que é o Modelo Relacional e junto a ele, o uso
do SQL. Assim, se você conhece os conceitos gerais do Modelo Relacional e do SQL,
consegue trabalhar com qualquer SGBD disponível.
Já o NoSQL, não possui um modelo ou conceito padrão de representação, então,
foram criados diversos modelos de bancos de dados com características bem diferentes
no quesito de armazenamento de dados. Atualmente existem pelo menos quatro

6
classificações de banco de dados não relacionais que são: orientandos a chave-valor,
orientandos a colunas, orientandos a documentos e orientandos a grafos.
4.1.1 Orientados a Chave Valor
Os bancos de dados orientandos a chave-valor (Key-Value Store) são considerados o
modelo mais simples de armazenamento entre as classificações de NoSQL. Bem como
diz o nome, o armazenamento é realizado por meio de uma chave e de um valor. Seria
algo semelhante ao um objeto do tipo Map em linguagens de programação. O valor de
uma chave pode ser único ou mesmo um tipo de lista. Outra relação poderia ser feita
com um sistema de arquivos, onde o caminho para o arquivo seria a chave e o conteúdo
do arquivo seria o valor correspondente a chave. Esta classificação de banco de dados é
considerada de alto desempenho em diversos cenários, mas tem um ponto negativo, que
é a dificuldade em se implementar consultas e agregações mais complexas [Redmond
2012].Veja a seguir (Tabela 1) um breve exemplo de armazenamento do tipo chave e
valor:
Tabela 1. Armazenamento por chave-valor
Key Value
101 name: ‘Fulano de Tal’
102 {name: ‘Fulano’, surname: ‘de Tal’}
Este tipo de banco de dados é considerado útil para um limitado perfil de
aplicações, já que as consultas são realizadas por chaves. Entretanto, são indicados pelo
alto desempenho e escalabilidade [MongoDB Inc.]. Atualmente existem diversos
fabricantes de bancos de dados classificados como Key-Value Store. Veja a seguir uma
lista com alguns bancos de dados orientandos ao armazenamento por chave-valor e
algumas empresas que os utilizam:
 Amazon DynamoDB – IMDB, Elsevier, Formspring, ScribbleLive;
 Aerospike – adMarketplace, Inmobi, Appnexus, Adform;
 Voldemort – LinkedIn;
 Redis – GitHub, Pinterest, Flickr e Snapchat;
 Riak – Best Buy, bet365, Yahoo! Japan, Symantec, McAfee;
4.1.2 Orientados a Colunas
Bancos de dados orientados a colunas (Wide Columns Store ou Columnar) são
considerados mais complexos que os orientados a chave-valor. Esta classificação de
banco de dados usa um sistema de armazenamento por meio de tabelas e, os dados, são
agrupados por colunas, o que reduz o tempo de leitura e escrita em disco. A diferença
entre o modelo relacional e o modelo não relacional do tipo colunar é que o relacional
agrupa os dados por linhas em uma tabela, enquanto o colunar, como já citado,
armazena os dados por colunas [Redmond 2012].
Veja no exemplo a seguir (Tabela 2) a diferença entre os dois tipos de
armazenamento, colunar e relacional (linear):

7
Tabela 2. Diferença entre armazenamento linear e colunar
Relacional – Orientado a linhas Não Relacional – Orientado a colunas
Ana Souza 23
Porto
Alegre
Ana Mario José Luísa
Mario Rosa 60 São Paulo Souza Rosa Silva Ramos
José Silva 30
Rio de
Janeiro
23 60 30 29
Luísa Ramos 29 Salvador
Porto
Alegre
São
Paulo
Rio de
Janeiro
Salvador
Os bancos de dados colunares são considerados uteis para aplicações em que as
consultas são realizadas por um único valor de chave. Assim como os bancos
classificados por Chave-Valor, seus pontos fortes são o desempenho e a escalabilidade,
os quais podem ser altamente otimizados [MongoDB Inc.]. Os bancos de dados
orientados por colunas mais conhecidos no mercado atualmente são:
 Cassandra – EBay, Rackspace, Netflix;
 HBase – Facebook, Trend Micro, Yahoo!, Cloudera;
 Google BigTable – Google Search, Youtube, Gmail;
3.1.3 Orientados a Documentos
Os bancos de dados orientados a documentos (Document-Oriented) têm como
característica o armazenamento de dados via documentos do tipo XML ou JSON. Cada
documento vai conter todos os dados de uma determinada entidade. Este modelo de
armazenamento permite um alto nível de flexibilidade, não dependendo de um esquema
rígido ou de uma estrutura fixa [Redmond 2012]. Desta forma os documentos se tornam
dinâmicos, cada documento pode possuir diferentes campos de dados e o documento
terá um identificador único, similar a chave primária de um banco de dados relacional
[Brito 2010].
Veja a seguir um exemplo de armazenamento documental no formado JSON de
dados:
{
_id : 100,
name: ‘Fulano de Tal’,
age: 25,
city: ‘Rio de Janeiro’,
tags: [‘filmes’, ‘futebol’, ‘motos’]
}
Quadro 1. Armazenamento documental com JSON
Os bancos de dados classificados como documentais são normalmente indicados
para vários tipos de aplicações, isto porque, possuem uma flexibilidade no modelo de
dados, possibilidade de consulta baseada por qualquer campo e um mapeamento de
dados considerado natural para as modernas linguagens de programação [MongoDB

8
Inc.]. Os mais conhecidos bancos de dados orientados a documentos podem ser vistos
na listagem a seguir:
 MongoDB – Forbes, The New York Times, The Washington Post, eBay;
 CouchDB – BBC.
3.1.4 Orientados a Grafos
Um dos bancos de dados NoSQL menos popular talvez seja os orientados a grafos
(Graph). Este modele de armazenamento utiliza nós (nodes) que se relacionam com
outros nós. Os nós são formados por propriedades do tipo chave-valor para armazenar
os dados [Redmond 2012].
Este modelo de armazenamento é bem visto quando há a existência de consultas
muitas complexas. O uso de nós torna o acesso aos dados mais fácil, devido o sistema
de navegação que pode ser usado entre os nós. Como cada nó está ligado a um ou mais
nós, a partir de um único nó se teria condições de acessar todos os nós ligados a ele e
também aos nós ligados as suas conexões [Fernandes 2013].
Figura 1. Relacionamento entre Nodes [Robinson, 2013]
Os bancos de dados do tipo Grafos são normalmente indicados quando os
relacionamentos são partes fundamentais para a aplicação, como as redes sociais
[MongoDB Inc.]. Veja a seguir alguns dos mais importantes banco de dados NoSQL
orientados a grafos:
 Neo4j – InfoJobs, Walmart, National Geographic;
 AllegroGraph – Pfizer, Ford, Bank of America;
 VelocityDB – Paradigm Publishing Inc, Trust Circle, SMSB Systems.

9
4.2 BASE
Como as aplicações precisaram ter o acesso a uma maior quantidade de dados em um
menor tempo possível e os bancos de dados relacionais não estavam dando o suporte
necessário a isto, o NoSQL apresentou o conceito BASE, enquanto os bancos de dados
relacionais fazem uso do conceito ACID. O BASE parte do principio que enquanto uma
aplicação está disponível o tempo todo, a base de dados não precisaria ser consistente
todo o tempo, assim, seria consistente eventualmente, o que agiliza não somente o
desempenho das consultas, mas muitas vezes as operações de escritas [Fernandes 2013]:
 BA (Basically Available) – sigla que representa o conceito de
basicamente disponível. Tem relação direta com a disponibilidade de
dados;
 S (Soft State) – possuir estado leve, ou seja, o sistema não precisa estar
consistente o tempo todo;
 E (Eventually Consistent) – a consistência é eventual, ou seja, em um
momento indeterminado.
5. Relacionais x Não Relacionais
Com a popularização da web a partir dos anos 2000 aumentou bastante o número de
usuários e aplicativos web. As redes sociais impulsionaram este aumento, que veio
seguido por grandes portais de notícias e de entretenimento. E com este novo cenário,
problemas de infraestrutura e hardwares começaram a se tornar preocupantes.
Muito constantemente, se tornou necessário adicionar cada vez mais memória
RAM para que as máquinas suportassem o grande número de transações e conexões
simultâneas. Os bancos de dados precisavam cada vez mais de espaço físico em disco
para suportar a grande quantidade de informações sendo inseridas a todo instante. Os
servidores necessitavam ser cada vez mais potentes e de alto desempenho. E a
escalabilidade se fez necessária, mas era complicada e demandava alto custo e
disponibilidade técnica. Tudo isso, gerou um acréscimo no custo financeiro que parecia
não ter mais fim. Foi quando grandes nomes da tecnologia da informação, como
Google, Amazon, Facebook, entre outras, se reuniram para buscar uma solução a estes
problemas [Souza 2013].
Após muitos debates verificou-se que a solução poderia ser uma nova forma de
armazenamento dos dados, já que os bancos de dados relacionais passaram a ser alvo de
críticas dentro deste novo cenário. Assim, surge o NoSQL como solução e nomes como
Google, Facebook e Amazon participaram de projetos importantes que deram origem
aos bancos de dados não relacionais atuais. Enquanto o Google desenvolvia sua própria
solução NoSQL, o BigTable, apoiava a empresa 10gen no desenvolvimento do
MongoDB. O Facebook deu inicio ao Cassandra, que mais tarde foi cedido a Fundação
Apache. E a Amazon construíu o SimpleDB e o DynamoDB. Atualmente, grandes
empresas utilizam bancos de dados não relacionais como solução para diversas
aplicações [Souza 2013].
Durante as próximas seções serão abordados aspectos que diferenciam os bancos
de dados do modelo relacional dos bancos de dados não relacionais (NoSQL). Estes

10
aspectos são referentes as distintas arquiteturas destes sistemas que implicam em fatores
como escalabilidade, esquema de dados, conceitos de transação, consistência, entre
outros.
5.1 ACID x BASE
Um dos principais motivos do modelo relacional que acabou tido como culpado para
seu mau desempenho no novo cenário da web foi o conceito ACID. Como o ACID está
ligado diretamente a transações, algumas de suas propriedades foram vistas como parte
do atraso em operações de CRUD.
A primeira propriedade do modelo ACID é a Atomicidade, ou seja, se a
transação falhar, seja por erro na instrução SQL, ou no meio físico, nada será persistido
e a transação será encerrada. Caso contrário, a operação será efetuada (commit) e a
transação será fechada. No modelo não relacional (BASE), não existe o conceito de
transação, assim, ao se executar uma operação os dados serão persistidos no decorrer
desta operação, e não após um commit. Se houver uma falha, os dados serão perdidos,
sem a necessidade de esperar que uma transação seja concluída [Araujo 2012].
Após uma transação ser encerrada, entra em ação a propriedade de Consistência.
A consistência garante que a base de dados se manterá consistente, em caso de falha ou
não. Isto é, se ocorrer uma falha, nenhuma informação será inserida ou alterada no
estado da base de dados antes desta transação. Caso a transação ocorra com sucesso, a
consistência garante que a base de dados vai passar do estado anterior para um novo
estado. A consistência garante que todas as regras que envolvem os relacionamentos
(PKs, FKs e Constraints) sejam garantidas em relação a integridade dos dados. O
modelo NoSQL não possui o mesmo conceito de consistência que os relacionais,
embora exista a garantia de que os dados estarão consistentes. Este conceito de
consistência que os relacionais utilizam não se aplica aos não relacionais. Isto porque,
os não relacionais não possuem o conceito de relacionamentos, assim, não existem
chaves estrangeiras ou restrições (constraints), para manter consistente [Araujo 2012].
O ACID ainda possui a propriedade de Isolamento. O isolamento fornece
segurança durante a persistência de dados em modo concorrente. O que significa, que
duas transações ou mais, não podem alterar uma mesma informação na base de dados ao
mesmo tempo. É necessário que uma transação seja finalizada, para que a outra possa
então alterar aquela informação. No NoSQL não existe isolamento de transações, já que
não existe o conceito de transação. Assim, é possível alterar a mesma informação por
acessos diferentes e simultâneos, a informação resultante, será aquela referente ao
último acesso finalizado [Araujo 2012].
Por fim, temos a Durabilidade, a qual garante que após uma transação ser
concluída, haverá a escrita em disco e a tal informação vai estar disponível até que uma
operação de delete seja executada. O conceito de durabilidade existente no modelo
relacional, não está presente no modelo não relacional por alguns motivos. O primeiro é
que a durabilidade deveria agir após uma transação ser efetuada com sucesso. Outro
motivo é que a durabilidade garante os dados escritos em disco e a grande maioria dos
bancos de dados NoSQL não persistem diretamente os dados em disco e sim na
memória RAM. Por isso, o modelo BASE tem o conceito de Eventualmente

11
Consistente. Por alguns instantes, os dados na RAM estarão mais atualizados do que os
dados no disco rígido. E apenas após alguns instantes, conforme cada banco de dados
NoSQL, eles serão escritos em disco. Ou seja, o estado do banco é eventualmente
alterado e de forma gradativa [Araujo 2012].
O modelo BASE parte do principio que os dados devem estar sempre
disponíveis (Basically Available), por isso, não existe transação. Assim, todos tem
acesso a mesma informação em tempo simultâneo. Isto habilita o acesso aos dados de
uma forma mais rápida, já que não vai existir uma fila esperando que uma transação
termine para que outra tenha acesso aos dados [Araujo 2012]. Como os dados são
mantidos em memória RAM, o acesso a eles é mais rápido, o que capacita as consultas
retornarem os dados em nano segundos e não em milissegundos como os bancos
relacionais. Isto também agiliza a escrita em banco, já que as operações de insert,
update ou delete, serão realizadas nos dados em memória RAM, para depois o
gerenciador do banco de dados atualizá-las no disco rígido. Porém, esta atualização em
disco, já não faz mais parte da operação executada por uma aplicação. A ação de
CRUD, que vem da aplicação, trabalha diretamente com a memória RAM [Souza 2015].
5.2 Escalabilidade: Vertical x Horizontal
Os bancos de dados relacionais possuem um sistema de escalabilidade do tipo vertical
(scale up).
A escalabilidade vertical é útil quando os hardwares atuais não são suficientes
para as necessidades dos servidores de bancos de dados relacionais. Isto é, conforme o
aumento de informações em um banco de dados se faz necessário aumentar a
configuração física dos servidores. Os componentes desta configuração física seriam:
disco rígido, memória e processador. Embora pareça uma opção viável e que possa
solucionar os problemas enfrentados na falta de recursos físicos, em um dado momento
no futuro, se fará necessário novamente uma nova escalabilidade [Toth 2012]. Ou seja,
o escalonamento vertical tem como objetivo aumentar o ganho de processamento e a
capacidade de armazenamento dos servidores de banco de dados [Fernandes 2013].
Os bancos de dados não relacionais, possuem um sistema de escalabilidade do
tipo horizontal (scale out). Este tipo de escalabilidade, também poderia ser utilizado em
bancos de dados relacionais, mas mediante o modelo relacional de armazenamento de
dados e uma modelagem de esquema rígida e pré-definida, a escalabilidade horizontal
torna-se complexa, cara e demorada. O modelo horizontal de escalabilidade é realizado
por meio do aumento de máquinas, criando uma conexão entre elas, diferente do modelo
vertical em que o aumento são dos componentes físicos de um servidor de banco de
dados [Toth 2012].
Quando os bancos de dados NoSQL foram criados, um dos objetivos era
exatamente criar um sistema de escalabilidade de baixa complexidade, de menor custo e
claro, de desempenho superior ao vertical. Assim optaram pela escalabilidade horizontal
[Souza 2015].
O modelo horizontal, como já citado anteriormente, é expandido com o
acréscimo de novas máquinas servidoras de banco de dados. Como os bancos de dados

12
NoSQL não possuem esquemas rígidos ou pré-definidos, e sim, a ausência de esquema
ou flexíveis, o processo de escalonamento horizontal se torna mais simples e eficaz.
Outro ponto positivo é que os bancos de dados não relacionais têm um sistema de
replicação de dados nativo, que favorece o processo de escalabilidade horizontal,
provendo uma diminuição no tempo gasto ao acesso dos dados. A replicação é realizada
de duas maneiras, por Master-to-Master (mestre para mestre) ou Master-Slave (mestre
para escravo) [Fernandes 2013].
O escalonamento horizontal no NoSQL utiliza também um conceito chamado
Sharding, que basicamente, tem como objetivo distribuir o banco de dados em vários
servidores, particionando os dados durante a distribuição. Alguns fatores impedem que
esta abordagem possa ser realizada no escalonamento vertical. Como os bancos de
dados relacionais utilizam do conceito de normalização de dados, o processo de
sharding se caracteriza pelo uso da não normalização, para que os dados que são usados
em conjunto devem ser armazenados em conjunto. Outra característica do sharding é
que, como há a distribuição de dados, entre diversas máquinas, a quantidade de dados se
torna menor por máquina, minimizando o acesso a eles. E como o sharding trabalha
com conjunto de dados, parte da premissa que um menor conjunto de dados é mais fácil
de ser acessado, alterado e gerenciado. Resumindo, o escalonamento horizontal fornece
uma maior disponibilidade aos dados, a qual se torna otimizada em relação ao
escalonamento vertical e devido ao uso da replicação, se houver a queda (off-line) de
uma das máquinas, o sistema de replicação garante que os dados ainda estarão
disponíveis [Brito 2010].
5.3 Esquemas: Rígido x Flexível
O modelo relacional de banco de dados força o uso de um esquema rígido na
estruturação dos dados. As tabelas são divididas por linhas e colunas, em que cada linha
é um conjunto único de informações e cada informação ou dado está presente em uma
coluna. Assim, essa estrutura de dados é fixa para todas as linhas da tabela, ou seja, não
é possível ter uma linha com três colunas e outras linhas com mais ou menos colunas.
Pelo fato do relacional possuir um esquema rígido, existe um consumo excessivo
de espaço físico em disco devido as colunas que não possuem informações de suma
importância para as aplicações. Estas informações sem importância seriam colunas com
valores nulos ou vazios. Para uma aplicação, valores nulos e vazios não são importantes,
mas os SGBDs reservam um espaço em disco para cada tipo de dado, seja ele um
VARCHAR, INT, LONG, CHAR, BLOB, ou qualquer outro tipo. Este ato acaba
consumindo espaço em disco sem que este espaço seja realmente ocupado por um dado
importante para a aplicação [Souza 2015].
Suponha que em um formulário de cadastro de uma rede social, existam dez
campos obrigatórios e cinco campos não obrigatórios para preenchimento. Os campos
não obrigatórios são os que vão gerar valores nulos ou vazios nas tabelas. Estas tabelas
são denominadas como esparsas (Tabela 3). Se cada usuário que realiza o cadastro na
rede social, deixa uma média de pelo menos três campos sem preenchimento e a rede
social possui cinco milhões de usuários cadastros, seriam quinze milhões de campos
com valores nulos ou vazios ocupando espaço insignificante em disco. E se a aplicação

13
possuir não apenas uma tabela esparsa com uma média de três campos nulos e vazios,
mas cinco, dez ou mais tabelas? Haveria muito mais do que quinze milhões de campos
nulos ou vazios ocupando espaço no disco rígido sem que as informações deles sejam
significativas para a aplicação.
Tabela 3. Tabela com colunas esparsas
ID FIRST_NAME LAST_NAME AGE PHONE NICKNAME
101 Ana Maria De Souza 35 null Aninha
102 José Cassiano null 91914020 Zé
103 Pedro Luiz Marinho 29 null
104 Pietra Ramos null null Pi
105 Anete Da Silva 35 91998596 Neti
106 Júlio Cesar Da Fonseca null 99896520
107 Aline Barbosa da Costa 37 90985623 Ali
Este cenário foi um dos grandes responsáveis pela alta necessidade de
escalonamento vertical. As aplicações precisavam muito frequentemente de novos
discos rígidos e com a maior quantidade de discos rígidos o processo de acesso
precisava ser maior e no final das contas, processadores mais potentes eram necessários
e o custo da manutenção dos servidores se tornava cada vez mais caro [Souza 2015].
Para solucionar o problema de tabelas esparsas, os modelos de bancos de dados
NoSQL partiram do pressuposto que deveriam possuir esquemas flexíveis de dados. Ou
seja, não é necessário criar um esquema fixo, ele se adapta conforme a necessidade da
aplicação [Robinson, 2013]. Assim, se em um formulário de cadastro existir campos
não obrigatórios, estes campos não serão inseridos no banco de dados com valores nulo
ou vazio. Simplesmente não são inseridos. Não haverá uma estrutura que obriga que
este campo, e não seu valor esteja presente para cada entidade inserida na base de dados.
Então, seria o mesmo que em uma tabela tivéssemos a possibilidade de ter uma linha
com três colunas e outras com mais ou menos colunas. Deste modo, não haverá valores
nulos e vazios ocupando espaço físico em disco, ou seja, não haverá informações
insignificantes para a aplicação adicionar a base de dados. Finalmente, os custos em
investimentos de hardwares diminuem consideravelmente. E com a base de dados
menor, com menos conteúdo armazenado, o acesso aos dados é mais rápido.
6. O NoSQL MongoDB
Como foco principal desta pesquisa, o banco de dados MongoDB será analisado
conforme as necessidades da web atual citadas durante a seção 5. Relacionais x Não
Relacionais. Serão abordadas as formas como este banco de dados documental fornece
meios para resolver problemas como de escalabilidade, consumo de memória em disco,
flexibilidade de esquema e uma rápida disponibilidade ao acesso a dados.
6.1 Histórico
O MongoDB foi lançado oficialmente em 2009 pela empresa Norte Americana 10gen,
como um banco de dados de código aberto com base na licença AGPL v3.0. Além disso,

14
todos os drivers de conexão com o banco de dados e as diversas linguagens de
programação, são desenvolvidos pela equipe do MongoDB com a licença Apache 2.0.
Existe também uma versão do MongoDB com licença comercial, a qual dará direito a
suporte e consultoria. Alguns anos depois, a 10gen trocou o nome da empresa para
MongoDB Inc, na tentativa de criar uma relação mais próxima entre seu produto e a
marca da empresa.
Assim como todos os bancos de dados NoSQL, o MongoDB nasceu para
solucionar problemas que estavam cada vez mais difíceis de serem resolvidos pelos
atuais bancos de dados relacionais [Souza 2015]. É considerado um poderoso bando de
dados não relacional orientado a documentos por ser flexível, escalável e indicado para
os mais diversos tipos de aplicações. Este banco de dados combina a capacidade de
escalabilidade horizontal com demais características como ordenação de dados, índices
secundários, agregações, índices geográficos e consultas por qualquer tipo de campo
[Chodorow 2013].
O Mongo também fornece uma documentação muito completa como auxilio
para instalação e uso dos diversos recursos que são oferecidos. Informações sobre
licença e documentação podem ser encontradas no site oficial do MongoDB no
endereço: https://www.mongodb.org/.
Entre os anos de 2009 e 2015 o MongoDB já recebeu diversos prêmios na área
de tecnologia, entre eles: 10 Most Successful Open Source Projects of 2012; The
InfoWorld Best of Open Source Software awards (Bossies); NoSQL Job Trends; The
Computerworld Honors Program; Technology of the Year 2014; Innovation Awards
2015 [Souza 2015].
6.2 Documentos x Tabelas
Sempre que falamos sobre bancos de dados orientados a documentos, como o
MongoDB, é importante ressaltar que o conceito de tabelas, linhas e colunas não faz
parte deste modelo, assim como, o conceito de relacionamento entre tabelas. O
MongoDB substitui o uso de tabelas por um conceito chamado coleções. Cada coleção
terá de zero ou muitos documentos. O MongoDB usa o modelo de documentos JSON
para armazenamento de dados. Porém, internamente, após um registro ser inserido, o
documento JSON é salvo no banco de dados como um BSON, um documento JSON
serializado. Cada documento em uma coleção representa uma entidade no banco de
dados. Fazendo uma analogia entre um banco de dados relacional e o MongoDB
teríamos o seguinte (Tabela 4) [Souza 2015]:
Tabela 4. Diferenças entre os modelos Relacionais e o MongoDB
Relacionais MongoDB (Document-Oriented)
Banco de Dados  Banco de Dados
Tabelas  Coleções
Linhas  Documentos
Colunas  Chaves e Valores dos documentos

15
Relacionamentos  Documentos internos e/ou arrays
O conceito de banco de dados, entre o modelo relacional e o MongoDB é o
mesmo, conforme indicado na Tabela 4. Porém, uma base de dados MongoDB terá
coleções ao invés de tabelas, e cada coleção pode conter inúmeros documentos. Sempre
que uma operação de CRUD for realizada, a instrução deve conter qual coleção estará
sendo acessada. Veja um exemplo no Quadro 2, onde uma consulta é realizada na
coleção chamada users. O comando db é padrão, indica a instancia do banco de
dados, em seguida temos o nome da coleção de acesso e o método de consulta find(),
similar a instrução SQL: select * from [tabela].
> db.users.find();
Quadro 2. Acesso a uma coleção e seus documentos
Um documento contém todos os dados que constituem uma entidade, assim,
como as linhas no modelo relacional, cada documento deve possuir uma chave primária
única. Por padrão, o MongoDB gera automaticamente a chave primária, caso um valor
não seja adicionado ao documento que está sendo inserido na coleção. Um exemplo de
documento pode ser visto no Quadro 3:
{
‘_id’: 100,
‘firstName’: ‘Julio Cesar’,
‘lastName’: ‘dos Santos,
‘age’: 40,
‘tags’: [‘filmes’, ‘futebol’, ‘música’],
‘phones’: [
{‘type’ : ‘celular, ‘number’ : ‘9199-0860’},
{‘type’ : ‘comercial’, ‘number’ : ‘3225-5015’}
],
‘address’: {
‘city’ : ‘Santa Maria’,
‘state’ : ‘RS’,
‘street’ : ‘Rua Benjamin Constant, 909’
}
}
Quadro 3. Documento JSON - MongoDB
Analisando o Quadro 3, veja que um documento JSON, é formado por chaves
(keys) e valores (values). Um documento está para uma coleção como uma linha está
para uma tabela no modelo relacional. Mas linhas são divididas em colunas e cada
coluna armazena um determinado valor. Em um documento JSON, as colunas são
substituídas por chaves e o valor das colunas são os valores atribuídos às chaves.

16
Ainda no Quadro 3, note que a chave tags é constituída por um valor do tipo
array, a chave phones possui um array de subdocumentos e a chave address é
formada por único subdocumento. Estes três tipos de chaves excluem a necessidade do
uso de relacionamento entre documentos. Em tabelas relacionais, os relacionamentos
são criados para relacionar uma ou mais linhas de uma tabela com outra tabela, por meio
de chaves primárias e estrangeiras.
O MongoDB não trabalha com o conceito de relacionamento. Todas as
informações que pertencem a uma entidade são salvas no mesmo documento. Isto exime
a necessidade de se criar relacionamentos como no modelo relacional. Por exemplo, no
MongoDB, o modelo relacional de um relacionamento do tipo um-para-um é
representado por um subdocumento como a chave address do Quadro 3. Já a chave
tags representa o conceito de relacionamento muitos-para-muitos. E por fim, o
relacionamento um-para-muitos pode ser representando por um array de subdocumentos
como a chave phones.
Se o documento do Quadro 3 fosse representado por um modelo relacional, seria
necessário ter pelo menos cinco tabelas após o processo de normalização. As tabelas
seriam as seguintes: users, phones, adresses, tags e users_has_tags,
conforme Figura 2:
Figura 2. Documento JSON normalizado para o modelo relacional
Com o processo de normalização qualquer consulta que precise dos dados de
tabelas relacionadas com users vai precisar de junções (joins), o que acarreta em um
tempo maior de resposta do banco de dados. Por exemplo, se uma consulta precisa
retornar todos os usuários que possuem uma mesma tag, seria necessário realizar pelo
menos três junções como mostra o Quadro 4.
SELECT * FROM
USERS U, TAGS T, USERS_HAS_TAGS UT

17
WHERE
T.TAG = ‘Futebol’
AND
U.ID_USER = UT.USERS_ID_USER
AND
UT.TAGS_ID_TAG = T.ID_TAG
Quadro 4. SQL para consulta por coluna
Com o uso de junções as consultas acabam retornando os dados em um tempo
maior, e quanto maior a quantidade de dados armazenados, mais demorada poderá ser a
consulta. Assim como, uma maior quantidade de junções também poderá influenciar em
uma consulta mais demorada. A mesma consulta (Quadro 4) no MongoDB poderia ser
realizada conforme o Quadro 5.
> db.users.find({‘tags’ : ‘Futebol’});
Quadro 5. Consulta por chave no MongoDB
Analisando a consulta do Quadro 5, veja que basta adicionar ao método
find(), implementação já fornecida pelo banco de dados MongoDB, a chave que se
deseja localizar tais documentos e o valor correspondente a tal chave. Assim, o
MongoDB retorna todos os documentos que possuem Futebol como valor da chave
tags. Como não existe relacionamento no MongoDB e o documento possui todos os
dados referentes a uma entidade, basta uma única instrução para ter como retorno os
dados necessários. Algo bem diferente do que foi realizado no Quadro 4 para uma
consulta no modelo relacional, onde foi necessário aplicar varias linhas de código e
varias junções para obter o mesmo resultado.
6.3 A Regra é Desnormalizar
Enquanto em um banco de dados relacional a normalização é usada para separar os
dados em tabelas especificas e também evita a redundância de dados, no modelo
documental do MongoDB esta pratica deve ser evitada ao máximo. Um dos principais
benefícios de se trabalhar com documentos é a possibilidade de desnormalizar o
esquema de dados.
A desnormalização é o oposto da normalização, ou seja, a normalização separa
os dados em diversas tabelas e a desnormalização vai manter os dados em um mesmo
documento. A vantagem de se ter os dados em um mesmo documento é que com uma
única operação de consulta o retorno já trás todos os valores presentes no documento.
Assim, não é necessário realizar operações de junções como no modelo relacional
[Chodorow 2013].
Mas se a redundância é evitada a partir da normalização no modelo relacional, a
desnormalização acaba gerando redundância entre os documentos do MongoDB. Isto
pode parecer ruim, quando se pensa no modelo relacional, mas a redundância para o
modelo documental do MongoDB é altamente aceita e necessária. Um exemplo de

18
redundância evitada pelo modelo relacional é a tabela tags da Figura 2. A tabela tags
vai conter diversas linhas, mas nenhuma delas com o mesmo valor para a coluna tag.
Evitando assim, que exista redundância. Já em um documento MongoDB, a tabela
tags é substituída por um array chamado tags, como no Quadro 3. Este array é
especifico de um documento, outros documentos contidos na coleção, poderão ter o seu
próprio array tags com os mesmo valores, tendo assim, a redundância de dados entre
os documentos.
Como os bancos de dados NoSQL são principalmente focados em desempenho
de consultas, a desnormalização foi uma forma encontrada para tornar as consultas mais
rápidas que o modelo relacional. No MongoDB, como não existe o conceito de
relacionamento, não vai existir junções, assim, as consultas possuem um desempenho
considerado formidável [Chodorow 2013].
6.4 Referência x Relacionamento
O modelo relacional de bancos de dados possui como principal característica o uso de
relacionamento entre tabelas. Um das características dos relacionamentos é a capacidade
de uso do conceito de cascata (Cascade). A cascata é quando uma operação realizada
em uma tabela atinge outras tabelas por meio dos relacionamentos entre elas. Um
exemplo bem comum do uso de cascata é em operações de exclusões. Uma linha
excluída em uma tabela, que tenha relacionamento com linhas em outras tabelas, poderá
remover também todas as outras linhas.
No MongoDB não existe o conceito de relacionamento, mas existe um conceito
chamado referência. O conceito de referência não é o mesmo que o de relacionamento e
é muito importante que não se tenha duvidas quanto a isso. A referência é uma forma de
apontar para um documento da mesma coleção ou de outra coleção. Mas não existirá um
relacionamento entre estes documentos. A referência poderia ser uma analogia a um
ponteiro em uma estrutura de dados. Se o documento referenciado for removido não
haverá uma operação em cascata para remover a referência no documento que o está
referenciando. Assim, uma consulta ao documento que está referenciando, vai gerar uma
exceção no banco dados, porque a referência existe, mas o documento referenciado não
existe mais [Souza 2015].
Com o uso do processo de referência é possível realizar normalização em um
banco de dados MongoDB. Mas é necessário avaliar o quando esta normalização seria
útil para tal sistema [Chodorow 2013].
Em alguns casos pode ser haver a necessidade de se ter varias coleções em um
mesmo banco de dados MongoDB. Assim, o uso de referência poderá ser útil. Suponha
que em uma base de dados exista a coleção users e a coleção logins, conforme o
Quadro 6.
/** coleção logins **/
{
‘_id’ : 1,
‘username’ : ‘jonas@email.com’,
‘password’ : ‘95erv34r’,

19
‘profile’ : ‘user’
}
/** coleção users **/
{
‘_id’ : 210,
‘login’ : { “$ref” : “logins”, “$id” : 1 },
‘tags’ : [ “java”, “mongodb”]
}
Quadro 6. Usando referência entre coleções
Na coleção logins são armazenadas as informações de login de um usuário, e
na coleção users estão armazenados os dados deste usuário. No Quadro 6, há um
documento da coleção logins, sendo referenciado por um documento da coleção
users. A referência é realizada por meio do valor da chave login na coleção users.
As informações desta referência são adicionadas via operador $ref, que recebe como
valor o nome da coleção referenciada e do operador $id, que recebe como valor da
chave primaria do documento referenciado.
A operação de cascata, com não é algo nativo do MongoDB, poderia ser
realizada a partir de uma operação implementada na aplicação. Para que antes que o
documento referenciado seja removido, se faça uma alteração (update) no documento
que o está referenciando para então, excluir o campo com o valor da referência. Depois
desta operação se remove o documento referenciado com uma operação de delete.
6.5 Esquema Dinâmico
Uma das grandes diferenças entre o modelo relacional e o não relacional é o esquema de
dados. Em suma, o modelo relacional tem um esquema considerado rígido e o não
relacional possui o esquema flexível. Um esquema é considerado rígido quando não é
possível ter uma definição de dados para cada entidade. No modelo relacional, as tabelas
possuem um determinado número de colunas, assim, cada linha de uma tabela terá o
mesmo número de colunas, tendo ou não informações armazenadas [Chodorow 2013].
O MongoDB faz uso do esquema flexível, porque cada documento pode ter um
esquema diferente do outro. Ou seja, é perfeitamente possível ter um documento com as
chaves _id, firstName e lastName enquanto outro documento da mesma coleção
tem as chaves _id, firstName, age e tags.
A vantagem do esquema flexível é que se pode a todo o momento atualizar o
esquema conforme as necessidades da aplicação e também é claro, poupar espaço físico
em disco. O espaço físico é poupado porque se um campo não faz parte do documento,
ele não ocupa espaço. Mas no modelo relacional, um campo (coluna), teria um valor
nulo ocupando espaço em disco [Souza 2015].
No Quadro 7 é possível ver um exemplo de dois documentos em uma mesma
coleção, mas com campos diferentes armazenados.··.

20
/** coleção users **/
{
'_id' : 105,
'firstName' : 'Anete',
'lastName' : 'da Silva Melo',
'age' : 30,
'tags' : ['filmes', 'novelas', 'moda']
}
{
'_id' : 200,
'firstName' : 'Maria',
'lastName' : 'Pereira',
'age' : 43,
'tags' : ['novelas', 'culinária'],
'address' : {
'city' : 'Porto Alegre',
'state' : 'RS',
'street' : 'Rua João Batista, 72'
}
}
Quadro 7. Esquema Flexível
Observando o Quadro 7 se nota que o documento de com o identificador igual a
105 possui cinco campos. Já o documento de identificador igual a 200 possui seis
campos. Como o usuário de identificador igual a 105 não tem um endereço cadastrado,
este campo não precisa fazer parte do documento.
Além de o MongoDB ter um esquema flexível, este esquema é considerado
dinâmico. É assim denominado porque um documento pode ter seu esquema modificado
em tempo de execução. No Quadro 7 o documento de identificador igual 105, poderia
em uma operação de atualização (update) receber novos campos ou ter campos já
existentes excluídos. E isto, nada afetaria os demais documentos desta coleção. Já em
um banco de dados relacional a mudança de esquema de uma tabela afeta todas as linhas
já existentes em tal tabela. Sendo assim, as linhas que não teriam valores a receber,
estariam ocupando espaço em disco com uma informação irrelevante para aplicação,
que seria o valor null.
6.6 Armazenamento de Arquivos
Em se tratando de bancos de dados relacionais, uma pratica não muito indicada é o
armazenamento de arquivos, principalmente de grandes arquivos. Isto porque o

21
armazenamento de arquivos torna o banco de dados mais lento e a operação de backup
extremamente demorada tanto para exportar o backup quanto para restaurá-lo.
No MongoDB não existe restrições sobre o armazenamento de arquivos, pelo
contrário, quando construído, já se pensava no MongoDB para este fim. Um ponto a ser
observado apenas é que um documento possui um tamanho limite de 16MB. Então, se o
arquivo for maior que 16MB, será necessário usar a implementação GridFS [Chodorow
2013].
O GridFS é um mecanismo para o armazenamento de arquivos ou documentos
maiores que 16MB. É um recurso muito utilizado principalmente para mídias de vídeos.
Uma vantagem do GridFS, é que um arquivo é separado por partes, assim, um player de
vídeo poderia reproduzir uma parte específica do vídeo sem precisar ler toda a mídia
armazenada no banco de dados [Souza, 2015].
6.7 Dados Consistentes
A consistência de dados por muito tempo, devido ao modelo relacional, sempre foi
tratada como uma situação natural para os desenvolvedores. Afinal, o banco de dados é
o responsável por ela. Embora não pareça, uma base de dados não precisa ser
consistente durante 100% do tempo que a aplicação está disponível, embora para alguns
tipos de aplicações haja a exigência que exista consistência todo o tempo. Entre os
bancos de dados NoSQL, os orientados a documentos e também orientados a grafos,
podem ser consistentes durante todo o tempo que a aplicação está disponível. Já bancos
de dados orientados a chave-valor e colunas, possuem a chamada consistência eventual
[MongoDB Inc.].
O banco de dados MongoDB fornece as duas situações, consistência eventual e
consistência durante todo o tempo de disponibilidade da aplicação. Desta forma, é
possível escolher qual consistência se encaixa melhor as necessidades de cada aplicação.
O MongoDB tem a consistência não eventual como padrão, na qual todas as
operações de escrita e leitura são feitas a partir de uma cópia primária do banco de
dados [MongoDB Inc.].
A consistência eventual pode ser configurada para leitura a partir de uma cópia
secundária, que é atualizada a partir da cópia primária em uma fração de tempo
predefinida. Este cenário é usado apenas em aplicações de leitura, em situações que os
dados não são atualizados frequentemente, por exemplo, dados históricos ou sistemas de
logs [MongoDB Inc.].
A vantagem de um sistema que utiliza a consistência eventual para leitura de
dados é a liberação de recursos para a cópia primária que vai receber as operações de
escrita. Enquanto uma cópia do banco de dados é usada para escrita, a cópia secundária
fica destinada apenas a geração de relatórios. Grandes relatórios demandam muitas
vezes muito tempo para a entrega dos dados, e este tempo pode interferir no
desempenho do banco de dados, o que reflete na parte de escrita. Separando o banco de
dados em uma cópia consistente e outra não consistente, se consegue direcionar os
recursos para escrita ou leitura. No MongoDB, para o uso de cópias secundárias se
utiliza o recurso de replicação, ou Replica Set [Souza, 2015].

22
6.8 Replica Set
O conceito de replicação (Replica Set) é baseado em manter cópias idênticas dos dados
em múltiplos servidores. Isto é largamente recomendado em qualquer sistema em
produção. A replicação vai garantir que sua aplicação estará rodando e os dados estarão
seguros, mesmo que algum problema ocorra em algum dos servidores [Chodorow
2013].
Em suma, a replicação no MongoDB é um grupo de servidores divididos entre
um primário (master), e os secundários (slaves). Os servidores secundários serão sempre
uma cópia do primário. As cópias podem ser configuradas de forma que o tempo de
replicação seja instantâneo ou a partir de uma fração qualquer de tempo [Chodorow,
2013].
Cada conjunto de replicas do MongoDB deve possuir pelo menos três
servidores, um primário e dois secundários. Os secundários podem ter configurações
distintas de tempo para a replicação. Assim, é possível ter um servidor secundário com
uma cópia quase que simultânea do primário e outro servidor para backup que faz a
cópia a cada vinte e quatro horas. Neste cenário, a cópia secundária configurada com
tempo simultâneo de replicação, pode ser usada para a geração de relatórios. Não
implicando no servidor primário, que fica responsável apenas pelas ações de escritas.
Assim, diminui a concorrência de acesso entre escrita e leitura, já que cada operação
estará sendo realizada em um servidor diferente, melhorando o desempenho da
aplicação. Já a cópia secundária, configurada como backup garante que se for necessário
ter acesso aos dados antigos, sem alterações nas últimas vinte e quatro horas, eles
estarão disponíveis. Este recurso é útil quando ocorre um problema sério na base de
dados que vai necessitar que os dados sejam restaurados para uma fração de tempo
anterior a falha [Souza, 2015].
Figura 3. Sistema básico de Replica Set do MongoDB
O conjunto de replica set do MongoDB possui internamente um sistema de
eleição para eleger um novo primário quando o servidor, inicialmente, configurado
como primário ficar off-line, como por exemplo, por um problema na rede. Este sistema
de eleição vai eleger um dos secundários para se tornar o primário. É possível também,
definir uma prioridade para que se possa especificar qual secundário se deseja que se
torne o primário. Assim, não é preciso que o administrador de redes ou de banco de
dados faça essa troca, evitando então, que a aplicação fique indisponível para os clientes
por um determinado tempo. A troca do secundário para o primário é realizada pelo

23
MongoDB quase que ou simultaneamente quando o primário se torna indisponível
[Plugge 2010].
Para aplicações web, que demandam um número muito grande de acessos ao
banco de dados, a replicação pode ajudar a melhorar o desempenho tornando as
aplicações escaláveis. Se uma aplicação tem uma grande quantidade de dados, e estes
dados são particularmente voltados para leitura, é possível distribuir as consultas entre
vários servidores de banco de dados diferentes para aumentar o paralelismo,
aumentando o desempenho da aplicação. Outro ponto positivo é que se pode permitir a
hospedagem de uma aplicação em vários data-centers. Neste cenário, é garantido que se
tenha uma cópia dos dados em cada data-center, para que a aplicação tenha acesso aos
dados em alta velocidade. Um cliente pode então, estar conectado ao data-center mais
próximo a ele, minimizando a latência [Plugge 2010].
6.9 Sharding: A Escalabilidade Horizontal
A escalabilidade horizontal realizada pelo MongoDB é realizada através de uma técnica
nomeada como Sharding.
O Sharding é capaz de efetuar a divisão de dados entre diversas máquinas. Ou
seja, é o ato de particionar dados e colocar um subconjunto destes dados em cada
máquina. Isto torna possível armazenar uma maior quantidade de dados e manuseá-los
com mais carga sem que haja a necessidade de custo com máquinas maiores ou mais
poderosas, sendo necessária apenas, uma quantidade maior de máquinas, mas não tão
potentes. É importante frisar que Sharding e Replica Set não são técnicas com a mesma
finalidade, embora trabalhem em conjunto. A replicação é o ato de criar um espelho ou
uma imagem dos dados entre vários servidores. O sharding divide a totalidade dos
dados em subconjuntos e adiciona cada subconjunto em uma máquina distinta
[Chodorow 2013].
É possível montar um sistema de Sharding manualmente, com praticamente
qualquer banco de dados. Porém, o sarnindo manual é controlado pela aplicação, que
mantém várias conexões com diferentes servidores de banco de dados. E cada servidor
de banco de dados é completamente independente um do outro. Assim, a aplicação
gerencia o armazenamento dos dados entre cada um dos servidores, consultando o
servidor apropriado para então obter acesso aos dados. Este tipo de abordagem pode até
funcionar de maneira apropriada, mas é difícil manter, adicionar e até remover os
servidores (clusters) em face de qualquer mudança que venha a ocorrer na distribuição
dos dados [Chodorow 2013].

24
Figura 4. Sharding simples sem redundância [Plugge 2010]
O MongoDB possui o conceito de Sharding automático (Autosharding), o qual é
abstrato para a arquitetura da aplicação e simplifica a administração de uma sistema.
Quem gerencia os clusters é uma instancia do MongoDB, a qual a aplicação estará
conectada. Assim, a aplicação não tem contato e nem conhece nenhum dos clusters,
sendo de total responsabilidade do MongoDB a distribuição de escrita dos dados. E
também de como localizar os dados dentro dos subconjuntos distribuídos entre vários
clusters é de responsabilidade do MongoDB. Como ponto positivo, em relação ao
sharding manual, o sharding automático facilita manter, adicionar ou remover os
servidores em face de qualquer mudança que venha ser necessária [Chodorow 2013].
O MongoDB usa um mecanismo de proxy para suportar a técnica de sharding.
Conforme a Figura 4, um servidor inicializado por um processo chamado mongos,
trabalha como um controlador entre os vários servidores particionados (mongod). A
aplicação cliente conecta-se ao mongos e os comandos das operações de CRUD são
enviados ao mongos que então vai enviá-los ao respectivo mongod. O esquema de
sharding da Figura 4 é considerado simples porque possui uma única coleção de
servidores (mongod). Um conjunto de mongod precisa também de uma máquina de
configuração (mongod – config server) para armazenar as informações de cada
um dos clusters deste conjunto [Plugge 2010].

25
Figura 5. Sharding: modo redundante com uso de Replica Set [Plugge 2010]
Outra técnica possível é realizar uma configuração nomeada como redundante.
Está configuração é chamada de redundante porque usa conjuntos de Replica Set no
processo de sharding. Dentro deste processo há também um conjunto de replicas
especifico para o serviço mongos que gerencia o cluster. Esta arquitetura permite
distribuir corretamente os servidores físicos de forma que haja garantia de que o sistema
vai ser tolerante a falhas de um ou mais servidores no cluster [Plugge 2010].
6.10 In-Memory Performance
Um dos grandes motivos que tornaram o MongoDB um banco de dados tão diferenciado
na questão de consulta a dados é o processo denominado In-Memory.
Este processo usa extensivamente a memória RAM para dar mais velocidade às
operações de banco de dados. A leitura dos dados, a partir da memória RAM, é
realizada em nanossegundos, enquanto ler os dados no disco rígido é medida em
milissegundos. O acesso aos dados a partir da RAM é considerado até cem mil vezes
mais rápido do que a leitura a partir do disco rígido. O MongoDB utiliza o mapeamento
de arquivo de memória para acessar e manipular os dados. Os dados que não são
acessados frequentemente não precisam estar na RAM, mas os índices de acesso a estes
dados estão. Caso o volume de dados acessado frequentemente seja maior que a
capacidade da RAM é possível realizar o escalonamento horizontal através do
autosharding. As ações de escrita também são realizadas em RAM, antes de serem
persistidas em disco. Pode parecer uma técnica insegura, já que a RAM é um tipo de
memória volátil, mas o MongoDB garante que os dados não serão perdidos. Um
mecanismo interno vai escrevê-los em disco, instantes depois dos dados terem sido
adicionados a RAM. Assim, tanto o processo de escrita como leitura de dados são
realizados a partir da RAM, gerando um acesso muito mais veloz aos dados em

26
comparação com os bancos de dados relacionais que carregam os dados diretamente em
disco [MongoDB Inc.].
7. MongoDB e Aplicações em Modo Produção
Nesta seção serão abordados alguns estudos de caso sobre empresas que optaram por
utilizar o banco de dados MongoDB em suas aplicações, ao invés, do modelo relacional.
Durante esta abordagem, serão citados os motivos pelos quais tais empresas
tomaram a decisão de escolher o MongoDB e não os tradicionais bancos de dados
relacionais. Outro aspecto importante a ser levado em consideração são os resultados
alcançados por esta escolha, por exemplo, se foram positivos ou negativos.
7.1 O MongoDB na Globo.com
Uma das maiores empresas brasileiras no ramo de comunicação é o Grupo Globo, que
possui diferentes tipos de mídias como impressa (Jornal O Globo), rádio (Rádio Globo),
televisiva (Rede Globo) e também o portal web Globo.com [Wikipédia].
Segundo Amorim (2011), especialista de banco de dados no Globo.com, o
MongoDB foi escolhido como forma de armazenamento de dados de um novo módulo
que deveria ser incluído na maior aplicação dinâmica do portal. Esta aplicação é um
jogo de fantasia chamado CartlolaFC. A aplicação possuía até Junho de 2011 mais de 2
milhões de usuários cadastrados, 15 milhões de visitas registradas como pico dentro de
um único mês, 90 milhões de páginas visualizadas também dentro de um único mês e 30
mil sessões simultâneas no servidor.
7.1.1 O Cenário e Objetivos
O CartolaFC trabalha com o banco de dados MySQL, o qual, o Globo.com tem
como principal ferramenta de armazenamento de dados em suas diversas aplicações
distribuídas no portal. Como desafio, este novo módulo deveria ser uma aplicação
separada do CartoloFC, mas, que estaria rodando junto a ele, sendo acessada a partir de
suas páginas internas. Este módulo seria um mural de mensagens, com apenas 1 nível de
comentário para cada mensagem principal e deveria ser de alto desempenho e
disponibilidade. Era importante que o usuário permanecesse o maior tempo possível
conectado a aplicação e a aplicação deveria suportar o equivalente a 30 mil sessões
simultâneas no servidor. Além disso, o tempo de resposta para a requisição do usuário
teria que ser rápida, de modo que, o usuário não tivesse nenhum problema quanto ao
desempenho. Como o aumento de usuários se tornaria crescente com o passar do tempo,
era importante que a aplicação fosse escalável, de forma que não houvesse a necessidade
de reescrever a aplicação para alcançar este objetivo.

27
Figura 6. Mural de Mensagens do CartolaFC [Amorim 2011].
A princípio a ideia era manter o MySQL como banco de dados do módulo referente ao
mural, mas depois de alguns estudos e testes se tomou a decisão de usar o MongoDB.
Durantes testes performance, um dos fatores mais importantes para a decisão em utilizar
o MongoDB, ele se mostrou 2 vezes mais rápido que o MySQL [Amorim 2011].
Conforme Amorim (2011), a equipe do Globo.com também optou por usar o
MongoDB sem trabalhar com o modelo objeto relacional (ORM) entre a aplicação e o
banco de dados, já que os desenvolvedores tem como preferencia escrever suas próprias
consultas a dados e não utilizar aquelas escritas pelo ORM. As consultas se tornam mais
naturais com o uso do MongoDB, já que seu armazenamento é em forma de documentos
JSON. A não necessidade de esquema de dados também foi um ponto de bastante
consideração, o que poderia permitir que a base de dados sofresse mudanças de forma
flexível e dinâmica. O failover automático do MongoDB também foi considerado eficaz
para garantir que quando o módulo mural tivesse um servidor off-line outro
automaticamente assumiria seu lugar. Essa técnica está presente no sistema de Replica
Set do MongoDB.
7.1.2 Os Resultados
Segundo Amorim (2011), os resultados alcançados com a escolha do MongoDB em
substituição ao tradicional uso do MySQL entre as diversas aplicações do Globo.com
foram os seguintes:

28
Figura 7. Relatório de sessões simultâneas no Mural [Amorim 2011].
 Deploy realizado em Maio de 2011;
 Banco de dados rodando 24 horas por dia e 7 dias por semana;
 Nenhum incidente reportado deste a implantação (de 05/2011 a 07/2011);
 1 milhão de comentários publicados entre 05/2011 e 07/2011. A equipe de
desenvolvimento considera ainda um número baixo, já que a arquitetura foi
desenvolvida para trabalhar um número muito maior;
 32 mil sessões simultâneas alcançadas (Figura 7).
A equipe de desenvolvimento do módulo mural também obteve como
aprendizado alguns pontos importantes sobre o MongoDB:
 É preferível usar sub-documentos (embedded documents), ao invés de,
referenciar documentos;
 Minimizar o tamanho dos documentos também é uma boa medida para alto
desempenho. Inicialmente a coleção posts, que armazena os documentos do
mural, possuía um campo de armazenamento do stream da imagem do escudo do
time do usuário. Este campo foi substituído por um redirecionamento para a
URL do arquivo, o que minimizou o tamanho o documento e melhorou a
performance;
 Escolher corretamente os tipos de dados também é importante para uma melhor
performance. Inicialmente a data era armazenada como um campo do tipo
String, o qual foi posteriormente substituído por um campo do tipo Date.
Essa alteração melhorou a busca por resultados a partir de datas;
 Reduzir o working set, a coleção de dados de trabalho em memória. Como o
MongoDB faz uso extensivo da memória RAM, é importante saber exatamente o
que e quanto você quer ter disponível em memória.·.

29
7.2 O MongoDB na Ingresse
Segundo Kelly (2014), a Ingresse é uma empresa voltada à área de vendas de ingressos
para qualquer tipo de evento e está presente em todos os Estado do território brasileiro,
já que seu foco é a venda on-line e via aplicativos. A Ingresse além de vender ingressos
para um evento cadastrado no site, ela também promove por meio de mídias sociais os
eventos cadastrados.
Conforme Kelly (2014), a aplicação da Ingresse trabalha com uma grande
quantidade de informações sendo consultadas a todo o instante. Como é uma aplicação
que possui eventos cadastrados em todo o Brasil, o número de usuários acessando o
sistema é muito grande e cada usuário antes de realizar uma compra, pesquisa por
diversos eventos até decidir para qual evento ele vai adquirir um ingresso. Durante o
período de acesso ao sistema o usuário acaba realizando inúmeras consultas ao banco de
dados, buscando informações por critérios como eventos, datas, locais, valor de ingresso
e tudo isso precisa de uma rápida resposta e o retorno de uma quantidade grande de
informações.
Kelly (2014) relata que inicialmente a aplicação usava como armazenamento de
dados o modelo relacional e o aumento de informações era muito grande e constante e,
com o número de acessos simultâneos ocasionava a queda do servidor. A frequente
queda do servidor passou a gerar insatisfação por partes dos clientes e também dos
usuários. A equipe de desenvolvimento da Ingresse precisou então ir atrás de uma
solução para este problema. Assim, foram detectados alguns problemas na arquitetura
da aplicação como o aumento exponencial no volume de dados, uso extensivo de joins e
o acesso rápido a grandes volumes de dados não era alcançado.
Como solução nasceu a ideia de migrar a base de dados para o modelo não
relacional, e como banco de dados, foi escolhido o MongoDB. A escolha pelo
MongoDB foi por características como o formato de armazenamento de dados (JSON),
considerado mais fácil de trabalhar; rápida recuperação dos dados, o que não se
conseguia com o modelo relacional devido ao grande número de tabelas e
relacionamentos; diferentes recursos de consultas que não exigem joins nem transações,
tornando as consultas mais velozes; a estrutura de dados é mais simples de ser
manipulada e ser alterada sempre que necessário, por ser uma estrutura flexível e
dinâmica; todos os dados podem estar em um único documento, facilitando as consultas
[Kelly 2011].
Conforme Kelly (2011) a maior dificuldade em realizar a migração do modelo
relacional para o MongoDB foi mudar a forma de pensar em relação a estrutura de
dados. Existe um tendência no primeiro contato com o MongoDB transformar cada
tabela do modelo relacional em uma coleção. Isto é um problema que precisa ser
superado, já que é possível ter varias tabelas representadas por uma única coleção.
Então, depois de algum tempo de trabalho e estudo, a equipe chegou a um modelo de
dados partindo de uma única coleção.

30
Segundo Kelly (2014), outro fator importante foi o de como recuperar os dados,
ou seja, como criar as consultas de modo a obter as informações necessárias de forma
rápida. No inicio tentaram realizar as consultas via agregação, com o suporte do
Aggregation Framework nativo do MongoDB. Isto gerou um problema semelhante ao
encontrado com o modelo relacional, o alto consumo de memória levava a aplicação a
ficar off-line. Embora tenham notado que o Aggregation Framework se mostrou
excelente para consultas consideradas pontuais ou para relatórios de dados, mas para
consultas concorrentes e recorrentes demandava muito esforço para a aplicação
ocasionando a queda da aplicação. Assim, o foco passou a ser a busca por uma melhor
performance das consultas.
Normalmente uma consulta na aplicação da Ingresse é realizada por diversos
critérios simultâneos, por exemplo, um evento (música, teatro, futebol, ...) mais a data
do evento mais a cidade do evento, entre outros. Com o uso de agregação estas consultas
não se mostraram eficazes então a solução foi partir para consultas simples, aquelas que
não utilizam agregadores nem projeções. Para isto, foram definidos índices sobre
campos específicos e também a criação índices compostos. Uma consulta passou a ser
realizada dentro de um índice o que tornou a resposta por parte do banco muito mais
rápida. Outra solução que melhorou a performance das consultas foi criar o recurso de
indexes com Text Index, uma característica do MongoDB para consultas baseadas em
campos de strings. Este sistema localiza palavras ou frases de maneira mais eficiente,
substituindo em alguns casos a necessidade de uso de expressões regulares nas consultas
[Kelly 2014].
7.2.2 Os Resultados
Segundo Kelly (2014), após a equipe investir um bom tempo no estudo de como
trabalhar com o MongoDB de maneira apropriada, o sistema da Ingresse passou a obter
resultados muito significativos em relação aos alcançados anteriormente com o modelo
relacional. Estes resultados estão listados a seguir:
 Ganho relevante no desempenho, suportando 2000 usuários simultâneos por
minuto contra 100 usuários simultâneos por minuto com o modelo relacional.
Dados obtidos em testes em laboratório;
 As consultas são mais simples do que as via SQL;
 Encontraram uma agilidade muito maior trabalhando com o MongoDB;
 A flexibilidade do esquema de dados é excelente, muito mais fácil de ser
elaborado;
 A escalabilidade também se tornou muito mais simples com um ganho
significativo em performance. O número de máquinas necessárias foi reduzido e
as mesmas são consideras simples o que reduz o custo da operação.

31
7.3 O MongoDB no The Guardian
O The Guardian, fundado em 1821 em Manchester na Inglaterra, é um dos líderes
jornalísticos no Reino Unido. Quase dois séculos depois de sua fundação é também
considerado um dos pioneiros na adoção de novas tecnologias [MongoDB Inc.].
Foi o primeiro portal de noticias no Reino Unido – guardian.co.uk – a
ultrapassar a marca de 20 milhões acessos de usuários únicos por mês, ou seja, sem
levar em consideração quantas vezes o mesmo usuário volta ao site do The Guardian no
mesmo período. Já foi inclusive premiado quatro vezes com o WebbyAwards como
melhor site de jornal na web [MongoDB Inc.].
A partir de estudos internos, o The Guardian reuniu informações importantes sobre o
que os usuários gostariam ter no site do jornal, assim como, o quanto o envolvimento
dos usuários com o site era diretamente relacionado a receita gerada [MongoDB Inc.].
Nasceu assim, uma grande necessidade de melhorar o relacionamento do jornal
com os leitores. O The Guardian precisava de um sistema de identidade flexível e
extensível para rastrear e armazenar dados de seus usuários. Porém, seu sistema atual,
baseado no modelo de dados relacional, contendo uma arquitetura rígida, não seria
capaz de atender aos novos objetivos [MongoDB Inc.].
Segundo Wall (2011), o The Guardian lançou seu primeiro site em 1995 e
passou por algumas mudanças significativas até meados dos anos 2000. A partir de 2005
as tecnologias usadas eram baseadas em JavaEE, Spring Framework, Hibernate ORM,
banco de dados Oracle e templates CMS. Um dos problemas enfrentados, dentro desta
arquitetura de aplicação, para as novas ideias a serem implementadas, era o fato de que
cada mudança no site precisaria de uma atualização na base de dados. Isto geraria uma
inatividade dos jornalistas que não poderiam dar continuidade a suas tarefas durante a
atualização do sistema. O sistema tinha até então mais de 300 tabelas no banco de
dados, 10.000 linhas de configurações em arquivos XML do Hibernate ORM,
aproximadamente 1.000 objetos mapeados e 70.000 mil linhas de código fonte muito
atrelado ao banco de dados. Embora usassem o Hibernate como mapeamento objeto
relacional, o banco de dados influenciava diretamente na complexidade do sistema. Já
que um sistema com mais de 300 tabelas, vai gerar um grande número de classes de
domínio na aplicação e inúmeros joins que vão resultar em consultas muito complexas.
Wall (2011) relata que com o aumento de usuários no site do The Guardian e o
grande volume de dados, foi necessário também escalar o banco de dados, o que se
mostrou uma tarefa muito difícil de lidar. Mediante a essas questões, a partir de 2009 se
iniciou uma busca por novas tecnologias. Chegou-se então a conclusão que deveriam
buscar um banco de dados de esquema flexível, para isto, pesquisaram informações
sobre o CouchDB, Cassandra e MongoDB. A escolha pelo MongoDB foi baseada em
conceitos como:
 Uso de documentos no formato JSON, o The Guardian já vinha trabalhando com
APIs JSON e gostava do formato;

32
 Consultas são fáceis de serem elaboradas;
 Suporta consultas complexas se necessário;
 Esquema de dados é flexível e também dinâmico, o qual torna possível qualquer
mudança do esquema de um documento em tempo de execução;
 A mudança de esquema pode facilmente ser realizada via operação de update;
 É capaz de trabalhar bem com qualquer nível de escalabilidade;
 Foi considerado de mais fácil usabilidade e aprendizado em relação aos demais
NoSQL analisados.
Outro ponto importante para a escolha do MongoDB foi a questão de liberdade no
trabalho com Replica Set e também com a escalabilidade. Foram levadas em
consideração duas situações distintas. Em uma delas se poderia ter um conjunto de
replicas onde o servidor primário poderia ser usado para leitura e escrita, utilizando o
conceito de consistência total. Por outro lado, o primário poderia estar sendo usado
apenas para operações de escritas enquanto os secundários poderiam ser escalonados
para operações de leituras via consistência eventual. E ainda o conjunto de replicas seria
gerenciado pelo driver do MongoDB, assim, se o primário (master) ficasse fora de
serviço em algum momento, o próprio driver elege um novo primário entre os
secundários (slaves) sem a intervenção humana neste processo. Além disso, uma
máquina de escrita (master) também pode ser escalonada gradualmente conforme for
necessário.
Uma das mudanças mais impactantes no uso do MongoDB foram às classes de
domínio, que tiveram um número de redução extremo em relação ao modelo de dados
anterior. Como o MongoDB trabalha com coleções de documentos, foi mais simples
gerar as classes de domínio já que não existe a necessidade de mapear relacionamentos.
Em alguns casos uma classe pode vir a representar uma coleção inteira [Wall 2011].
7.3.1 Os Resultados
Os resultados obtidos pela equipe de desenvolvimento do The Guardian foram
considerados excelentes no uso do modelo não relacional. Nenhum dado estatístico
sobre diferenças de desempenho entre o relacional e o não relacional foi citado.
Entretendo, as considerações finais relatadas por Wall (2011) referentes ao contato com
o MongoDB estão listadas a seguir:
 Simples, flexível e com consultas e indexação similares aos relacionais;
 Grande desempenho para qualquer nível de escalabilidade;
 É de fácil aprendizado para a equipe de desenvolvimento;
 Possui suporte comercial do fabricante;
 Um dia poderá ser o banco de dados de todas as operações ligadas ao
guardian.co.uk;

33
 Sem transações e joins: os desenvolvedores devem estar atentos quanto a
isto;
 Produz uma redução significativa em linhas de código fonte e também na
complexidade.
Segundo Philip Wills, arquiteto de softwares na The Guardian, o MongoDB permitiu ao
The Guardian ficar à frente da concorrência no ambiente de mídia e fornece rápida
evolução. Eles podem agora oferecer recursos interativos para os usuários mais
rapidamente, o que se traduz em mais receita para o The Guardian [MongoDB Inc.].
8. Conclusão
Durante este estudo foram identificados alguns problemas enfrentados pela web na
atualidade. Os bancos de dados relacionais foram apontados como parte da causa destes
problemas que estão ligados principalmente a baixa performance das aplicações e
também ao aumento de custo para manter tais aplicações em funcionamento. Como
solução para resolvê-los grandes empresas de tecnologia como Google, Facebook e
Amazon investiram tempo e dinheiro em um novo conceito de banco de dados, o
NoSQL ou não relacionais.
Um estudo comparativo entre os modelos relacionais e não relacionais (NoSQL)
de banco de dados foi apresentado, ressaltando as principais características entre tais
modelos. Algumas destas características são as formas de armazenamento de dados, os
tipos de esquemas de dados, as diferenças entre escalabilidade vertical e horizontal,
como também, as diferenças entre os conceitos ACID do modelo relacional e BASE do
modelo não relacional.
Em especial, um banco de dados NoSQL foi escolhido como foco de estudo para
citações de como ele conseguiu solucionar os problemas apresentados pelos bancos de
dados relacionais na web atual. Este banco de dados é o MongoDB, um banco orientado
a documentos lançado em 2009 pela empresa Norte Americana, atualmente, nomeada
MongoDB Inc. Como característica principal o MongoDB é conhecido por sua grande
capacidade de trabalhar com uma enorme quantidade de dados, por possuir alta
disponibilidade e escalabilidade, além de ser considerado de fácil aprendizado.
Atualmente o MongoDB é considerado o quarto banco de dados mais utilizado no
mundo, segundo dados da db-engines.com.
Além de apresentar as características do MongoDB e como ele vem
solucionando problemas enfrentados pelo modelo relacional, dentro da web atual, foram
citados três estudos de casos reais. Estas citações abordaram empresas que trabalham
com aplicações que precisam lidar com um grande volume de dados e também um
grande número de acessos simultâneos e porque elas decidiram trocar o modelo
relacional pelo NoSQL MongoDB. Entre elas podemos citar o Globo.com que utiliza o
MongoDB em um dos módulos do fantasy game CartolaFC. A empresa Ingresse, que
tem como foco a venda de ingressos para eventos no território brasileiro, usava o banco
de dados MySQL e enfrentava sérios problemas de desempenho, os quais, a fizeram
trocar sua base de dados para o MongoDB. Por fim, o site do jornal Britânico The
Guardian, optou por utilizar em uma nova aplicação o MongoDB, o qual trouxe,

34
segundo Wall (2011), grandes benefícios tanto pelo lado de desempenho quanto pela
facilidade de criar e manipular o modelo de dados da aplicação.
Em suma, este trabalho de pesquisa teve como característica um estudo
ressaltando as diferenças entre os modelos relacionais de bancos de dados e o NoSQL.
Com destaque principal ao NoSQL MongoDB, este trabalho abordou pontos
importantes sobre como o MongoDB pode superar em performance e também baixar o
custo financeiro para aplicações web. Este banco de dados se mostra capaz de trabalhar
com uma enorme quantidade de dados, possui um sistema escalabilidade considerado
superior ao dos modelos relacionais, oferece um sistema de replicação de dados com
failover automático e principalmente seu esquema flexível e dinâmico é um grande
atrativo para aplicações que podem vir a sofrer mudanças constantes no esquema de
dados. Os depoimentos citados pelas três empresas dos estudos de casos apoiam o
MongoDB como uma solução real para aplicações que vem sofrendo com baixo
desempenho, principalmente em operações de consultas.
Referências
Juravich, T. (2012) “CouchDB and PHP Web Development”, Packt Publishing Ltd,
First Edition, 2012.
Brito. R. W. (2010) “Bancos de Dados NoSQL x SGBDs Relacionais: Análise
Comparativa”, Universidade de Fortaleza. Disponível em: http://tinyurl.com/o5ajnp7.
Data de acesso: 12/08/2015.
Strozzi, C. “NoSQL – A Relational Database Management System”, Disponível em:
http://tinyurl.com/7ohrr9t. Data de acesso: 12/08/2015.
Araújo, E. de C. e Guizzo, G. (2012) “JPA/Hibernate ou NoSQL, qual utilizar?” –
Revista Java Magazine, Edição 103.
Kokay, M. C. (2012) “Bancos de Dados NoSQL: Um novo paradigma”, Revista SQL
Magazine, Edição 102, 2012.
Greenwald, R., Stackowiak, R. and Stern, J. (2007) “Oracle Essentials – Oracle
Database 11g” O’Reilly Media Inc, Fourth Edition, 2007.
Redmond, E. and Wilson, J. R. (2012) “Seven Databases in Seven Weeks – A guide to
Modern Databases and NoSQL Movement”, Pragmatic Programmers, LLC; First
Edition, 2012.
MongoDB Inc. “Top 5 Considerations When Evaluating NoSQL Databases”, A
MongoDB White Paper. Disponível em: http://tinyurl.com/nz4f5yf. Data de acesso:
12/08/2015.
______ “MongoDB Architecture Guide”, A MongoDB White Paper. Disponível em:
http://tinyurl.com/pdfjspk. Data de acesso: 27/08/2015.
______ “The Guardian”. Disponível em: http://tinyurl.com/p22dk9z. Data de acesso:
11/11/2015.
Fernandes, A. de S. e Candido, P. (2013) “NoSQL – Teorema Base x Acid – Teorema
Cap”, Instituto Federal de Educação e Tecnologia, Campus Januária – MG.

35
Robinson, I., Webber, J. and Eifrem, E. (2013) “Graph Databases”, O’Reilly Media Inc,
First Edition, 2013.
Souza, M. B. (2015) “Desvendando o MongoDB: Do Mongo Shell ao Java Driver”,
Ciência Moderna Ltda., 1ª Edição, 2015.
______ (2013) “Apresentando a API Morphia”, Revista Java Magazine, Edição 109.
Toth, R. M. (2012) “Abordagem NoSQL – Uma Alternativa Real”, Universidade
Federal de São Carlos – Campus Sorocaba, Sorocaba – SP. Disponível em:
http://tinyurl.com/q5qsw5n. Date de acesso: 21/08/2015.
Issa, Felipe G. de S. (2011) “Estudo comparativo entre banco de dados relacionais e
bancos de dados NoSQL na utilização de aplicações de business intelligence”,
Faculdade de Tecnologia de São José dos Campos – SP. Disponível em:
http://tinyurl.com/nwf7vlo. Data de acesso: 27/10/2015.
Chodorow, K. (2013) “MongoDB – The Definitive Guide”, O’Reilly Media Inc, Second
Edition, 2013.
Plugge, E., Membrey, P. and Hawkins, T. (2010) “The Difinitive Guide To MongoDB –
The NoSQL Database for Cloud and Desktop Computing”, Apress, First Edition,
2010.
Wikipédia – “Grupo Globo”. Disponível em:
https://pt.wikipedia.org/wiki/Grupo_Globo. Data de acesso: 09/11/2015.
Amorim, Franklin (2011) “MongoDB @ Globo.com”, Conferência MongoDB São
Paulo 2011 – SP. Disponível em: http://tinyurl.com/b9a927j. Date de acesso:
09/11/2015.
Costa, Kelly (2014) “MongoDB na Ingresse.com”, The Developers Conference, TDC
2014 – SP. Disponível em: http://www.infoq.com/br/presentations/mongodb-no-
ingressecom. Date de acesso: 10/11/2015.
Wall, Mat (2011) “Why I Chose MongoDB for guardian.co.uk”, QCon London 2011.
Disponível em: http://www.infoq.com/presentations/Why-I-Chose-MongoDB-for-
Guardian. Date de acesso: 11/11/2015.

Análise comparativa entre bancos de dados relacionais e NoSQL

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Análise comparativa entre bancos de dados relacionais e NoSQL

Semelhante a Análise comparativa entre bancos de dados relacionais e NoSQL (20)

Análise comparativa entre bancos de dados relacionais e NoSQL