Comparando o NoSQL ao modelo relacional

08/04/2015
Comparando o NoSQL ao modelo relacional
Buscar
código fonte
comentários
post favorito (9)
SQL Magazine 123 ­ Índice
Comparando o NoSQL ao
modelo relacional
Conheça nesse artigo os benefícios e dificuldades no uso do
NoSQL em comparação com o modelo de banco de dados
relacionais.
0
Gostei (12)
0
Curtir
0
(0)
Fique por dentro
O tradicional modelo relacional é o tipo de banco de dados mais utilizado nas
últimas décadas. Porém, há um crescimento cada vez mais intenso do volume de
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
1/29
08/04/2015
Comparando o NoSQL ao modelo relacional
dados na era da Big Data, redes sociais e computação na nuvem, e certos fatores
limitantes têm propiciado o surgimento de modelos alternativos de banco de
dados.
O NoSQL vem ganhando espaço no mercado e se tornando uma opção que atende
aos requisitos do ambiente de computação distribuída em larga escala, permitindo
escalabilidade, disponibilidade, alto desempenho e confiabilidade. Este artigo tem
como objetivo fornecer uma visão geral das soluções de banco de dados NoSQL
modernas, abordar suas principais características, mostrar suas principais
diferenças com relação aos bancos de dados relacionais e apresentar um estudo
de caso de uma destas soluções.
Por décadas, os bancos de dados relacionais têm sido a escolha padrão para
persistência de dados corporativos. No entanto, as grandes empresas e aplicações
web estão mudando ao longo dos últimos anos.
Com o aumento da quantidade e do fluxo de informações e a certeza de que sempre
haverá mais dados para armazenar, o tradicional modelo relacional começa a sofrer
limitações de escalabilidade.
Neste cenário surge uma nova geração de banco de dados, não­relacional, como
uma maneira de lidar com o crescente volume de dados. O NoSQL (Not only SQL)
atende aos requisitos do ambiente de computação distribuída em larga escala, o que
permite escalabilidade, alta disponibilidade, alto desempenho e confiabilidade.
A grande motivação para o NoSQL é resolver o problema de escalabilidade dos
bancos tradicionais. Contudo, se faz necessário analisar todas as suas características
para se ter uma visão geral de seus prós e contras quando comparado ao modelo
relacional.
Este artigo fornecerá uma visão geral sobre o modelo relacional de banco de dados,
suas limitações e as soluções do NoSQL como alternativa a este modelo de banco.
Esta análise irá abordar os principais recursos e discutir os desafios da tecnologia
NoSQL, identificando quais benefícios e dificuldades esta tecnologia traz para a
solução do grande volume de dados processados atualmente.
Além disso, será apresentado, através de um estudo de caso, algumas das
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
2/29
08/04/2015
Comparando o NoSQL ao modelo relacional
diferenças identificadas entre os dois modelos.
SGBDs Relacionais
O banco de dados no modelo relacional foi proposto por Edgar Codd, um pesquisador
da IBM, em torno de 1970. Desde então se tornou o modelo de banco de dados
dominante para aplicações comerciais. Hoje, há muitos Sistemas de Gerenciamento
de Banco de Dados (SGBDs), como Oracle, IBM DB2 e Microsoft SQL Server, MySQL,
PostgreSQL, entre outros.
Um banco de dados relacional organiza os dados em tabelas ou relações. Uma tabela
é composta de linhas e colunas. As linhas também são chamadas de registros ou
tuplas. As colunas também são chamadas de campo ou atributo. Uma tabela de
banco de dados é semelhante a uma folha de cálculo.
No entanto, as relações que podem ser criadas entre as mesmas possibilitam a um
banco de dados relacional armazenar eficientemente uma quantidade de dados e,
efetivamente, recuperar os dados selecionados.
Outra característica importante deste modelo é o uso de elementos para garantir a
integridade dos dados. As restrições mais comuns são as chaves primárias e as
estrangeiras. O termo chave primária é utilizado para identificar o atributo que foi
escolhido pelo projetista do banco para identificar unicamente os registros que são
armazenados em uma determinada tabela.
Nenhum registro pode ter o mesmo valor no campo chave primária de uma
determinada tabela do banco de dados, por isso os atributos chaves devem ser
selecionados com muito cuidado. Já a chave estrangeira transforma o valor de um
atributo dependente do valor existente em outro atributo, normalmente de outra
tabela, criando uma relação de dependência entre atributos de tabelas distintas.
As chaves são muito utilizadas em bancos de dados relacionais, inclusive para a
criação de outros componentes como os índices, que são usados para melhorar o
desempenho de consultas no banco.
Para projetar corretamente as tabelas de um banco de dados relacional temos um
conjunto de orientações que ajudam a reduzir a redundância e chance de corrupção
de dados. É o que chamamos de normalização. As regras de normalização são
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
3/29
08/04/2015
Comparando o NoSQL ao modelo relacional
projetadas para evitar anomalias de atualização e inconsistências de dados, e ao
mesmo tempo para permitir uma recuperação mais fácil de informações.
A linguagem chamada SQL foi desenvolvida para trabalhar com bancos de dados
relacionais. Inspirada na álgebra relacional e desenvolvida pela IBM, o SQL é uma
linguagem declarativa para banco de dados.
A facilidade de uso e simplicidade de expressão fez com que o SQL se transformasse
na linguagem de consulta de dados mais usada no mundo, o que ajudou a consolidar
o modelo relacional de banco de dados.
Outro conceito importante para bancos de dados são as propriedades ACID. A sigla
significa Atomicidade, Consistência, Isolamento e Durabilidade. As propriedades ACID
de um SGBD permitem o compartilhamento seguro de dados, oferecendo otimização
de consultas, recuperação de falhas, validação, controle de concorrência e
verificação de integridade dos dados.
Todas essas características e recursos deram ao Modelo Relacional de banco de
dados uma posição de destaque e predominância nos diversos ambientes
computacionais. No entanto, a sua complexidade estrutural fez com que surgissem
problemas, principalmente relacionados ao crescente volume de dados que as
empresas necessitam armazenar atualmente.
Limitações do Modelo Relacional
O Walmart, um gigante do varejo, trabalha com mais de 1 milhão de transações de
clientes por hora, alimentando bancos de dados estimados em mais de 2,5
petabytes. Já o Facebook, possui em seu banco cerca de 40 bilhões de fotos. Estes
são exemplos que mostram que o mundo contém enorme quantidade de informação
digital, e que este volume de informações e dados está ficando cada vez maior
rapidamente.
Este é um dos principais problemas encontrados com a utilização do Modelo
Relacional, a dificuldade em se usar esse modelo com uma demanda por
escalabilidade cada vez maior. As aplicações web que usam banco de dados
relacional vêm sofrendo com o grande volume de dados e problemas de
desempenho.
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
4/29
08/04/2015
Comparando o NoSQL ao modelo relacional
Para solucionar tais problemas de escalabilidade, geralmente se recorre a duas
alternativas: o aumento do número de servidores (escalonamento horizontal) ou a
realização de um upgrade no servidor (escalonamento vertical).
Isto não é o suficiente caso o volume de informações continue a crescer em ritmo
acelerado. Com o constante crescimento dos dados, a solução passa a ser escalar o
banco de dados em sistemas distribuídos.
Entretanto, por causa da natureza estruturada do modelo relacional, os
administradores de bancos de dados perceberam uma dificuldade em organizar as
informações em sistemas distribuídos, particionando os dados em máquinas
diferentes. Manusear tabelas em diferentes servidores é muito difícil e problemático.
Por conta disso, começam a surgir as soluções não relacionais.
NoSQL
Os desenvolvedores começaram a pensar em um modelo alternativo para modelar as
bases de dados frente às dificuldades encontradas no modelo relacional. As soluções
propostas para a melhoria de desempenho visavam evitar a rígida e tradicional
estrutura usada no modelo relacional.
O objetivo dos projetistas de banco de dados das grandes organizações era
desenvolver uma nova maneira de armazenar as informações flexibilizando o banco
de dados para as características particulares de sua empresa.
Esta flexibilidade é fundamental para atender aos requisitos dos sistemas
distribuídos em larga escala, permitindo escalabilidade e alta disponibilidade para as
aplicações que gerenciam grande quantidade de dados.
Assim surgiu o NoSQL, termo usado primeiramente em 1998, por Carlo Strozzi, como
um nome para um banco de dados relacional leve, de código aberto, que não possuía
interface SQL.
Em 2009, este nome foi novamente usado em um evento para descrever um modelo
de banco que conseguia ajustar os dados, principalmente quando o modelo relacional
não atendia aos requisitos pretendidos. É um movimento totalmente adepto ao
código aberto.
A intenção do NoSQL não é substituir o tradicional modelo relacional, e sim ser uma
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
5/29
08/04/2015
Comparando o NoSQL ao modelo relacional
alternativa para as empresas que necessitam de um modelo de banco de dados mais
flexível para suportar o seu volume de dados.
A constante tendência de computação em nuvem e o crescimento das redes sociais
são fatores importantes que levam ao desenvolvimento de armazenamento NoSQL.
Apesar da existência de muitos bancos de dados NoSQL, o movimento ganhou força
quando grandes empresas da tecnologia passaram a usar suas próprias
implementações a fim de fornecer serviços para seus sistemas distribuídos.
Buscando atender suas necessidades de armazenamento, em 2004, o Google criou o
BigTable.
Na sequência, buscando também a alta disponibilidade, a Amazon lançou o Dynamo.
Em 2008, o Facebook desenvolveu o Cassandra para tratar o grande volume de
dados, e este se mostrou tão eficiente que em 2010 o Twitter deixou o MySQL de
lado para usá­lo.
Outras soluções lançadas são o Apache CouchDB e o MongoDB, que são banco de
dados orientados a documentos e com características bem semelhantes, como alta
performance e escaláveis, projetados para suportar sistemas distribuídos em larga
escala.
Todos os bancos citados são considerados NoSQL, possuem características
semelhantes, mas também possuem particularidades que os diferenciam. A próxima
seção aborda justamente os diferentes modelos de bancos de dados NoSQL,
mostrando suas características.
3.1 Modelos de BD NoSQL
Mais e mais organizações têm adotado soluções NoSQL para apoiar seus projetos.
Estas soluções apresentam características em comum, como uma maior
escalabilidade e alta disponibilidade, mas também apresentam diversas
singularidades. Os bancos de dados NoSQL são subdivididos pela maneira como
armazenam as informações. Os principais tipos são: Armazenamento Chave­Valor
(Key/Value), Documento, Coluna e Grafo.
A solução chave­valor armazena qualquer coisa como pares de valores­chave, o que
implica valores armazenados recuperados por chaves únicas. São capazes de
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
6/29
08/04/2015
Comparando o NoSQL ao modelo relacional
armazenar grandes quantidades de dados e, no entanto, mantêm o acesso simples
por uma chave primária.
Este tipo de armazenamento funciona bem para listas, como as categorias de
produtos, os atributos de cada produto, carrinho de compras, conteúdos ou valores
individuais, etc.
Por conta disto, o Amazon Dynamo é uma solução que adota este modelo. Os dados
deste sistema são particionados e replicados usando hashing consistente, a fim de
fornecer a escalabilidade e disponibilidade.
O segundo modelo de solução muda o tradicional paradigma de orientação a
registros (ou tuplas) para orientação a colunas (ou atributos). Aqui os dados seguem
uma indexação tripla (linha, coluna e timestamp), onde as linhas e as colunas são
identificadas por chaves e o timestamp possibilita a diferenciação de múltiplas
versões de um mesmo dado.
Alguns modelos deste tipo de armazenamento possuem colunas (registros que
possuem nome, valor e timestamp), famílias de colunas (uma coleção de colunas,
equivalente a uma tabela do Modelo Relacional) e super­colunas (formadas por
arrays de colunas).
O conceito de família de colunas pode ser observado na Figura 1, onde
primeiroNome e sobrenome são colunas pertencentes à família de colunas
denominada nome e as colunas endereço e cidade pertencem à família local. Dois
grandes exemplos de sistemas orientados a coluna são o Cassandra e o BigTable.
Figura 1. Exemplo de modelo baseado em colunas
Já uma solução baseada em documento é um tipo de banco de dados que armazena
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
7/29
08/04/2015
Comparando o NoSQL ao modelo relacional
coleções de documentos. Os documentos são representados como objetos com um
único identificador e um conjunto de campos, que podem ser strings, listas ou
documentos aninhados. Como esta base de dados é semiestruturada e não possui
esquema, uma informação específica ou atributos podem ser adicionados a qualquer
campo sem que isso cause algum problema na base de dados.
Podemos observar um documento na Figura 2 com seus campos e atributos
associados. Comparado com o SQL, esta abordagem fornece flexibilidade e
extensibilidade. Como exemplos que usam este tipo de armazenamento tem­se o
MongoDB e o Apache CouchDB.
Figura 2. Exemplo de modelo baseado em documento
A quarta categoria (os banco de dados baseados em grafos) possui três
componentes básicos: os vértices (são os nós do grafo), as arestas (são os
relacionamentos entre os nós) e os atributos dos nós e relacionamentos. Os dados
são armazenados nos nós do grafo e as arestas representam o tipo de associação
entre eles.
Novas arestas podem ser adicionadas (ou as antigas removidas) a qualquer
momento, permitindo que relações 1­N (um para muitos) e N­N (muitos para muitos)
sejam expressas de forma fácil. Construções como amigos, seguidores, graus de
separação, listas são muito naturalmente acomodadas em bancos de dados do tipo
grafo.
A Figura 3 representa um exemplo de grafo de uma aplicação que possui
informações sobre locais visitados e locais onde pessoas moram. Comparado ao
modelo relacional, algumas consultas passam a ser bem mais simples e diretas por
conta dos relacionamentos existentes nos grafos.
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
8/29
08/04/2015
Comparando o NoSQL ao modelo relacional
No exemplo da figura temos três pessoas que são nós do grafo e estão conectados à
cidades que ou já visitaram ou moraram. Através da representação do grafo fica fácil
perceber que Maria e José já visitaram o Rio de Janeiro.
E que João já morou em Recife e Salvador. Um exemplo de banco de dados baseado
em grafo é o Neo4j, que é open­source e implementado em Java.
Figura 3. Exemplo de modelo baseado em grafo
É importante ressaltar que nenhum dos modelos apresentados deve ser considerado
superior ao outro, pois tudo depende da necessidade da aplicação. É importante que
os desenvolvedores conheçam os diversos modelos de solução para que seja
adotado aquele que mais se adequar ao que a aplicação ou empresa precisa. Isto
contribui para a diminuição do custo de criação do banco de dados, e com o aumento
do desempenho no processamento dos dados.
A Tabela 1 apresenta uma comparação dos modelos apresentados destacando suas
principais vantagens e desvantagens, e ainda citando seus principais exemplos e
suas disponibilidades.
Tipo
Vantagem
Desvantagem Exemplos
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
Disponibilidade
9/29
08/04/2015
Comparando o NoSQL ao modelo relacional
Amazon
Simplicidade
Chave/Valor e
escalabilidade
Falta recursos
O nível gratuito da AWS inclui 100
DynamoDB MB de armazenamento, 5 unidades
de capacidade de gravação e 10
mais
unidades de capacidade de leitura
avançados de
com o Amazon DynamoDB.
consulta
Disponível em:
http://aws.amazon.com/pt/dynamodb
Não é
MongoDB
adequado para
dados
Documento
Como a maioria das licenças de
software livre, permite seja usado,
CouchDB
modificado e distribuído por usuários.
Facilidade de
relacionais;
Pode­se adquirir o MongoDB em:
uso
Consulta
http://www.mongodb.org
limitada a
chaves e
e CouchDB:
índices
http://couchdb.apache.org
Google Big BigTable foi desenvolvida no Google
Table
em tem sido usado desde 2005 em
dezenas de serviços do Google. Uma
Cassandra
Coluna
Escalabilidade
e flexibilidade
versão de código aberto, HBase, foi
criado pelo Apache:
Complexidade
http://hbase.apache.org.
Já o Cassandra também pode ser
adquirido de forma gratuita:
http://cassandra.apache.org
Modelo de
Grafo
dados
Neo4j
Flexibilidade
poderoso e
Como os demais acima o Neo4j
também está disponível para
download em http://www.neo4j.org/
rápido
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
10/29
08/04/2015
Comparando o NoSQL ao modelo relacional
Tabela 1. Análise comparativa dos modelos de BD NoSQL.
Modelo Relacional x NoSQL
Ao se comparar os modelos em questão, uma grande diferença a se notar é que as
tecnologias relacionais têm esquemas rígidos, enquanto os modelos NoSQL são
schema­free, ou seja, sem esquema. O modelo relacional requer uma definição
estrita de um esquema antes de armazenar todos os dados em um banco de dados.
Alterar o esquema uma vez que os dados já estão inseridos é muito complicado e,
por isso, evitado. No entanto, isto é exatamente o oposto do comportamento
desejado na era “Big Data”, onde os desenvolvedores precisam constante e
rapidamente incorporar novos tipos de dados para enriquecer seus aplicativos.
Muitas coisas devem ser levadas em conta na hora de se escolher qual tipo de banco
de dados usar: NoSQL ou modelo relacional. Entretanto, três critérios são
considerados relevantes para esta escolha: escalonamento, consistência de dados e
disponibilidade. E é isto que será abordado a partir de agora.
Basicamente pelo fato de terem sido criados para essa finalidade, os bancos NoSQL
apresentam vantagens em relação aos SGBDs relacionais quando se trata de
escalonamento. O modelo NoSQL apresenta uma maior flexibilidade em sua estrutura
e se adaptada com maior facilidade a cenários em que o escalonamento é
necessário.
É possível tornar um banco de dados relacional mais escalável através da técnica de
escalonamento vertical, onde é feita uma atualização (upgrade) no servidor de
bancos de dados.
Porém, este escalonamento fica limitado à capacidade de uma única máquina. Já o
escalonamento horizontal é feito com o aumento da quantidade de servidores que
irão disponibilizar os dados paralelamente (Figura 4), facilitando o acesso aos dados
e garantindo que a queda de um servidor não seja um problema de disponibilidade
dos dados.
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
11/29
08/04/2015
Comparando o NoSQL ao modelo relacional
Figura 4. O uso do escalonamento horizontal
Outra característica a favor do NoSQL é o uso do sharding, que consiste em trabalhar
com o escalonamento horizontal, particionando e paralelizando seus dados em vários
servidores (Figura 5). Essa técnica é complexa para se usar em SGBDs relacionais
devido a toda a sua estrutura lógica e devido ao uso da desnormalização dos dados,
o contrário usado no modelo relacional.
O sharding traz benefícios, pois conjuntos de dados menores são mais fáceis de
serem acessados, atualizados e gerenciados. O maior benefício, em comparação ao
modelo relacional, é a otimização do grau de disponibilidade do sistema, pois como
já dito anteriormente, a queda de uma máquina não causaria a interrupção de todo o
sistema.
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
12/29
08/04/2015
Comparando o NoSQL ao modelo relacional
Figura 5. Técnica de sharding
O controle de concorrência também funciona de maneira distinta nos modelos em
questão. O modelo relacional utiliza bloqueios (locks) como garantia de que dois
usuários não atualizem o mesmo dado ao mesmo tempo. Já no modelo NoSQL são
usadas outras estratégias para permitir um maior grau de concorrência.
Alguns bancos NoSQL usam o MVCC (Multiversion Concurrency Control) ou Controle
de Concorrência Multi­versões. Nesta técnica, o acesso aos dados pode ser realizado
em paralelo.
Cada usuário que se conecta ao banco de dados visualiza uma cópia temporária do
banco de dados naquele instante. Qualquer atualização que esteja sendo feita em
determinado momento por um usuário não será vista pelos demais que estão
operando simultaneamente no banco de dados, até que a atualização tenha sido
concluída.
Quando se opta por usar um modelo NoSQL, há ganhos de performance, flexibilidade
e disponibilidade, mas há uma perda de consistência. Há um teorema na ciência da
computação, criado Eric Brewer, chamado Teorema CAP (Consistency, Availability e
Partition Tolerance) que diz ser impossível para um sistema distribuído garantir
consistência, disponibilidade e tolerância ao particionamento. De forma simultânea,
só é possível conseguir duas destas três características. Vejamos exemplos de
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
13/29
08/04/2015
Comparando o NoSQL ao modelo relacional
SGBDs na Figura 6 segundo o Teorema CAP.
Figura 6. Distribuição relativa de alguns bancos de dados quanto ao Teorema CAP
As soluções NoSQL seguem um paradigma denominado BASE (Basically Available,
Soft state, Eventual consistency). Este tem como características estar basicamente
disponível o tempo todo, estar em estado leve, ou seja, não sendo consistente o
tempo todo, e possuir uma consistência eventual, o sistema se torna consistente no
momento apropriado.
O modelo BASE é um contraste ao paradigma ACID (Atomicity, Consistency,
Isolation, Durability) comumente associado aos bancos de dados de modelo
relacional. Ao contrário do modelo ACID que promove uma segurança dos dados
forçando a consistência ao final de cada operação, o modelo BASE permite que o
banco de dados esteja em um estado eventualmente consistente.
A disponibilidade do modelo BASE está associada justamente ao fato de que a falha
de uma máquina do sistema não interrompe o sistema como um todo.
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
14/29
08/04/2015
Comparando o NoSQL ao modelo relacional
Para se analisar de forma mais rápida e comparativa, a Tabela 2 apresenta as
principais características de ambos os modelos discutidos aqui.
Escalonamento
Modelo Relacional
NoSQL
Possui sua natureza
É livre de esquemas, por isso
estruturada, e por conta disto o NoSQL possui uma maior
o escalonamento de bancos
flexibilidade e alta
tende a ser uma tarefa
escalabilidade, considerada
complexa.
uma das principais vantagens
desse modelo.
Consistência
Possui uma estrutura mais
A consistência nesse modelo
rígida e garante em suas
possui um caráter eventual,
transações a existência dessa o que não garante que uma
propriedade. As diversas
determinada atualização, em
regras deste modelo
um dado momento, seja
possibilitam uma maior
percebida por todos os nós.
rigidez quanto a garantia de
consistência dos dados,
sendo este o ponto mais
forte desse modelo.
Disponibilidade
Há uma dificuldade de se
Considerada outra das
trabalhar de forma eficiente
grandes vantagens do
com a distribuição de dados
modelo, essa propriedade,
por causa de sua natureza
junto com o alto grau de
estruturada, situações em
distribuição desse modelo,
que exigem uma maior
possibilita que o sistema
demanda de um sistema que
fique um menor período de
utilizem esse modelo podem
tempo não­disponível, assim
não ser bem suportadas por
como também permite que a
ele.
solicitação aos dados por um
número crescente de clientes
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
15/29
08/04/2015
Comparando o NoSQL ao modelo relacional
seja atendida.
Tolerância a
Por não terem sido
Trabalha de forma fácil e
Particionamento
construído com a finalidade
eficiente com a distribuição
de trabalhar com
de dados. Este modelo é
particionamento de dados,
capaz de suportar grandes
este modelo não possui um
demandas de dados assim
grau muito alto de tolerância
como possui alta tolerância
ao particionamento, cuja
ao particionamento dos
razão principal seria a
mesmos.
dificuldade de junções entre
as tabelas.
Tabela 2. Análise comparativa entre o Modelo Relacional e NoSQL.
A tabela nos mostra que o novo paradigma BASE usado pelos bancos de dados
NoSQL tem permitido uma melhor escalabilidade aos sistemas. A verificação contínua
da consistência de cada transação adiciona custos consideráveis para um sistema
que tem milhares de transações ocorrendo.
A consistência eventual promovida pelo modelo BASE dá às organizações a
capacidade de interagir com os clientes, de forma contínua, com a necessária
disponibilidade e tolerância a partição, mantendo baixos custos e o sistema rodando
sem interrupções. Sem dúvida seria excelente ter consistência completa o tempo
todo, mas é preciso haver compensações, e a consistência eventual permite o
desenvolvimento eficaz de sistemas que podem lidar com o aumento exponencial de
dados devido às redes sociais, computação em nuvem e outros projetos de Big Data.
Estudo de Caso ­ MongoDB
Para fins comparativos serão analisadas nesta seção algumas diferenças entre um
banco NoSQL, o MongoDB, e os bancos relacionais baseados em SQL. O MongoDB é
um banco de dados NoSQL criado em 2009 pela empresa 10gen, orientado a
documentos, altamente escalável, de alta performance e de código aberto. O
cofundador e diretor de tecnologia da 10gen define o MongoDB da seguinte forma: “O
MongoDB não foi concebido em um laboratório.
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
16/29
08/04/2015
Comparando o NoSQL ao modelo relacional
Nós construímos o MongoDB com base em nossas experiências na construção de
sistemas robustos de grande escala e alta disponibilidade. Não começamos do zero,
nós tentamos descobrir o que estava problemático, e solucionamos isso.
Assim, o que eu penso sobre MongoDB é que se você pegar o MySQL, e alterar o
modelo de dados do relacional para orientado a documento, você ganha uma grande
quantidade de recursos: documentos embarcados para melhorar velocidade,
facilidade de gerenciamento, desenvolvimento ágil com bancos de dados sem
“schema”, escalabilidade horizontal mais fácil, pois “joins” não são tão importantes.
Há muitas coisas que funcionam muito bem nos bancos de dados relacionais: índices,
consultas dinâmicas e atualizações, e nós não mudamos muito neste ponto. Por
exemplo, a maneira de projetar seus índices no MongoDB deve ser exatamente do
jeito que você faz isso no MySQL ou Oracle, você só ganha a opção de indexar um
campo embarcado”.
Como dito na seção de modelos de bancos de dados NoSQL, um banco orientado a
documentos não possui esquemas rígidos e estruturados, sendo possível que ocorra
uma atualização na estrutura do documento. Portanto, inserir novos campos no
documento não causa problemas na estrutura do banco.
Para um maior entendimento e fins comparativos, a Tabela 3 apresenta os diversos
conceitos e terminologia SQL, e a terminologia e conceitos correspondentes no
MongoDB.
MySQL
MongoDB
tabela
coleção
índice
índice
linha
documento BSON
coluna
campo
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
17/29
08/04/2015
Comparando o NoSQL ao modelo relacional
joins
documentos incorporados e vinculação
primary key
primary key
(Especifica qualquer combinação de colunas
(No MongoDB, a chave primária é definida
ou coluna única como chave primária)
automaticamente como campo _id)
group by
aggregation
Tabela 3. Comparativo de termos e conceitos entre MySQL e MongoDB.
O MongoDB faz uso de documentos com esquemas dinâmicos, ou seja, sem a
necessidade de que cada registro tenha a mesma estrutura. Estas estruturas são
chamadas de coleções (collections). Para isso, o MongoDB armazena os documentos
no estilo parecido com o JSON (Java Script Object Notation), chamado BSON (Binary
JSON). Exemplo:
// Um documento usado para representar um aluno
aluno1 = {nome: "Paulo", sobrenome:"Silva", idade:22, bairro:"Pituba"}
// Outro documento para representar um aluno na mesma coleção
aluno2={nome:"Lia”, sobrenome:"Sá", curso:"Direito", materias:['Civil', 'Penal']}
Pode­se ter registros diferentes um do outro dentro de uma mesma coleção. Parece
estranho este tipo de abordagem, mas no modelo relacional usamos isto o tempo
inteiro e de maneira ineficiente, com a formação de tabelas esparsas.
Estas são tabelas incompletas onde algumas colunas são sempre preenchidas e
outras nem sempre são usadas. Para ilustrar isto, observe a Tabela 4 que apresenta
registros da construção civil.
Código
Produto
Altura
Potência
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
Peso
Diâmetro
18/29
08/04/2015
Comparando o NoSQL ao modelo relacional
1
Britadeira
2
Cimento
3
Empilhadeira
4
Escada
5
Tubulação
300cv
100kg
15cv
300kg
3m
20cm
Tabela 4. Cadastro de produtos da construção civil em banco de dados modelo
relacional.
Neste exemplo há uma desvantagem no modelo relacional. Há colunas cujo valor é
preenchido apenas uma vez, como pode ser visto no exemplo das colunas Altura e
Diâmetro. Na construção das tabelas ao incluir colunas que são pouco utilizadas,
joga­se fora espaço de armazenamento e reduz­se o desempenho do sistema como
um todo. E ainda tratamos objetos diferentes como se fossem iguais, o que nem
sempre é uma boa prática. Abaixo o exemplo de como ficaria este cadastro de
produtos no modelo documental:
{codigo:1, produto:"Britadeira", potencia:"300cv", peso:"100kg"}
{codigo:2, produto:"Cimento"}
{codigo:3, produto:"Empilhadeira", potencia:"15cv", peso:"300kg"}
{codigo:4, produto:"Escada", altura:"3m"}
{codigo:5, produto:"Tubulação", diametro:"20cm"}
Portanto, o MongoDB por ser um banco de modelo documental evita o problema de
tabelas esparsas presente no modelo relacional, melhorando seu armazenamento e
desempenho.
Serão apresentados agora alguns comandos comuns usados no MongoDB. Voltando
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
19/29
08/04/2015
Comparando o NoSQL ao modelo relacional
ao primeiro exemplo de documento criado para alunos, observe como ficaria o
comando para salvar os alunos em uma coleção:
db.unifacs.save(aluno1)
db.unifacs.save(aluno2)
O comando acima salva os documentos aluno1 e aluno2 na coleção “unifacs”. É
possível acessar os dados de uma coleção através do comando find(), basicamente
ele vai percorrer todos os registros da coleção e retornar os documentos listados. No
exemplo dado o comando seria: db.unifacs.find(). E para apagar tudo que existe na
coleção: db.unifacs.remove().
Não é necessário que se crie uma coleção ou mesmo que se configure uma estrutura,
isso é feito automaticamente quando o primeiro registro é incluído. No entanto, é
possível usar o comando de criar uma coleção, e isto pode ser utilizado para pré­
atribuir espaço para uma coleção. Uma coleção de tamanho fixo usa o comando
“capped”, e vem a substituir automaticamente as entradas mais antigas quando
atinge seu tamanho máximo.
Todas as coleções limitadas e fixas devem especificar um tamanho máximo e
também podem especificar um número máximo de documentos. O MongoDB remove
os documentos antigos se uma coleção atinge o limite de tamanho máximo antes
que ele atinja a contagem máxima de documentos. Considere o seguinte exemplo:
db.createCollection ("unifacs", {capped: true, size: 5242880, max: 5000})
Este comando cria uma coleção nomeada de “unifacs” com uma dimensão máxima
de 5 megabytes e um máximo de 5000 documentos.
Para visualizar todas as coleções de um banco de dados MongoDB utiliza­se o
seguinte comando
db.getCollectionNames().
Enfim, há muitas diferenças entre os comandos usados no MongoDB e no MySQL. As
quatro operações básicas usadas para criação, consulta, atualização e destruição de
dados, conhecidas como CRUD (Create, Read, Update e Delete), apresentam
comandos bem distintos nos dois tipos de bancos em questão. A Tabela 5 compara
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
20/29
08/04/2015
Comparando o NoSQL ao modelo relacional
alguns comandos de CRUD em ambos os bancos.
MySQL
MongoDB
CREATE TABLE unifacs (
A coleção é criada implicitamente na primeira
id MEDIUMINT NOT NULL
AUTO_INCREMENT,
matricula Number,
nome Varchar(30),
idade Number,
PRIMARY KEY (id)
)
inserção de dados. O _id chave primária é
adicionada automaticamente se o campo _id não
é especificado.
db.unifacs.insert ({
matricula: 04217253,
nome: "Paulo",
idade: 22
})
Coleções não descrevem ou forçam a estrutura
dos seus documentos. No entanto, no nível do
documento, operações de update () podem
adicionar campos para documentos existentes
usando o operador $set e remover usando
$unset.
ALTER TABLE unifacs
db.unifacs.update (
ADD join_date DATETIME
{},
{$set: {join_date: new Date ()}},
{multi: true}
)
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
21/29
08/04/2015
Comparando o NoSQL ao modelo relacional
db.unifacs.update(
ALTER TABLE unifacs
{ },
DROP COLUMN join_date
{ $unset: { join_date: "" } },
{ multi: true }
)
db.unifacs.insert(
INSERT INTO unifacs (matricula, nome,
idade)
{ matricula: 032104211, nome: “Joana”, idade:
21 }
VALUES (032104211, “Joana”, 21)
)
SELECT * FROM unifacs
SELECT * FROM unifacs WHERE idade =
21
db.unifacs.find()
db.unifacs.find( { idade: 21 } )
SELECT * FROM unifacs WHERE nome =
“Joana”
db.unifacs.find( { nome: “Joana”, idade: 21 } )
AND idade = 21
SELECT * FROM unifacs WHERE idade >
db.unifacs.find( { age: { $gt: 20 } } )
20
db.users.count()
SELECT COUNT(*) FROM unifacs
ou
db.unifacs.find().count()
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
22/29
08/04/2015
Comparando o NoSQL ao modelo relacional
UPDATE unifacs SET status = “Aprovado”
db.unifacs.update( { nota: { $gt: 7 } }, {
WHERE nota > 7
$set: { status: “Aprovado” } }, { multi: true } )
UPDATE unifacs SET nota = nota + 1
db.unifacs.update( { status: "Aprovado" } , {
WHERE status = "Aprovado"
$inc: { nota: 1 } }, { multi: true } )
DELETE FROM unifacs WHERE status =
"Reprovado"
db.unifacs.remove( { status: "Reprovado" } )
Tabela 5. Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
É importante saber que cada documento de uma coleção no MongoDB tem um
tamanho máximo de 16MB, o que é mais do que suficiente para armazenar dados em
um documento. No entanto, o MongoDB ainda é capaz de armazenar arquivos no
banco de dados em uma coleção especifica, que é a coleção do tipo GridFS.
Ela é ideal para trabalhar com arquivos maiores de imagens, vídeo e áudio. O GridFS
divide o arquivo em partes ou pedaços e salva cada pedaço em um documento
separado. Quando você consulta um arquivo no GridFS, é preciso remontar os
pedaços conforme a necessidade.
O MongoDB atinge o objetivo de ser amigável para o desenvolvedor. Possui uma
documentação bem escrita para a maioria dos principais idiomas. Sua consulta
baseada em JavaScript é fácil para os desenvolvedores da Web e ele também é fácil
de instalar. Por estas razões, o MongoDB é uma ótima opção de tecnologia para uso
em uma aplicação.
Um exemplo do sucesso deste banco é o depoimento do especialista em banco de
dados da Globo.com, Franklin Amorim. Em um evento sobre o MongoDB, em 2011 na
cidade de São Paulo, Franklin apresentou o case de sucesso da adoção do MongoDB
para uma nova função do “fantasy game” CartolaFC.
O jogo é maior aplicação dinâmica do portal Globo.com, com mais de 2 milhões de
usuários cadastrados e quase 90 milhões de pageviews somente em um mês.
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
23/29
08/04/2015
Comparando o NoSQL ao modelo relacional
A ideia da aplicação era criar uma espécie de “twitter” para os usuários do jogo, com
a finalidade de promover uma maior interação entre os usuários, além de aumentar o
seu tempo de permanência no site.
Na Globo.com, a maioria dos projetos são em banco de dados relacional, porém
resolveram tentar algo novo para o CartolaFC, já que em alguns testes de
performance, as vantagens do MongoDB foram mais atrativas do que o MySQL. Nos
testes realizados pela equipe da Globo conseguiu­se uma velocidade duas vezes
maior com o MongoDB comparado ao MySQL.
O acesso mais natural aos dados no banco via BSON, sem ter que fazer abstrações
de tabelas, foi considerado atrativo pelos desenvolvedores. Não possuir schema
também foi fator de vantagem pela flexibilidade dos documentos criados. E o fato de
o sistema estar sempre ativo devido ao “Failover” automático que mantém o sistema
sempre disponível e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicação.
A partir desta experiência de sucesso, outros projetos na Globo.com passaram a usar
o MongoDB. Atualmente tem­se o receitas.com e o novo catálogo de vídeos da
emissora que possui cerca de 800 mil arquivos cadastrados.
Este artigo discutiu as soluções NoSQL como modelo de banco de dados em cenários
onde escalabilidade é a questão principal. O objetivo foi mostrar aos mais
conservadores a existência de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional. O desenvolvedor precisa, portanto, observar o cenário
em que está trabalhando para tomar uma decisão coerente de qual modelo de banco
de dados deve usar.
No cenário atual da Web 2.0, Big Data, computação em nuvem e redes sociais, os
modelos tradicionais para gerenciamento de dados têm apresentado limitações,
principalmente no quesito escalabilidade, e assim o NoSQL surgiu como opção.
Atualmente podemos observar grandes empresas e negócios de escala global
fazendo uso dessa tecnologia. Como já citado como exemplos, o Cassandra é usado
no Facebook e Twitter, e o MongoDB está em uso no Foursquare, SourceForge e na
Globo.com. Isto é um indicativo de que esse tipo de tecnologia certamente não será
descartada facilmente como um modismo.
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
24/29
08/04/2015
Comparando o NoSQL ao modelo relacional
O NoSQL não é uma tecnologia de banco de dados totalmente nova e há indícios de
que seu futuro é bastante promissor. Ela oferece a possibilidade e flexibilidade de
manipulação de dados semiestruturados complexos e otimiza soluções para
diferentes tipos de dados nesta era da computação em larga escala. Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponíveis como solução no quesito banco de dados.
DevMedia
A DevMedia é um portal para analistas, desenvolvedores de sistemas, gerentes e DBAs com milhares de
artigos, dicas, cursos e videoaulas gratuitos e exclusivos para assinantes.
O que você achou deste post?
Gostei (12)
(0)
Todos os comentarios (2)
Postar dúvida / Comentário
Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente. Parabéns ! No entanto, gostaria de tirar 3 dúvidas. 1º) É possível criar um coleção com "atributos" obrigatórios ? Ex: Colocar como obrigatório o
preenchimento dos atributos "matricula" e "nome" na coleção [unifacs]. 2º) Na modelagem NoSQL Documental é possível criar relacionamentos ? Algo similar a uma FK. 3º) Todos os artigos que vejo sobre NoSQL sempre são com o foco em Desenvolvimento. Gostaria
de saber mais a respeito das tarefas administrativas necessárias para um BD desse tipo. Em um
Banco SQL precisamos coletar estatísticas, realizar rebuild de índices, desfragmentação de
segmentos. Quais tarefas administrativas são necessárias em um BD NoSQL ? [há +1 mês] ­ Responder
Daniella Adriana Da Costa
Olá Rafael, conforme vc já enviou feedback para o autor, vamos postar abaixo a mesma resposta dada
por ele para as suas dúvidas: André, http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
25/29
08/04/2015
Comparando o NoSQL ao modelo relacional
Parabéns mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
dúvidas. Vou ler os links que você enviou com calma. Rafael Dantas [RESPOSTA DO AUTOR] Olá Rafael Dantas, Fico contente de ter gostado do artigo! A pesquisa que realizei foi bem focada em fazer uma comparação entre os modelos,
portanto não busquei e nem me preocupei com algumas outras demandas da área. Tentei dar uma pesquisada no assunto sobre as perguntas feitas: 1­ No desenvolvimento do meu artigo, ao estudar o mongo e o NoSQL em si, não observei
em nenhum dos artigos que utilizei como referência um relato de possibilidade de tornar
um atributo obrigatório. Pesquisando sobre o assunto vejo que há gem de mapeamento
objeto­documento usadas pra acessar o MongoDB, como Mongoose e MongoID, e nelas há
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvá­lo e também é possível definir um campo como obrigatório na definição de esquema.
(http://stackoverflow.com/questions/17943609/can­i­require­an­attribute­to­be­set­in­a­
mongodb­collection­not­null) 2­ "Uma diferença fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais, diferente dos bancos orientados a
documentos que não fornecem relacionamentos entre documentos, o que mantém seu
design sem esquemas." Leia mais em: Introdução ao MongoDB http://www.devmedia.com.br/introducao­ao­
mongodb/30792#ixzz3A0lWPu00" No entanto, buscando sobre o assunto vi que há a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid. http://mongoid.org/en/mongoid/docs/relations.html 3­ Os bancos de dados NoSQL são caracterizados por afastar a complexidade dos bancos
SQL. A lógica de validação, controle de acesso, mapeamento de consultas de dados
indexados, correlação entre os dados relacionados, resolução de conflitos, manutenção de
restrições de integridade (constraint), e procedimentos engatilhados são movidos para
fora da camada de banco de dados. Isto permite o foco em performance e escalabilidade.
Uma das grandes vantagens da arquitetura NoSQL é que a lógica pode ser codificada em
qualquer linguagem de programação, ao invés de depender da grande variedade de APIs
complexas em um servidor SQL. 4­ Sobre as tarefas administrativas, não achei nada a respeito. Vi que no próprio site do
Mongodb, há um serviço de gerenciamento: https://mms.mongodb.com Espero ter ajudado! Att, André Simões
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
26/29
08/04/2015
Comparando o NoSQL ao modelo relacional
[há +1 mês] ­ Responder
Serviços
Inclua um comentário
Adicionar aos Favoritos
Marcar como lido/assistido
Incluir anotação pessoal
Versão para impressão
+SQL
Mais posts
Video aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicações da Segunda Forma Normal - Curso Modelagem de
Dados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
27/29
08/04/2015
Comparando o NoSQL ao modelo relacional
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalização e Anomalias - Curso Modelagem de Dados Aula 22
Video aula
Dependências Funcionais - Curso Modelagem de Dados - Aula
21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitários - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo de
MySQL - Aula 14
Listar mais conteúdo
Anuncie | Loja | Publique | Assine | Fale conosco
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
28/29
08/04/2015
Comparando o NoSQL ao modelo relacional
DevMedia
Curtir Você curtiu isso.
Você e outras 63.895 pessoas curtiram DevMedia.
Plug­in social do Facebook
Hospedagem web por Porta 80 Web Hosting
http://www.devmedia.com.br/comparando­o­nosql­ao­modelo­relacional/30917
29/29