Uma analise crtica sobre o uso do NoSQL para

desenvolvimento de aplicaco es
Antonio Alves Lopes Filho1 , Adriana M. R. Nascimento1 ,
Elidiane Martins Freitas1 , Francisco Edvan Chaves1 ,
Hitalo Joserfeson Batista Nascimento 1
1
Ciencia da Computaca o - Faculdade Integrada da Grande Fortaleza (FGF)
Av. Porto Velho, 410 60.510-040 Fortaleza CE Brasil
{tonyalveslopes@gmail.com}, {adri,edvan,hitalo,elidiane}@fgf.edu.br

Resumo. A Internet apos a WEB 2.0 vem gerando uma quantidade expressiva
de dados e com isso vem a necessidade de agilizar o gerenciamento desses da-
dos, bem como seu armazenamento de forma que fiquem disponveis sempre que
precisar. NoSQL (Not Only SQL) vem com a missao de resolver esse gargalo de
forma eficaz, com isso o presente artigo visa apresentar os conceitos que envol-
vem o termo NoSQL, a sua necessidade de implementaca o para com a escalabi-
lidade e performance na WEB 2.0, relata comparaco es com o modelo relacional
nas propriedades ACID e BASE e a sua relaca o com o Teorema CAP. No estudo
de caso e mostrada uma implementaca o utilizando o MongoDB, demonstrando
a abordagem de desenvolvimento junto com o seu driver e a tecnologia Java.
Por fim, ele explana os resultados do estudo de caso e sugere como trabalhos
futuros a implementaca o do algoritmo MapReduce.
Palavras-chave: nosql, sgbd, sql.

Abstract. The Internet after Web 2.0 has generated a significant amount of data
and with that comes the need to streamline the management of these data and
their storage so they are available whenever you need. NoSQL ( it Not Only
SQL) comes with the mission to solve this bottleneck effectively, thus this article
is to present the concepts involving the term NoSQL, their need for implemen-
tation towards the scalability and performance on the Web 2.0 reports compari-
sons with the relational model in ACID and BASE and its relationship with the
CAP theorem. In the case study is shown an implementation using MongoDB,
demonstrating the development approach together with its it driver and Java
technology. Finally, he explains the results of the case study and suggests future
work as the implementation of the MapReduce algorithm.
Keywords: nosql, sgbd, sql.

1. Introduca o
Durante muito tempo os Sistemas Gerenciadores de Banco de Dados (SGBD) relacio-
nais dominaram com eficiencia a forma como as pessoas armazenavam e buscavam seus
dados, de forma segura e consistente. Porem, com o advento da WEB 2.0 e sua gama
incontavel de dados manipulaveis, gerou-se um problema para abordagem antes domi-
nante, o armazenamento e a escalabilidade desses dados. Atualmente, os grandes sites
coletam informaco es acerca de seus usuarios, que hoje passam de bilhoes (caso do Go-
ogle e Facebook)[Rubinstein and Good 2013], e cada usuario tem diversas nuances que
devem ser analisadas para melhor gerenciamento dessas informaco es, e por conseguinte
gerar receita para essas empresas atraves de propagandas e desenvolvimento de platafor-
mas especficas para utilizaca o em massa.
Diante deste novo panorama, termos como escalabilidade e performance vieram
a` tona com mais forca do que nunca. Os grandes SGBDs nao possuam suporte ade-
quado a` s novas exigencias, como escalonamento horizontal e velocidade de manipulaca o
de uma grande quantidade de dados. Com isso, vem a ideia do NoSQL (Not Only
SQL), onde se torna mais facil o escalonamento horizontal e a grande capacidade para
armazenamento[Leavitt 2010].
Ao pesquisar trabalhos relacionados com o assunto aqui enfatizado foram
identificados artigos que abordam as diversas nuances do modelo nao relacio-
nal, dentre estes podemos citar: NoSQL no desenvolvimento de aplicaco es Web
colaborativas[Loscio et al. 2011]; o artigo Bancos de Dados NoSQL x SGBDs Rela-
cionais: Analise Comparativa[Brito 2010]; foi utilizado tambem o minicurso Bancos
de Dados NoSQL: Conceitos, Ferramentas, Linguagens e Estudos de Casos no Con-
texto de Big Data[Vieira et al. 2012]; e o livro NoSQL: Um Guia Conciso para o
Mundo Emergente da Persistencia Poliglota[Sadalage and Fowler 2012] e NoSQL para
leigos[Fowler 2015].
Este artigo tem como objetivo mostrar os conceitos norteados em torno do
NoSQL, suas caractersticas, as diferencas com o modelo relacional, os seus tipos de ar-
quitetura, e por fim demonstrar uma aplicaca o usando MongoDB com o uso da sua API de
manipulaca o. Ele esta dividido da seguinte forma: na seca o 2 e dado um breve compara-
tivo da tecnologia nao relacional com a relacional, e explicado como funciona o Teorema
CAP e o seu surgimento, e mostrado o conceito de escalonamento horizontal e vertical
e os tipos de particionamento em rede, tambem e mostrado o historico do termo NoSQL
e como foi dada a sua influencia de desenvolvimento, no final da seca o e explanado os
principais tipos de bancos de dados nao relacionais e uma pequena comparaca o com um
banco de dados relacional, na seca o 3 e descrita a metodologia utilizada para desenvolver
o trabalho, na seca o 4 e feita uma analise dos dados utilizando uma implementaca o como
estudo de caso com MongoDB e Java, e finalmente na seca o 5 temos as consideraco es
finais sugerindo trabalhos futuros.

2. Referencial Teorico
Neste captulo apresentamos paralelos entre o modelo atual de gerenciamento de dados, os
modelos relacionais, com o paradigma de dados distribudos, os ditos NoSQL. E definido
alguns conceitos primordiais na elaboraca o do modelo NoSQL atraves do Teorema CAP.
Tambem apresentamos as caractersticas dos banco de dados nao relacionais, junto com os
metodos de implementaca o e distribuica o em rede. Sao apresentados os quatro principais
tipos de banco de dados nao relacionais conhecidos atualmente, representado por cada
um de seus representantes no mercado. E por fim e apresentado algumas caractersticas
do MongoDB, objeto de caso de estudo deste artigo.

2.1. Modelo Relacional

O modelo relacional tem caractersticas estruturadas ha muito tempo, inclusive possui
uma comunidade apenas para definir os padroes adotados pelas diversas empresas que
implementam SGBDS, dentre os quais podemos ressaltar: Oracle1 , Microsoft SQL
Server2 , MySQL3 e PostgreSQL4 . Dentre as principais caractersticas de um SGBD,
destacam-se: controle de concorrencia, seguranca, recuperaca o de falhas, gerenciamento
do mecanismos de armazenamento de dados e controle das restrico es de integridade do
banco de dados. Outra importante funca o de um SGBD e o gerenciamento de transaco es.
A execuca o de transaco es em um SGBD deve obedecer a algumas propriedades a fim
de garantir o correto funcionamento do sistema e a respectiva consistencia dos dados.
Estas propriedades sao chamadas ACID(Atomicidade, Consistencia, Durabilidade e
Isolamento)[Gray et al. 1981]. Elas garantem que transaco es sejam feitas com seguranca,
garantindo atomicidade de cada uma delas, consistencia dos dados, isolamento e integri-
dade durante todas as transaco es. Entretanto, garantir todos esses atributos pode acarretar
em configuraco es complexas e um pessimo desempenho em uma transaca o. Os conflitos
surgem entre os diferentes aspectos da necessidade de garantir as propriedades ACID em
sistemas distribudos[Hadjigeorgiou et al. 2013].

2.2. Modelos nao relacionais

Nesta seca o e apresentado conceitos que envolvem o modelo nao relacional quanto a sua
arquitetura de funcionamento. E apresentado o Teorema CAP, os metodos de escalona-
mento vertical e horizontal e os metodos de particionamento em rede.

2.2.1. O Teorema CAP

No ano 2000, no Simposio de Princpios de Computaca o Distribuda (ACM Symposium

on the Principles of Distributed Computing), o Dr. Eric A. Brewer discursava sobre o
seu trabalho teorico na empresa que fundou, Inktomi. Na ocasiao, Dr. Brewer mostrou
em sua apresentaca o que os sistemas executados em ambientes distribudos possuem tres
nucleos fundamentais, e definiu uma relaca o de funcionamento entre estes, de forma que
apenas dois destes sejam genuinamente viaveis[Browne 2009]. O teorema CAP foi for-
malmente provado[Gilbert and Lynch 2002] em 2002, por Seth Gilbert e Nancy Lynch do
MIT. Nascendo assim o teorema CAP.
Tres nucleos fundamentais sao[Browne 2009]:
1. (C - Consistency) Consistencia: Todos os nos da rede necessitam ter a mesma
versao do arquivo.
2. (A - Availability) Disponibilidade: Todos os clientes podem sempre encontrar pelo
menos uma copia dos dados solicitados, mesmo que um cluster esteja desligado.
3. (P - Partition Tolerance): Tolerancia a partico es [na rede]. O sistema continua com
seus dados, propriedades e caractersticas mesmo se for implantado em servidores
diferentes, transparente para o cliente.
O teorema de CAP postula que apenas dois desses tres itens, citados acima, podem
ser alcancados plenamente, ao mesmo tempo. Com isso, para garantir a melhor escalabi-
lidade e armazenamento dos dados, foi proposto enfraquecer o atributo de consistencia,
1
http://www.oracle.com/br/index.html
2
https://www.microsoft.com/pt-br/server-cloud/products/sql-server
3
https://www.mysql.com
4
https://www.postgresql.org
focando-se em melhorar a disponibilidade e a tolerancia de criar mais partico es. Foi dessa
ideia que nasceu o conceito BASE (Basically Available, Soft state, Eventual consistency)
com propriedades e filosofia oposta. Esse novo conceito considera um cenario que prove
transaco es distribudas, tolerancia a falhas de consistencia e replicaca o otimista em um
sistema distribudo, porem essa e uma das abordagens na implementaca o do banco de
dados NoSQL usando esse teorema. Outras formas de pensar ja foram divulgadas a` co-
munidade baseado no teorema CAP, onde e posto em evidencia o P (Partition Tolerance)
e a partir deste faz-se variaco es acerca dos outros dois nucleos, pois poder particionar os
dados em varios clusters atraves da rede, e uma das vantagens na abordagem de banco
de dados NoSQL, onde os sistemas de banco de dados relacionais mostram-se menos
eficazes justamente por causa da ACID, explicado anteriormente na seca o 2.1.

2.2.2. Escalonamento horizontal e vertical

No incio dos anos 2000, quando o mundo foi imerso pela crescente utilizaca o da WEB
e os domnios .com, enquanto ainda surgiam questionamentos quanto ao funciona-
mento em si e o futuro economico desse novo paradigma, houve, tambem, uma crescente
preocupaca o com a forma que essa grande e frequente quantidade de dados seria utilizada,
armazenada e processada.
Seguir com este aumento de dados exige tecnicas de expansao de hardware, que
hoje podem ser[Sadalage and Fowler 2012]: escalonamento vertical (scale-up) ou escalo-
namento horizontal (scale-out). Escalonamento vertical diz respeito a adquirir maquinas
maiores, mais processadores, mais memoria primaria, aumento da memoria secundaria,
ou seja, aumentar os componentes de determinado servidor que atende as requisico es
para determinada tarefa, no entanto, isso tende a se tornar extremamente caro com o
passar do tempo, e uma hora ira esbarrar na propria limitaca o fsica da maquina, visto
que ha um limite para este tipo de crescimento. Ja o escalonamento horizontal visa au-
mentar o numero de servidores e dividir a carga entre eles formando um cluster. Esses
servidores nao precisam ser maquinas super potentes, e sim maquinas de menor custo
(commodity server), o que deixaria o projeto bem mais barato do que o apresentado an-
teriormente. Outra caracterstica positiva dessa abordagem e a resiliencia, onde e normal
que maquinas apresentem problemas de funcionamento, no entanto, caso uma apresente
neste modelo, nao interferira no trabalho das outras (exceco es se for um modelo master-
slave e o que falhar for o master), atribuindo, assim, um aspecto de alta confiabilidade.
Na Tabela 1 [Appuswamy et al. 2013] e apresentado uma analise comparativa dessas duas
abordagens.
Ao passo que a maioria das empresas percebe que a segunda alternativa e a mais
viavel, surge um novo problema: bancos de dados relacionais nao foram projetados para
serem executados em clusters [Sadalage and Fowler 2012]. Os bancos relacionais atuais
baseiam-se no conceito de um subsistema de disco compartilhado. Eles utilizam um
sistema que reconhece o ambiente de cluster, porem ha uma rotina de replicaca o para
um disco de alta disponibilidade. Sendo assim, mesmo balanceando as cargas, ainda
necessita de um ponto u nico, o que pode gerar falhas, caso ocorra algo com este ponto,
todo o sistema fica comprometido.
Todo esse gargalo com relaca o aos clusters e aos bancos de dados relacionais,
 Pros Contras
- Menor consumo de energia do que - Alto custo a medida que a neces-
Escalonamento Vertical
comparado a` multiplos servidores. sidade aumenta.
- Maior risco de falha por estar lo-
- Manutenca o de refrigeraca o.
calizado em um u nico ponto.
- Custo com licencas de softwares
- Limite fsico para crescimento.
diminudas.
- Mais barato do que um u nico ser- - Pode ser usado mais licencas de
- Escalonamento Horizontal
vidor robusto. softwares.
- Lida bem com falhas no nos. (To-
- Maior custo com energia eletrica.
lerancia a falhas).
- Precisa de mais equipamentos de
- Upgrade mais acessvel.
rede (switches/roteadores).

Tabela 1. Vantagens e desvantagens de escalonamento vertical e horizontal

levou grandes empresas a buscarem uma nova forma de armazenar os dados. Com
isso, entra em cena duas empresas percussoras da arquitetura de dados e sistemas dis-
tribudos, Google e Amazon. Essas empresas no incio da decada ja projetavam suas
soluco es para contornar esta falha dos modelos relacionais. Com isso, em 2004 a Google
comecava seu trabalho com o BigTable[Chang et al. 2008] e a Amazon, em 2005, com
o Dynamo[DeCandia et al. 2007]. Ambas as empresas publicaram seus resultados para o
publico em geral, e por causa disso, se tornaram as percussoras e grandes influentes no
mercado quando o assunto era sistemas distribudos em clusters e NoSQL.

2.2.3. Metodos de particionamento em rede

Uma das caractersticas em NoSQL e a sua capacidade de executar em varios nos da rede
(particionamento). Sendo assim, a` medida que os dados fossem evoluindo, pode-se usar
cluster de servidores para gerenciar e balancear as cargas.
Cada modelo de distribuica o possui uma forma de armazenamento de dados,
gerencia de trafego de rede com relaca o a leitura e gravaca o, ou mais disponibilidade
quanto a atrasos e interrupco es na rede. Os benefcios sao muito atrativos para sua
utilizaca o, no entanto deve-se lembrar que existe varios custos relacionados. A execuca o
em ambiente de cluster introduz uma complexidade muito alta, portanto nao trata-se de
algo trivial e so deve ser utilizada em casos em que os benefcios sejam bastantes recom-
pensadores.
Atualmente, sao discutidos dois metodos de distribuica o em rede de
dados[Sadalage and Fowler 2012]: fragmentaca o (sharding) e replicaca o. De forma resu-
mida, pode-se dizer que fragmentaca o busca distribuir dados diferentes em varios pontos
da rede, enquanto que a replicaca o distribui os dados de um ponto u nico e os replica aos
diversos nos na rede. Essas duas tecnicas sao diferentes, porem nao precisam ser imple-
mentadas isoladamente, podem se complementar.

Fragmentaca o (Sharding): Trata-se de um processo para escalonamento hori-

zontal, onde sao postos diferentes conjuntos de dados em diferentes servidores.
Em termos gerais, usuarios diferentes consultam dados especficos em servidores
 que contivessem a informaca o buscada[Sadalage and Fowler 2012] .
Varios bancos de dados NoSQL ja implementam a auto-fragmentaca o, onde fica
a cargo do banco de dados distribuir os dados e garantir que os mesmos sejam
recuperados. Tambem e necessario frisar que em caso de falha em algum no, os
dados deste nao ficarao mais disponveis, sendo assim podendo ter um sistema
parcialmente indisponvel.
Replicaca o mestre-escravo: Uma distribuica o mestre-escravo acontece quando
ha replicaca o de dados de um servidor mestre (primario) aos servidores escravos
(secundarios). Um no e considerado como mestre (primario), quando este e a
fonte principal dos dados e onde sao feitas as escritas. Este tipo de procedimento
e u til quando estamos lidando com um ambiente onde tem-se muitas leituras de
dados. No entanto, ha a necessidade de mais processamento para o servidor mestre
replicar as informaco es aos escravos e uma eventual falha do mestre compromete
o sistema quanto a` escrita de novas informaco es.
Um fator interessante nessa arquitetura diz respeito ao fato de que, se o mestre
falhar, o sistema continua operando normalmente para leituras, isso e muito bom
quando temos um ambiente que exige muito mais leitura que escrita. A falha no
mestre pode ser lidada com a escolha de seu sucessor por um dos nos escravos.
Essa escolha pode ser automatica, programaticamente selecionavel, ou manual-
mente selecionada pelo operador do sistema[Sadalage and Fowler 2012].
Replicaca o ponto a ponto: A replicaca o mestre-escravo possui alguns gargalos
com relaca o a gravaca o, por ter um ponto centralizador, e possivelmente de fa-
lhas para gravaco es, dizemos que temos uma escalabilidade para leitura, nao para
gravaca o. Com a replicaca o ponto a ponto, divide-se os dados em varios nos e
todos tem a habilidade de gravar e ler os dados simultaneamente, eliminando a ne-
cessidade de sincronizaca o das informaco es de um no mestre. Porem, novamente,
esbarra-se no problema de consistencia visto anteriormente, tendo um agravante,
pois a inconsistencia pode ser de gravaca o, o que geraria problemas piores do que
a inconsistencia de leitura. Para este problema ha abordagens que podem ser uti-
lizadas. A primeira e criar uma rotina que ao perceber uma nova atualizaca o, esta
seja sincronizada com todos os nos e estes, atraves de um algoritmo, escolher se
a atualizaca o sera ou nao aprovada. O algoritmo nao precisa escolher gravar se a
escolha for unanime, e sim de uma maioria dos nos. A segunda, e ao lidarmos com
as gravaco es inconsistentes posteriormente, utilizando de heursticas para mesclar
essas gravaco es.

2.3. NoSQL
Nesta seca o e explanado acerca do historico do NoSQL, as principais caractersticas e os
principais tipos de bancos de dados existentes hoje no Mercado.

2.3.1. Historico

O termo NoSQL foi utilizado pela primeira vez em 1998, por Carlo
Strozzi[Nascimento 2015], como nome de seu SGBD, baseado no Modelo Relacio-
nal de codigo aberto (open source), sem interface SQL. Este banco de dados utilizava
shell script para recuperar os dados, e estes, por sua vez, ficavam armazenados em forma
de arquivos ASCII, uma tupla era representada por uma linha com os campos separados
por tabulaco es, ou seja, nao se assemelha em nada aos modelos de NoSQL atuais,
assemelhando-se mais a um SGBD onde nao se utilizava o modelo relacional para as
consultas, pode ser melhor abordado como NoREL (No Relational), concluindo-se que,
apesar do nome, o termo de Strozzi nao teve influencia sobre o que sera abordado neste
artigo.
Ja o termo NoSQL como conhecemos atualmente foi introduzido no incio de
2009[Evans 2009] por um funcionario do Rackspace, Eric Evans, quando Johan Oskars-
son, um desenvolvedor de software de Londres que trabalhava na Last.fm5 , organizou um
evento para discutir bancos de dados open source distribudos. Este evento ocorreu em
Sao Francisco, nos Estados Unidos. Johan estava interessado em descobrir mais sobre
esses novos tipos de bancos, inspirados no BigTable6 e DynamoDB7 , Google e Amazon,
respectivamente. Como ele dispunha de pouco tempo na cidade, viu que nao era viavel
visitar todas as empresas que estava participando do desenvolvimento desses softwares,
entao decidiu realizar o evento e convidou a todos para mostrar seus trabalhos e discu-
tir sobre o futuro da tecnologia. Este evento ficou conhecido como primeiro encontro
NoSQL.
Atualmente ha diversas soluco es NoSQL implementadas, sendo majoritariamente
Open Source, mostrando o interesse da comunidade em disseminar da forma mais a gil
possvel essa nova tecnologia. Porem, com isso, vem o que pode ser problematico a longo
prazo, a quantidade relativamente grande de SGBDs implementando diferentes padroes
NoSQL. Dentre eles citamos: Key-value, Document store, Column Store e Graphs.

2.3.2. Caractersticas

Os modelos nao relacionais possuem algumas caractersticas fundamentais que o dife-

renciam dos relacionais, dando-lhe vazoes para gerenciamento de grandes quantidades
de dados estruturados e semi-estruturados, bem como escalabilidade e replicaca o. Sao
elas[Loscio et al. 2011]:
Nao utiliza SQL: Os bancos de dados relacionais sao conhecidos pelo seu padrao
SQL, linguagem de consulta estruturada. Ja tratando-se de NoSQL, percebemos
que os mesmos nao utilizam esse padrao, implementando suas proprias APIs de
consultas. Hoje o Cassandra, por exemplo, implementa uma linguagem bastante
similar ao SQL, o CQL. Todavia, ate hoje, nao existe uma padronizaca o de APIs
de consultas para o NoSQL. Algo realmente esperado para os proximos anos.
Codigo aberto (Open-source): Uma caracterstica importante e que eles sao
projetados, em sua maioria, em codigo aberto. Nao significa dizer que para ser
um SGBD NoSQL precisa ser de codigo aberto, porem a sua grande maioria o e .
WEB do seculo XXI: Os bancos de dados NoSQL vieram da necessidade de
resolver gargalos enfrentados com o advento da WEB do seculo XXI, a dita WEB
2.0, sendo assim e normal relacionarmos o desenvolvimento destes terem sidos
5
http://last.fm
6
https://cloud.google.com/bigtable
7
https://aws.amazon.com/pt/documentation/dynamodb
 iniciados apenas apos o incio do milenio, o que exclui varios bancos com algumas
caractersticas similares.
Schemaless ou Esquemas dinamicos: Diferente dos modelos relacionais, o
NoSQL nao implementa uma forma de definica o rgida dos dados, ou seja, campos
podem ser retirados e inseridos sem a preocupaca o de consistencia. Com isso
ganha-se em escalabilidade de uma forma geral e tambem garante maior aumento
da disponibilidade.
Consistencia eventual: E uma caracterstica de bancos NoSQL relacionada
ao fato da consistencia nem sempre ser mantida entre os diversos pontos de
distribuica o de dados. Esta caracterstica tem como princpio o teorema CAP
(Consistency, Availability e Partition Tolerance).
Sharding: Particionamento horizontal e um princpio de projeto de banco de
dados pelo qual as linhas de um banco de dados sao armazenadas separadamente,
em vez de serem quebradas em colunas (que e o que a normalizaca o e o partici-
onamento vertical fazem, para diferenciar extensoes). Cada partica o forma parte
de um shard, que pode, por sua vez, ser instalada em um servidor de banco de
dados ou localizaca o fsica separada.

Essas caractersticas fazem parte de um sistema comum para reconhecimento do

que e um SGBD NoSQL. Porem, nenhuma delas define em 100% dos casos. Sendo
uma melhor definica o, segundo Martin Fowler [Sadalage and Fowler 2012], como um
conjunto de bancos de dados criados a partir do seculo XXI que nao utilizam SQL e
pensados para distribuica o em nos de rede.

2.3.3. Tipos de banco de dados

Nesta seca o e mostrado os quatro tipos de banco de dados relacionais existentes atual-
mente que sao: Chave-Valor, Documentos, Famlia de Colunas e Grafos. Aqui elenca-se
as suas caractersticas, tracando um paralelo com alguns modelos relacionais e exempli-
ficado com alguns representantes de cada um.

Bancos de dados de chave-valor: Um banco de dados chave-valor pode ser

definido como um deposito hash simples. De forma que a chave primaria seja a
principal fonte da busca na diferenciaca o dos registros obtidos. De forma a uma
melhor exemplificaca o, imagina-se uma tabela de um banco de dados relacional,
onde esta devera possuir duas colunas: CHAVE e VALOR. Na coluna CHAVE
armazena-se dados do tipo texto, que devera conter algum criterio que permita a
busca posteriormente, e a coluna VALOR e o valor agregado a CHAVE. Na Tabela
2[Sadalage and Fowler 2012], podemos verificar essas terminologias como seria
no PostgreSQL (banco de dados relacional) e Riak (banco de dados nao-relacional
baseado em chave-valor).
Os bancos de dados chave-valor sao os mais simples NoSQL quando o as-
sunto e com relaca o a sua API (Application Programming Interface). Onde
todas as operaco es se dao, basicamente, por meio das chaves, caso queira in-
serir, basta lancar o par chave-valor, caso a chave nao exista sera lancado um
novo registro, quando ha a chave no banco, este atualiza o valor correspondente
 PostgreSQL Riak
Banco de dados Cluster riak
Tabela Bucket
Linha chave-valor
OID Chave

Tabela 2. Comparativo PostgreSQL e Riak

aquele registro. Bancos de dados baseados em chave-valor fazem acesso so-

mente pela chave primaria, eles possuem, geralmente, um bom desempenho e
facil escalabilidade[Sadalage and Fowler 2012].
Alguns dos bancos de dados de chave-valor mais populares sao: Riak8 , Redis9 ,
Memcached DB10 e suas variedades, Berkeley DB11 , Amazon DynamoDB12 (nao
e open-source) e o Projeto Voldemort13 (uma implmentaca o do open-source do
Amazon DynamoDB).
Bancos de dados de documentos: Os bancos de dados baseados em documen-
tos utilizam como conceito principal armazenar estruturas de dados de a rvores
hierarquicas e declarativas. Essas estruturas de dados podem ser XML (EXten-
sible Markup Language), JSON (JavaScript Object Notation), BSON (JSON em
formato binario), entre outros. Os documentos podem ser imaginados como os
registros no banco de dados relacional, porem estes nao precisam ter o mesmo
formato dos ja inseridos anteriormente (Schemaless). Bancos de dados de do-
cumentos sao bastante parecidos com os de chave-valor, porem, diferentemente,
aqui os valores podem ser verificados e estes podem ser, inclusive, referencias a
outros documentos. Na Tabela 3[Sadalage and Fowler 2012] vemos a comparaca o
de terminologias entre PostgreSQL e MongoDB.

PostgreSQL MongoDB
Banco de dados Instancia MongoDB
Esquema Banco de dados
Tabela Coleco es
Linha Documento
OID id
Junca o DBRef

Tabela 3. Comparativo PostgreSQL e MongoDB

O campo ide um campo especial no MongoDB, este existe em todo docu-

mento criado, e e criado automaticamente. O usuario pode definir o valor deste
campo, contanto que este seja u nico na coleca o. Os bancos de dados de docu-
mentos adotam o modelo schemaless, ou seja nao e preciso definir um esquema
8
http://basho.com/products
9
http://redis.io
10
http://memcachedb.org
11
http://www.oracle.com/technetwork/database/database-technologies/berkeleydb
12
https://aws.amazon.com/pt/documentation/dynamodb
13
http://www.project-voldemort.com/voldemort
 para uma determinada coleca o, na mesma coleca o e possvel ter documentos to-
talmente diferentes entre si, algo que nao acontece no modelo relacional, onde
devemos definir um esquema de colunas, e todas as linhas daquela tabela de-
verao obedecer ao padrao de colunas criado. Em documentos nao ha atributos
vazios[Sadalage and Fowler 2012], quando um valor nao e encontrado, e suposto
que este nao foi configurado anteriormente e, portanto, nao e relevante para a con-
sulta. Os bancos de dados baseados em documentos mais populares atualmente
sao: MongoDB14 , CouchDB15 , Terrastore16 , OrientDB17 , RavenDB18 e o Lotus
Notes19 .
Bancos de dados em famlias de colunas: O armazenamento em famlia de co-
lunas ficaram bastante conhecidos devido a sua primeira implementaca o, o Goo-
gle Big Table[Chang et al. 2008]. Nesse modelo ha tambem muitas similaridades
a sua API de manipulaca o de dados e a o padrao SQL (Structered Query Lan-
guage). Esse modelo armazena os dados em chaves mapeadas para valores, e
os valores sao agrupados em famlias de colunas, cada uma dessas famlias de
colunas funcionando como um mapa de dados. Diferente do modelo relacional,
onde os dados sao agrupados por linhas seguindo um esquema pre-estabelecido
de colunas, ou seja, as linhas precisam seguir aquele leiaute, ja aqui tem-se esse
paradigma trocado, onde as informaco es estao em colunas, e o conjunto dessas
colunas forma uma famlia de colunas. Na Tabela 4[Sadalage and Fowler 2012]
traca-se um paralelo de conceitos entre o modelo relacional com PostgreSQL e
este novo modelo representado pelo Cassandra.

PostgreSQL Cassandra
Banco de dados Keyspace
Tabela Famlia de colunas
Linha Linha
Coluna (a mesma para todas as linhas) Colunas (podem ser diferentes por linha)

Tabela 4. Comparativo PostgreSQL e Cassandra

As famlias de colunas armazenam os seus dados em um conjunto onde as

informaco es, geralmente, sao associadas, fazendo disso uma chave de linha. Elas
sao um grupo de dados relacionados onde o seu acesso se da de maneira uniforme,
ou seja, sao acessados juntos. Para melhor entendimento, verifica-se o acesso de
um perfil de um cliente para listar seus pedidos, no modelo relacional este se da
atraves de junco es, com a tabela de clientes e a tabela de pedidos, no entanto,
torna-se computacionalmente custoso essa transaca o. Na famlia de colunas tem-
se um ID para identificar a linha do cliente, e nas colunas desse cliente tem-se
todas as informaco es pertinentes a este, bem como as informaco es de pedidos,
14
https://www.mongodb.org
15
http://couchdb.apache.org
16
https://code.google.com/archive/p/terrastore
17
http://orientdb.com/orientdb
18
https://ravendb.net
19
https://www.ibm.com/developerworks/lotus
 parecido com o que temos no modelo de documentos JSON, onde ha informaca o
hierarquizada.
Banco de de dados de Grafos: Os bancos de dados em grafos utilizam concei-
tos da Teoria dos Grafos para estruturar seus dados. Basicamente, a topologia de
um grafo G pode ser expressa como G = (V, E), onde V e o conjunto de vertices
(nodos) e E e o conjunto de arestas. Cada aresta representa uma relaca o entre
dois nodos. Um conjunto de vertices conectados por meio de arestas definem um
caminho no grafo. No modelo de dados em Grafos temos a figura da Entidade,
que seria o vertice no grafo, esta entidade possui propriedades. Os relaciona-
mentos entre as Entidades sao as arestas, e estas tambem possuem propriedades,
sendo uma caracterstica essencial o direcionamento entre as arestas e os nodos.
Dessa forma pode-se construir consultas otimizadas a esses relacionamentos. Atu-
almente tem-se muitos bancos de dados baseados em grafos, tais como Neo4J20 ,
Infinite Graph21 , o OrientDB22 e o FlockDB23 .
Com relaca o a consistencia nesse modelo, temos uma diferenca em relaca o
aos outros modelos nao-relacionais mostrados ate agora, podemos ver que
a maioria dos bancos de dados em grafos implementam as propriedades
ACID[Sadalage and Fowler 2012], isso se da porque as soluco es implementadas
atualmente nao suportam a distribuica o dos nodos em um cluster de servidores,
porem o Infinite Graph24 possui essa funcionalidade.

2.4. MongoDB
MongoDB e um banco de dados de codigo aberto, nao relacional orientado a documen-
tos, que prove mecanismos para aumento de performance, alta disponibilidade e esca-
lonamento horizontal automatico. A API de manipulaca o de dados, que sera mostrada
na implementaca o do estudo de caso, deriva do conceito de ORM (Object Relational
Map), Mapeamento Objeto-Relacional, para ODM (Objetct Document Model), Mapea-
mento Objeto-Documento. Esta tecnica, por sua vez, determina a interoperabilidade entre
a programaca o orientada a objetos e os modelos relacionais de banco de dados.

2.4.1. Documentos

Um registro em MongoDB e um documento, que por sua vez e uma estrutura que consiste
em um par de chave e valor, porem, diferentemente de um outro banco Chave-Valor, este
par pode ser aninhado com outros pares dessa mesma estrutura, algo bastante similar
ao que ja temos com objetos JSON (Java Script Object Notation), que e um formato
leve para intercambio de dados computacionais, no entanto, em MongoDB, temos uma
melhoria dessa estrutura de dados, onde o seu armazenamento e feito em BSON, que e
o documento JSON guardado e indexado em forma binaria, isso traz muitas melhorias
com relaca o a velocidade de acesso e manipulaca o das informaco es, em contra-partida,
documentos BSON sao maiores o que gera maior tamanho em disco. Um documento
20
http://neo4j.com
21
http://www.objectivity.com/products/infinitegrap
22
http://orientdb.com/orientdb
23
https://github.com/twitter/flockdb
24
http://www.objectivity.com/products/infinitegraph
em MongoDB e equivalente a um registro no banco de dados relacional. O codigo 1
exemplifica um documento JSON utilizado pelo MongoDB[MongoDB 2016].

Codigo 1 - Exemplo de objeto JSON

1
2 {
3 "address": {
4 "building": "1007",
5 "street": "Morris Park Ave",
6 "zipcode": "10462"
7 },
8 "borough": "Bronx",
9 "cuisine": "Bakery",
10 "name": "Morris Park Bake Shop",
11 "restaurant_id": "30075445"
12 }

2.4.2. Coleco es

Coleco es em MongoDB sao um conjunto de documentos. Semelhante ao que temos no

modelo relacional, as tabelas. No entanto, temos nas coleco es a falta de esquema que
e caracterstica forte nos modelos nao-relacionais, ou seja, uma coleca o nao precisa que
todos os seus documentos tenham as mesmas quantidades de pares e valores, ou mesmo
equidade de tipos.

2.4.3. Recuperaca o de dados

As operaco es de manipulaca o de dados em MongoDB se da atraves da sua API. Dentro do

MongoShell (cliente do MongoDB) esta se dara de forma nativa, diferente do driver, onde
usa-se uma linguagem baseada em ODM (Object Document Model) que simula, atraves
do proprio codigo, as consultas e manipulaco es da API. Diferentemente do SQL, onde
as querys sao passadas diretamente do driver para o banco, aqui nao se faz necessario.
A API de manipulaca o do MongoDB e bastante rica e possui muitas caractersticas que
deixara, dificilmente, um desenvolvedor sem opco es para resolver determinado problema.

3. Metodologia
Para exemplificar os conceitos discorridos ate agora, foi implementado uma aplicaca o
que usa os conceitos de banco de dados nao relacional. Ela e uma aplicaca o WEB usando
Java e MongoDB para consulta e manipulaca o de informaco es referentes a um catalogo
de restaurantes. Nela o usuario podera consultar restaurantes por endereco, nome e ci-
dade. Podera, tambem, mesclar as consultas em uma u nica usando o full text search do
MongoDB e cadastrar um novo restaurante no catalogo.
Para esta aplicaca o foi usado o driver Java do MongoDB, API de consultas dire-
tamente da linguagem, que se assemelha bastante com a implementada no MongoShell.
Tambem foi utilizado uma base de dados disponibilizada na documentaca o do MongoDB,
que consiste em uma coleca o de documentos JSON com informaco es de restaurantes,
como nome, endereco e avaliaca o de qualidade.

4. Analise dos dados

Nesta seca o e mostrado como foi desenvolvido a aplicaca o com MongoDB, demonstrando
as classes criadas e os servicos utilizadas como base para tal.

4.1. Estudo de caso

Para reproduca o dos exemplos de uso do MongoDB foram necessarios conhecimentos
basicos da linguagem Java com JSF, Primefaces e uso na ferramenta Eclipse, bem como a
criaca o de projetos utilizando Maven. Para a implementaca o foram utilizados as seguin-
tes versoes: a JDK 1.8, Maven 3.3.9, MongoDB 3.22 no ambiente de desenvolvimento
Eclipse Mars. Os drivers referentes API de Java para MongoDB podem ser baixados do
proprio site ou carregando as dependencias via Maven.
Para fazer uso das funco es da API do MongoDB com o driver Java, foram cons-
trudos metodos que realizam, primeiramente, as operaco es basicas para conexao com a
base e manipulaca o das informaco es. No contexto da coleca o de restaurantes foi usado
metodos que acessam as informaco es desses com base em busca realizada pelo usuario
nos campos desta coleca o. Sendo assim, a aplicaca o tem as seguintes classes:
Connection.java : Classe responsavel por prover as conexoes do MongoDB para
aplicaca o;
RestaurantDAO.java : Classe responsavel por prover os metodos que manipulam
as informaco es referentes aos restaurantes;
UsersDAO.java : Classe responsavel por prover os metodos que manipulam as
informaco es referentes aos usuarios, incluindo o controle de acesso;
User.java : Classe que modela as caractersticas dos usuarios do sistema;
Restaurant.java : Classe que modela as caratersticas dos restaurantes, usada para
receber os valores do banco.
Alem dessas, foram usadas classes beans, que sao as classes anotadas como Ma-
naged Bean referentes ao framework JSF (Java Server Faces) para acesso, controle e
manutenca o das paginas webs criadas (.xhtml).
Como citado acima, a classe Connection prove o mecanismo para acessar o banco
de dados, esta interface se da atraves do driver desenvolvido pela propria empresa Mon-
goDB para Java. Essa implementaca o difere do usual pela sua enorme facilidade e por
nao exigir registro de classes, metodos de abertura e fechamento, tambem nao exigindo
URL de conexao, caso nao seja passado estes como parametro da chamada do metodo
getDatabase, ele ira pedir apenas o nome do banco de dados e se conectara automatica-
mente na maquina local (localhost) na porta 27017 (porta padrao). A seguir, no Codigo
2, e mostrado sua implementaca o.

Codigo com o MongoDB
2 - Classe de conexao

1 public class Connection {

2 private static MongoClient mongoClient;
 3 private Connection (){
4 }
5 public static MongoDatabase getConnection (){
6 mongoClient = new MongoClient ();
7 MongoDatabase db = mongoClient.getDatabase ("test
");
8 return db;
9 }
10 }

Ve-se que no codigo mostrado, a classe MongoDatabase e responsavel por guardar a

instancia de conexao provida pela classe MongoClient, nesta e passado em sua cha-
mada ao metodo getDataBase o nome do banco de dados a ser recuperado. Nota-se
que nao e preciso passar os dados de conexao com o servidor, como endereco e porta,
e possvel passar esses argumentos, como usualmente e feito nas aplicaco es com mo-
delos relacionais. Devido a sua natureza NoSQL, e possvel invocar varios servidores
na chamada deste metodo, implementando assim o conceito visto na seca o de carac-
tersticas do NoSQL o conceito de sharding e replication. No codigo 3, a seguir, pode-
se ver como seria a implementacao desse codigo, de acordo com a documentaca o do
MongoDB[MongoDB 2016].

Codigo 3 - Modelo de chamada de servidores

1 MongoClient mongoClient = new MongoClient (Arrays.asList (

2 new ServerAddress ("localhost", 27017),
3 new ServerAddress ("localhost", 27018),
4 new ServerAddress ("localhost", 27019)));

Por padrao, todas as leituras e escritas sao feitas no servidor primario, mas e
possvel que as leituras sejam feitas nos servidores secundarios, para isso e necessario
configurar as preferencias de leitura conforme codigo a seguir.
1 mongoClient.setReadPreference
2 (ReadPreference.secondaryPreferred ());

Na classe RestaurantDAO, sao feitas todas as interaco es de manipulaca o de dados

com a base de dados. No codigo 4, o metodo getAllRestaurantsespera como parametro
um inteiro que representa o numero de linhas a serem retornadas na consulta, que por sua
vez traz todos os dados da coleca o restaurant.

Codigo
4 - Metodo de busca de registros

1 public List<Restaurant> getAllRestaurants (int limit){

2 FindIterable<Document> it = db.getCollection ("restaurants").
find ().sort (new Document ("name", -1)).limit (limit);
3 List<Restaurant> rests = new ArrayList<> ();
4 it.forEach (new Block<Document> () {
5 @Override
6 public void apply (final Document t) {
7 Restaurant rest = new Restaurant ();
8 rest.setAddressBuilding ( (String) ( (Document)
t.get ("address")).getString ("building"));
9 rest.setAddressStreet ( (String) ( (Document) t.
get ("address")).getString ("street"));
 10 rest.setAddressZipCode ( (String) ( (Document)t.
get ("address")).getString ("zipcode"));
11 rest.setBorough ( (String) t.get ("borough"));
12 rest.setCuisine ( (String) t.get ("cuisine"));
13 rest.setName (t.get ("name").toString ());
14 rests.add (rest);
15 }
16 });
17
18 return rests;
19 }

Nessa consulta a quantidade de registros esta de acordo com o parametro passado

no metodo limit, e percebido que ha um metodo que ordena o resultado pelo campo
name. No MongoDB e usado o metodo sortaninhado a` consulta, e e passado como
parametro um Documento contendo o campo a ser ordenado e o tipo de ordenaca o, que
no caso e 1 para crescente e -1 para decrescente.
Se fosse necessario usar um criterio para a busca das informaco es usando esta API,
precisava-se passar como parametro ao metodo findum ou mais Documentos contendo
os pares, chave e valor, a serem buscados. Pode-se ver o exemplo desse caso no codigo
5, a seguir, onde e passado um objeto do tipo Document, este objeto deve ser preenchido
previamente com os valores a serem buscados como criterio.

Codigo
5 - Metodo de registros
de obtencao

1 public List<Restaurant> getDocumentsByCriteria (Document document

, int limit){
2 //consulta para recuperar restaurantes dado um criterio
3 FindIterable<Document> it = db.getCollection ("
restaurants").find (document).limit (limit);
4
5 List<Restaurant> rests = new ArrayList<> ();
6 it.forEach (new Block<Document> () {
7 @Override
8 public void apply (final Document t) {
9 Restaurant rest = new Restaurant ();
10
11 rest.setAddressBuilding ( (String) ( (
Document) t.get ("address")).
getString ("building"));
12 rest.setAddressStreet ( (String) ( (
Document) t.get ("address")).
getString ("street"));
13 rest.setAddressZipCode ( (String) ( (
Document)t.get ("address")).getString
("zipcode"));
14 rest.setBorough ( (String) t.get ("
borough"));
15 rest.setCuisine ( (String) t.get ("
cuisine"));
16
17 rest.setName (t.get ("name").toString ())
;
18
 19 rests.add (rest);
20
21 }
22 });
23 return rests;
24 }

A estrutura do MongoDB foi implementada visando a simplicidade de operaco es

que utilizam o seu framework, e busca sempre se manter em consonancia com os co-
mandos utilizados no seu shell, dado a sua disponibilidade na plataforma utilizada. As
operaco es de inserca o, deleca o e atualizaca o, tambem mostram-se muito simples devido
ao seu modelo schemaless ou esquema dinamico, e varias operaco es sao bastante simpli-
ficadas. Ao verificar o codigo 6, a seguir, e possvel ver sua implementaca o.

Codigo
6 - Metodos de dados
de acesso e manipulacao

1 public void updateRestaurant (Document criteria, Document

toUpdate){
2 db.getCollection ("restaurants").updateMany (criteria,
new Document ("\$set", toUpdate));
3 }
4
5 public void replaceRestaurant (Document criteria, Document
toReplace){
6 db.getCollection ("restaurants").replaceOne (criteria,
toReplace);
7 }
8
9 public void deleteRestaurant (Document criteria){
10 db.getCollection ("restaurants").deleteMany (criteria);
11 }
12
13 public void insertRestaurant (Document t){
14 db.getCollection ("restaurants").insertOne (t);
15 }

Nesses metodos sao definidas as suas caractersticas de utilizaca o conforme se

segue:
void insertOne (TDocument document): Insere o documento provido. Caso este
nao possua um identificador, o driver devera cria-lo. Caso a coleca o passada nao
exista, o driver tambem criara a coleca o.
void insertMany (List documents): Insere uma lista de Documentos na coleca o
passada.
UpdateResult updateOne (Bson filter, Bson update): Atualiza um documento de
acordo com os parametros passados como criterio, sendo o primeiro o filtro e o
segundo o valor a atualizar.
DeleteResult deleteOne (Bson filter): Remove um documento da coleca o con-
forme o filtro passado como argumento.
UpdateResult replaceOne (Bson filter, TDocument replacement): Substitui um do-
cumento inteiro da coleca o de acordo com o filtro passado.
Com o conhecimento desses comandos basicos, de como funciona a estrutura,
pode-se implementar uma aplicaca o web, ou standalone de forma bastante simplificada e
usando o melhor que o NoSQL pode oferecer para que aplicaco es performem satisfatori-
amente com alto volume de dados.
Na figura 1, e mostrada a tela de busca dos dados utilizada no sistema desenvol-
vido.

Figura 1. Tela de busca de restaurantes

5. Consideraco es Finais
Neste artigo foi visto a historia por tras da criaca o do NoSQL, os conceitos basicos para
o reconhecimento dessas aplicaco es, fundamentaca o de pontos chaves na implementaca o
de uma soluca o nao relacional com escalabilidade horizontal e implementando o Teo-
rema CAP. Foi visto tambem as caractersticas das principais implementaco es existentes
no Mercado e suas comparaco es com outros bancos relacionais. E por fim, foi mostrado
um estudo de caso usando MongoDB, para demonstrar como e usada a API de consultas
e o seu driver desenvolvido para a plataforma Java. Com base nisso, este trabalho agrega
o conhecimento necessario para o entendimento dos modelos nao relacionais de gerenci-
amento de dados, e como este relaciona-se com os modelos relacionais existentes. Aqui
tem-se tambem, os conhecimentos iniciais para o desenvolvimento de uma aplicaca o que
o usa o driver para Java do MongoDB.
Diante deste artigo, sugere-se como trabalhos futuros o aprofundamento na
questao de escalabilidade horizontal, dando e nfase aos algoritmos de mapeamento e
reduca o (MapReduce), visando a verificaca o da eficiencia quanto a disponibilidade e con-
sistencia em ambiente de cluster. Tambem pode-se verificar as outras APIs de consultas
dos outros SGBDs, bem como sua integraca o com as linguagens de programaca o atuais
atraves de seus frameworks.
Por fim, percebe-se que estamos no incio de uma caminhada em tecnologia bas-
tante promissora, que se apoia nas costas de gigantes, como Google, Amazon e Facebook,
que a cada dia contribuem com o fomento e disseminaca o dessa nova forma de manipular
e armazenar nossos dados. Vale ressaltar que o modelo relacional ainda e o mais apropri-
ado para a maioria dos casos e, principalmente, onde o crescimento dos dados nao seja
tao grande.
Referencias
Appuswamy, R., Gkantsidis, C., Narayanan, D., Hodson, O., and Rowstron, A. (2013).
Scale-up vs scale-out for hadoop: Time to rethink? In Proceedings of the 4th annual
Symposium on Cloud Computing, page 20. ACM.
Brito, R. W. (2010). Bancos de dados nosql x sgbds relacionais: analise comparativa.
Faculdade Farias Brito e Universidade de Fortaleza.
Browne, J. (2009). Brewers CAP Theorem Disponvel em: http://www.
julianbrowne.com/article/viewer/brewers-captheorem. Acessado
em: 01/06/2016.
Chang, F., Dean, J., Ghemawat, S., Hsieh, W. C., Wallach, D. A., Burrows, M., Chandra,
T., Fikes, A., and Gruber, R. E. (2008). Bigtable: A distributed storage system for
structured data. ACM Transactions on Computer Systems (TOCS), 26(2):4.
DeCandia, G., Hastorun, D., Jampani, M., Kakulapati, G., Lakshman, A., Pilchin, A.,
Sivasubramanian, S., Vosshall, P., and Vogels, W. (2007). Dynamo: amazons highly
available key-value store. In ACM SIGOPS Operating Systems Review, volume 41,
pages 205220. ACM.
Evans, E. (2009). NoSQL 2009. Disponvel em: http://blog.sym-link.com/
2009/05/12/nosql_2009.html. Acessado em: 03/06/2016.
Fowler, A. (2015). NoSQL for Dummies. John Wiley & Sons.
Gilbert, S. and Lynch, N. (2002). Brewers conjecture and the feasibility of consistent,
available, partition-tolerant web services. ACM SIGACT News, 33(2):5159.
Gray, J. et al. (1981). The transaction concept: Virtues and limitations. In VLDB, vo-
lume 81, pages 144154.
Hadjigeorgiou, C. et al. (2013). Rdbms vs nosql: Performance and scaling comparison.
Leavitt, N. (2010). Will nosql databases live up to their promise? Computer, 43(2):1214.
Loscio, B. F., OLIVEIRA, H. R. d., and PONTES, J. C. d. S. (2011). Nosql no desen-
volvimento de aplicaco es web colaborativas. VIII Simposio Brasileiro de Sistemas
Colaborativos, Brasil.
MongoDB (2016). Documentaca o MongoDB Disponvel em: http://api.
mongodb.com/java/3.0, Acessado em: 01/06/2016.
Nascimento, J. C. (2015). Introduca o ao NoSQL.
Rubinstein, I. S. and Good, N. (2013). Privacy by design: A counterfactual analysis of
google and facebook privacy incidents. Berkeley Tech. LJ, 28:1333.
Sadalage, P. J. and Fowler, M. (2012). NoSQL distilled: a brief guide to the emerging
world of polyglot persistence. Pearson Education.
Vieira, M. R., FIGUEIREDO, J. M. d., Liberatti, G., and Viebrantz, A. F. M. (2012). Ban-
cos de dados nosql: conceitos, ferramentas, linguagens e estudos de casos no contexto
de big data. Simposio Brasileiro de Bancos de Dados.