Escolar Documentos
Profissional Documentos
Cultura Documentos
27-05-S4-1-68840-Bancos de Dados NoSQL
27-05-S4-1-68840-Bancos de Dados NoSQL
Relacionais:Anlise Comparativa*
Ricardo W. Brito, Faculdade Farias Brito e Universidade de Fortaleza, ricardow@ffb.edu.br
I. INTRODUO
2
Outra caracterstica importante dos SGDBs relacionais
consiste na possibilidade do sistema se recuperar de forma
adequada de possveis falhas. O sistema tem a capacidade de
retornar ao ponto anterior falha ocorrida, garantindo que o
banco permanecer em um estado consistente.
Todos esses recursos ajudaram a manter os SGDBs
Relacionais em posio de destaque entre os mais diversos
tipos de ambientes computacionais, mas no impediram o
surgimento de certos problemas, principalmente devido ao
crescimento vertiginoso do volume de dados presentes nos
bancos de certas organizaes.
III. LIMITAES
Devido ao intenso crescimento do nmero de aplicaes,
solues, recursos e tudo o que se refere a sistemas
computacionais nas ltimas dcadas, o volume de dados
associados a tais tipos de sistemas tambm teve um ritmo de
crescimento acelerado.
Atualmente, o volume de dados de determinadas
organizaes, como o caso do Google, atinge o nvel de
petabytes, o que corresponde a 1015 bytes. Em cenrios nos
quais o gerenciamento de grande volume de dados tem se
mostrado problemtico, a utilizao de SGBDs relacionais, ou
em outras palavras do prprio Modelo Relacional, j no se
mostra to eficiente.
De um modo geral, os principais problemas encontrados
com a utilizao do Modelo Relacional estavam concentrados
na dificuldade em se conciliar tal modelo com a demanda por
escalabilidade cada vez mais frequente.
Como exemplo, tomemos uma determinada aplicao web
sendo executada sobre um SGBD relacional. Com o
crescimento do nmero de usurios, o sistema comea a ter
uma queda de performance. Para superar esse problema,
restam duas alternativas promover um upgrade no servidor ou
aumentar o nmero de servidores.
Tais opes no seriam suficientes se o nmero de usurios
continuar a crescer em ritmo intenso porque o problema passa
a se concentrar no prprio acesso base de dados. A soluo,
portanto, passa a ser escalar o banco de dados, distribuindo-o
em vrias mquinas. Tal abordagem possvel em um SGBD
relacional, porm, no realizada de maneira to simples.
Devido a sua natureza estruturada, os desenvolvedores
comearam a perceber a dificuldade em se organizar os dados
do Modelo Relacional em um sistema distribudo trabalhando
com particionamento de dados [8]. justamente nesse ponto
em que o foco das solues no-relacionais esto
concentradas.
3
escalvel, de alta performance e livre de esquemas, com vrias
caractersticas semelhantes ao CouchDB [15].
Todas essas solues apresentam certas caractersticas em
comum e outras particulares que os diferenciam. O captulo a
seguir descreve e categoriza as principais caractersticas dos
principais sistemas de banco de dados NoSQL.
4
O Escalonamento Vertical, que se caracteriza por sua
simplicidade, tem sido tradicionalmente mais indicado para as
camadas de banco de dados, enquanto o Escalonamento
Horizontal tem sido mais utilizado nas camadas das
aplicaes, principalmente para a Web.
O prximo passo consiste em tentar escalonar o prprio
banco de dados. A idia bsica distribuir o banco em vrias
mquinas, utilizando-se do particionamento dos dados. Esse
processo tambm conhecido como sharding. No entanto,
esta abordagem esbarra nas caractersticas do SGBD, dada a
dificuldade em se adaptar a toda a estrutura lgica do Modelo
Relacional soluo proposta. A Figura 4 ilustra essa
abordagem.
A dificuldade em se aplicar o processo de sharding em
bancos de dados relacionais est relacionada com alguns
fatores importantes. Primeiro, enquanto os dados de um SGBD
relacional obedecem o critrio de normalizao, o processo de
sharding se caracteriza justamente pelo inverso: a
desnormalizao dos dados. Dados que so utilizados em
conjunto so armazenados em conjunto.
concorrncia.
Os bancos de dados NoSQL foram especialmente
projetados para atender essas caractersticas de forma mais
natural. O MongoDB inclui um mdulo de sharding
automtico que permite a construo de um cluster de banco
de dados escalvel horizontalmente projetado para incorporar
novas mquinas de forma dinmica [15].
Nessa arquitetura, conforme ilustrado na Figura 5, um
cluster consiste de dois ou mais blocos de servidores
chamados de shards, um ou mais servidores de configurao
os quais armazenam os metadados do banco e qualquer
nmero de processos roteadores chamados de mongos atravs
dos quais os servidores da aplicao se conectam [15].
5
documentos e permitir a atualizao sobre uma dessas verses,
mantendo ainda a verso desatualizada. Assim, no h
necessidade de se bloquear os itens de dados. A Figura 6
ilustra o contraste entre o sistema de locking dos SGBDs
tradicionais e o MVCC do CouchDB [1].
VII. CONCLUSES
A deciso de se realizar uma mudana dessa natureza
optar por um abordagem NoSQL em contraste com uma
Escalonamento
Relacional
Possvel, mas complexo.
Devido
natureza
estruturada do modelo, a
adio de forma dinmica
e transparente de novos
ns no grid no
realizada de modo natural.
Consistncia
Disponibilidade
Dada a dificuldade de se
conseguir trabalhar de
forma eficiente com a
distribuio dos dados,
esse modelo pode no
suportar a demanda muito
grande de informaes do
banco.
NoSQL
Uma
das
principais
vantagens desse modelo.
Por no possuir nenhum
tipo de esquema prdefinido, o modelo possui
maior flexibilidade o que
favorece
a
incluso
transparente de outros
elementos.
Realizada
de
modo
eventual no modelo: s
garante que, se nenhuma
atualizao for realizada
sobre o item de dados,
todos os acessos a esse
item devolvero o ltimo
valor atualizado.
Outro fator fundamental
do sucesso desse modelo.
O
alto
grau
de
distribuio dos dados
propicia que um maior
nmero de solicitaes
aos dados seja atendida
por parte do sistema e que
o sistema fique menos
tempo no-disponvel.
6
uma linguagem de consulta, como o caso do SQL para os
SGBDs relacionais. No existe, em qualquer abordagem
noSQL, nada que se aproxime da simplicidade e
expressividade oferecida pelo SQL. Adicionalmente, perde-se
toda a funcionalidade oferecida pela linguagem, tais como
funes, rotinas, etc. Alm disso, deixa-se de utilizar a mais
simples restrio de integridade sobre o banco, o que pode
tornar a aplicao mais pesada.
Adicionalmente, deve-se ter em mente que a escalabilidade
em alto grau faz-se necessria apenas em bancos de grande
porte, nos quais a alta disponibilidade imprescindvel.
Utilizar uma soluo NoSQL para bancos de dados nos quais a
disponibilidade no seja um fator imprescindvel ainda uma
abordagem discutvel.
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]