1

ESTUDO DE CASO BANCO DE DADOS NOSQL

Davi Pistorello1
Fbio Giordani2
Kaie Guex3

Resumo: Os bancos de dados relacionais so amplamente utilizados como soluo de

armazenagem em diversos tipos de sistemas, mas devido ao crescimento das empresas e da
quantidade de dados que movimentam as novas aplicaes da web 2.0, novas abordagens
esto sendo desenvolvidas e empregadas, como o caso dos bancos de dados NoSQL. So
solues que vem sendo adotadas e consolidadas por grandes empresas de tecnologia para
solucionar os novos desafios que esto surgindo com o grande volume de dados movimentado
pelos sistemas da atualidade. Neste artigo ser feita uma anlise do que um banco de dados
NoSQL e sero demonstradas quais as necessidades que este modelo de banco de dados veio
atender no atual mercado de TI, conceituando-o junto a outros modelos existentes,
procurando saber qual sua real vantagem e desvantagem em relao a estes.

Palavras Chave: NoSQL, Escalabilidade, Banco de dados, web 2.0.

1 Introduo
O setor de tecnologia da informao, TI, sempre procurou atender as
demandas conforme a necessidade do seu tempo, demandas que ficam cada vez mais
complexas devido ao crescimento do uso da internet e as rpidas mudanas e inovaes deste
mercado. O ritmo da inovao no armazenamento de dados acelerou significativamente na
ltima dcada, e com isso as ferramentas para gerenciamento tambm precisaram ser
repensadas sobre o desempenho do armazenamento e controle sobre o acesso aos dados. A
1

Aluno do Curso de Tecnlogo em Anlise e Desenvolvimento de Sistemas

Aluno do Curso de Tecnlogo em Anlise e Desenvolvimento de Sistemas
3
Aluno do Curso de Tecnlogo em Segurana da Informao
2

abordagem mais inteligente no gerenciamento de armazenamento de grandes dados inclui

um conjunto de ferramentas, servios, software e hardware. Grandes empresas como o
Twitter j relataram problemas em administrar sua grande quantidade de dados e a seu
constante crescimento. Para lidar com este problema a soluo adotada em foi migrar seu
banco dados relacional para um banco de dados no-relacional, o NoSQL (Not Only SQL), no
caso do Twitter foi selecionado o banco de dados Cassandra, que promete escalabilidade, alta
disponibilidade, sem comprometer o desempenho. O Cassandra inicialmente foi criado pelo
Facebook, que abriu seu cdigo-fonte para a comunidade em 2008, e de acordo com o
engenheiro Avinash Lakshman [1] tem o poder de escrever 2500 vezes mais rpido em um
grande banco de dados de 50 Gb do que o MySQL.
O NoSQL aparece como uma soluo para atender esta necessidade iminente de
processamento de grandes montantes de dados que as empresas esto achando custosas
realizar com um banco de dados relacional. As grandes preocupaes com os dados criaram
uma oportunidade para que as pessoas pensem na hora sobre as suas necessidades de
armazenamento de dados, e algumas equipes de desenvolvimento podem ver que o uso de
um banco de dados NoSQL ajudam na sua produtividade, simplificando o acesso do banco de
dados, mesmo que eles no tenham a necessidade de escalar alm de uma nica mquina.

2 Referencial Terico

2.1 NoSQL
Apesar de estar em maior evidncia hoje, segundo Sadalage e Fowler o termo
NoSQL foi utilizado pela primeira vez em 1998 referenciado a um banco de dados de cdigo
aberto que no utilizava a linguagem SQL. Mais tarde em 2009 este termo ganhou mais fora
quando utilizado em uma conferncia de defensores de banco de dados no-relacionais em
San Francisco. A principal vantagem de um tipo de banco de dados no relacional que,
diferente da abordagem tradicional, eles lidam bem com dados desestruturados, tais como emails, dados multimdia e dados provenientes de mdias sociais (Leavit, 2010).

Os bancos de dados, antes o hierrquico e o de rede, at chegarmos ao banco de

dados mantido pelas relaes entre as tabelas o modelo relacional, no foram projetados para
funcionar de forma eficiente em clusters. Desta maneira, procurando atender necessidade
das grandes empresas, desenvolvedores de bancos de dados passaram a pensar novas
estratgias de armazenamento, estratgias essas que os desprenderiam de trabalhar nas
regras que o modelo relacional impunha.
O desenvolvimento prprio comea, segundo Levitt, principalmente em empresas
da web 2.0, gigantes como a Google e Amazon foram pioneiras, criando bancos de dados
NoSQL para trabalharem com sua enorme quantidade de dados, chamados de BigTable e
DynamoDB. NoSQL, no se define a um tipo banco de dados de fato, mas a uma caracterstica
comum, segundo Fowler 2012:
a) No utilizam o modelo relacional nem a linguagem SQL;
b) So de cdigo aberto (Open source);
c) Desenhados para utilizao em grandes cluster;
d) Baseados nas necessidades da web 2.0;
e) No existe um esquema, permitindo que campos possam ser adicionados a
qualquer registro. Ausncia de esquema ou esquema flexvel;
f) Suporte replicao nativo;
g) Acesso via APIs simples.

2.2 Tipos NoSQL

As categorias nas quais o NoSQL pode ser agrupado so definidas como chavevalor, orientado a colunas, orientado a documentos e orientado a grafos.
2.2.1 Chave-valor
Podendo tambm ser definida como key-value ou tabela de hash, essa categoria
conhecida como sendo um modelo de fcil implementao, uma vez que os dados sero

armazenados e consultados utilizando-se de chaves hash, como definido no conceito

dicionrio ou mapa de dados (DE DIANA e GEROSA, 2010).
Esse modelo permite visualizar o banco de dados em tabelas hash. Utilizando-se
da sua caracterstica, simplicidade, o banco acaba por ser composto por inmeras chaves,
onde cada uma delas est associada a um valor nico.
Como exemplo de banco de dados desta categoria de NoSQL o DynamoDB acaba
sendo o mais difundido, pois alm de ser fornecido como alternativa de armazenamento de
dados pela Amazon, esse foi utilizado com base para o desenvolvimento do Cassandra.
Segundo afirma Strauch (2011), o DynamoDB foi criado para ser um sistema de
consistncia eventual, ou seja, quando uma operao for executada, o retorno da operao
acontece antes de todos os ns serem atualizados, ocasionando que leituras posteriores
possam retornar verses diferentes dos dados.

2.2.2 Orientado a colunas

Comumentemente relacionado ao tipo de armazenamento definido por Chang
(2006) em "BigTable: A distributed Storage System for Structured data", vrios projetos alm
do prprio BigTable utilizam este conceito de bancos de dados, que suportam um grande
nmero de colunas por linha e permitem buscas mais geis nos valores das colunas. Estas por
sua vez, podem possuir valores baseados em listas, sub colunas ou outras linhas com colunas.
Nesse modelo, a indexao dos dados efetuada pela tripla formada pela linha,
coluna e data/hora. Para identificao, tanto a linha quanto a coluna so identificadas por
chaves e o timestamp, um diferenciador entre as verses dos dados, segundo Lscio, De
Oliveira e Pontes (2011).
Criado pela Google em 2004, o BigTable, foi uma das implementaes pioneiras
de um sistema no relacional objetivando a promoo de uma maior escalabilidade e
disponibilidade (BRITO, 2010), contudo este modelo no suporta unies, fazendo-se
necessria a tratativa de relacionamentos na aplicao e no em nvel de banco de dados
como ocorre nos sistemas relacionais.

2.2.3 Orientado a documentos

Na categoria de NoSQL orientado a documentos, cada documento
implementado como um objeto com um identificador nico e possui um conjunto de campos.
Os documentos tm como caracterstica a flexibilidade de seu esquema (definio),
permitindo assim que cada documento possa possuir seu prprio conjunto de campos sem
que seja seguido rigidamente um padro de tabelas estruturadas (LSCIO, DE OLIVEIRA e
PONTES, 2011). Com esta abordagem, os desenvolvedores podem adicionar quantos campos
se fizerem necessrios e de quaisquer tipos disponveis, sem restries estruturais.
O CouchDB, que desde 2008 pertence Apache Software Foundation, um dos
exemplos de banco de dados desta categoria. Uma caracterstica interessante que o controle
de concorrncia dos dados feito utilizando identificadores de sequncia para cada uma das
verses do documento. Quando este alterado por outro usurio desde a sua ltima leitura,
a aplicao notificada e por sua vez combina ou descarta as alteraes e por fim, aps as
alteraes serem confirmadas os dados so gravados.

2.2.4 Orientado a grafos

O modelo de grafos possui trs elementos bsicos: os vrtices dos grafos (ns), as
arestas (relacionamentos) e os atributos (propriedades dos ns e dos relacionamentos)
(LSCIO, DE OLIVEIRA e PONTES, 2011).
A vantagem da utilizao deste modelo se d ao aplic-lo em consultas mais
complexas na extrao de dados por parte do usurio. Ao se comparar esse com o modelo
conceitual onde estas pesquisas exigiriam, em grande parte, uma melhor implementao da
aplicao que poderia ocasionar perda de desempenho, a orientao a grafos resultaria em
melhores resultados com relao ao tempo de retorno dessas informaes.
OrientDB um dos principais bancos de dados de NoSQL desta categoria.
Conforme definido pela prpria Orient Technologies LTD: um banco open source, escrito em
Java e mistura funcionalidade dos modelos orientados a documento e orientados a grafos e

permite a utilizao com schema rgido quanto flexvel, dando tambm suporte a SQL, que
permite a migrao de programadores acostumados com o modelo relacional [2].
Na figura encontram-se exemplos de bancos de dados conforme os modeles descritos:

2.3 NoSQL x Relacionais

De acordo com Elmasri e Navathe (2006), bancos de dados Relacionais baseiamse no conceito de entidade e relacionamento, onde todos os dados so armazenados em
tabelas e separados de forma nica tentando diminuir ao mximo a redundncia. A
informao criada pelo conjunto dos dados e a que entram as relaes entre as tabelas.
As caractersticas mais marcantes deste modelo so: Tabelas, hierarquia, esquema definido,
mnima redundncia, entidades, relacionamentos e transaes ACID (Atomicity, Consistency,
Isolation e Durability em ingls).

a) A Atomicidade: Garante que as transaes sejam atmicas (indivisveis). A

transao ser executada totalmente ou no ser executada.
b) C Consistncia: Garante que o banco de dados passar de uma forma consistente
para outra forma consistente.
c) I Isolamento: A propriedade de isolamento garante que a transao no ser
interferida por nenhuma outra transao concorrente.
d) D Durabilidade: A propriedade de durabilidade garante que o que foi salvo, no
ser mais perdido.

Bancos de dados NoSQL abrem mo destas propriedades, ganhando em

flexibilidade, disponibilidade, desempenho e menor tempo de resposta a consultas, valendose da abordagem BASE (Basically Available, Soft state e Eventual consistency em ingls) [3].

a) BA (Basically Available) Basicamente Disponvel Prioridade na disponibilidade

dos dados.
b) S - (Soft-State) Estado leve No precisa ser consistente o tempo todo.
c) E (Eventually Consistent) Eventualmente Consistente - torna-se consistente no
momento devido.

Ippolito (apud STRAUCH, 2011, p. 32) resume a propriedade em: uma aplicao
funciona basicamente todo o tempo (disponibilidade bsica), no necessita ser consistente
todo o tempo (estado leve), mas ter um estado consistente eventual (consistncia
eventual).
Tal ideia se baseia no Teorema de Eric Brewer conhecido como Teorema CAP
(Consistency, Availability e Partition Tolerance), o qual afirma que impossvel para um
sistema

computacional

distribudo

garantir,

de

forma

simultnea,

consistncia,

disponibilidade e tolerncia ao particionamento. Segundo esse teorema, um sistema

distribudo pode garantir apenas duas dessas trs caractersticas simultaneamente. (Leite,
2010)

O teorema CAP em portugus significa: consistncia, disponibilidade e tolerncia

ao particionamento (no quadro representado pelo escalonamento) em uma comparao com
o banco de dados relacional (Brito, 2010 p.5):

Segundo Padalage e Fowler, diferentes aplicaes tm diferentes necessidades

estruturais e de desempenho, por isso, sabendo que nem todos os dados podem ser
estruturados, os tipos de banco de dados NoSQL cresceram nos ltimos anos.

Na Tabela 1 encontram-se comparaes complementares entre os modelos.

Tipos

BANCOS DE DADOS SQL

BANCOS DE DADOS NOSQL

Um tipo (banco de dados SQL) com

Muitos tipos diferentes,

pequenas variaes

incluindo chavevalor, orientados a documentos,

orientado a grafos e etc.

Histria de

Desenvolvido em 1970 para lidar

Desenvolvimento com a primeira onda de aplicaes

de armazenamento de dados

Desenvolvido em 2000 para

lidar com as limitaes dos
bancos de dados SQL,
particularmente em matria de

escala, replicao e
armazenamento de dados no
estruturados.
Exemplos

MySQL, Postgres, Oracle Database

MongoDB, Cassandra, HBase,

Neo4j

Modelo de

Os registros individuais (Ex:

Varia com base no tipo de banco

Armazenamento

empregados) so armazenados

de dados. Por exemplo,

de Dados

como linhas em tabelas, com cada

armazenagens chave-valor

coluna armazenando uma parte

funcionam de forma semelhante

especfica de dados sobre esse

aos bancos de dados SQL, mas

registro (Ex: gerente, setor,

tem apenas duas colunas (key

etc.), bem como uma

e value), com informaes

planilha. Tipos de dados separados

mais complexas, por vezes,

so armazenadas em tabelas

armazenados dentro das

separadas, e depois juntaram-se

colunas "valor". Bancos de

quando as consultas mais

dados documentais acabam

complexas so executadas. Por

com o modelo de tabela-e-linha

exemplo, "escritrios" pode ser

por completo, armazenam todos

armazenado em uma tabela, e

os dados relevantes juntos em

"empregados" em outra. Quando

um nico "documento" em

um usurio quer encontrar o

JSON, XML ou outro formato,

endereo de trabalho de um

que pode agrupar valores

empregado, o motor de banco de

hierarquicamente.

dados se junta ao "empregado" e

"escritrio" mesas em conjunto
para obter todas as informaes
necessrias.

10

Esquemas

Estrutura e tipos de dados so

Tipicamente dinmica. Os

determinados com

registros podem adicionar novas

antecedncia. Para armazenar

informaes em tempo real, e

informaes sobre um novo item

ao contrrio de linhas da tabela

de dado, toda a base de dados tem

SQL, dados diferentes podem

de ser alterada, tempo durante o

ser armazenados juntos

qual a base de dados tem de ser

conforme necessrio. Para

colocada no modo offline.

alguns bancos de dados (por

exemplo, column-family), um
pouco mais desafiador para
adicionar novos campos
dinamicamente.

Escalabilidade

Vertical, ou seja, um nico servidor

Horizontal, significa que um

deve ficar mais poderoso, a fim de

administrador de banco de

lidar com o aumento da

dados pode simplesmente

demanda. possvel espalhar

adicionar mais servidores ou

bancos de dados SQL ao longo de

instncias de nuvem. O banco

muitos servidores, mas geralmente

de dados espalha

uma significativa engenharia

automaticamente dados entre

adicional necessria.

servidores conforme se faz

necessrio.

Modelo de

Mix de cdigo-fonte aberto (por

Open source

Desenvolvimento exemplo, Postgres, MySQL) e de

cdigo fechado (por exemplo,
banco de dados Oracle)
Suporta

Sim, as atualizaes podem ser

Em determinadas circunstncias

Transaes

configuradas para completar

e em determinados nveis (por

totalmente ou no

exemplo, nvel de documento

vs. nvel de banco de dados)

11

Manipulao de

Linguagem especfica utilizando

Atravs de APIs orientadas a

Dados

SELECT, INSERT e UPDATE. Ex:

objeto

SELECT campos FROM tabela

WHERE ...
Consistncia

Pode ser configurado para uma

Depende do produto. Alguns

forte consistncia

fornecem consistncia forte (por

exemplo, MongoDB), enquanto
outros oferecem consistncia
eventual (por exemplo,
Cassandra)
Tabela 1

2.4 Principais aplicaes (cases)

Os principais utilizadores do NoSQL so empresas que processam uma enorme
quantidade de dados e esses dados devem estar acessveis de forma rpida. Como exemplo
disso, pode ser citado o caso do Twitter. Em 2008, enquanto ainda utilizava o PostgreSQL, o
site que funciona como rede social ficou 84 horas for do ar. Em 2009, aps a utilizao do
Cassandra, esse tempo foi sensivelmente reduzido para 23 horas e 45 minutos [4].
Outros, exemplos de empresas que adotaram o modelo NoSQL so:
Empresa

Banco de Dados

Bigtable

Google

Dynamo

Amazon

Hadoop

Yahoo

Cassandra

Facebook, Digg, Twitter, IBM, Netflix

Voldemort

LinkedIn

MongoDB

Engine Yard

12

3 Metodologia
O desenvolvimento deste artigo foi realizado atravs coleta de dados em livros,
pesquisas acadmicas e visitas em portais de tecnologia em busca de dados que mostrassem
a real utilizao e os detalhes de como o NoSQL est presente nas empresas de web 2.0,
detalhes de onde e como esto sendo utilizados nessas organizaes. Aps a coleta destes
dados buscamos identificar quais as caractersticas e vantagens que esse novo conceito de
armazenamento de dados em larga escala tem proporcionado para empresas como Google,
Amazon, Twitter e outras grandes da tecnologia atual.

4 Consideraes Finais
De acordo com os apontamentos anteriores, percebe-se que as solues NoSQL,
mesmo que empregadas por gigantes da tecnologia como a Google, no vieram substituir as
relacionais, que permanecem como principal opo para aplicaes consideradas crticas, e
sim suprir novas demandas que surgiram com as inovaes da Web 2.0.
Aplicaes que movimentam uma massa de dados gigantesca, onde em alguns
casos pode passar de 15 Terabytes gerados diariamente, como o caso do Facebook [3],
clamavam por alternativas que viabilizassem a escalabilidade, esquema flexvel, alto
desempenho e alta disponibilidade, tornando o gerenciamento de seus dados muito mais
eficiente, mesmo que para isso tenham de se submeter a possiblidade de nem sempre ser
possvel garantir que os dados estejam consistentes e de que haja um controle na
concorrncia, dentre outras caractersticas dos banco de dados tradicionais.
Entre perdas e ganhos, conclui-se que so solues diferentes para problemas
especficos, cabe aos desenvolvedores e projetistas mensurarem os pros e contras de cada
soluo para cada tipo de problema.

13

5 Referencial Terico
Pramod J Sadalage, Martin Fowler, NoSQL distilled : a brief guide to the emerging world of
polyglot persistence / Crawfordsville, Indiana. August 2012
Leavit, N. Will NoSQL Databases Live Up to Their Promise? 2010. Computer, 12. ISSN 00189162
BRITO, R. W. Bancos de Dados NoSQL x SGBDs Relacionais:Anlise Comparativa. InfoBrasil,
2010.
Disponvel
em:
http://www.infobrasil.inf.br/userfiles/27-05-S4-1-68840Bancos%20de%20Dados%20NoSQL.pdf . Acessado em: 15 out. 2014
LEITE, Gleidson Sobreira. Anlise Comparativa do Teorema CAP Entre Bancos de Dados
NoSQL e Bancos de Dados Relacionais. 2010. 49 p. Monografia (Bacharel em Cincias da
Computao) Faculdade Farias Brito, Fortaleza.
ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 5. ed. [S.l.]: Addison Wesley, 2006.
Acesso em: 21 maio 2012.
CHANG, F; Dean, J; GHEMAWATT, S; HSIEH, W. C. B;, DEBORAH A. W. M; CHANDRA, T; FIKES,
A GRUBER, R. E. Bigtable: A Distributed Storage System for Structured Data, 2006 - OSDI '06
Proceedings of the 7th USENIX Symposium on Operating Systems Design and Implementation
- Volume 7
DE DIANA, M.; GEROSA, M. A. NOSQL na Web 2.0: Um Estudo Comparativo de Bancos NoRelacionais para Armazenamento de Dados na Web 2.0. Workshop de Teses e Dissertaes
em Banco de Dados. Belo Horizonte: [s.n.]. 2010.
LSCIO, B. F.; DE OLIVEIRA, H. R.; PONTES, J. C. D. S. NoSQL no desenvolvimento de aplicaes
Web colaborativas. Simpsio Brasileiro de Sistemas Colaborativos, Paraty, ago. 2011.
Disponvel em: http://www.addlabs.uff.br/sbsc_site/SBSC2011_NoSQL.pdf Acessado em: 17
out 2014.
STRAUCH, C. NoSQL Databases. iiWAS '11 Proceedings of the 13th International Conference
on Information Integration and Web-based Applications and Services, Nova Iorque, dez.
2011. 278-283. Disponvel em: http://dl.acm.org/citation.cfm?id=2095583 Acessado em: 10
out. 2014.
[1] http://www.computerworld.com/article/2526317/database-administration/no-to-sql-anti-database-movement-gains-steam.html
[2] ORIENTDB.Disponvel em: https://github.com/orientechnologies/orientdb/ Acesso em:
05 out. 2014.
[3] FHH: Facebook, Hadoop, and Hive. 2009. http://www.dbms2.com/2009/05/11/facebookhadoop-and-hive/

14

[4] Twitter growth prompts switch from MySQL to 'NoSQL' database.

http://www.computerworld.com/s/article/9161078/Twitter_growth_prompts_switch_from
_MySQL_to_NoSQL_database. Acessado em 14/05/2010.