Embed Size (px)
DESCRIPTION
Comparando o NoSQL ao modelo relacional
Citation preview
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 129
Gostei (12) (0)
Buscar
coacutedigo fonte comentaacuterios post favorito (9)
SQL Magazine 123 shy Iacutendice
Comparando o NoSQL aomodelo relacional
Conheccedila nesse artigo os benefiacutecios e dificuldades no uso doNoSQL em comparaccedilatildeo com o modelo de banco de dadosrelacionais
Fique por dentro
O tradicional modelo relacional eacute o tipo de banco de dados mais utilizado nas
uacuteltimas deacutecadas Poreacutem haacute um crescimento cada vez mais intenso do volume de
0 0Curtir0
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 229
dados na era da Big Data redes sociais e computaccedilatildeo na nuvem e certos fatores
limitantes tecircm propiciado o surgimento de modelos alternativos de banco de
dados
O NoSQL vem ganhando espaccedilo no mercado e se tornando uma opccedilatildeo que atende
aos requisitos do ambiente de computaccedilatildeo distribuiacuteda em larga escala permitindo
escalabilidade disponibilidade alto desempenho e confiabilidade Este artigo tem
como objetivo fornecer uma visatildeo geral das soluccedilotildees de banco de dados NoSQL
modernas abordar suas principais caracteriacutesticas mostrar suas principais
diferenccedilas com relaccedilatildeo aos bancos de dados relacionais e apresentar um estudo
de caso de uma destas soluccedilotildees
Por deacutecadas os bancos de dados relacionais tecircm sido a escolha padratildeo para
persistecircncia de dados corporativos No entanto as grandes empresas e aplicaccedilotildees
web estatildeo mudando ao longo dos uacuteltimos anos
Com o aumento da quantidade e do fluxo de informaccedilotildees e a certeza de que sempre
haveraacute mais dados para armazenar o tradicional modelo relacional comeccedila a sofrer
limitaccedilotildees de escalabilidade
Neste cenaacuterio surge uma nova geraccedilatildeo de banco de dados natildeoshyrelacional como
uma maneira de lidar com o crescente volume de dados O NoSQL (Not only SQL)
atende aos requisitos do ambiente de computaccedilatildeo distribuiacuteda em larga escala o que
permite escalabilidade alta disponibilidade alto desempenho e confiabilidade
A grande motivaccedilatildeo para o NoSQL eacute resolver o problema de escalabilidade dos
bancos tradicionais Contudo se faz necessaacuterio analisar todas as suas caracteriacutesticas
para se ter uma visatildeo geral de seus proacutes e contras quando comparado ao modelo
relacional
Este artigo forneceraacute uma visatildeo geral sobre o modelo relacional de banco de dados
suas limitaccedilotildees e as soluccedilotildees do NoSQL como alternativa a este modelo de banco
Esta anaacutelise iraacute abordar os principais recursos e discutir os desafios da tecnologia
NoSQL identificando quais benefiacutecios e dificuldades esta tecnologia traz para a
soluccedilatildeo do grande volume de dados processados atualmente
Aleacutem disso seraacute apresentado atraveacutes de um estudo de caso algumas das
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 329
diferenccedilas identificadas entre os dois modelos
SGBDs RelacionaisO banco de dados no modelo relacional foi proposto por Edgar Codd um pesquisador
da IBM em torno de 1970 Desde entatildeo se tornou o modelo de banco de dados
dominante para aplicaccedilotildees comerciais Hoje haacute 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 relaccedilotildees Uma tabela
eacute composta de linhas e colunas As linhas tambeacutem satildeo chamadas de registros ou
tuplas As colunas tambeacutem satildeo chamadas de campo ou atributo Uma tabela de
banco de dados eacute semelhante a uma folha de caacutelculo
No entanto as relaccedilotildees 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 caracteriacutestica importante deste modelo eacute o uso de elementos para garantir a
integridade dos dados As restriccedilotildees mais comuns satildeo as chaves primaacuterias e as
estrangeiras O termo chave primaacuteria eacute utilizado para identificar o atributo que foi
escolhido pelo projetista do banco para identificar unicamente os registros que satildeo
armazenados em uma determinada tabela
Nenhum registro pode ter o mesmo valor no campo chave primaacuteria de uma
determinada tabela do banco de dados por isso os atributos chaves devem ser
selecionados com muito cuidado Jaacute a chave estrangeira transforma o valor de um
atributo dependente do valor existente em outro atributo normalmente de outra
tabela criando uma relaccedilatildeo de dependecircncia entre atributos de tabelas distintas
As chaves satildeo muito utilizadas em bancos de dados relacionais inclusive para a
criaccedilatildeo de outros componentes como os iacutendices que satildeo usados para melhorar o
desempenho de consultas no banco
Para projetar corretamente as tabelas de um banco de dados relacional temos um
conjunto de orientaccedilotildees que ajudam a reduzir a redundacircncia e chance de corrupccedilatildeo
de dados Eacute o que chamamos de normalizaccedilatildeo As regras de normalizaccedilatildeo satildeo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 429
projetadas para evitar anomalias de atualizaccedilatildeo e inconsistecircncias de dados e ao
mesmo tempo para permitir uma recuperaccedilatildeo mais faacutecil de informaccedilotildees
A linguagem chamada SQL foi desenvolvida para trabalhar com bancos de dados
relacionais Inspirada na aacutelgebra relacional e desenvolvida pela IBM o SQL eacute uma
linguagem declarativa para banco de dados
A facilidade de uso e simplicidade de expressatildeo 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 satildeo as propriedades ACID A sigla
significa Atomicidade Consistecircncia Isolamento e Durabilidade As propriedades ACID
de um SGBD permitem o compartilhamento seguro de dados oferecendo otimizaccedilatildeo
de consultas recuperaccedilatildeo de falhas validaccedilatildeo controle de concorrecircncia e
verificaccedilatildeo de integridade dos dados
Todas essas caracteriacutesticas e recursos deram ao Modelo Relacional de banco de
dados uma posiccedilatildeo de destaque e predominacircncia 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
Limitaccedilotildees do Modelo RelacionalO Walmart um gigante do varejo trabalha com mais de 1 milhatildeo de transaccedilotildees de
clientes por hora alimentando bancos de dados estimados em mais de 25
petabytes Jaacute o Facebook possui em seu banco cerca de 40 bilhotildees de fotos Estes
satildeo exemplos que mostram que o mundo conteacutem enorme quantidade de informaccedilatildeo
digital e que este volume de informaccedilotildees e dados estaacute ficando cada vez maior
rapidamente
Este eacute um dos principais problemas encontrados com a utilizaccedilatildeo do Modelo
Relacional a dificuldade em se usar esse modelo com uma demanda por
escalabilidade cada vez maior As aplicaccedilotildees web que usam banco de dados
relacional vecircm sofrendo com o grande volume de dados e problemas de
desempenho
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 529
Para solucionar tais problemas de escalabilidade geralmente se recorre a duas
alternativas o aumento do nuacutemero de servidores (escalonamento horizontal) ou a
realizaccedilatildeo de um upgrade no servidor (escalonamento vertical)
Isto natildeo eacute o suficiente caso o volume de informaccedilotildees continue a crescer em ritmo
acelerado Com o constante crescimento dos dados a soluccedilatildeo passa a ser escalar o
banco de dados em sistemas distribuiacutedos
Entretanto por causa da natureza estruturada do modelo relacional os
administradores de bancos de dados perceberam uma dificuldade em organizar as
informaccedilotildees em sistemas distribuiacutedos particionando os dados em maacutequinas
diferentes Manusear tabelas em diferentes servidores eacute muito difiacutecil e problemaacutetico
Por conta disso comeccedilam a surgir as soluccedilotildees natildeo relacionais
NoSQLOs desenvolvedores comeccedilaram a pensar em um modelo alternativo para modelar as
bases de dados frente agraves dificuldades encontradas no modelo relacional As soluccedilotildees
propostas para a melhoria de desempenho visavam evitar a riacutegida e tradicional
estrutura usada no modelo relacional
O objetivo dos projetistas de banco de dados das grandes organizaccedilotildees era
desenvolver uma nova maneira de armazenar as informaccedilotildees flexibilizando o banco
de dados para as caracteriacutesticas particulares de sua empresa
Esta flexibilidade eacute fundamental para atender aos requisitos dos sistemas
distribuiacutedos em larga escala permitindo escalabilidade e alta disponibilidade para as
aplicaccedilotildees 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 coacutedigo aberto que natildeo possuiacutea
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
natildeo atendia aos requisitos pretendidos Eacute um movimento totalmente adepto ao
coacutedigo aberto
A intenccedilatildeo do NoSQL natildeo eacute substituir o tradicional modelo relacional e sim ser uma
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 629
alternativa para as empresas que necessitam de um modelo de banco de dados mais
flexiacutevel para suportar o seu volume de dados
A constante tendecircncia de computaccedilatildeo em nuvem e o crescimento das redes sociais
satildeo fatores importantes que levam ao desenvolvimento de armazenamento NoSQL
Apesar da existecircncia de muitos bancos de dados NoSQL o movimento ganhou forccedila
quando grandes empresas da tecnologia passaram a usar suas proacuteprias
implementaccedilotildees a fim de fornecer serviccedilos para seus sistemas distribuiacutedos
Buscando atender suas necessidades de armazenamento em 2004 o Google criou o
BigTable
Na sequecircncia buscando tambeacutem a alta disponibilidade a Amazon lanccedilou o Dynamo
Em 2008 o Facebook desenvolveu o Cassandra para tratar o grande volume de
dados e este se mostrou tatildeo eficiente que em 2010 o Twitter deixou o MySQL de
lado para usaacuteshylo
Outras soluccedilotildees lanccediladas satildeo o Apache CouchDB e o MongoDB que satildeo banco de
dados orientados a documentos e com caracteriacutesticas bem semelhantes como alta
performance e escalaacuteveis projetados para suportar sistemas distribuiacutedos em larga
escala
Todos os bancos citados satildeo considerados NoSQL possuem caracteriacutesticas
semelhantes mas tambeacutem possuem particularidades que os diferenciam A proacutexima
seccedilatildeo aborda justamente os diferentes modelos de bancos de dados NoSQL
mostrando suas caracteriacutesticas
31 Modelos de BD NoSQLMais e mais organizaccedilotildees tecircm adotado soluccedilotildees NoSQL para apoiar seus projetos
Estas soluccedilotildees apresentam caracteriacutesticas em comum como uma maior
escalabilidade e alta disponibilidade mas tambeacutem apresentam diversas
singularidades Os bancos de dados NoSQL satildeo subdivididos pela maneira como
armazenam as informaccedilotildees Os principais tipos satildeo Armazenamento ChaveshyValor
(KeyValue) Documento Coluna e Grafo
A soluccedilatildeo chaveshyvalor armazena qualquer coisa como pares de valoresshychave o que
implica valores armazenados recuperados por chaves uacutenicas Satildeo capazes de
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 729
armazenar grandes quantidades de dados e no entanto mantecircm o acesso simples
por uma chave primaacuteria
Este tipo de armazenamento funciona bem para listas como as categorias de
produtos os atributos de cada produto carrinho de compras conteuacutedos ou valores
individuais etc
Por conta disto o Amazon Dynamo eacute uma soluccedilatildeo que adota este modelo Os dados
deste sistema satildeo particionados e replicados usando hashing consistente a fim de
fornecer a escalabilidade e disponibilidade
O segundo modelo de soluccedilatildeo muda o tradicional paradigma de orientaccedilatildeo a
registros (ou tuplas) para orientaccedilatildeo a colunas (ou atributos) Aqui os dados seguem
uma indexaccedilatildeo tripla (linha coluna e timestamp) onde as linhas e as colunas satildeo
identificadas por chaves e o timestamp possibilita a diferenciaccedilatildeo de muacuteltiplas
versotildees de um mesmo dado
Alguns modelos deste tipo de armazenamento possuem colunas (registros que
possuem nome valor e timestamp) famiacutelias de colunas (uma coleccedilatildeo de colunas
equivalente a uma tabela do Modelo Relacional) e supershycolunas (formadas por
arrays de colunas)
O conceito de famiacutelia de colunas pode ser observado na Figura 1 onde
primeiroNome e sobrenome satildeo colunas pertencentes agrave famiacutelia de colunas
denominada nome e as colunas endereccedilo e cidade pertencem agrave famiacutelia local Dois
grandes exemplos de sistemas orientados a coluna satildeo o Cassandra e o BigTable
Figura 1 Exemplo de modelo baseado em colunas
Jaacute uma soluccedilatildeo baseada em documento eacute um tipo de banco de dados que armazena
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 829
coleccedilotildees de documentos Os documentos satildeo representados como objetos com um
uacutenico identificador e um conjunto de campos que podem ser strings listas ou
documentos aninhados Como esta base de dados eacute semiestruturada e natildeo possui
esquema uma informaccedilatildeo especiacutefica 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 temshyse 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 trecircs
componentes baacutesicos os veacutertices (satildeo os noacutes do grafo) as arestas (satildeo os
relacionamentos entre os noacutes) e os atributos dos noacutes e relacionamentos Os dados
satildeo armazenados nos noacutes do grafo e as arestas representam o tipo de associaccedilatildeo
entre eles
Novas arestas podem ser adicionadas (ou as antigas removidas) a qualquer
momento permitindo que relaccedilotildees 1shyN (um para muitos) e NshyN (muitos para muitos)
sejam expressas de forma faacutecil Construccedilotildees como amigos seguidores graus de
separaccedilatildeo listas satildeo muito naturalmente acomodadas em bancos de dados do tipo
grafo
A Figura 3 representa um exemplo de grafo de uma aplicaccedilatildeo que possui
informaccedilotildees 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
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 929
No exemplo da figura temos trecircs pessoas que satildeo noacutes do grafo e estatildeo conectados agrave
cidades que ou jaacute visitaram ou moraram Atraveacutes da representaccedilatildeo do grafo fica faacutecil
perceber que Maria e Joseacute jaacute visitaram o Rio de Janeiro
E que Joatildeo jaacute morou em Recife e Salvador Um exemplo de banco de dados baseado
em grafo eacute o Neo4j que eacute openshysource e implementado em Java
Figura 3 Exemplo de modelo baseado em grafo
Eacute importante ressaltar que nenhum dos modelos apresentados deve ser considerado
superior ao outro pois tudo depende da necessidade da aplicaccedilatildeo Eacute importante que
os desenvolvedores conheccedilam os diversos modelos de soluccedilatildeo para que seja
adotado aquele que mais se adequar ao que a aplicaccedilatildeo ou empresa precisa Isto
contribui para a diminuiccedilatildeo do custo de criaccedilatildeo do banco de dados e com o aumento
do desempenho no processamento dos dados
A Tabela 1 apresenta uma comparaccedilatildeo dos modelos apresentados destacando suas
principais vantagens e desvantagens e ainda citando seus principais exemplos e
suas disponibilidades
Tipo Vantagem Desvantagem Exemplos Disponibilidade
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1029
ChaveValor
Simplicidade
e
escalabilidade
Falta recursos
mais
avanccedilados de
consulta
Amazon
DynamoDB
O niacutevel gratuito da AWS inclui 100
MB de armazenamento 5 unidades
de capacidade de gravaccedilatildeo e 10
unidades de capacidade de leitura
com o Amazon DynamoDB
Disponiacutevel em
httpawsamazoncomptdynamodb
DocumentoFacilidade de
uso
Natildeo eacute
adequado para
dados
relacionais
Consulta
limitada a
chaves e
iacutendices
MongoDB
CouchDB
Como a maioria das licenccedilas de
software livre permite seja usado
modificado e distribuiacutedo por usuaacuterios
Podeshyse adquirir o MongoDB em
httpwwwmongodborg
e CouchDB
httpcouchdbapacheorg
ColunaEscalabilidade
e flexibilidadeComplexidade
Google Big
Table
Cassandra
BigTable foi desenvolvida no Google
em tem sido usado desde 2005 em
dezenas de serviccedilos do Google Uma
versatildeo de coacutedigo aberto HBase foi
criado pelo Apache
httphbaseapacheorg
Jaacute o Cassandra tambeacutem pode ser
adquirido de forma gratuita
httpcassandraapacheorg
Grafo
Modelo de
dados
poderoso e
raacutepido
Flexibilidade
Neo4j Como os demais acima o Neo4j
tambeacutem estaacute disponiacutevel para
download em httpwwwneo4jorg
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1129
Tabela 1 Anaacutelise comparativa dos modelos de BD NoSQL
Modelo Relacional x NoSQLAo se comparar os modelos em questatildeo uma grande diferenccedila a se notar eacute que as
tecnologias relacionais tecircm esquemas riacutegidos enquanto os modelos NoSQL satildeo
schemashyfree ou seja sem esquema O modelo relacional requer uma definiccedilatildeo
estrita de um esquema antes de armazenar todos os dados em um banco de dados
Alterar o esquema uma vez que os dados jaacute estatildeo inseridos eacute muito complicado e
por isso evitado No entanto isto eacute exatamente o oposto do comportamento
desejado na era ldquoBig Datardquo 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 trecircs criteacuterios satildeo
considerados relevantes para esta escolha escalonamento consistecircncia de dados e
disponibilidade E eacute isto que seraacute abordado a partir de agora
Basicamente pelo fato de terem sido criados para essa finalidade os bancos NoSQL
apresentam vantagens em relaccedilatildeo 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 cenaacuterios em que o escalonamento eacute
necessaacuterio
Eacute possiacutevel tornar um banco de dados relacional mais escalaacutevel atraveacutes da teacutecnica de
escalonamento vertical onde eacute feita uma atualizaccedilatildeo (upgrade) no servidor de
bancos de dados
Poreacutem este escalonamento fica limitado agrave capacidade de uma uacutenica maacutequina Jaacute o
escalonamento horizontal eacute feito com o aumento da quantidade de servidores que
iratildeo disponibilizar os dados paralelamente (Figura 4) facilitando o acesso aos dados
e garantindo que a queda de um servidor natildeo seja um problema de disponibilidade
dos dados
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1229
Figura 4 O uso do escalonamento horizontal
Outra caracteriacutestica a favor do NoSQL eacute o uso do sharding que consiste em trabalhar
com o escalonamento horizontal particionando e paralelizando seus dados em vaacuterios
servidores (Figura 5) Essa teacutecnica eacute complexa para se usar em SGBDs relacionais
devido a toda a sua estrutura loacutegica e devido ao uso da desnormalizaccedilatildeo dos dados
o contraacuterio usado no modelo relacional
O sharding traz benefiacutecios pois conjuntos de dados menores satildeo mais faacuteceis de
serem acessados atualizados e gerenciados O maior benefiacutecio em comparaccedilatildeo ao
modelo relacional eacute a otimizaccedilatildeo do grau de disponibilidade do sistema pois como
jaacute dito anteriormente a queda de uma maacutequina natildeo causaria a interrupccedilatildeo de todo o
sistema
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1329
Figura 5 Teacutecnica de sharding
O controle de concorrecircncia tambeacutem funciona de maneira distinta nos modelos em
questatildeo O modelo relacional utiliza bloqueios (locks) como garantia de que dois
usuaacuterios natildeo atualizem o mesmo dado ao mesmo tempo Jaacute no modelo NoSQL satildeo
usadas outras estrateacutegias para permitir um maior grau de concorrecircncia
Alguns bancos NoSQL usam o MVCC (Multiversion Concurrency Control) ou Controle
de Concorrecircncia Multishyversotildees Nesta teacutecnica o acesso aos dados pode ser realizado
em paralelo
Cada usuaacuterio que se conecta ao banco de dados visualiza uma coacutepia temporaacuteria do
banco de dados naquele instante Qualquer atualizaccedilatildeo que esteja sendo feita em
determinado momento por um usuaacuterio natildeo seraacute vista pelos demais que estatildeo
operando simultaneamente no banco de dados ateacute que a atualizaccedilatildeo tenha sido
concluiacuteda
Quando se opta por usar um modelo NoSQL haacute ganhos de performance flexibilidade
e disponibilidade mas haacute uma perda de consistecircncia Haacute um teorema na ciecircncia da
computaccedilatildeo criado Eric Brewer chamado Teorema CAP (Consistency Availability e
Partition Tolerance) que diz ser impossiacutevel para um sistema distribuiacutedo garantir
consistecircncia disponibilidade e toleracircncia ao particionamento De forma simultacircnea
soacute eacute possiacutevel conseguir duas destas trecircs caracteriacutesticas Vejamos exemplos de
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1429
SGBDs na Figura 6 segundo o Teorema CAP
Figura 6 Distribuiccedilatildeo relativa de alguns bancos de dados quanto ao Teorema CAP
As soluccedilotildees NoSQL seguem um paradigma denominado BASE (Basically Available
Soft state Eventual consistency) Este tem como caracteriacutesticas estar basicamente
disponiacutevel o tempo todo estar em estado leve ou seja natildeo sendo consistente o
tempo todo e possuir uma consistecircncia eventual o sistema se torna consistente no
momento apropriado
O modelo BASE eacute um contraste ao paradigma ACID (Atomicity Consistency
Isolation Durability) comumente associado aos bancos de dados de modelo
relacional Ao contraacuterio do modelo ACID que promove uma seguranccedila dos dados
forccedilando a consistecircncia ao final de cada operaccedilatildeo o modelo BASE permite que o
banco de dados esteja em um estado eventualmente consistente
A disponibilidade do modelo BASE estaacute associada justamente ao fato de que a falha
de uma maacutequina do sistema natildeo interrompe o sistema como um todo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1529
Para se analisar de forma mais raacutepida e comparativa a Tabela 2 apresenta as
principais caracteriacutesticas de ambos os modelos discutidos aqui
Modelo Relacional NoSQL
Escalonamento Possui sua natureza
estruturada e por conta disto
o escalonamento de bancos
tende a ser uma tarefa
complexa
Eacute livre de esquemas por isso
o NoSQL possui uma maior
flexibilidade e alta
escalabilidade considerada
uma das principais vantagens
desse modelo
Consistecircncia Possui uma estrutura mais
riacutegida e garante em suas
transaccedilotildees a existecircncia dessa
propriedade As diversas
regras deste modelo
possibilitam uma maior
rigidez quanto a garantia de
consistecircncia dos dados
sendo este o ponto mais
forte desse modelo
A consistecircncia nesse modelo
possui um caraacuteter eventual
o que natildeo garante que uma
determinada atualizaccedilatildeo em
um dado momento seja
percebida por todos os noacutes
Disponibilidade Haacute uma dificuldade de se
trabalhar de forma eficiente
com a distribuiccedilatildeo de dados
por causa de sua natureza
estruturada situaccedilotildees em
que exigem uma maior
demanda de um sistema que
utilizem esse modelo podem
natildeo ser bem suportadas por
ele
Considerada outra das
grandes vantagens do
modelo essa propriedade
junto com o alto grau de
distribuiccedilatildeo desse modelo
possibilita que o sistema
fique um menor periacuteodo de
tempo natildeoshydisponiacutevel assim
como tambeacutem permite que a
solicitaccedilatildeo aos dados por um
nuacutemero crescente de clientes
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1629
seja atendida
Toleracircncia a
Particionamento
Por natildeo terem sido
construiacutedo com a finalidade
de trabalhar com
particionamento de dados
este modelo natildeo possui um
grau muito alto de toleracircncia
ao particionamento cuja
razatildeo principal seria a
dificuldade de junccedilotildees entre
as tabelas
Trabalha de forma faacutecil e
eficiente com a distribuiccedilatildeo
de dados Este modelo eacute
capaz de suportar grandes
demandas de dados assim
como possui alta toleracircncia
ao particionamento dos
mesmos
Tabela 2 Anaacutelise 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 verificaccedilatildeo contiacutenua
da consistecircncia de cada transaccedilatildeo adiciona custos consideraacuteveis para um sistema
que tem milhares de transaccedilotildees ocorrendo
A consistecircncia eventual promovida pelo modelo BASE daacute agraves organizaccedilotildees a
capacidade de interagir com os clientes de forma contiacutenua com a necessaacuteria
disponibilidade e toleracircncia a particcedilatildeo mantendo baixos custos e o sistema rodando
sem interrupccedilotildees Sem duacutevida seria excelente ter consistecircncia completa o tempo
todo mas eacute preciso haver compensaccedilotildees e a consistecircncia eventual permite o
desenvolvimento eficaz de sistemas que podem lidar com o aumento exponencial de
dados devido agraves redes sociais computaccedilatildeo em nuvem e outros projetos de Big Data
Estudo de Caso shy MongoDBPara fins comparativos seratildeo analisadas nesta seccedilatildeo algumas diferenccedilas entre um
banco NoSQL o MongoDB e os bancos relacionais baseados em SQL O MongoDB eacute
um banco de dados NoSQL criado em 2009 pela empresa 10gen orientado a
documentos altamente escalaacutevel de alta performance e de coacutedigo aberto O
cofundador e diretor de tecnologia da 10gen define o MongoDB da seguinte forma ldquoO
MongoDB natildeo foi concebido em um laboratoacuterio
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1729
Noacutes construiacutemos o MongoDB com base em nossas experiecircncias na construccedilatildeo de
sistemas robustos de grande escala e alta disponibilidade Natildeo comeccedilamos do zero
noacutes tentamos descobrir o que estava problemaacutetico e solucionamos isso
Assim o que eu penso sobre MongoDB eacute que se vocecirc pegar o MySQL e alterar o
modelo de dados do relacional para orientado a documento vocecirc ganha uma grande
quantidade de recursos documentos embarcados para melhorar velocidade
facilidade de gerenciamento desenvolvimento aacutegil com bancos de dados sem
ldquoschemardquo escalabilidade horizontal mais faacutecil pois ldquojoinsrdquo natildeo satildeo tatildeo importantes
Haacute muitas coisas que funcionam muito bem nos bancos de dados relacionais iacutendices
consultas dinacircmicas e atualizaccedilotildees e noacutes natildeo mudamos muito neste ponto Por
exemplo a maneira de projetar seus iacutendices no MongoDB deve ser exatamente do
jeito que vocecirc faz isso no MySQL ou Oracle vocecirc soacute ganha a opccedilatildeo de indexar um
campo embarcadordquo
Como dito na seccedilatildeo de modelos de bancos de dados NoSQL um banco orientado a
documentos natildeo possui esquemas riacutegidos e estruturados sendo possiacutevel que ocorra
uma atualizaccedilatildeo na estrutura do documento Portanto inserir novos campos no
documento natildeo 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 coleccedilatildeo
iacutendice iacutendice
linha documento BSON
coluna campo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1829
joins documentos incorporados e vinculaccedilatildeo
primary key
(Especifica qualquer combinaccedilatildeo de colunas
ou coluna uacutenica como chave primaacuteria)
primary key
(No MongoDB a chave primaacuteria eacute definida
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 dinacircmicos ou seja sem a
necessidade de que cada registro tenha a mesma estrutura Estas estruturas satildeo
chamadas de coleccedilotildees (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 sobrenomeSilva idade22 bairroPituba
Outro documento para representar um aluno na mesma coleccedilatildeo
aluno2=nomeLiardquo sobrenomeSaacute cursoDireito materias[Civil Penal]
Podeshyse ter registros diferentes um do outro dentro de uma mesma coleccedilatildeo Parece
estranho este tipo de abordagem mas no modelo relacional usamos isto o tempo
inteiro e de maneira ineficiente com a formaccedilatildeo de tabelas esparsas
Estas satildeo tabelas incompletas onde algumas colunas satildeo sempre preenchidas e
outras nem sempre satildeo usadas Para ilustrar isto observe a Tabela 4 que apresenta
registros da construccedilatildeo civil
Coacutedigo Produto Altura Potecircncia Peso Diacircmetro
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1929
1 Britadeira 300cv 100kg
2 Cimento
3 Empilhadeira 15cv 300kg
4 Escada 3m
5 Tubulaccedilatildeo 20cm
Tabela 4 Cadastro de produtos da construccedilatildeo civil em banco de dados modelo
relacional
Neste exemplo haacute uma desvantagem no modelo relacional Haacute colunas cujo valor eacute
preenchido apenas uma vez como pode ser visto no exemplo das colunas Altura e
Diacircmetro Na construccedilatildeo das tabelas ao incluir colunas que satildeo pouco utilizadas
jogashyse fora espaccedilo de armazenamento e reduzshyse o desempenho do sistema como
um todo E ainda tratamos objetos diferentes como se fossem iguais o que nem
sempre eacute uma boa praacutetica Abaixo o exemplo de como ficaria este cadastro de
produtos no modelo documental
codigo1 produtoBritadeira potencia300cv peso100kg
codigo2 produtoCimento
codigo3 produtoEmpilhadeira potencia15cv peso300kg
codigo4 produtoEscada altura3m
codigo5 produtoTubulaccedilatildeo diametro20cm
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
Seratildeo apresentados agora alguns comandos comuns usados no MongoDB Voltando
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2029
ao primeiro exemplo de documento criado para alunos observe como ficaria o
comando para salvar os alunos em uma coleccedilatildeo
dbunifacssave(aluno1)
dbunifacssave(aluno2)
O comando acima salva os documentos aluno1 e aluno2 na coleccedilatildeo ldquounifacsrdquo Eacute
possiacutevel acessar os dados de uma coleccedilatildeo atraveacutes do comando find() basicamente
ele vai percorrer todos os registros da coleccedilatildeo e retornar os documentos listados No
exemplo dado o comando seria dbunifacsfind() E para apagar tudo que existe na
coleccedilatildeo dbunifacsremove()
Natildeo eacute necessaacuterio que se crie uma coleccedilatildeo ou mesmo que se configure uma estrutura
isso eacute feito automaticamente quando o primeiro registro eacute incluiacutedo No entanto eacute
possiacutevel usar o comando de criar uma coleccedilatildeo e isto pode ser utilizado para preacuteshy
atribuir espaccedilo para uma coleccedilatildeo Uma coleccedilatildeo de tamanho fixo usa o comando
ldquocappedrdquo e vem a substituir automaticamente as entradas mais antigas quando
atinge seu tamanho maacuteximo
Todas as coleccedilotildees limitadas e fixas devem especificar um tamanho maacuteximo e
tambeacutem podem especificar um nuacutemero maacuteximo de documentos O MongoDB remove
os documentos antigos se uma coleccedilatildeo atinge o limite de tamanho maacuteximo antes
que ele atinja a contagem maacutexima de documentos Considere o seguinte exemplo
dbcreateCollection (unifacs capped true size 5242880 max 5000)
Este comando cria uma coleccedilatildeo nomeada de ldquounifacsrdquo com uma dimensatildeo maacutexima
de 5 megabytes e um maacuteximo de 5000 documentos
Para visualizar todas as coleccedilotildees de um banco de dados MongoDB utilizashyse o
seguinte comando
dbgetCollectionNames()
Enfim haacute muitas diferenccedilas entre os comandos usados no MongoDB e no MySQL As
quatro operaccedilotildees baacutesicas usadas para criaccedilatildeo consulta atualizaccedilatildeo e destruiccedilatildeo de
dados conhecidas como CRUD (Create Read Update e Delete) apresentam
comandos bem distintos nos dois tipos de bancos em questatildeo A Tabela 5 compara
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2129
alguns comandos de CRUD em ambos os bancos
MySQL MongoDB
CREATE TABLE unifacs (
id MEDIUMINT NOT NULL
AUTO_INCREMENT
matricula Number
nome Varchar(30)
idade Number
PRIMARY KEY (id)
)
A coleccedilatildeo eacute criada implicitamente na primeira
inserccedilatildeo de dados O _id chave primaacuteria eacute
adicionada automaticamente se o campo _id natildeo
eacute especificado
dbunifacsinsert (
matricula 04217253
nome Paulo
idade 22
)
ALTER TABLE unifacs
ADD join_date DATETIME
Coleccedilotildees natildeo descrevem ou forccedilam a estrutura
dos seus documentos No entanto no niacutevel do
documento operaccedilotildees de update () podem
adicionar campos para documentos existentes
usando o operador $set e remover usando
$unset
dbunifacsupdate (
$set join_date new Date ()
multi true
)
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2229
ALTER TABLE unifacs
DROP COLUMN join_date
dbunifacsupdate(
$unset join_date
multi true
)
INSERT INTO unifacs (matricula nome
idade)
VALUES (032104211 ldquoJoanardquo 21)
dbunifacsinsert(
matricula 032104211 nome ldquoJoanardquo idade
21
)
SELECT FROM unifacs dbunifacsfind()
SELECT FROM unifacs WHERE idade =
21dbunifacsfind( idade 21 )
SELECT FROM unifacs WHERE nome =
ldquoJoanardquo
AND idade = 21
dbunifacsfind( nome ldquoJoanardquo idade 21 )
SELECT FROM unifacs WHERE idade gt
20dbunifacsfind( age $gt 20 )
SELECT COUNT() FROM unifacs
dbuserscount()
ou
dbunifacsfind()count()
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2329
UPDATE unifacs SET status = ldquoAprovadordquo
WHERE nota gt 7
dbunifacsupdate( nota $gt 7
$set status ldquoAprovadordquo multi true )
UPDATE unifacs SET nota = nota + 1
WHERE status = Aprovado
dbunifacsupdate( status Aprovado
$inc nota 1 multi true )
DELETE FROM unifacs WHERE status =
Reprovadodbunifacsremove( status Reprovado )
Tabela 5 Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
Eacute importante saber que cada documento de uma coleccedilatildeo no MongoDB tem um
tamanho maacuteximo de 16MB o que eacute mais do que suficiente para armazenar dados em
um documento No entanto o MongoDB ainda eacute capaz de armazenar arquivos no
banco de dados em uma coleccedilatildeo especifica que eacute a coleccedilatildeo do tipo GridFS
Ela eacute ideal para trabalhar com arquivos maiores de imagens viacutedeo e aacuteudio O GridFS
divide o arquivo em partes ou pedaccedilos e salva cada pedaccedilo em um documento
separado Quando vocecirc consulta um arquivo no GridFS eacute preciso remontar os
pedaccedilos conforme a necessidade
O MongoDB atinge o objetivo de ser amigaacutevel para o desenvolvedor Possui uma
documentaccedilatildeo bem escrita para a maioria dos principais idiomas Sua consulta
baseada em JavaScript eacute faacutecil para os desenvolvedores da Web e ele tambeacutem eacute faacutecil
de instalar Por estas razotildees o MongoDB eacute uma oacutetima opccedilatildeo de tecnologia para uso
em uma aplicaccedilatildeo
Um exemplo do sucesso deste banco eacute o depoimento do especialista em banco de
dados da Globocom Franklin Amorim Em um evento sobre o MongoDB em 2011 na
cidade de Satildeo Paulo Franklin apresentou o case de sucesso da adoccedilatildeo do MongoDB
para uma nova funccedilatildeo do ldquofantasy gamerdquo CartolaFC
O jogo eacute maior aplicaccedilatildeo dinacircmica do portal Globocom com mais de 2 milhotildees de
usuaacuterios cadastrados e quase 90 milhotildees de pageviews somente em um mecircs
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 229
dados na era da Big Data redes sociais e computaccedilatildeo na nuvem e certos fatores
limitantes tecircm propiciado o surgimento de modelos alternativos de banco de
dados
O NoSQL vem ganhando espaccedilo no mercado e se tornando uma opccedilatildeo que atende
aos requisitos do ambiente de computaccedilatildeo distribuiacuteda em larga escala permitindo
escalabilidade disponibilidade alto desempenho e confiabilidade Este artigo tem
como objetivo fornecer uma visatildeo geral das soluccedilotildees de banco de dados NoSQL
modernas abordar suas principais caracteriacutesticas mostrar suas principais
diferenccedilas com relaccedilatildeo aos bancos de dados relacionais e apresentar um estudo
de caso de uma destas soluccedilotildees
Por deacutecadas os bancos de dados relacionais tecircm sido a escolha padratildeo para
persistecircncia de dados corporativos No entanto as grandes empresas e aplicaccedilotildees
web estatildeo mudando ao longo dos uacuteltimos anos
Com o aumento da quantidade e do fluxo de informaccedilotildees e a certeza de que sempre
haveraacute mais dados para armazenar o tradicional modelo relacional comeccedila a sofrer
limitaccedilotildees de escalabilidade
Neste cenaacuterio surge uma nova geraccedilatildeo de banco de dados natildeoshyrelacional como
uma maneira de lidar com o crescente volume de dados O NoSQL (Not only SQL)
atende aos requisitos do ambiente de computaccedilatildeo distribuiacuteda em larga escala o que
permite escalabilidade alta disponibilidade alto desempenho e confiabilidade
A grande motivaccedilatildeo para o NoSQL eacute resolver o problema de escalabilidade dos
bancos tradicionais Contudo se faz necessaacuterio analisar todas as suas caracteriacutesticas
para se ter uma visatildeo geral de seus proacutes e contras quando comparado ao modelo
relacional
Este artigo forneceraacute uma visatildeo geral sobre o modelo relacional de banco de dados
suas limitaccedilotildees e as soluccedilotildees do NoSQL como alternativa a este modelo de banco
Esta anaacutelise iraacute abordar os principais recursos e discutir os desafios da tecnologia
NoSQL identificando quais benefiacutecios e dificuldades esta tecnologia traz para a
soluccedilatildeo do grande volume de dados processados atualmente
Aleacutem disso seraacute apresentado atraveacutes de um estudo de caso algumas das
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 329
diferenccedilas identificadas entre os dois modelos
SGBDs RelacionaisO banco de dados no modelo relacional foi proposto por Edgar Codd um pesquisador
da IBM em torno de 1970 Desde entatildeo se tornou o modelo de banco de dados
dominante para aplicaccedilotildees comerciais Hoje haacute 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 relaccedilotildees Uma tabela
eacute composta de linhas e colunas As linhas tambeacutem satildeo chamadas de registros ou
tuplas As colunas tambeacutem satildeo chamadas de campo ou atributo Uma tabela de
banco de dados eacute semelhante a uma folha de caacutelculo
No entanto as relaccedilotildees 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 caracteriacutestica importante deste modelo eacute o uso de elementos para garantir a
integridade dos dados As restriccedilotildees mais comuns satildeo as chaves primaacuterias e as
estrangeiras O termo chave primaacuteria eacute utilizado para identificar o atributo que foi
escolhido pelo projetista do banco para identificar unicamente os registros que satildeo
armazenados em uma determinada tabela
Nenhum registro pode ter o mesmo valor no campo chave primaacuteria de uma
determinada tabela do banco de dados por isso os atributos chaves devem ser
selecionados com muito cuidado Jaacute a chave estrangeira transforma o valor de um
atributo dependente do valor existente em outro atributo normalmente de outra
tabela criando uma relaccedilatildeo de dependecircncia entre atributos de tabelas distintas
As chaves satildeo muito utilizadas em bancos de dados relacionais inclusive para a
criaccedilatildeo de outros componentes como os iacutendices que satildeo usados para melhorar o
desempenho de consultas no banco
Para projetar corretamente as tabelas de um banco de dados relacional temos um
conjunto de orientaccedilotildees que ajudam a reduzir a redundacircncia e chance de corrupccedilatildeo
de dados Eacute o que chamamos de normalizaccedilatildeo As regras de normalizaccedilatildeo satildeo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 429
projetadas para evitar anomalias de atualizaccedilatildeo e inconsistecircncias de dados e ao
mesmo tempo para permitir uma recuperaccedilatildeo mais faacutecil de informaccedilotildees
A linguagem chamada SQL foi desenvolvida para trabalhar com bancos de dados
relacionais Inspirada na aacutelgebra relacional e desenvolvida pela IBM o SQL eacute uma
linguagem declarativa para banco de dados
A facilidade de uso e simplicidade de expressatildeo 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 satildeo as propriedades ACID A sigla
significa Atomicidade Consistecircncia Isolamento e Durabilidade As propriedades ACID
de um SGBD permitem o compartilhamento seguro de dados oferecendo otimizaccedilatildeo
de consultas recuperaccedilatildeo de falhas validaccedilatildeo controle de concorrecircncia e
verificaccedilatildeo de integridade dos dados
Todas essas caracteriacutesticas e recursos deram ao Modelo Relacional de banco de
dados uma posiccedilatildeo de destaque e predominacircncia 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
Limitaccedilotildees do Modelo RelacionalO Walmart um gigante do varejo trabalha com mais de 1 milhatildeo de transaccedilotildees de
clientes por hora alimentando bancos de dados estimados em mais de 25
petabytes Jaacute o Facebook possui em seu banco cerca de 40 bilhotildees de fotos Estes
satildeo exemplos que mostram que o mundo conteacutem enorme quantidade de informaccedilatildeo
digital e que este volume de informaccedilotildees e dados estaacute ficando cada vez maior
rapidamente
Este eacute um dos principais problemas encontrados com a utilizaccedilatildeo do Modelo
Relacional a dificuldade em se usar esse modelo com uma demanda por
escalabilidade cada vez maior As aplicaccedilotildees web que usam banco de dados
relacional vecircm sofrendo com o grande volume de dados e problemas de
desempenho
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 529
Para solucionar tais problemas de escalabilidade geralmente se recorre a duas
alternativas o aumento do nuacutemero de servidores (escalonamento horizontal) ou a
realizaccedilatildeo de um upgrade no servidor (escalonamento vertical)
Isto natildeo eacute o suficiente caso o volume de informaccedilotildees continue a crescer em ritmo
acelerado Com o constante crescimento dos dados a soluccedilatildeo passa a ser escalar o
banco de dados em sistemas distribuiacutedos
Entretanto por causa da natureza estruturada do modelo relacional os
administradores de bancos de dados perceberam uma dificuldade em organizar as
informaccedilotildees em sistemas distribuiacutedos particionando os dados em maacutequinas
diferentes Manusear tabelas em diferentes servidores eacute muito difiacutecil e problemaacutetico
Por conta disso comeccedilam a surgir as soluccedilotildees natildeo relacionais
NoSQLOs desenvolvedores comeccedilaram a pensar em um modelo alternativo para modelar as
bases de dados frente agraves dificuldades encontradas no modelo relacional As soluccedilotildees
propostas para a melhoria de desempenho visavam evitar a riacutegida e tradicional
estrutura usada no modelo relacional
O objetivo dos projetistas de banco de dados das grandes organizaccedilotildees era
desenvolver uma nova maneira de armazenar as informaccedilotildees flexibilizando o banco
de dados para as caracteriacutesticas particulares de sua empresa
Esta flexibilidade eacute fundamental para atender aos requisitos dos sistemas
distribuiacutedos em larga escala permitindo escalabilidade e alta disponibilidade para as
aplicaccedilotildees 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 coacutedigo aberto que natildeo possuiacutea
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
natildeo atendia aos requisitos pretendidos Eacute um movimento totalmente adepto ao
coacutedigo aberto
A intenccedilatildeo do NoSQL natildeo eacute substituir o tradicional modelo relacional e sim ser uma
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 629
alternativa para as empresas que necessitam de um modelo de banco de dados mais
flexiacutevel para suportar o seu volume de dados
A constante tendecircncia de computaccedilatildeo em nuvem e o crescimento das redes sociais
satildeo fatores importantes que levam ao desenvolvimento de armazenamento NoSQL
Apesar da existecircncia de muitos bancos de dados NoSQL o movimento ganhou forccedila
quando grandes empresas da tecnologia passaram a usar suas proacuteprias
implementaccedilotildees a fim de fornecer serviccedilos para seus sistemas distribuiacutedos
Buscando atender suas necessidades de armazenamento em 2004 o Google criou o
BigTable
Na sequecircncia buscando tambeacutem a alta disponibilidade a Amazon lanccedilou o Dynamo
Em 2008 o Facebook desenvolveu o Cassandra para tratar o grande volume de
dados e este se mostrou tatildeo eficiente que em 2010 o Twitter deixou o MySQL de
lado para usaacuteshylo
Outras soluccedilotildees lanccediladas satildeo o Apache CouchDB e o MongoDB que satildeo banco de
dados orientados a documentos e com caracteriacutesticas bem semelhantes como alta
performance e escalaacuteveis projetados para suportar sistemas distribuiacutedos em larga
escala
Todos os bancos citados satildeo considerados NoSQL possuem caracteriacutesticas
semelhantes mas tambeacutem possuem particularidades que os diferenciam A proacutexima
seccedilatildeo aborda justamente os diferentes modelos de bancos de dados NoSQL
mostrando suas caracteriacutesticas
31 Modelos de BD NoSQLMais e mais organizaccedilotildees tecircm adotado soluccedilotildees NoSQL para apoiar seus projetos
Estas soluccedilotildees apresentam caracteriacutesticas em comum como uma maior
escalabilidade e alta disponibilidade mas tambeacutem apresentam diversas
singularidades Os bancos de dados NoSQL satildeo subdivididos pela maneira como
armazenam as informaccedilotildees Os principais tipos satildeo Armazenamento ChaveshyValor
(KeyValue) Documento Coluna e Grafo
A soluccedilatildeo chaveshyvalor armazena qualquer coisa como pares de valoresshychave o que
implica valores armazenados recuperados por chaves uacutenicas Satildeo capazes de
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 729
armazenar grandes quantidades de dados e no entanto mantecircm o acesso simples
por uma chave primaacuteria
Este tipo de armazenamento funciona bem para listas como as categorias de
produtos os atributos de cada produto carrinho de compras conteuacutedos ou valores
individuais etc
Por conta disto o Amazon Dynamo eacute uma soluccedilatildeo que adota este modelo Os dados
deste sistema satildeo particionados e replicados usando hashing consistente a fim de
fornecer a escalabilidade e disponibilidade
O segundo modelo de soluccedilatildeo muda o tradicional paradigma de orientaccedilatildeo a
registros (ou tuplas) para orientaccedilatildeo a colunas (ou atributos) Aqui os dados seguem
uma indexaccedilatildeo tripla (linha coluna e timestamp) onde as linhas e as colunas satildeo
identificadas por chaves e o timestamp possibilita a diferenciaccedilatildeo de muacuteltiplas
versotildees de um mesmo dado
Alguns modelos deste tipo de armazenamento possuem colunas (registros que
possuem nome valor e timestamp) famiacutelias de colunas (uma coleccedilatildeo de colunas
equivalente a uma tabela do Modelo Relacional) e supershycolunas (formadas por
arrays de colunas)
O conceito de famiacutelia de colunas pode ser observado na Figura 1 onde
primeiroNome e sobrenome satildeo colunas pertencentes agrave famiacutelia de colunas
denominada nome e as colunas endereccedilo e cidade pertencem agrave famiacutelia local Dois
grandes exemplos de sistemas orientados a coluna satildeo o Cassandra e o BigTable
Figura 1 Exemplo de modelo baseado em colunas
Jaacute uma soluccedilatildeo baseada em documento eacute um tipo de banco de dados que armazena
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 829
coleccedilotildees de documentos Os documentos satildeo representados como objetos com um
uacutenico identificador e um conjunto de campos que podem ser strings listas ou
documentos aninhados Como esta base de dados eacute semiestruturada e natildeo possui
esquema uma informaccedilatildeo especiacutefica 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 temshyse 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 trecircs
componentes baacutesicos os veacutertices (satildeo os noacutes do grafo) as arestas (satildeo os
relacionamentos entre os noacutes) e os atributos dos noacutes e relacionamentos Os dados
satildeo armazenados nos noacutes do grafo e as arestas representam o tipo de associaccedilatildeo
entre eles
Novas arestas podem ser adicionadas (ou as antigas removidas) a qualquer
momento permitindo que relaccedilotildees 1shyN (um para muitos) e NshyN (muitos para muitos)
sejam expressas de forma faacutecil Construccedilotildees como amigos seguidores graus de
separaccedilatildeo listas satildeo muito naturalmente acomodadas em bancos de dados do tipo
grafo
A Figura 3 representa um exemplo de grafo de uma aplicaccedilatildeo que possui
informaccedilotildees 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
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 929
No exemplo da figura temos trecircs pessoas que satildeo noacutes do grafo e estatildeo conectados agrave
cidades que ou jaacute visitaram ou moraram Atraveacutes da representaccedilatildeo do grafo fica faacutecil
perceber que Maria e Joseacute jaacute visitaram o Rio de Janeiro
E que Joatildeo jaacute morou em Recife e Salvador Um exemplo de banco de dados baseado
em grafo eacute o Neo4j que eacute openshysource e implementado em Java
Figura 3 Exemplo de modelo baseado em grafo
Eacute importante ressaltar que nenhum dos modelos apresentados deve ser considerado
superior ao outro pois tudo depende da necessidade da aplicaccedilatildeo Eacute importante que
os desenvolvedores conheccedilam os diversos modelos de soluccedilatildeo para que seja
adotado aquele que mais se adequar ao que a aplicaccedilatildeo ou empresa precisa Isto
contribui para a diminuiccedilatildeo do custo de criaccedilatildeo do banco de dados e com o aumento
do desempenho no processamento dos dados
A Tabela 1 apresenta uma comparaccedilatildeo dos modelos apresentados destacando suas
principais vantagens e desvantagens e ainda citando seus principais exemplos e
suas disponibilidades
Tipo Vantagem Desvantagem Exemplos Disponibilidade
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1029
ChaveValor
Simplicidade
e
escalabilidade
Falta recursos
mais
avanccedilados de
consulta
Amazon
DynamoDB
O niacutevel gratuito da AWS inclui 100
MB de armazenamento 5 unidades
de capacidade de gravaccedilatildeo e 10
unidades de capacidade de leitura
com o Amazon DynamoDB
Disponiacutevel em
httpawsamazoncomptdynamodb
DocumentoFacilidade de
uso
Natildeo eacute
adequado para
dados
relacionais
Consulta
limitada a
chaves e
iacutendices
MongoDB
CouchDB
Como a maioria das licenccedilas de
software livre permite seja usado
modificado e distribuiacutedo por usuaacuterios
Podeshyse adquirir o MongoDB em
httpwwwmongodborg
e CouchDB
httpcouchdbapacheorg
ColunaEscalabilidade
e flexibilidadeComplexidade
Google Big
Table
Cassandra
BigTable foi desenvolvida no Google
em tem sido usado desde 2005 em
dezenas de serviccedilos do Google Uma
versatildeo de coacutedigo aberto HBase foi
criado pelo Apache
httphbaseapacheorg
Jaacute o Cassandra tambeacutem pode ser
adquirido de forma gratuita
httpcassandraapacheorg
Grafo
Modelo de
dados
poderoso e
raacutepido
Flexibilidade
Neo4j Como os demais acima o Neo4j
tambeacutem estaacute disponiacutevel para
download em httpwwwneo4jorg
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1129
Tabela 1 Anaacutelise comparativa dos modelos de BD NoSQL
Modelo Relacional x NoSQLAo se comparar os modelos em questatildeo uma grande diferenccedila a se notar eacute que as
tecnologias relacionais tecircm esquemas riacutegidos enquanto os modelos NoSQL satildeo
schemashyfree ou seja sem esquema O modelo relacional requer uma definiccedilatildeo
estrita de um esquema antes de armazenar todos os dados em um banco de dados
Alterar o esquema uma vez que os dados jaacute estatildeo inseridos eacute muito complicado e
por isso evitado No entanto isto eacute exatamente o oposto do comportamento
desejado na era ldquoBig Datardquo 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 trecircs criteacuterios satildeo
considerados relevantes para esta escolha escalonamento consistecircncia de dados e
disponibilidade E eacute isto que seraacute abordado a partir de agora
Basicamente pelo fato de terem sido criados para essa finalidade os bancos NoSQL
apresentam vantagens em relaccedilatildeo 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 cenaacuterios em que o escalonamento eacute
necessaacuterio
Eacute possiacutevel tornar um banco de dados relacional mais escalaacutevel atraveacutes da teacutecnica de
escalonamento vertical onde eacute feita uma atualizaccedilatildeo (upgrade) no servidor de
bancos de dados
Poreacutem este escalonamento fica limitado agrave capacidade de uma uacutenica maacutequina Jaacute o
escalonamento horizontal eacute feito com o aumento da quantidade de servidores que
iratildeo disponibilizar os dados paralelamente (Figura 4) facilitando o acesso aos dados
e garantindo que a queda de um servidor natildeo seja um problema de disponibilidade
dos dados
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1229
Figura 4 O uso do escalonamento horizontal
Outra caracteriacutestica a favor do NoSQL eacute o uso do sharding que consiste em trabalhar
com o escalonamento horizontal particionando e paralelizando seus dados em vaacuterios
servidores (Figura 5) Essa teacutecnica eacute complexa para se usar em SGBDs relacionais
devido a toda a sua estrutura loacutegica e devido ao uso da desnormalizaccedilatildeo dos dados
o contraacuterio usado no modelo relacional
O sharding traz benefiacutecios pois conjuntos de dados menores satildeo mais faacuteceis de
serem acessados atualizados e gerenciados O maior benefiacutecio em comparaccedilatildeo ao
modelo relacional eacute a otimizaccedilatildeo do grau de disponibilidade do sistema pois como
jaacute dito anteriormente a queda de uma maacutequina natildeo causaria a interrupccedilatildeo de todo o
sistema
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1329
Figura 5 Teacutecnica de sharding
O controle de concorrecircncia tambeacutem funciona de maneira distinta nos modelos em
questatildeo O modelo relacional utiliza bloqueios (locks) como garantia de que dois
usuaacuterios natildeo atualizem o mesmo dado ao mesmo tempo Jaacute no modelo NoSQL satildeo
usadas outras estrateacutegias para permitir um maior grau de concorrecircncia
Alguns bancos NoSQL usam o MVCC (Multiversion Concurrency Control) ou Controle
de Concorrecircncia Multishyversotildees Nesta teacutecnica o acesso aos dados pode ser realizado
em paralelo
Cada usuaacuterio que se conecta ao banco de dados visualiza uma coacutepia temporaacuteria do
banco de dados naquele instante Qualquer atualizaccedilatildeo que esteja sendo feita em
determinado momento por um usuaacuterio natildeo seraacute vista pelos demais que estatildeo
operando simultaneamente no banco de dados ateacute que a atualizaccedilatildeo tenha sido
concluiacuteda
Quando se opta por usar um modelo NoSQL haacute ganhos de performance flexibilidade
e disponibilidade mas haacute uma perda de consistecircncia Haacute um teorema na ciecircncia da
computaccedilatildeo criado Eric Brewer chamado Teorema CAP (Consistency Availability e
Partition Tolerance) que diz ser impossiacutevel para um sistema distribuiacutedo garantir
consistecircncia disponibilidade e toleracircncia ao particionamento De forma simultacircnea
soacute eacute possiacutevel conseguir duas destas trecircs caracteriacutesticas Vejamos exemplos de
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1429
SGBDs na Figura 6 segundo o Teorema CAP
Figura 6 Distribuiccedilatildeo relativa de alguns bancos de dados quanto ao Teorema CAP
As soluccedilotildees NoSQL seguem um paradigma denominado BASE (Basically Available
Soft state Eventual consistency) Este tem como caracteriacutesticas estar basicamente
disponiacutevel o tempo todo estar em estado leve ou seja natildeo sendo consistente o
tempo todo e possuir uma consistecircncia eventual o sistema se torna consistente no
momento apropriado
O modelo BASE eacute um contraste ao paradigma ACID (Atomicity Consistency
Isolation Durability) comumente associado aos bancos de dados de modelo
relacional Ao contraacuterio do modelo ACID que promove uma seguranccedila dos dados
forccedilando a consistecircncia ao final de cada operaccedilatildeo o modelo BASE permite que o
banco de dados esteja em um estado eventualmente consistente
A disponibilidade do modelo BASE estaacute associada justamente ao fato de que a falha
de uma maacutequina do sistema natildeo interrompe o sistema como um todo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1529
Para se analisar de forma mais raacutepida e comparativa a Tabela 2 apresenta as
principais caracteriacutesticas de ambos os modelos discutidos aqui
Modelo Relacional NoSQL
Escalonamento Possui sua natureza
estruturada e por conta disto
o escalonamento de bancos
tende a ser uma tarefa
complexa
Eacute livre de esquemas por isso
o NoSQL possui uma maior
flexibilidade e alta
escalabilidade considerada
uma das principais vantagens
desse modelo
Consistecircncia Possui uma estrutura mais
riacutegida e garante em suas
transaccedilotildees a existecircncia dessa
propriedade As diversas
regras deste modelo
possibilitam uma maior
rigidez quanto a garantia de
consistecircncia dos dados
sendo este o ponto mais
forte desse modelo
A consistecircncia nesse modelo
possui um caraacuteter eventual
o que natildeo garante que uma
determinada atualizaccedilatildeo em
um dado momento seja
percebida por todos os noacutes
Disponibilidade Haacute uma dificuldade de se
trabalhar de forma eficiente
com a distribuiccedilatildeo de dados
por causa de sua natureza
estruturada situaccedilotildees em
que exigem uma maior
demanda de um sistema que
utilizem esse modelo podem
natildeo ser bem suportadas por
ele
Considerada outra das
grandes vantagens do
modelo essa propriedade
junto com o alto grau de
distribuiccedilatildeo desse modelo
possibilita que o sistema
fique um menor periacuteodo de
tempo natildeoshydisponiacutevel assim
como tambeacutem permite que a
solicitaccedilatildeo aos dados por um
nuacutemero crescente de clientes
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1629
seja atendida
Toleracircncia a
Particionamento
Por natildeo terem sido
construiacutedo com a finalidade
de trabalhar com
particionamento de dados
este modelo natildeo possui um
grau muito alto de toleracircncia
ao particionamento cuja
razatildeo principal seria a
dificuldade de junccedilotildees entre
as tabelas
Trabalha de forma faacutecil e
eficiente com a distribuiccedilatildeo
de dados Este modelo eacute
capaz de suportar grandes
demandas de dados assim
como possui alta toleracircncia
ao particionamento dos
mesmos
Tabela 2 Anaacutelise 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 verificaccedilatildeo contiacutenua
da consistecircncia de cada transaccedilatildeo adiciona custos consideraacuteveis para um sistema
que tem milhares de transaccedilotildees ocorrendo
A consistecircncia eventual promovida pelo modelo BASE daacute agraves organizaccedilotildees a
capacidade de interagir com os clientes de forma contiacutenua com a necessaacuteria
disponibilidade e toleracircncia a particcedilatildeo mantendo baixos custos e o sistema rodando
sem interrupccedilotildees Sem duacutevida seria excelente ter consistecircncia completa o tempo
todo mas eacute preciso haver compensaccedilotildees e a consistecircncia eventual permite o
desenvolvimento eficaz de sistemas que podem lidar com o aumento exponencial de
dados devido agraves redes sociais computaccedilatildeo em nuvem e outros projetos de Big Data
Estudo de Caso shy MongoDBPara fins comparativos seratildeo analisadas nesta seccedilatildeo algumas diferenccedilas entre um
banco NoSQL o MongoDB e os bancos relacionais baseados em SQL O MongoDB eacute
um banco de dados NoSQL criado em 2009 pela empresa 10gen orientado a
documentos altamente escalaacutevel de alta performance e de coacutedigo aberto O
cofundador e diretor de tecnologia da 10gen define o MongoDB da seguinte forma ldquoO
MongoDB natildeo foi concebido em um laboratoacuterio
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1729
Noacutes construiacutemos o MongoDB com base em nossas experiecircncias na construccedilatildeo de
sistemas robustos de grande escala e alta disponibilidade Natildeo comeccedilamos do zero
noacutes tentamos descobrir o que estava problemaacutetico e solucionamos isso
Assim o que eu penso sobre MongoDB eacute que se vocecirc pegar o MySQL e alterar o
modelo de dados do relacional para orientado a documento vocecirc ganha uma grande
quantidade de recursos documentos embarcados para melhorar velocidade
facilidade de gerenciamento desenvolvimento aacutegil com bancos de dados sem
ldquoschemardquo escalabilidade horizontal mais faacutecil pois ldquojoinsrdquo natildeo satildeo tatildeo importantes
Haacute muitas coisas que funcionam muito bem nos bancos de dados relacionais iacutendices
consultas dinacircmicas e atualizaccedilotildees e noacutes natildeo mudamos muito neste ponto Por
exemplo a maneira de projetar seus iacutendices no MongoDB deve ser exatamente do
jeito que vocecirc faz isso no MySQL ou Oracle vocecirc soacute ganha a opccedilatildeo de indexar um
campo embarcadordquo
Como dito na seccedilatildeo de modelos de bancos de dados NoSQL um banco orientado a
documentos natildeo possui esquemas riacutegidos e estruturados sendo possiacutevel que ocorra
uma atualizaccedilatildeo na estrutura do documento Portanto inserir novos campos no
documento natildeo 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 coleccedilatildeo
iacutendice iacutendice
linha documento BSON
coluna campo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1829
joins documentos incorporados e vinculaccedilatildeo
primary key
(Especifica qualquer combinaccedilatildeo de colunas
ou coluna uacutenica como chave primaacuteria)
primary key
(No MongoDB a chave primaacuteria eacute definida
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 dinacircmicos ou seja sem a
necessidade de que cada registro tenha a mesma estrutura Estas estruturas satildeo
chamadas de coleccedilotildees (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 sobrenomeSilva idade22 bairroPituba
Outro documento para representar um aluno na mesma coleccedilatildeo
aluno2=nomeLiardquo sobrenomeSaacute cursoDireito materias[Civil Penal]
Podeshyse ter registros diferentes um do outro dentro de uma mesma coleccedilatildeo Parece
estranho este tipo de abordagem mas no modelo relacional usamos isto o tempo
inteiro e de maneira ineficiente com a formaccedilatildeo de tabelas esparsas
Estas satildeo tabelas incompletas onde algumas colunas satildeo sempre preenchidas e
outras nem sempre satildeo usadas Para ilustrar isto observe a Tabela 4 que apresenta
registros da construccedilatildeo civil
Coacutedigo Produto Altura Potecircncia Peso Diacircmetro
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1929
1 Britadeira 300cv 100kg
2 Cimento
3 Empilhadeira 15cv 300kg
4 Escada 3m
5 Tubulaccedilatildeo 20cm
Tabela 4 Cadastro de produtos da construccedilatildeo civil em banco de dados modelo
relacional
Neste exemplo haacute uma desvantagem no modelo relacional Haacute colunas cujo valor eacute
preenchido apenas uma vez como pode ser visto no exemplo das colunas Altura e
Diacircmetro Na construccedilatildeo das tabelas ao incluir colunas que satildeo pouco utilizadas
jogashyse fora espaccedilo de armazenamento e reduzshyse o desempenho do sistema como
um todo E ainda tratamos objetos diferentes como se fossem iguais o que nem
sempre eacute uma boa praacutetica Abaixo o exemplo de como ficaria este cadastro de
produtos no modelo documental
codigo1 produtoBritadeira potencia300cv peso100kg
codigo2 produtoCimento
codigo3 produtoEmpilhadeira potencia15cv peso300kg
codigo4 produtoEscada altura3m
codigo5 produtoTubulaccedilatildeo diametro20cm
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
Seratildeo apresentados agora alguns comandos comuns usados no MongoDB Voltando
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2029
ao primeiro exemplo de documento criado para alunos observe como ficaria o
comando para salvar os alunos em uma coleccedilatildeo
dbunifacssave(aluno1)
dbunifacssave(aluno2)
O comando acima salva os documentos aluno1 e aluno2 na coleccedilatildeo ldquounifacsrdquo Eacute
possiacutevel acessar os dados de uma coleccedilatildeo atraveacutes do comando find() basicamente
ele vai percorrer todos os registros da coleccedilatildeo e retornar os documentos listados No
exemplo dado o comando seria dbunifacsfind() E para apagar tudo que existe na
coleccedilatildeo dbunifacsremove()
Natildeo eacute necessaacuterio que se crie uma coleccedilatildeo ou mesmo que se configure uma estrutura
isso eacute feito automaticamente quando o primeiro registro eacute incluiacutedo No entanto eacute
possiacutevel usar o comando de criar uma coleccedilatildeo e isto pode ser utilizado para preacuteshy
atribuir espaccedilo para uma coleccedilatildeo Uma coleccedilatildeo de tamanho fixo usa o comando
ldquocappedrdquo e vem a substituir automaticamente as entradas mais antigas quando
atinge seu tamanho maacuteximo
Todas as coleccedilotildees limitadas e fixas devem especificar um tamanho maacuteximo e
tambeacutem podem especificar um nuacutemero maacuteximo de documentos O MongoDB remove
os documentos antigos se uma coleccedilatildeo atinge o limite de tamanho maacuteximo antes
que ele atinja a contagem maacutexima de documentos Considere o seguinte exemplo
dbcreateCollection (unifacs capped true size 5242880 max 5000)
Este comando cria uma coleccedilatildeo nomeada de ldquounifacsrdquo com uma dimensatildeo maacutexima
de 5 megabytes e um maacuteximo de 5000 documentos
Para visualizar todas as coleccedilotildees de um banco de dados MongoDB utilizashyse o
seguinte comando
dbgetCollectionNames()
Enfim haacute muitas diferenccedilas entre os comandos usados no MongoDB e no MySQL As
quatro operaccedilotildees baacutesicas usadas para criaccedilatildeo consulta atualizaccedilatildeo e destruiccedilatildeo de
dados conhecidas como CRUD (Create Read Update e Delete) apresentam
comandos bem distintos nos dois tipos de bancos em questatildeo A Tabela 5 compara
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2129
alguns comandos de CRUD em ambos os bancos
MySQL MongoDB
CREATE TABLE unifacs (
id MEDIUMINT NOT NULL
AUTO_INCREMENT
matricula Number
nome Varchar(30)
idade Number
PRIMARY KEY (id)
)
A coleccedilatildeo eacute criada implicitamente na primeira
inserccedilatildeo de dados O _id chave primaacuteria eacute
adicionada automaticamente se o campo _id natildeo
eacute especificado
dbunifacsinsert (
matricula 04217253
nome Paulo
idade 22
)
ALTER TABLE unifacs
ADD join_date DATETIME
Coleccedilotildees natildeo descrevem ou forccedilam a estrutura
dos seus documentos No entanto no niacutevel do
documento operaccedilotildees de update () podem
adicionar campos para documentos existentes
usando o operador $set e remover usando
$unset
dbunifacsupdate (
$set join_date new Date ()
multi true
)
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2229
ALTER TABLE unifacs
DROP COLUMN join_date
dbunifacsupdate(
$unset join_date
multi true
)
INSERT INTO unifacs (matricula nome
idade)
VALUES (032104211 ldquoJoanardquo 21)
dbunifacsinsert(
matricula 032104211 nome ldquoJoanardquo idade
21
)
SELECT FROM unifacs dbunifacsfind()
SELECT FROM unifacs WHERE idade =
21dbunifacsfind( idade 21 )
SELECT FROM unifacs WHERE nome =
ldquoJoanardquo
AND idade = 21
dbunifacsfind( nome ldquoJoanardquo idade 21 )
SELECT FROM unifacs WHERE idade gt
20dbunifacsfind( age $gt 20 )
SELECT COUNT() FROM unifacs
dbuserscount()
ou
dbunifacsfind()count()
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2329
UPDATE unifacs SET status = ldquoAprovadordquo
WHERE nota gt 7
dbunifacsupdate( nota $gt 7
$set status ldquoAprovadordquo multi true )
UPDATE unifacs SET nota = nota + 1
WHERE status = Aprovado
dbunifacsupdate( status Aprovado
$inc nota 1 multi true )
DELETE FROM unifacs WHERE status =
Reprovadodbunifacsremove( status Reprovado )
Tabela 5 Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
Eacute importante saber que cada documento de uma coleccedilatildeo no MongoDB tem um
tamanho maacuteximo de 16MB o que eacute mais do que suficiente para armazenar dados em
um documento No entanto o MongoDB ainda eacute capaz de armazenar arquivos no
banco de dados em uma coleccedilatildeo especifica que eacute a coleccedilatildeo do tipo GridFS
Ela eacute ideal para trabalhar com arquivos maiores de imagens viacutedeo e aacuteudio O GridFS
divide o arquivo em partes ou pedaccedilos e salva cada pedaccedilo em um documento
separado Quando vocecirc consulta um arquivo no GridFS eacute preciso remontar os
pedaccedilos conforme a necessidade
O MongoDB atinge o objetivo de ser amigaacutevel para o desenvolvedor Possui uma
documentaccedilatildeo bem escrita para a maioria dos principais idiomas Sua consulta
baseada em JavaScript eacute faacutecil para os desenvolvedores da Web e ele tambeacutem eacute faacutecil
de instalar Por estas razotildees o MongoDB eacute uma oacutetima opccedilatildeo de tecnologia para uso
em uma aplicaccedilatildeo
Um exemplo do sucesso deste banco eacute o depoimento do especialista em banco de
dados da Globocom Franklin Amorim Em um evento sobre o MongoDB em 2011 na
cidade de Satildeo Paulo Franklin apresentou o case de sucesso da adoccedilatildeo do MongoDB
para uma nova funccedilatildeo do ldquofantasy gamerdquo CartolaFC
O jogo eacute maior aplicaccedilatildeo dinacircmica do portal Globocom com mais de 2 milhotildees de
usuaacuterios cadastrados e quase 90 milhotildees de pageviews somente em um mecircs
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 329
diferenccedilas identificadas entre os dois modelos
SGBDs RelacionaisO banco de dados no modelo relacional foi proposto por Edgar Codd um pesquisador
da IBM em torno de 1970 Desde entatildeo se tornou o modelo de banco de dados
dominante para aplicaccedilotildees comerciais Hoje haacute 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 relaccedilotildees Uma tabela
eacute composta de linhas e colunas As linhas tambeacutem satildeo chamadas de registros ou
tuplas As colunas tambeacutem satildeo chamadas de campo ou atributo Uma tabela de
banco de dados eacute semelhante a uma folha de caacutelculo
No entanto as relaccedilotildees 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 caracteriacutestica importante deste modelo eacute o uso de elementos para garantir a
integridade dos dados As restriccedilotildees mais comuns satildeo as chaves primaacuterias e as
estrangeiras O termo chave primaacuteria eacute utilizado para identificar o atributo que foi
escolhido pelo projetista do banco para identificar unicamente os registros que satildeo
armazenados em uma determinada tabela
Nenhum registro pode ter o mesmo valor no campo chave primaacuteria de uma
determinada tabela do banco de dados por isso os atributos chaves devem ser
selecionados com muito cuidado Jaacute a chave estrangeira transforma o valor de um
atributo dependente do valor existente em outro atributo normalmente de outra
tabela criando uma relaccedilatildeo de dependecircncia entre atributos de tabelas distintas
As chaves satildeo muito utilizadas em bancos de dados relacionais inclusive para a
criaccedilatildeo de outros componentes como os iacutendices que satildeo usados para melhorar o
desempenho de consultas no banco
Para projetar corretamente as tabelas de um banco de dados relacional temos um
conjunto de orientaccedilotildees que ajudam a reduzir a redundacircncia e chance de corrupccedilatildeo
de dados Eacute o que chamamos de normalizaccedilatildeo As regras de normalizaccedilatildeo satildeo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 429
projetadas para evitar anomalias de atualizaccedilatildeo e inconsistecircncias de dados e ao
mesmo tempo para permitir uma recuperaccedilatildeo mais faacutecil de informaccedilotildees
A linguagem chamada SQL foi desenvolvida para trabalhar com bancos de dados
relacionais Inspirada na aacutelgebra relacional e desenvolvida pela IBM o SQL eacute uma
linguagem declarativa para banco de dados
A facilidade de uso e simplicidade de expressatildeo 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 satildeo as propriedades ACID A sigla
significa Atomicidade Consistecircncia Isolamento e Durabilidade As propriedades ACID
de um SGBD permitem o compartilhamento seguro de dados oferecendo otimizaccedilatildeo
de consultas recuperaccedilatildeo de falhas validaccedilatildeo controle de concorrecircncia e
verificaccedilatildeo de integridade dos dados
Todas essas caracteriacutesticas e recursos deram ao Modelo Relacional de banco de
dados uma posiccedilatildeo de destaque e predominacircncia 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
Limitaccedilotildees do Modelo RelacionalO Walmart um gigante do varejo trabalha com mais de 1 milhatildeo de transaccedilotildees de
clientes por hora alimentando bancos de dados estimados em mais de 25
petabytes Jaacute o Facebook possui em seu banco cerca de 40 bilhotildees de fotos Estes
satildeo exemplos que mostram que o mundo conteacutem enorme quantidade de informaccedilatildeo
digital e que este volume de informaccedilotildees e dados estaacute ficando cada vez maior
rapidamente
Este eacute um dos principais problemas encontrados com a utilizaccedilatildeo do Modelo
Relacional a dificuldade em se usar esse modelo com uma demanda por
escalabilidade cada vez maior As aplicaccedilotildees web que usam banco de dados
relacional vecircm sofrendo com o grande volume de dados e problemas de
desempenho
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 529
Para solucionar tais problemas de escalabilidade geralmente se recorre a duas
alternativas o aumento do nuacutemero de servidores (escalonamento horizontal) ou a
realizaccedilatildeo de um upgrade no servidor (escalonamento vertical)
Isto natildeo eacute o suficiente caso o volume de informaccedilotildees continue a crescer em ritmo
acelerado Com o constante crescimento dos dados a soluccedilatildeo passa a ser escalar o
banco de dados em sistemas distribuiacutedos
Entretanto por causa da natureza estruturada do modelo relacional os
administradores de bancos de dados perceberam uma dificuldade em organizar as
informaccedilotildees em sistemas distribuiacutedos particionando os dados em maacutequinas
diferentes Manusear tabelas em diferentes servidores eacute muito difiacutecil e problemaacutetico
Por conta disso comeccedilam a surgir as soluccedilotildees natildeo relacionais
NoSQLOs desenvolvedores comeccedilaram a pensar em um modelo alternativo para modelar as
bases de dados frente agraves dificuldades encontradas no modelo relacional As soluccedilotildees
propostas para a melhoria de desempenho visavam evitar a riacutegida e tradicional
estrutura usada no modelo relacional
O objetivo dos projetistas de banco de dados das grandes organizaccedilotildees era
desenvolver uma nova maneira de armazenar as informaccedilotildees flexibilizando o banco
de dados para as caracteriacutesticas particulares de sua empresa
Esta flexibilidade eacute fundamental para atender aos requisitos dos sistemas
distribuiacutedos em larga escala permitindo escalabilidade e alta disponibilidade para as
aplicaccedilotildees 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 coacutedigo aberto que natildeo possuiacutea
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
natildeo atendia aos requisitos pretendidos Eacute um movimento totalmente adepto ao
coacutedigo aberto
A intenccedilatildeo do NoSQL natildeo eacute substituir o tradicional modelo relacional e sim ser uma
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 629
alternativa para as empresas que necessitam de um modelo de banco de dados mais
flexiacutevel para suportar o seu volume de dados
A constante tendecircncia de computaccedilatildeo em nuvem e o crescimento das redes sociais
satildeo fatores importantes que levam ao desenvolvimento de armazenamento NoSQL
Apesar da existecircncia de muitos bancos de dados NoSQL o movimento ganhou forccedila
quando grandes empresas da tecnologia passaram a usar suas proacuteprias
implementaccedilotildees a fim de fornecer serviccedilos para seus sistemas distribuiacutedos
Buscando atender suas necessidades de armazenamento em 2004 o Google criou o
BigTable
Na sequecircncia buscando tambeacutem a alta disponibilidade a Amazon lanccedilou o Dynamo
Em 2008 o Facebook desenvolveu o Cassandra para tratar o grande volume de
dados e este se mostrou tatildeo eficiente que em 2010 o Twitter deixou o MySQL de
lado para usaacuteshylo
Outras soluccedilotildees lanccediladas satildeo o Apache CouchDB e o MongoDB que satildeo banco de
dados orientados a documentos e com caracteriacutesticas bem semelhantes como alta
performance e escalaacuteveis projetados para suportar sistemas distribuiacutedos em larga
escala
Todos os bancos citados satildeo considerados NoSQL possuem caracteriacutesticas
semelhantes mas tambeacutem possuem particularidades que os diferenciam A proacutexima
seccedilatildeo aborda justamente os diferentes modelos de bancos de dados NoSQL
mostrando suas caracteriacutesticas
31 Modelos de BD NoSQLMais e mais organizaccedilotildees tecircm adotado soluccedilotildees NoSQL para apoiar seus projetos
Estas soluccedilotildees apresentam caracteriacutesticas em comum como uma maior
escalabilidade e alta disponibilidade mas tambeacutem apresentam diversas
singularidades Os bancos de dados NoSQL satildeo subdivididos pela maneira como
armazenam as informaccedilotildees Os principais tipos satildeo Armazenamento ChaveshyValor
(KeyValue) Documento Coluna e Grafo
A soluccedilatildeo chaveshyvalor armazena qualquer coisa como pares de valoresshychave o que
implica valores armazenados recuperados por chaves uacutenicas Satildeo capazes de
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 729
armazenar grandes quantidades de dados e no entanto mantecircm o acesso simples
por uma chave primaacuteria
Este tipo de armazenamento funciona bem para listas como as categorias de
produtos os atributos de cada produto carrinho de compras conteuacutedos ou valores
individuais etc
Por conta disto o Amazon Dynamo eacute uma soluccedilatildeo que adota este modelo Os dados
deste sistema satildeo particionados e replicados usando hashing consistente a fim de
fornecer a escalabilidade e disponibilidade
O segundo modelo de soluccedilatildeo muda o tradicional paradigma de orientaccedilatildeo a
registros (ou tuplas) para orientaccedilatildeo a colunas (ou atributos) Aqui os dados seguem
uma indexaccedilatildeo tripla (linha coluna e timestamp) onde as linhas e as colunas satildeo
identificadas por chaves e o timestamp possibilita a diferenciaccedilatildeo de muacuteltiplas
versotildees de um mesmo dado
Alguns modelos deste tipo de armazenamento possuem colunas (registros que
possuem nome valor e timestamp) famiacutelias de colunas (uma coleccedilatildeo de colunas
equivalente a uma tabela do Modelo Relacional) e supershycolunas (formadas por
arrays de colunas)
O conceito de famiacutelia de colunas pode ser observado na Figura 1 onde
primeiroNome e sobrenome satildeo colunas pertencentes agrave famiacutelia de colunas
denominada nome e as colunas endereccedilo e cidade pertencem agrave famiacutelia local Dois
grandes exemplos de sistemas orientados a coluna satildeo o Cassandra e o BigTable
Figura 1 Exemplo de modelo baseado em colunas
Jaacute uma soluccedilatildeo baseada em documento eacute um tipo de banco de dados que armazena
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 829
coleccedilotildees de documentos Os documentos satildeo representados como objetos com um
uacutenico identificador e um conjunto de campos que podem ser strings listas ou
documentos aninhados Como esta base de dados eacute semiestruturada e natildeo possui
esquema uma informaccedilatildeo especiacutefica 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 temshyse 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 trecircs
componentes baacutesicos os veacutertices (satildeo os noacutes do grafo) as arestas (satildeo os
relacionamentos entre os noacutes) e os atributos dos noacutes e relacionamentos Os dados
satildeo armazenados nos noacutes do grafo e as arestas representam o tipo de associaccedilatildeo
entre eles
Novas arestas podem ser adicionadas (ou as antigas removidas) a qualquer
momento permitindo que relaccedilotildees 1shyN (um para muitos) e NshyN (muitos para muitos)
sejam expressas de forma faacutecil Construccedilotildees como amigos seguidores graus de
separaccedilatildeo listas satildeo muito naturalmente acomodadas em bancos de dados do tipo
grafo
A Figura 3 representa um exemplo de grafo de uma aplicaccedilatildeo que possui
informaccedilotildees 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
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 929
No exemplo da figura temos trecircs pessoas que satildeo noacutes do grafo e estatildeo conectados agrave
cidades que ou jaacute visitaram ou moraram Atraveacutes da representaccedilatildeo do grafo fica faacutecil
perceber que Maria e Joseacute jaacute visitaram o Rio de Janeiro
E que Joatildeo jaacute morou em Recife e Salvador Um exemplo de banco de dados baseado
em grafo eacute o Neo4j que eacute openshysource e implementado em Java
Figura 3 Exemplo de modelo baseado em grafo
Eacute importante ressaltar que nenhum dos modelos apresentados deve ser considerado
superior ao outro pois tudo depende da necessidade da aplicaccedilatildeo Eacute importante que
os desenvolvedores conheccedilam os diversos modelos de soluccedilatildeo para que seja
adotado aquele que mais se adequar ao que a aplicaccedilatildeo ou empresa precisa Isto
contribui para a diminuiccedilatildeo do custo de criaccedilatildeo do banco de dados e com o aumento
do desempenho no processamento dos dados
A Tabela 1 apresenta uma comparaccedilatildeo dos modelos apresentados destacando suas
principais vantagens e desvantagens e ainda citando seus principais exemplos e
suas disponibilidades
Tipo Vantagem Desvantagem Exemplos Disponibilidade
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1029
ChaveValor
Simplicidade
e
escalabilidade
Falta recursos
mais
avanccedilados de
consulta
Amazon
DynamoDB
O niacutevel gratuito da AWS inclui 100
MB de armazenamento 5 unidades
de capacidade de gravaccedilatildeo e 10
unidades de capacidade de leitura
com o Amazon DynamoDB
Disponiacutevel em
httpawsamazoncomptdynamodb
DocumentoFacilidade de
uso
Natildeo eacute
adequado para
dados
relacionais
Consulta
limitada a
chaves e
iacutendices
MongoDB
CouchDB
Como a maioria das licenccedilas de
software livre permite seja usado
modificado e distribuiacutedo por usuaacuterios
Podeshyse adquirir o MongoDB em
httpwwwmongodborg
e CouchDB
httpcouchdbapacheorg
ColunaEscalabilidade
e flexibilidadeComplexidade
Google Big
Table
Cassandra
BigTable foi desenvolvida no Google
em tem sido usado desde 2005 em
dezenas de serviccedilos do Google Uma
versatildeo de coacutedigo aberto HBase foi
criado pelo Apache
httphbaseapacheorg
Jaacute o Cassandra tambeacutem pode ser
adquirido de forma gratuita
httpcassandraapacheorg
Grafo
Modelo de
dados
poderoso e
raacutepido
Flexibilidade
Neo4j Como os demais acima o Neo4j
tambeacutem estaacute disponiacutevel para
download em httpwwwneo4jorg
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1129
Tabela 1 Anaacutelise comparativa dos modelos de BD NoSQL
Modelo Relacional x NoSQLAo se comparar os modelos em questatildeo uma grande diferenccedila a se notar eacute que as
tecnologias relacionais tecircm esquemas riacutegidos enquanto os modelos NoSQL satildeo
schemashyfree ou seja sem esquema O modelo relacional requer uma definiccedilatildeo
estrita de um esquema antes de armazenar todos os dados em um banco de dados
Alterar o esquema uma vez que os dados jaacute estatildeo inseridos eacute muito complicado e
por isso evitado No entanto isto eacute exatamente o oposto do comportamento
desejado na era ldquoBig Datardquo 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 trecircs criteacuterios satildeo
considerados relevantes para esta escolha escalonamento consistecircncia de dados e
disponibilidade E eacute isto que seraacute abordado a partir de agora
Basicamente pelo fato de terem sido criados para essa finalidade os bancos NoSQL
apresentam vantagens em relaccedilatildeo 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 cenaacuterios em que o escalonamento eacute
necessaacuterio
Eacute possiacutevel tornar um banco de dados relacional mais escalaacutevel atraveacutes da teacutecnica de
escalonamento vertical onde eacute feita uma atualizaccedilatildeo (upgrade) no servidor de
bancos de dados
Poreacutem este escalonamento fica limitado agrave capacidade de uma uacutenica maacutequina Jaacute o
escalonamento horizontal eacute feito com o aumento da quantidade de servidores que
iratildeo disponibilizar os dados paralelamente (Figura 4) facilitando o acesso aos dados
e garantindo que a queda de um servidor natildeo seja um problema de disponibilidade
dos dados
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1229
Figura 4 O uso do escalonamento horizontal
Outra caracteriacutestica a favor do NoSQL eacute o uso do sharding que consiste em trabalhar
com o escalonamento horizontal particionando e paralelizando seus dados em vaacuterios
servidores (Figura 5) Essa teacutecnica eacute complexa para se usar em SGBDs relacionais
devido a toda a sua estrutura loacutegica e devido ao uso da desnormalizaccedilatildeo dos dados
o contraacuterio usado no modelo relacional
O sharding traz benefiacutecios pois conjuntos de dados menores satildeo mais faacuteceis de
serem acessados atualizados e gerenciados O maior benefiacutecio em comparaccedilatildeo ao
modelo relacional eacute a otimizaccedilatildeo do grau de disponibilidade do sistema pois como
jaacute dito anteriormente a queda de uma maacutequina natildeo causaria a interrupccedilatildeo de todo o
sistema
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1329
Figura 5 Teacutecnica de sharding
O controle de concorrecircncia tambeacutem funciona de maneira distinta nos modelos em
questatildeo O modelo relacional utiliza bloqueios (locks) como garantia de que dois
usuaacuterios natildeo atualizem o mesmo dado ao mesmo tempo Jaacute no modelo NoSQL satildeo
usadas outras estrateacutegias para permitir um maior grau de concorrecircncia
Alguns bancos NoSQL usam o MVCC (Multiversion Concurrency Control) ou Controle
de Concorrecircncia Multishyversotildees Nesta teacutecnica o acesso aos dados pode ser realizado
em paralelo
Cada usuaacuterio que se conecta ao banco de dados visualiza uma coacutepia temporaacuteria do
banco de dados naquele instante Qualquer atualizaccedilatildeo que esteja sendo feita em
determinado momento por um usuaacuterio natildeo seraacute vista pelos demais que estatildeo
operando simultaneamente no banco de dados ateacute que a atualizaccedilatildeo tenha sido
concluiacuteda
Quando se opta por usar um modelo NoSQL haacute ganhos de performance flexibilidade
e disponibilidade mas haacute uma perda de consistecircncia Haacute um teorema na ciecircncia da
computaccedilatildeo criado Eric Brewer chamado Teorema CAP (Consistency Availability e
Partition Tolerance) que diz ser impossiacutevel para um sistema distribuiacutedo garantir
consistecircncia disponibilidade e toleracircncia ao particionamento De forma simultacircnea
soacute eacute possiacutevel conseguir duas destas trecircs caracteriacutesticas Vejamos exemplos de
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1429
SGBDs na Figura 6 segundo o Teorema CAP
Figura 6 Distribuiccedilatildeo relativa de alguns bancos de dados quanto ao Teorema CAP
As soluccedilotildees NoSQL seguem um paradigma denominado BASE (Basically Available
Soft state Eventual consistency) Este tem como caracteriacutesticas estar basicamente
disponiacutevel o tempo todo estar em estado leve ou seja natildeo sendo consistente o
tempo todo e possuir uma consistecircncia eventual o sistema se torna consistente no
momento apropriado
O modelo BASE eacute um contraste ao paradigma ACID (Atomicity Consistency
Isolation Durability) comumente associado aos bancos de dados de modelo
relacional Ao contraacuterio do modelo ACID que promove uma seguranccedila dos dados
forccedilando a consistecircncia ao final de cada operaccedilatildeo o modelo BASE permite que o
banco de dados esteja em um estado eventualmente consistente
A disponibilidade do modelo BASE estaacute associada justamente ao fato de que a falha
de uma maacutequina do sistema natildeo interrompe o sistema como um todo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1529
Para se analisar de forma mais raacutepida e comparativa a Tabela 2 apresenta as
principais caracteriacutesticas de ambos os modelos discutidos aqui
Modelo Relacional NoSQL
Escalonamento Possui sua natureza
estruturada e por conta disto
o escalonamento de bancos
tende a ser uma tarefa
complexa
Eacute livre de esquemas por isso
o NoSQL possui uma maior
flexibilidade e alta
escalabilidade considerada
uma das principais vantagens
desse modelo
Consistecircncia Possui uma estrutura mais
riacutegida e garante em suas
transaccedilotildees a existecircncia dessa
propriedade As diversas
regras deste modelo
possibilitam uma maior
rigidez quanto a garantia de
consistecircncia dos dados
sendo este o ponto mais
forte desse modelo
A consistecircncia nesse modelo
possui um caraacuteter eventual
o que natildeo garante que uma
determinada atualizaccedilatildeo em
um dado momento seja
percebida por todos os noacutes
Disponibilidade Haacute uma dificuldade de se
trabalhar de forma eficiente
com a distribuiccedilatildeo de dados
por causa de sua natureza
estruturada situaccedilotildees em
que exigem uma maior
demanda de um sistema que
utilizem esse modelo podem
natildeo ser bem suportadas por
ele
Considerada outra das
grandes vantagens do
modelo essa propriedade
junto com o alto grau de
distribuiccedilatildeo desse modelo
possibilita que o sistema
fique um menor periacuteodo de
tempo natildeoshydisponiacutevel assim
como tambeacutem permite que a
solicitaccedilatildeo aos dados por um
nuacutemero crescente de clientes
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1629
seja atendida
Toleracircncia a
Particionamento
Por natildeo terem sido
construiacutedo com a finalidade
de trabalhar com
particionamento de dados
este modelo natildeo possui um
grau muito alto de toleracircncia
ao particionamento cuja
razatildeo principal seria a
dificuldade de junccedilotildees entre
as tabelas
Trabalha de forma faacutecil e
eficiente com a distribuiccedilatildeo
de dados Este modelo eacute
capaz de suportar grandes
demandas de dados assim
como possui alta toleracircncia
ao particionamento dos
mesmos
Tabela 2 Anaacutelise 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 verificaccedilatildeo contiacutenua
da consistecircncia de cada transaccedilatildeo adiciona custos consideraacuteveis para um sistema
que tem milhares de transaccedilotildees ocorrendo
A consistecircncia eventual promovida pelo modelo BASE daacute agraves organizaccedilotildees a
capacidade de interagir com os clientes de forma contiacutenua com a necessaacuteria
disponibilidade e toleracircncia a particcedilatildeo mantendo baixos custos e o sistema rodando
sem interrupccedilotildees Sem duacutevida seria excelente ter consistecircncia completa o tempo
todo mas eacute preciso haver compensaccedilotildees e a consistecircncia eventual permite o
desenvolvimento eficaz de sistemas que podem lidar com o aumento exponencial de
dados devido agraves redes sociais computaccedilatildeo em nuvem e outros projetos de Big Data
Estudo de Caso shy MongoDBPara fins comparativos seratildeo analisadas nesta seccedilatildeo algumas diferenccedilas entre um
banco NoSQL o MongoDB e os bancos relacionais baseados em SQL O MongoDB eacute
um banco de dados NoSQL criado em 2009 pela empresa 10gen orientado a
documentos altamente escalaacutevel de alta performance e de coacutedigo aberto O
cofundador e diretor de tecnologia da 10gen define o MongoDB da seguinte forma ldquoO
MongoDB natildeo foi concebido em um laboratoacuterio
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1729
Noacutes construiacutemos o MongoDB com base em nossas experiecircncias na construccedilatildeo de
sistemas robustos de grande escala e alta disponibilidade Natildeo comeccedilamos do zero
noacutes tentamos descobrir o que estava problemaacutetico e solucionamos isso
Assim o que eu penso sobre MongoDB eacute que se vocecirc pegar o MySQL e alterar o
modelo de dados do relacional para orientado a documento vocecirc ganha uma grande
quantidade de recursos documentos embarcados para melhorar velocidade
facilidade de gerenciamento desenvolvimento aacutegil com bancos de dados sem
ldquoschemardquo escalabilidade horizontal mais faacutecil pois ldquojoinsrdquo natildeo satildeo tatildeo importantes
Haacute muitas coisas que funcionam muito bem nos bancos de dados relacionais iacutendices
consultas dinacircmicas e atualizaccedilotildees e noacutes natildeo mudamos muito neste ponto Por
exemplo a maneira de projetar seus iacutendices no MongoDB deve ser exatamente do
jeito que vocecirc faz isso no MySQL ou Oracle vocecirc soacute ganha a opccedilatildeo de indexar um
campo embarcadordquo
Como dito na seccedilatildeo de modelos de bancos de dados NoSQL um banco orientado a
documentos natildeo possui esquemas riacutegidos e estruturados sendo possiacutevel que ocorra
uma atualizaccedilatildeo na estrutura do documento Portanto inserir novos campos no
documento natildeo 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 coleccedilatildeo
iacutendice iacutendice
linha documento BSON
coluna campo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1829
joins documentos incorporados e vinculaccedilatildeo
primary key
(Especifica qualquer combinaccedilatildeo de colunas
ou coluna uacutenica como chave primaacuteria)
primary key
(No MongoDB a chave primaacuteria eacute definida
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 dinacircmicos ou seja sem a
necessidade de que cada registro tenha a mesma estrutura Estas estruturas satildeo
chamadas de coleccedilotildees (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 sobrenomeSilva idade22 bairroPituba
Outro documento para representar um aluno na mesma coleccedilatildeo
aluno2=nomeLiardquo sobrenomeSaacute cursoDireito materias[Civil Penal]
Podeshyse ter registros diferentes um do outro dentro de uma mesma coleccedilatildeo Parece
estranho este tipo de abordagem mas no modelo relacional usamos isto o tempo
inteiro e de maneira ineficiente com a formaccedilatildeo de tabelas esparsas
Estas satildeo tabelas incompletas onde algumas colunas satildeo sempre preenchidas e
outras nem sempre satildeo usadas Para ilustrar isto observe a Tabela 4 que apresenta
registros da construccedilatildeo civil
Coacutedigo Produto Altura Potecircncia Peso Diacircmetro
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1929
1 Britadeira 300cv 100kg
2 Cimento
3 Empilhadeira 15cv 300kg
4 Escada 3m
5 Tubulaccedilatildeo 20cm
Tabela 4 Cadastro de produtos da construccedilatildeo civil em banco de dados modelo
relacional
Neste exemplo haacute uma desvantagem no modelo relacional Haacute colunas cujo valor eacute
preenchido apenas uma vez como pode ser visto no exemplo das colunas Altura e
Diacircmetro Na construccedilatildeo das tabelas ao incluir colunas que satildeo pouco utilizadas
jogashyse fora espaccedilo de armazenamento e reduzshyse o desempenho do sistema como
um todo E ainda tratamos objetos diferentes como se fossem iguais o que nem
sempre eacute uma boa praacutetica Abaixo o exemplo de como ficaria este cadastro de
produtos no modelo documental
codigo1 produtoBritadeira potencia300cv peso100kg
codigo2 produtoCimento
codigo3 produtoEmpilhadeira potencia15cv peso300kg
codigo4 produtoEscada altura3m
codigo5 produtoTubulaccedilatildeo diametro20cm
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
Seratildeo apresentados agora alguns comandos comuns usados no MongoDB Voltando
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2029
ao primeiro exemplo de documento criado para alunos observe como ficaria o
comando para salvar os alunos em uma coleccedilatildeo
dbunifacssave(aluno1)
dbunifacssave(aluno2)
O comando acima salva os documentos aluno1 e aluno2 na coleccedilatildeo ldquounifacsrdquo Eacute
possiacutevel acessar os dados de uma coleccedilatildeo atraveacutes do comando find() basicamente
ele vai percorrer todos os registros da coleccedilatildeo e retornar os documentos listados No
exemplo dado o comando seria dbunifacsfind() E para apagar tudo que existe na
coleccedilatildeo dbunifacsremove()
Natildeo eacute necessaacuterio que se crie uma coleccedilatildeo ou mesmo que se configure uma estrutura
isso eacute feito automaticamente quando o primeiro registro eacute incluiacutedo No entanto eacute
possiacutevel usar o comando de criar uma coleccedilatildeo e isto pode ser utilizado para preacuteshy
atribuir espaccedilo para uma coleccedilatildeo Uma coleccedilatildeo de tamanho fixo usa o comando
ldquocappedrdquo e vem a substituir automaticamente as entradas mais antigas quando
atinge seu tamanho maacuteximo
Todas as coleccedilotildees limitadas e fixas devem especificar um tamanho maacuteximo e
tambeacutem podem especificar um nuacutemero maacuteximo de documentos O MongoDB remove
os documentos antigos se uma coleccedilatildeo atinge o limite de tamanho maacuteximo antes
que ele atinja a contagem maacutexima de documentos Considere o seguinte exemplo
dbcreateCollection (unifacs capped true size 5242880 max 5000)
Este comando cria uma coleccedilatildeo nomeada de ldquounifacsrdquo com uma dimensatildeo maacutexima
de 5 megabytes e um maacuteximo de 5000 documentos
Para visualizar todas as coleccedilotildees de um banco de dados MongoDB utilizashyse o
seguinte comando
dbgetCollectionNames()
Enfim haacute muitas diferenccedilas entre os comandos usados no MongoDB e no MySQL As
quatro operaccedilotildees baacutesicas usadas para criaccedilatildeo consulta atualizaccedilatildeo e destruiccedilatildeo de
dados conhecidas como CRUD (Create Read Update e Delete) apresentam
comandos bem distintos nos dois tipos de bancos em questatildeo A Tabela 5 compara
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2129
alguns comandos de CRUD em ambos os bancos
MySQL MongoDB
CREATE TABLE unifacs (
id MEDIUMINT NOT NULL
AUTO_INCREMENT
matricula Number
nome Varchar(30)
idade Number
PRIMARY KEY (id)
)
A coleccedilatildeo eacute criada implicitamente na primeira
inserccedilatildeo de dados O _id chave primaacuteria eacute
adicionada automaticamente se o campo _id natildeo
eacute especificado
dbunifacsinsert (
matricula 04217253
nome Paulo
idade 22
)
ALTER TABLE unifacs
ADD join_date DATETIME
Coleccedilotildees natildeo descrevem ou forccedilam a estrutura
dos seus documentos No entanto no niacutevel do
documento operaccedilotildees de update () podem
adicionar campos para documentos existentes
usando o operador $set e remover usando
$unset
dbunifacsupdate (
$set join_date new Date ()
multi true
)
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2229
ALTER TABLE unifacs
DROP COLUMN join_date
dbunifacsupdate(
$unset join_date
multi true
)
INSERT INTO unifacs (matricula nome
idade)
VALUES (032104211 ldquoJoanardquo 21)
dbunifacsinsert(
matricula 032104211 nome ldquoJoanardquo idade
21
)
SELECT FROM unifacs dbunifacsfind()
SELECT FROM unifacs WHERE idade =
21dbunifacsfind( idade 21 )
SELECT FROM unifacs WHERE nome =
ldquoJoanardquo
AND idade = 21
dbunifacsfind( nome ldquoJoanardquo idade 21 )
SELECT FROM unifacs WHERE idade gt
20dbunifacsfind( age $gt 20 )
SELECT COUNT() FROM unifacs
dbuserscount()
ou
dbunifacsfind()count()
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2329
UPDATE unifacs SET status = ldquoAprovadordquo
WHERE nota gt 7
dbunifacsupdate( nota $gt 7
$set status ldquoAprovadordquo multi true )
UPDATE unifacs SET nota = nota + 1
WHERE status = Aprovado
dbunifacsupdate( status Aprovado
$inc nota 1 multi true )
DELETE FROM unifacs WHERE status =
Reprovadodbunifacsremove( status Reprovado )
Tabela 5 Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
Eacute importante saber que cada documento de uma coleccedilatildeo no MongoDB tem um
tamanho maacuteximo de 16MB o que eacute mais do que suficiente para armazenar dados em
um documento No entanto o MongoDB ainda eacute capaz de armazenar arquivos no
banco de dados em uma coleccedilatildeo especifica que eacute a coleccedilatildeo do tipo GridFS
Ela eacute ideal para trabalhar com arquivos maiores de imagens viacutedeo e aacuteudio O GridFS
divide o arquivo em partes ou pedaccedilos e salva cada pedaccedilo em um documento
separado Quando vocecirc consulta um arquivo no GridFS eacute preciso remontar os
pedaccedilos conforme a necessidade
O MongoDB atinge o objetivo de ser amigaacutevel para o desenvolvedor Possui uma
documentaccedilatildeo bem escrita para a maioria dos principais idiomas Sua consulta
baseada em JavaScript eacute faacutecil para os desenvolvedores da Web e ele tambeacutem eacute faacutecil
de instalar Por estas razotildees o MongoDB eacute uma oacutetima opccedilatildeo de tecnologia para uso
em uma aplicaccedilatildeo
Um exemplo do sucesso deste banco eacute o depoimento do especialista em banco de
dados da Globocom Franklin Amorim Em um evento sobre o MongoDB em 2011 na
cidade de Satildeo Paulo Franklin apresentou o case de sucesso da adoccedilatildeo do MongoDB
para uma nova funccedilatildeo do ldquofantasy gamerdquo CartolaFC
O jogo eacute maior aplicaccedilatildeo dinacircmica do portal Globocom com mais de 2 milhotildees de
usuaacuterios cadastrados e quase 90 milhotildees de pageviews somente em um mecircs
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 429
projetadas para evitar anomalias de atualizaccedilatildeo e inconsistecircncias de dados e ao
mesmo tempo para permitir uma recuperaccedilatildeo mais faacutecil de informaccedilotildees
A linguagem chamada SQL foi desenvolvida para trabalhar com bancos de dados
relacionais Inspirada na aacutelgebra relacional e desenvolvida pela IBM o SQL eacute uma
linguagem declarativa para banco de dados
A facilidade de uso e simplicidade de expressatildeo 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 satildeo as propriedades ACID A sigla
significa Atomicidade Consistecircncia Isolamento e Durabilidade As propriedades ACID
de um SGBD permitem o compartilhamento seguro de dados oferecendo otimizaccedilatildeo
de consultas recuperaccedilatildeo de falhas validaccedilatildeo controle de concorrecircncia e
verificaccedilatildeo de integridade dos dados
Todas essas caracteriacutesticas e recursos deram ao Modelo Relacional de banco de
dados uma posiccedilatildeo de destaque e predominacircncia 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
Limitaccedilotildees do Modelo RelacionalO Walmart um gigante do varejo trabalha com mais de 1 milhatildeo de transaccedilotildees de
clientes por hora alimentando bancos de dados estimados em mais de 25
petabytes Jaacute o Facebook possui em seu banco cerca de 40 bilhotildees de fotos Estes
satildeo exemplos que mostram que o mundo conteacutem enorme quantidade de informaccedilatildeo
digital e que este volume de informaccedilotildees e dados estaacute ficando cada vez maior
rapidamente
Este eacute um dos principais problemas encontrados com a utilizaccedilatildeo do Modelo
Relacional a dificuldade em se usar esse modelo com uma demanda por
escalabilidade cada vez maior As aplicaccedilotildees web que usam banco de dados
relacional vecircm sofrendo com o grande volume de dados e problemas de
desempenho
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 529
Para solucionar tais problemas de escalabilidade geralmente se recorre a duas
alternativas o aumento do nuacutemero de servidores (escalonamento horizontal) ou a
realizaccedilatildeo de um upgrade no servidor (escalonamento vertical)
Isto natildeo eacute o suficiente caso o volume de informaccedilotildees continue a crescer em ritmo
acelerado Com o constante crescimento dos dados a soluccedilatildeo passa a ser escalar o
banco de dados em sistemas distribuiacutedos
Entretanto por causa da natureza estruturada do modelo relacional os
administradores de bancos de dados perceberam uma dificuldade em organizar as
informaccedilotildees em sistemas distribuiacutedos particionando os dados em maacutequinas
diferentes Manusear tabelas em diferentes servidores eacute muito difiacutecil e problemaacutetico
Por conta disso comeccedilam a surgir as soluccedilotildees natildeo relacionais
NoSQLOs desenvolvedores comeccedilaram a pensar em um modelo alternativo para modelar as
bases de dados frente agraves dificuldades encontradas no modelo relacional As soluccedilotildees
propostas para a melhoria de desempenho visavam evitar a riacutegida e tradicional
estrutura usada no modelo relacional
O objetivo dos projetistas de banco de dados das grandes organizaccedilotildees era
desenvolver uma nova maneira de armazenar as informaccedilotildees flexibilizando o banco
de dados para as caracteriacutesticas particulares de sua empresa
Esta flexibilidade eacute fundamental para atender aos requisitos dos sistemas
distribuiacutedos em larga escala permitindo escalabilidade e alta disponibilidade para as
aplicaccedilotildees 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 coacutedigo aberto que natildeo possuiacutea
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
natildeo atendia aos requisitos pretendidos Eacute um movimento totalmente adepto ao
coacutedigo aberto
A intenccedilatildeo do NoSQL natildeo eacute substituir o tradicional modelo relacional e sim ser uma
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 629
alternativa para as empresas que necessitam de um modelo de banco de dados mais
flexiacutevel para suportar o seu volume de dados
A constante tendecircncia de computaccedilatildeo em nuvem e o crescimento das redes sociais
satildeo fatores importantes que levam ao desenvolvimento de armazenamento NoSQL
Apesar da existecircncia de muitos bancos de dados NoSQL o movimento ganhou forccedila
quando grandes empresas da tecnologia passaram a usar suas proacuteprias
implementaccedilotildees a fim de fornecer serviccedilos para seus sistemas distribuiacutedos
Buscando atender suas necessidades de armazenamento em 2004 o Google criou o
BigTable
Na sequecircncia buscando tambeacutem a alta disponibilidade a Amazon lanccedilou o Dynamo
Em 2008 o Facebook desenvolveu o Cassandra para tratar o grande volume de
dados e este se mostrou tatildeo eficiente que em 2010 o Twitter deixou o MySQL de
lado para usaacuteshylo
Outras soluccedilotildees lanccediladas satildeo o Apache CouchDB e o MongoDB que satildeo banco de
dados orientados a documentos e com caracteriacutesticas bem semelhantes como alta
performance e escalaacuteveis projetados para suportar sistemas distribuiacutedos em larga
escala
Todos os bancos citados satildeo considerados NoSQL possuem caracteriacutesticas
semelhantes mas tambeacutem possuem particularidades que os diferenciam A proacutexima
seccedilatildeo aborda justamente os diferentes modelos de bancos de dados NoSQL
mostrando suas caracteriacutesticas
31 Modelos de BD NoSQLMais e mais organizaccedilotildees tecircm adotado soluccedilotildees NoSQL para apoiar seus projetos
Estas soluccedilotildees apresentam caracteriacutesticas em comum como uma maior
escalabilidade e alta disponibilidade mas tambeacutem apresentam diversas
singularidades Os bancos de dados NoSQL satildeo subdivididos pela maneira como
armazenam as informaccedilotildees Os principais tipos satildeo Armazenamento ChaveshyValor
(KeyValue) Documento Coluna e Grafo
A soluccedilatildeo chaveshyvalor armazena qualquer coisa como pares de valoresshychave o que
implica valores armazenados recuperados por chaves uacutenicas Satildeo capazes de
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 729
armazenar grandes quantidades de dados e no entanto mantecircm o acesso simples
por uma chave primaacuteria
Este tipo de armazenamento funciona bem para listas como as categorias de
produtos os atributos de cada produto carrinho de compras conteuacutedos ou valores
individuais etc
Por conta disto o Amazon Dynamo eacute uma soluccedilatildeo que adota este modelo Os dados
deste sistema satildeo particionados e replicados usando hashing consistente a fim de
fornecer a escalabilidade e disponibilidade
O segundo modelo de soluccedilatildeo muda o tradicional paradigma de orientaccedilatildeo a
registros (ou tuplas) para orientaccedilatildeo a colunas (ou atributos) Aqui os dados seguem
uma indexaccedilatildeo tripla (linha coluna e timestamp) onde as linhas e as colunas satildeo
identificadas por chaves e o timestamp possibilita a diferenciaccedilatildeo de muacuteltiplas
versotildees de um mesmo dado
Alguns modelos deste tipo de armazenamento possuem colunas (registros que
possuem nome valor e timestamp) famiacutelias de colunas (uma coleccedilatildeo de colunas
equivalente a uma tabela do Modelo Relacional) e supershycolunas (formadas por
arrays de colunas)
O conceito de famiacutelia de colunas pode ser observado na Figura 1 onde
primeiroNome e sobrenome satildeo colunas pertencentes agrave famiacutelia de colunas
denominada nome e as colunas endereccedilo e cidade pertencem agrave famiacutelia local Dois
grandes exemplos de sistemas orientados a coluna satildeo o Cassandra e o BigTable
Figura 1 Exemplo de modelo baseado em colunas
Jaacute uma soluccedilatildeo baseada em documento eacute um tipo de banco de dados que armazena
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 829
coleccedilotildees de documentos Os documentos satildeo representados como objetos com um
uacutenico identificador e um conjunto de campos que podem ser strings listas ou
documentos aninhados Como esta base de dados eacute semiestruturada e natildeo possui
esquema uma informaccedilatildeo especiacutefica 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 temshyse 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 trecircs
componentes baacutesicos os veacutertices (satildeo os noacutes do grafo) as arestas (satildeo os
relacionamentos entre os noacutes) e os atributos dos noacutes e relacionamentos Os dados
satildeo armazenados nos noacutes do grafo e as arestas representam o tipo de associaccedilatildeo
entre eles
Novas arestas podem ser adicionadas (ou as antigas removidas) a qualquer
momento permitindo que relaccedilotildees 1shyN (um para muitos) e NshyN (muitos para muitos)
sejam expressas de forma faacutecil Construccedilotildees como amigos seguidores graus de
separaccedilatildeo listas satildeo muito naturalmente acomodadas em bancos de dados do tipo
grafo
A Figura 3 representa um exemplo de grafo de uma aplicaccedilatildeo que possui
informaccedilotildees 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
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 929
No exemplo da figura temos trecircs pessoas que satildeo noacutes do grafo e estatildeo conectados agrave
cidades que ou jaacute visitaram ou moraram Atraveacutes da representaccedilatildeo do grafo fica faacutecil
perceber que Maria e Joseacute jaacute visitaram o Rio de Janeiro
E que Joatildeo jaacute morou em Recife e Salvador Um exemplo de banco de dados baseado
em grafo eacute o Neo4j que eacute openshysource e implementado em Java
Figura 3 Exemplo de modelo baseado em grafo
Eacute importante ressaltar que nenhum dos modelos apresentados deve ser considerado
superior ao outro pois tudo depende da necessidade da aplicaccedilatildeo Eacute importante que
os desenvolvedores conheccedilam os diversos modelos de soluccedilatildeo para que seja
adotado aquele que mais se adequar ao que a aplicaccedilatildeo ou empresa precisa Isto
contribui para a diminuiccedilatildeo do custo de criaccedilatildeo do banco de dados e com o aumento
do desempenho no processamento dos dados
A Tabela 1 apresenta uma comparaccedilatildeo dos modelos apresentados destacando suas
principais vantagens e desvantagens e ainda citando seus principais exemplos e
suas disponibilidades
Tipo Vantagem Desvantagem Exemplos Disponibilidade
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1029
ChaveValor
Simplicidade
e
escalabilidade
Falta recursos
mais
avanccedilados de
consulta
Amazon
DynamoDB
O niacutevel gratuito da AWS inclui 100
MB de armazenamento 5 unidades
de capacidade de gravaccedilatildeo e 10
unidades de capacidade de leitura
com o Amazon DynamoDB
Disponiacutevel em
httpawsamazoncomptdynamodb
DocumentoFacilidade de
uso
Natildeo eacute
adequado para
dados
relacionais
Consulta
limitada a
chaves e
iacutendices
MongoDB
CouchDB
Como a maioria das licenccedilas de
software livre permite seja usado
modificado e distribuiacutedo por usuaacuterios
Podeshyse adquirir o MongoDB em
httpwwwmongodborg
e CouchDB
httpcouchdbapacheorg
ColunaEscalabilidade
e flexibilidadeComplexidade
Google Big
Table
Cassandra
BigTable foi desenvolvida no Google
em tem sido usado desde 2005 em
dezenas de serviccedilos do Google Uma
versatildeo de coacutedigo aberto HBase foi
criado pelo Apache
httphbaseapacheorg
Jaacute o Cassandra tambeacutem pode ser
adquirido de forma gratuita
httpcassandraapacheorg
Grafo
Modelo de
dados
poderoso e
raacutepido
Flexibilidade
Neo4j Como os demais acima o Neo4j
tambeacutem estaacute disponiacutevel para
download em httpwwwneo4jorg
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1129
Tabela 1 Anaacutelise comparativa dos modelos de BD NoSQL
Modelo Relacional x NoSQLAo se comparar os modelos em questatildeo uma grande diferenccedila a se notar eacute que as
tecnologias relacionais tecircm esquemas riacutegidos enquanto os modelos NoSQL satildeo
schemashyfree ou seja sem esquema O modelo relacional requer uma definiccedilatildeo
estrita de um esquema antes de armazenar todos os dados em um banco de dados
Alterar o esquema uma vez que os dados jaacute estatildeo inseridos eacute muito complicado e
por isso evitado No entanto isto eacute exatamente o oposto do comportamento
desejado na era ldquoBig Datardquo 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 trecircs criteacuterios satildeo
considerados relevantes para esta escolha escalonamento consistecircncia de dados e
disponibilidade E eacute isto que seraacute abordado a partir de agora
Basicamente pelo fato de terem sido criados para essa finalidade os bancos NoSQL
apresentam vantagens em relaccedilatildeo 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 cenaacuterios em que o escalonamento eacute
necessaacuterio
Eacute possiacutevel tornar um banco de dados relacional mais escalaacutevel atraveacutes da teacutecnica de
escalonamento vertical onde eacute feita uma atualizaccedilatildeo (upgrade) no servidor de
bancos de dados
Poreacutem este escalonamento fica limitado agrave capacidade de uma uacutenica maacutequina Jaacute o
escalonamento horizontal eacute feito com o aumento da quantidade de servidores que
iratildeo disponibilizar os dados paralelamente (Figura 4) facilitando o acesso aos dados
e garantindo que a queda de um servidor natildeo seja um problema de disponibilidade
dos dados
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1229
Figura 4 O uso do escalonamento horizontal
Outra caracteriacutestica a favor do NoSQL eacute o uso do sharding que consiste em trabalhar
com o escalonamento horizontal particionando e paralelizando seus dados em vaacuterios
servidores (Figura 5) Essa teacutecnica eacute complexa para se usar em SGBDs relacionais
devido a toda a sua estrutura loacutegica e devido ao uso da desnormalizaccedilatildeo dos dados
o contraacuterio usado no modelo relacional
O sharding traz benefiacutecios pois conjuntos de dados menores satildeo mais faacuteceis de
serem acessados atualizados e gerenciados O maior benefiacutecio em comparaccedilatildeo ao
modelo relacional eacute a otimizaccedilatildeo do grau de disponibilidade do sistema pois como
jaacute dito anteriormente a queda de uma maacutequina natildeo causaria a interrupccedilatildeo de todo o
sistema
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1329
Figura 5 Teacutecnica de sharding
O controle de concorrecircncia tambeacutem funciona de maneira distinta nos modelos em
questatildeo O modelo relacional utiliza bloqueios (locks) como garantia de que dois
usuaacuterios natildeo atualizem o mesmo dado ao mesmo tempo Jaacute no modelo NoSQL satildeo
usadas outras estrateacutegias para permitir um maior grau de concorrecircncia
Alguns bancos NoSQL usam o MVCC (Multiversion Concurrency Control) ou Controle
de Concorrecircncia Multishyversotildees Nesta teacutecnica o acesso aos dados pode ser realizado
em paralelo
Cada usuaacuterio que se conecta ao banco de dados visualiza uma coacutepia temporaacuteria do
banco de dados naquele instante Qualquer atualizaccedilatildeo que esteja sendo feita em
determinado momento por um usuaacuterio natildeo seraacute vista pelos demais que estatildeo
operando simultaneamente no banco de dados ateacute que a atualizaccedilatildeo tenha sido
concluiacuteda
Quando se opta por usar um modelo NoSQL haacute ganhos de performance flexibilidade
e disponibilidade mas haacute uma perda de consistecircncia Haacute um teorema na ciecircncia da
computaccedilatildeo criado Eric Brewer chamado Teorema CAP (Consistency Availability e
Partition Tolerance) que diz ser impossiacutevel para um sistema distribuiacutedo garantir
consistecircncia disponibilidade e toleracircncia ao particionamento De forma simultacircnea
soacute eacute possiacutevel conseguir duas destas trecircs caracteriacutesticas Vejamos exemplos de
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1429
SGBDs na Figura 6 segundo o Teorema CAP
Figura 6 Distribuiccedilatildeo relativa de alguns bancos de dados quanto ao Teorema CAP
As soluccedilotildees NoSQL seguem um paradigma denominado BASE (Basically Available
Soft state Eventual consistency) Este tem como caracteriacutesticas estar basicamente
disponiacutevel o tempo todo estar em estado leve ou seja natildeo sendo consistente o
tempo todo e possuir uma consistecircncia eventual o sistema se torna consistente no
momento apropriado
O modelo BASE eacute um contraste ao paradigma ACID (Atomicity Consistency
Isolation Durability) comumente associado aos bancos de dados de modelo
relacional Ao contraacuterio do modelo ACID que promove uma seguranccedila dos dados
forccedilando a consistecircncia ao final de cada operaccedilatildeo o modelo BASE permite que o
banco de dados esteja em um estado eventualmente consistente
A disponibilidade do modelo BASE estaacute associada justamente ao fato de que a falha
de uma maacutequina do sistema natildeo interrompe o sistema como um todo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1529
Para se analisar de forma mais raacutepida e comparativa a Tabela 2 apresenta as
principais caracteriacutesticas de ambos os modelos discutidos aqui
Modelo Relacional NoSQL
Escalonamento Possui sua natureza
estruturada e por conta disto
o escalonamento de bancos
tende a ser uma tarefa
complexa
Eacute livre de esquemas por isso
o NoSQL possui uma maior
flexibilidade e alta
escalabilidade considerada
uma das principais vantagens
desse modelo
Consistecircncia Possui uma estrutura mais
riacutegida e garante em suas
transaccedilotildees a existecircncia dessa
propriedade As diversas
regras deste modelo
possibilitam uma maior
rigidez quanto a garantia de
consistecircncia dos dados
sendo este o ponto mais
forte desse modelo
A consistecircncia nesse modelo
possui um caraacuteter eventual
o que natildeo garante que uma
determinada atualizaccedilatildeo em
um dado momento seja
percebida por todos os noacutes
Disponibilidade Haacute uma dificuldade de se
trabalhar de forma eficiente
com a distribuiccedilatildeo de dados
por causa de sua natureza
estruturada situaccedilotildees em
que exigem uma maior
demanda de um sistema que
utilizem esse modelo podem
natildeo ser bem suportadas por
ele
Considerada outra das
grandes vantagens do
modelo essa propriedade
junto com o alto grau de
distribuiccedilatildeo desse modelo
possibilita que o sistema
fique um menor periacuteodo de
tempo natildeoshydisponiacutevel assim
como tambeacutem permite que a
solicitaccedilatildeo aos dados por um
nuacutemero crescente de clientes
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1629
seja atendida
Toleracircncia a
Particionamento
Por natildeo terem sido
construiacutedo com a finalidade
de trabalhar com
particionamento de dados
este modelo natildeo possui um
grau muito alto de toleracircncia
ao particionamento cuja
razatildeo principal seria a
dificuldade de junccedilotildees entre
as tabelas
Trabalha de forma faacutecil e
eficiente com a distribuiccedilatildeo
de dados Este modelo eacute
capaz de suportar grandes
demandas de dados assim
como possui alta toleracircncia
ao particionamento dos
mesmos
Tabela 2 Anaacutelise 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 verificaccedilatildeo contiacutenua
da consistecircncia de cada transaccedilatildeo adiciona custos consideraacuteveis para um sistema
que tem milhares de transaccedilotildees ocorrendo
A consistecircncia eventual promovida pelo modelo BASE daacute agraves organizaccedilotildees a
capacidade de interagir com os clientes de forma contiacutenua com a necessaacuteria
disponibilidade e toleracircncia a particcedilatildeo mantendo baixos custos e o sistema rodando
sem interrupccedilotildees Sem duacutevida seria excelente ter consistecircncia completa o tempo
todo mas eacute preciso haver compensaccedilotildees e a consistecircncia eventual permite o
desenvolvimento eficaz de sistemas que podem lidar com o aumento exponencial de
dados devido agraves redes sociais computaccedilatildeo em nuvem e outros projetos de Big Data
Estudo de Caso shy MongoDBPara fins comparativos seratildeo analisadas nesta seccedilatildeo algumas diferenccedilas entre um
banco NoSQL o MongoDB e os bancos relacionais baseados em SQL O MongoDB eacute
um banco de dados NoSQL criado em 2009 pela empresa 10gen orientado a
documentos altamente escalaacutevel de alta performance e de coacutedigo aberto O
cofundador e diretor de tecnologia da 10gen define o MongoDB da seguinte forma ldquoO
MongoDB natildeo foi concebido em um laboratoacuterio
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1729
Noacutes construiacutemos o MongoDB com base em nossas experiecircncias na construccedilatildeo de
sistemas robustos de grande escala e alta disponibilidade Natildeo comeccedilamos do zero
noacutes tentamos descobrir o que estava problemaacutetico e solucionamos isso
Assim o que eu penso sobre MongoDB eacute que se vocecirc pegar o MySQL e alterar o
modelo de dados do relacional para orientado a documento vocecirc ganha uma grande
quantidade de recursos documentos embarcados para melhorar velocidade
facilidade de gerenciamento desenvolvimento aacutegil com bancos de dados sem
ldquoschemardquo escalabilidade horizontal mais faacutecil pois ldquojoinsrdquo natildeo satildeo tatildeo importantes
Haacute muitas coisas que funcionam muito bem nos bancos de dados relacionais iacutendices
consultas dinacircmicas e atualizaccedilotildees e noacutes natildeo mudamos muito neste ponto Por
exemplo a maneira de projetar seus iacutendices no MongoDB deve ser exatamente do
jeito que vocecirc faz isso no MySQL ou Oracle vocecirc soacute ganha a opccedilatildeo de indexar um
campo embarcadordquo
Como dito na seccedilatildeo de modelos de bancos de dados NoSQL um banco orientado a
documentos natildeo possui esquemas riacutegidos e estruturados sendo possiacutevel que ocorra
uma atualizaccedilatildeo na estrutura do documento Portanto inserir novos campos no
documento natildeo 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 coleccedilatildeo
iacutendice iacutendice
linha documento BSON
coluna campo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1829
joins documentos incorporados e vinculaccedilatildeo
primary key
(Especifica qualquer combinaccedilatildeo de colunas
ou coluna uacutenica como chave primaacuteria)
primary key
(No MongoDB a chave primaacuteria eacute definida
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 dinacircmicos ou seja sem a
necessidade de que cada registro tenha a mesma estrutura Estas estruturas satildeo
chamadas de coleccedilotildees (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 sobrenomeSilva idade22 bairroPituba
Outro documento para representar um aluno na mesma coleccedilatildeo
aluno2=nomeLiardquo sobrenomeSaacute cursoDireito materias[Civil Penal]
Podeshyse ter registros diferentes um do outro dentro de uma mesma coleccedilatildeo Parece
estranho este tipo de abordagem mas no modelo relacional usamos isto o tempo
inteiro e de maneira ineficiente com a formaccedilatildeo de tabelas esparsas
Estas satildeo tabelas incompletas onde algumas colunas satildeo sempre preenchidas e
outras nem sempre satildeo usadas Para ilustrar isto observe a Tabela 4 que apresenta
registros da construccedilatildeo civil
Coacutedigo Produto Altura Potecircncia Peso Diacircmetro
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1929
1 Britadeira 300cv 100kg
2 Cimento
3 Empilhadeira 15cv 300kg
4 Escada 3m
5 Tubulaccedilatildeo 20cm
Tabela 4 Cadastro de produtos da construccedilatildeo civil em banco de dados modelo
relacional
Neste exemplo haacute uma desvantagem no modelo relacional Haacute colunas cujo valor eacute
preenchido apenas uma vez como pode ser visto no exemplo das colunas Altura e
Diacircmetro Na construccedilatildeo das tabelas ao incluir colunas que satildeo pouco utilizadas
jogashyse fora espaccedilo de armazenamento e reduzshyse o desempenho do sistema como
um todo E ainda tratamos objetos diferentes como se fossem iguais o que nem
sempre eacute uma boa praacutetica Abaixo o exemplo de como ficaria este cadastro de
produtos no modelo documental
codigo1 produtoBritadeira potencia300cv peso100kg
codigo2 produtoCimento
codigo3 produtoEmpilhadeira potencia15cv peso300kg
codigo4 produtoEscada altura3m
codigo5 produtoTubulaccedilatildeo diametro20cm
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
Seratildeo apresentados agora alguns comandos comuns usados no MongoDB Voltando
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2029
ao primeiro exemplo de documento criado para alunos observe como ficaria o
comando para salvar os alunos em uma coleccedilatildeo
dbunifacssave(aluno1)
dbunifacssave(aluno2)
O comando acima salva os documentos aluno1 e aluno2 na coleccedilatildeo ldquounifacsrdquo Eacute
possiacutevel acessar os dados de uma coleccedilatildeo atraveacutes do comando find() basicamente
ele vai percorrer todos os registros da coleccedilatildeo e retornar os documentos listados No
exemplo dado o comando seria dbunifacsfind() E para apagar tudo que existe na
coleccedilatildeo dbunifacsremove()
Natildeo eacute necessaacuterio que se crie uma coleccedilatildeo ou mesmo que se configure uma estrutura
isso eacute feito automaticamente quando o primeiro registro eacute incluiacutedo No entanto eacute
possiacutevel usar o comando de criar uma coleccedilatildeo e isto pode ser utilizado para preacuteshy
atribuir espaccedilo para uma coleccedilatildeo Uma coleccedilatildeo de tamanho fixo usa o comando
ldquocappedrdquo e vem a substituir automaticamente as entradas mais antigas quando
atinge seu tamanho maacuteximo
Todas as coleccedilotildees limitadas e fixas devem especificar um tamanho maacuteximo e
tambeacutem podem especificar um nuacutemero maacuteximo de documentos O MongoDB remove
os documentos antigos se uma coleccedilatildeo atinge o limite de tamanho maacuteximo antes
que ele atinja a contagem maacutexima de documentos Considere o seguinte exemplo
dbcreateCollection (unifacs capped true size 5242880 max 5000)
Este comando cria uma coleccedilatildeo nomeada de ldquounifacsrdquo com uma dimensatildeo maacutexima
de 5 megabytes e um maacuteximo de 5000 documentos
Para visualizar todas as coleccedilotildees de um banco de dados MongoDB utilizashyse o
seguinte comando
dbgetCollectionNames()
Enfim haacute muitas diferenccedilas entre os comandos usados no MongoDB e no MySQL As
quatro operaccedilotildees baacutesicas usadas para criaccedilatildeo consulta atualizaccedilatildeo e destruiccedilatildeo de
dados conhecidas como CRUD (Create Read Update e Delete) apresentam
comandos bem distintos nos dois tipos de bancos em questatildeo A Tabela 5 compara
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2129
alguns comandos de CRUD em ambos os bancos
MySQL MongoDB
CREATE TABLE unifacs (
id MEDIUMINT NOT NULL
AUTO_INCREMENT
matricula Number
nome Varchar(30)
idade Number
PRIMARY KEY (id)
)
A coleccedilatildeo eacute criada implicitamente na primeira
inserccedilatildeo de dados O _id chave primaacuteria eacute
adicionada automaticamente se o campo _id natildeo
eacute especificado
dbunifacsinsert (
matricula 04217253
nome Paulo
idade 22
)
ALTER TABLE unifacs
ADD join_date DATETIME
Coleccedilotildees natildeo descrevem ou forccedilam a estrutura
dos seus documentos No entanto no niacutevel do
documento operaccedilotildees de update () podem
adicionar campos para documentos existentes
usando o operador $set e remover usando
$unset
dbunifacsupdate (
$set join_date new Date ()
multi true
)
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2229
ALTER TABLE unifacs
DROP COLUMN join_date
dbunifacsupdate(
$unset join_date
multi true
)
INSERT INTO unifacs (matricula nome
idade)
VALUES (032104211 ldquoJoanardquo 21)
dbunifacsinsert(
matricula 032104211 nome ldquoJoanardquo idade
21
)
SELECT FROM unifacs dbunifacsfind()
SELECT FROM unifacs WHERE idade =
21dbunifacsfind( idade 21 )
SELECT FROM unifacs WHERE nome =
ldquoJoanardquo
AND idade = 21
dbunifacsfind( nome ldquoJoanardquo idade 21 )
SELECT FROM unifacs WHERE idade gt
20dbunifacsfind( age $gt 20 )
SELECT COUNT() FROM unifacs
dbuserscount()
ou
dbunifacsfind()count()
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2329
UPDATE unifacs SET status = ldquoAprovadordquo
WHERE nota gt 7
dbunifacsupdate( nota $gt 7
$set status ldquoAprovadordquo multi true )
UPDATE unifacs SET nota = nota + 1
WHERE status = Aprovado
dbunifacsupdate( status Aprovado
$inc nota 1 multi true )
DELETE FROM unifacs WHERE status =
Reprovadodbunifacsremove( status Reprovado )
Tabela 5 Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
Eacute importante saber que cada documento de uma coleccedilatildeo no MongoDB tem um
tamanho maacuteximo de 16MB o que eacute mais do que suficiente para armazenar dados em
um documento No entanto o MongoDB ainda eacute capaz de armazenar arquivos no
banco de dados em uma coleccedilatildeo especifica que eacute a coleccedilatildeo do tipo GridFS
Ela eacute ideal para trabalhar com arquivos maiores de imagens viacutedeo e aacuteudio O GridFS
divide o arquivo em partes ou pedaccedilos e salva cada pedaccedilo em um documento
separado Quando vocecirc consulta um arquivo no GridFS eacute preciso remontar os
pedaccedilos conforme a necessidade
O MongoDB atinge o objetivo de ser amigaacutevel para o desenvolvedor Possui uma
documentaccedilatildeo bem escrita para a maioria dos principais idiomas Sua consulta
baseada em JavaScript eacute faacutecil para os desenvolvedores da Web e ele tambeacutem eacute faacutecil
de instalar Por estas razotildees o MongoDB eacute uma oacutetima opccedilatildeo de tecnologia para uso
em uma aplicaccedilatildeo
Um exemplo do sucesso deste banco eacute o depoimento do especialista em banco de
dados da Globocom Franklin Amorim Em um evento sobre o MongoDB em 2011 na
cidade de Satildeo Paulo Franklin apresentou o case de sucesso da adoccedilatildeo do MongoDB
para uma nova funccedilatildeo do ldquofantasy gamerdquo CartolaFC
O jogo eacute maior aplicaccedilatildeo dinacircmica do portal Globocom com mais de 2 milhotildees de
usuaacuterios cadastrados e quase 90 milhotildees de pageviews somente em um mecircs
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 529
Para solucionar tais problemas de escalabilidade geralmente se recorre a duas
alternativas o aumento do nuacutemero de servidores (escalonamento horizontal) ou a
realizaccedilatildeo de um upgrade no servidor (escalonamento vertical)
Isto natildeo eacute o suficiente caso o volume de informaccedilotildees continue a crescer em ritmo
acelerado Com o constante crescimento dos dados a soluccedilatildeo passa a ser escalar o
banco de dados em sistemas distribuiacutedos
Entretanto por causa da natureza estruturada do modelo relacional os
administradores de bancos de dados perceberam uma dificuldade em organizar as
informaccedilotildees em sistemas distribuiacutedos particionando os dados em maacutequinas
diferentes Manusear tabelas em diferentes servidores eacute muito difiacutecil e problemaacutetico
Por conta disso comeccedilam a surgir as soluccedilotildees natildeo relacionais
NoSQLOs desenvolvedores comeccedilaram a pensar em um modelo alternativo para modelar as
bases de dados frente agraves dificuldades encontradas no modelo relacional As soluccedilotildees
propostas para a melhoria de desempenho visavam evitar a riacutegida e tradicional
estrutura usada no modelo relacional
O objetivo dos projetistas de banco de dados das grandes organizaccedilotildees era
desenvolver uma nova maneira de armazenar as informaccedilotildees flexibilizando o banco
de dados para as caracteriacutesticas particulares de sua empresa
Esta flexibilidade eacute fundamental para atender aos requisitos dos sistemas
distribuiacutedos em larga escala permitindo escalabilidade e alta disponibilidade para as
aplicaccedilotildees 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 coacutedigo aberto que natildeo possuiacutea
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
natildeo atendia aos requisitos pretendidos Eacute um movimento totalmente adepto ao
coacutedigo aberto
A intenccedilatildeo do NoSQL natildeo eacute substituir o tradicional modelo relacional e sim ser uma
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 629
alternativa para as empresas que necessitam de um modelo de banco de dados mais
flexiacutevel para suportar o seu volume de dados
A constante tendecircncia de computaccedilatildeo em nuvem e o crescimento das redes sociais
satildeo fatores importantes que levam ao desenvolvimento de armazenamento NoSQL
Apesar da existecircncia de muitos bancos de dados NoSQL o movimento ganhou forccedila
quando grandes empresas da tecnologia passaram a usar suas proacuteprias
implementaccedilotildees a fim de fornecer serviccedilos para seus sistemas distribuiacutedos
Buscando atender suas necessidades de armazenamento em 2004 o Google criou o
BigTable
Na sequecircncia buscando tambeacutem a alta disponibilidade a Amazon lanccedilou o Dynamo
Em 2008 o Facebook desenvolveu o Cassandra para tratar o grande volume de
dados e este se mostrou tatildeo eficiente que em 2010 o Twitter deixou o MySQL de
lado para usaacuteshylo
Outras soluccedilotildees lanccediladas satildeo o Apache CouchDB e o MongoDB que satildeo banco de
dados orientados a documentos e com caracteriacutesticas bem semelhantes como alta
performance e escalaacuteveis projetados para suportar sistemas distribuiacutedos em larga
escala
Todos os bancos citados satildeo considerados NoSQL possuem caracteriacutesticas
semelhantes mas tambeacutem possuem particularidades que os diferenciam A proacutexima
seccedilatildeo aborda justamente os diferentes modelos de bancos de dados NoSQL
mostrando suas caracteriacutesticas
31 Modelos de BD NoSQLMais e mais organizaccedilotildees tecircm adotado soluccedilotildees NoSQL para apoiar seus projetos
Estas soluccedilotildees apresentam caracteriacutesticas em comum como uma maior
escalabilidade e alta disponibilidade mas tambeacutem apresentam diversas
singularidades Os bancos de dados NoSQL satildeo subdivididos pela maneira como
armazenam as informaccedilotildees Os principais tipos satildeo Armazenamento ChaveshyValor
(KeyValue) Documento Coluna e Grafo
A soluccedilatildeo chaveshyvalor armazena qualquer coisa como pares de valoresshychave o que
implica valores armazenados recuperados por chaves uacutenicas Satildeo capazes de
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 729
armazenar grandes quantidades de dados e no entanto mantecircm o acesso simples
por uma chave primaacuteria
Este tipo de armazenamento funciona bem para listas como as categorias de
produtos os atributos de cada produto carrinho de compras conteuacutedos ou valores
individuais etc
Por conta disto o Amazon Dynamo eacute uma soluccedilatildeo que adota este modelo Os dados
deste sistema satildeo particionados e replicados usando hashing consistente a fim de
fornecer a escalabilidade e disponibilidade
O segundo modelo de soluccedilatildeo muda o tradicional paradigma de orientaccedilatildeo a
registros (ou tuplas) para orientaccedilatildeo a colunas (ou atributos) Aqui os dados seguem
uma indexaccedilatildeo tripla (linha coluna e timestamp) onde as linhas e as colunas satildeo
identificadas por chaves e o timestamp possibilita a diferenciaccedilatildeo de muacuteltiplas
versotildees de um mesmo dado
Alguns modelos deste tipo de armazenamento possuem colunas (registros que
possuem nome valor e timestamp) famiacutelias de colunas (uma coleccedilatildeo de colunas
equivalente a uma tabela do Modelo Relacional) e supershycolunas (formadas por
arrays de colunas)
O conceito de famiacutelia de colunas pode ser observado na Figura 1 onde
primeiroNome e sobrenome satildeo colunas pertencentes agrave famiacutelia de colunas
denominada nome e as colunas endereccedilo e cidade pertencem agrave famiacutelia local Dois
grandes exemplos de sistemas orientados a coluna satildeo o Cassandra e o BigTable
Figura 1 Exemplo de modelo baseado em colunas
Jaacute uma soluccedilatildeo baseada em documento eacute um tipo de banco de dados que armazena
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 829
coleccedilotildees de documentos Os documentos satildeo representados como objetos com um
uacutenico identificador e um conjunto de campos que podem ser strings listas ou
documentos aninhados Como esta base de dados eacute semiestruturada e natildeo possui
esquema uma informaccedilatildeo especiacutefica 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 temshyse 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 trecircs
componentes baacutesicos os veacutertices (satildeo os noacutes do grafo) as arestas (satildeo os
relacionamentos entre os noacutes) e os atributos dos noacutes e relacionamentos Os dados
satildeo armazenados nos noacutes do grafo e as arestas representam o tipo de associaccedilatildeo
entre eles
Novas arestas podem ser adicionadas (ou as antigas removidas) a qualquer
momento permitindo que relaccedilotildees 1shyN (um para muitos) e NshyN (muitos para muitos)
sejam expressas de forma faacutecil Construccedilotildees como amigos seguidores graus de
separaccedilatildeo listas satildeo muito naturalmente acomodadas em bancos de dados do tipo
grafo
A Figura 3 representa um exemplo de grafo de uma aplicaccedilatildeo que possui
informaccedilotildees 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
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 929
No exemplo da figura temos trecircs pessoas que satildeo noacutes do grafo e estatildeo conectados agrave
cidades que ou jaacute visitaram ou moraram Atraveacutes da representaccedilatildeo do grafo fica faacutecil
perceber que Maria e Joseacute jaacute visitaram o Rio de Janeiro
E que Joatildeo jaacute morou em Recife e Salvador Um exemplo de banco de dados baseado
em grafo eacute o Neo4j que eacute openshysource e implementado em Java
Figura 3 Exemplo de modelo baseado em grafo
Eacute importante ressaltar que nenhum dos modelos apresentados deve ser considerado
superior ao outro pois tudo depende da necessidade da aplicaccedilatildeo Eacute importante que
os desenvolvedores conheccedilam os diversos modelos de soluccedilatildeo para que seja
adotado aquele que mais se adequar ao que a aplicaccedilatildeo ou empresa precisa Isto
contribui para a diminuiccedilatildeo do custo de criaccedilatildeo do banco de dados e com o aumento
do desempenho no processamento dos dados
A Tabela 1 apresenta uma comparaccedilatildeo dos modelos apresentados destacando suas
principais vantagens e desvantagens e ainda citando seus principais exemplos e
suas disponibilidades
Tipo Vantagem Desvantagem Exemplos Disponibilidade
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1029
ChaveValor
Simplicidade
e
escalabilidade
Falta recursos
mais
avanccedilados de
consulta
Amazon
DynamoDB
O niacutevel gratuito da AWS inclui 100
MB de armazenamento 5 unidades
de capacidade de gravaccedilatildeo e 10
unidades de capacidade de leitura
com o Amazon DynamoDB
Disponiacutevel em
httpawsamazoncomptdynamodb
DocumentoFacilidade de
uso
Natildeo eacute
adequado para
dados
relacionais
Consulta
limitada a
chaves e
iacutendices
MongoDB
CouchDB
Como a maioria das licenccedilas de
software livre permite seja usado
modificado e distribuiacutedo por usuaacuterios
Podeshyse adquirir o MongoDB em
httpwwwmongodborg
e CouchDB
httpcouchdbapacheorg
ColunaEscalabilidade
e flexibilidadeComplexidade
Google Big
Table
Cassandra
BigTable foi desenvolvida no Google
em tem sido usado desde 2005 em
dezenas de serviccedilos do Google Uma
versatildeo de coacutedigo aberto HBase foi
criado pelo Apache
httphbaseapacheorg
Jaacute o Cassandra tambeacutem pode ser
adquirido de forma gratuita
httpcassandraapacheorg
Grafo
Modelo de
dados
poderoso e
raacutepido
Flexibilidade
Neo4j Como os demais acima o Neo4j
tambeacutem estaacute disponiacutevel para
download em httpwwwneo4jorg
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1129
Tabela 1 Anaacutelise comparativa dos modelos de BD NoSQL
Modelo Relacional x NoSQLAo se comparar os modelos em questatildeo uma grande diferenccedila a se notar eacute que as
tecnologias relacionais tecircm esquemas riacutegidos enquanto os modelos NoSQL satildeo
schemashyfree ou seja sem esquema O modelo relacional requer uma definiccedilatildeo
estrita de um esquema antes de armazenar todos os dados em um banco de dados
Alterar o esquema uma vez que os dados jaacute estatildeo inseridos eacute muito complicado e
por isso evitado No entanto isto eacute exatamente o oposto do comportamento
desejado na era ldquoBig Datardquo 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 trecircs criteacuterios satildeo
considerados relevantes para esta escolha escalonamento consistecircncia de dados e
disponibilidade E eacute isto que seraacute abordado a partir de agora
Basicamente pelo fato de terem sido criados para essa finalidade os bancos NoSQL
apresentam vantagens em relaccedilatildeo 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 cenaacuterios em que o escalonamento eacute
necessaacuterio
Eacute possiacutevel tornar um banco de dados relacional mais escalaacutevel atraveacutes da teacutecnica de
escalonamento vertical onde eacute feita uma atualizaccedilatildeo (upgrade) no servidor de
bancos de dados
Poreacutem este escalonamento fica limitado agrave capacidade de uma uacutenica maacutequina Jaacute o
escalonamento horizontal eacute feito com o aumento da quantidade de servidores que
iratildeo disponibilizar os dados paralelamente (Figura 4) facilitando o acesso aos dados
e garantindo que a queda de um servidor natildeo seja um problema de disponibilidade
dos dados
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1229
Figura 4 O uso do escalonamento horizontal
Outra caracteriacutestica a favor do NoSQL eacute o uso do sharding que consiste em trabalhar
com o escalonamento horizontal particionando e paralelizando seus dados em vaacuterios
servidores (Figura 5) Essa teacutecnica eacute complexa para se usar em SGBDs relacionais
devido a toda a sua estrutura loacutegica e devido ao uso da desnormalizaccedilatildeo dos dados
o contraacuterio usado no modelo relacional
O sharding traz benefiacutecios pois conjuntos de dados menores satildeo mais faacuteceis de
serem acessados atualizados e gerenciados O maior benefiacutecio em comparaccedilatildeo ao
modelo relacional eacute a otimizaccedilatildeo do grau de disponibilidade do sistema pois como
jaacute dito anteriormente a queda de uma maacutequina natildeo causaria a interrupccedilatildeo de todo o
sistema
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1329
Figura 5 Teacutecnica de sharding
O controle de concorrecircncia tambeacutem funciona de maneira distinta nos modelos em
questatildeo O modelo relacional utiliza bloqueios (locks) como garantia de que dois
usuaacuterios natildeo atualizem o mesmo dado ao mesmo tempo Jaacute no modelo NoSQL satildeo
usadas outras estrateacutegias para permitir um maior grau de concorrecircncia
Alguns bancos NoSQL usam o MVCC (Multiversion Concurrency Control) ou Controle
de Concorrecircncia Multishyversotildees Nesta teacutecnica o acesso aos dados pode ser realizado
em paralelo
Cada usuaacuterio que se conecta ao banco de dados visualiza uma coacutepia temporaacuteria do
banco de dados naquele instante Qualquer atualizaccedilatildeo que esteja sendo feita em
determinado momento por um usuaacuterio natildeo seraacute vista pelos demais que estatildeo
operando simultaneamente no banco de dados ateacute que a atualizaccedilatildeo tenha sido
concluiacuteda
Quando se opta por usar um modelo NoSQL haacute ganhos de performance flexibilidade
e disponibilidade mas haacute uma perda de consistecircncia Haacute um teorema na ciecircncia da
computaccedilatildeo criado Eric Brewer chamado Teorema CAP (Consistency Availability e
Partition Tolerance) que diz ser impossiacutevel para um sistema distribuiacutedo garantir
consistecircncia disponibilidade e toleracircncia ao particionamento De forma simultacircnea
soacute eacute possiacutevel conseguir duas destas trecircs caracteriacutesticas Vejamos exemplos de
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1429
SGBDs na Figura 6 segundo o Teorema CAP
Figura 6 Distribuiccedilatildeo relativa de alguns bancos de dados quanto ao Teorema CAP
As soluccedilotildees NoSQL seguem um paradigma denominado BASE (Basically Available
Soft state Eventual consistency) Este tem como caracteriacutesticas estar basicamente
disponiacutevel o tempo todo estar em estado leve ou seja natildeo sendo consistente o
tempo todo e possuir uma consistecircncia eventual o sistema se torna consistente no
momento apropriado
O modelo BASE eacute um contraste ao paradigma ACID (Atomicity Consistency
Isolation Durability) comumente associado aos bancos de dados de modelo
relacional Ao contraacuterio do modelo ACID que promove uma seguranccedila dos dados
forccedilando a consistecircncia ao final de cada operaccedilatildeo o modelo BASE permite que o
banco de dados esteja em um estado eventualmente consistente
A disponibilidade do modelo BASE estaacute associada justamente ao fato de que a falha
de uma maacutequina do sistema natildeo interrompe o sistema como um todo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1529
Para se analisar de forma mais raacutepida e comparativa a Tabela 2 apresenta as
principais caracteriacutesticas de ambos os modelos discutidos aqui
Modelo Relacional NoSQL
Escalonamento Possui sua natureza
estruturada e por conta disto
o escalonamento de bancos
tende a ser uma tarefa
complexa
Eacute livre de esquemas por isso
o NoSQL possui uma maior
flexibilidade e alta
escalabilidade considerada
uma das principais vantagens
desse modelo
Consistecircncia Possui uma estrutura mais
riacutegida e garante em suas
transaccedilotildees a existecircncia dessa
propriedade As diversas
regras deste modelo
possibilitam uma maior
rigidez quanto a garantia de
consistecircncia dos dados
sendo este o ponto mais
forte desse modelo
A consistecircncia nesse modelo
possui um caraacuteter eventual
o que natildeo garante que uma
determinada atualizaccedilatildeo em
um dado momento seja
percebida por todos os noacutes
Disponibilidade Haacute uma dificuldade de se
trabalhar de forma eficiente
com a distribuiccedilatildeo de dados
por causa de sua natureza
estruturada situaccedilotildees em
que exigem uma maior
demanda de um sistema que
utilizem esse modelo podem
natildeo ser bem suportadas por
ele
Considerada outra das
grandes vantagens do
modelo essa propriedade
junto com o alto grau de
distribuiccedilatildeo desse modelo
possibilita que o sistema
fique um menor periacuteodo de
tempo natildeoshydisponiacutevel assim
como tambeacutem permite que a
solicitaccedilatildeo aos dados por um
nuacutemero crescente de clientes
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1629
seja atendida
Toleracircncia a
Particionamento
Por natildeo terem sido
construiacutedo com a finalidade
de trabalhar com
particionamento de dados
este modelo natildeo possui um
grau muito alto de toleracircncia
ao particionamento cuja
razatildeo principal seria a
dificuldade de junccedilotildees entre
as tabelas
Trabalha de forma faacutecil e
eficiente com a distribuiccedilatildeo
de dados Este modelo eacute
capaz de suportar grandes
demandas de dados assim
como possui alta toleracircncia
ao particionamento dos
mesmos
Tabela 2 Anaacutelise 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 verificaccedilatildeo contiacutenua
da consistecircncia de cada transaccedilatildeo adiciona custos consideraacuteveis para um sistema
que tem milhares de transaccedilotildees ocorrendo
A consistecircncia eventual promovida pelo modelo BASE daacute agraves organizaccedilotildees a
capacidade de interagir com os clientes de forma contiacutenua com a necessaacuteria
disponibilidade e toleracircncia a particcedilatildeo mantendo baixos custos e o sistema rodando
sem interrupccedilotildees Sem duacutevida seria excelente ter consistecircncia completa o tempo
todo mas eacute preciso haver compensaccedilotildees e a consistecircncia eventual permite o
desenvolvimento eficaz de sistemas que podem lidar com o aumento exponencial de
dados devido agraves redes sociais computaccedilatildeo em nuvem e outros projetos de Big Data
Estudo de Caso shy MongoDBPara fins comparativos seratildeo analisadas nesta seccedilatildeo algumas diferenccedilas entre um
banco NoSQL o MongoDB e os bancos relacionais baseados em SQL O MongoDB eacute
um banco de dados NoSQL criado em 2009 pela empresa 10gen orientado a
documentos altamente escalaacutevel de alta performance e de coacutedigo aberto O
cofundador e diretor de tecnologia da 10gen define o MongoDB da seguinte forma ldquoO
MongoDB natildeo foi concebido em um laboratoacuterio
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1729
Noacutes construiacutemos o MongoDB com base em nossas experiecircncias na construccedilatildeo de
sistemas robustos de grande escala e alta disponibilidade Natildeo comeccedilamos do zero
noacutes tentamos descobrir o que estava problemaacutetico e solucionamos isso
Assim o que eu penso sobre MongoDB eacute que se vocecirc pegar o MySQL e alterar o
modelo de dados do relacional para orientado a documento vocecirc ganha uma grande
quantidade de recursos documentos embarcados para melhorar velocidade
facilidade de gerenciamento desenvolvimento aacutegil com bancos de dados sem
ldquoschemardquo escalabilidade horizontal mais faacutecil pois ldquojoinsrdquo natildeo satildeo tatildeo importantes
Haacute muitas coisas que funcionam muito bem nos bancos de dados relacionais iacutendices
consultas dinacircmicas e atualizaccedilotildees e noacutes natildeo mudamos muito neste ponto Por
exemplo a maneira de projetar seus iacutendices no MongoDB deve ser exatamente do
jeito que vocecirc faz isso no MySQL ou Oracle vocecirc soacute ganha a opccedilatildeo de indexar um
campo embarcadordquo
Como dito na seccedilatildeo de modelos de bancos de dados NoSQL um banco orientado a
documentos natildeo possui esquemas riacutegidos e estruturados sendo possiacutevel que ocorra
uma atualizaccedilatildeo na estrutura do documento Portanto inserir novos campos no
documento natildeo 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 coleccedilatildeo
iacutendice iacutendice
linha documento BSON
coluna campo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1829
joins documentos incorporados e vinculaccedilatildeo
primary key
(Especifica qualquer combinaccedilatildeo de colunas
ou coluna uacutenica como chave primaacuteria)
primary key
(No MongoDB a chave primaacuteria eacute definida
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 dinacircmicos ou seja sem a
necessidade de que cada registro tenha a mesma estrutura Estas estruturas satildeo
chamadas de coleccedilotildees (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 sobrenomeSilva idade22 bairroPituba
Outro documento para representar um aluno na mesma coleccedilatildeo
aluno2=nomeLiardquo sobrenomeSaacute cursoDireito materias[Civil Penal]
Podeshyse ter registros diferentes um do outro dentro de uma mesma coleccedilatildeo Parece
estranho este tipo de abordagem mas no modelo relacional usamos isto o tempo
inteiro e de maneira ineficiente com a formaccedilatildeo de tabelas esparsas
Estas satildeo tabelas incompletas onde algumas colunas satildeo sempre preenchidas e
outras nem sempre satildeo usadas Para ilustrar isto observe a Tabela 4 que apresenta
registros da construccedilatildeo civil
Coacutedigo Produto Altura Potecircncia Peso Diacircmetro
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1929
1 Britadeira 300cv 100kg
2 Cimento
3 Empilhadeira 15cv 300kg
4 Escada 3m
5 Tubulaccedilatildeo 20cm
Tabela 4 Cadastro de produtos da construccedilatildeo civil em banco de dados modelo
relacional
Neste exemplo haacute uma desvantagem no modelo relacional Haacute colunas cujo valor eacute
preenchido apenas uma vez como pode ser visto no exemplo das colunas Altura e
Diacircmetro Na construccedilatildeo das tabelas ao incluir colunas que satildeo pouco utilizadas
jogashyse fora espaccedilo de armazenamento e reduzshyse o desempenho do sistema como
um todo E ainda tratamos objetos diferentes como se fossem iguais o que nem
sempre eacute uma boa praacutetica Abaixo o exemplo de como ficaria este cadastro de
produtos no modelo documental
codigo1 produtoBritadeira potencia300cv peso100kg
codigo2 produtoCimento
codigo3 produtoEmpilhadeira potencia15cv peso300kg
codigo4 produtoEscada altura3m
codigo5 produtoTubulaccedilatildeo diametro20cm
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
Seratildeo apresentados agora alguns comandos comuns usados no MongoDB Voltando
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2029
ao primeiro exemplo de documento criado para alunos observe como ficaria o
comando para salvar os alunos em uma coleccedilatildeo
dbunifacssave(aluno1)
dbunifacssave(aluno2)
O comando acima salva os documentos aluno1 e aluno2 na coleccedilatildeo ldquounifacsrdquo Eacute
possiacutevel acessar os dados de uma coleccedilatildeo atraveacutes do comando find() basicamente
ele vai percorrer todos os registros da coleccedilatildeo e retornar os documentos listados No
exemplo dado o comando seria dbunifacsfind() E para apagar tudo que existe na
coleccedilatildeo dbunifacsremove()
Natildeo eacute necessaacuterio que se crie uma coleccedilatildeo ou mesmo que se configure uma estrutura
isso eacute feito automaticamente quando o primeiro registro eacute incluiacutedo No entanto eacute
possiacutevel usar o comando de criar uma coleccedilatildeo e isto pode ser utilizado para preacuteshy
atribuir espaccedilo para uma coleccedilatildeo Uma coleccedilatildeo de tamanho fixo usa o comando
ldquocappedrdquo e vem a substituir automaticamente as entradas mais antigas quando
atinge seu tamanho maacuteximo
Todas as coleccedilotildees limitadas e fixas devem especificar um tamanho maacuteximo e
tambeacutem podem especificar um nuacutemero maacuteximo de documentos O MongoDB remove
os documentos antigos se uma coleccedilatildeo atinge o limite de tamanho maacuteximo antes
que ele atinja a contagem maacutexima de documentos Considere o seguinte exemplo
dbcreateCollection (unifacs capped true size 5242880 max 5000)
Este comando cria uma coleccedilatildeo nomeada de ldquounifacsrdquo com uma dimensatildeo maacutexima
de 5 megabytes e um maacuteximo de 5000 documentos
Para visualizar todas as coleccedilotildees de um banco de dados MongoDB utilizashyse o
seguinte comando
dbgetCollectionNames()
Enfim haacute muitas diferenccedilas entre os comandos usados no MongoDB e no MySQL As
quatro operaccedilotildees baacutesicas usadas para criaccedilatildeo consulta atualizaccedilatildeo e destruiccedilatildeo de
dados conhecidas como CRUD (Create Read Update e Delete) apresentam
comandos bem distintos nos dois tipos de bancos em questatildeo A Tabela 5 compara
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2129
alguns comandos de CRUD em ambos os bancos
MySQL MongoDB
CREATE TABLE unifacs (
id MEDIUMINT NOT NULL
AUTO_INCREMENT
matricula Number
nome Varchar(30)
idade Number
PRIMARY KEY (id)
)
A coleccedilatildeo eacute criada implicitamente na primeira
inserccedilatildeo de dados O _id chave primaacuteria eacute
adicionada automaticamente se o campo _id natildeo
eacute especificado
dbunifacsinsert (
matricula 04217253
nome Paulo
idade 22
)
ALTER TABLE unifacs
ADD join_date DATETIME
Coleccedilotildees natildeo descrevem ou forccedilam a estrutura
dos seus documentos No entanto no niacutevel do
documento operaccedilotildees de update () podem
adicionar campos para documentos existentes
usando o operador $set e remover usando
$unset
dbunifacsupdate (
$set join_date new Date ()
multi true
)
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2229
ALTER TABLE unifacs
DROP COLUMN join_date
dbunifacsupdate(
$unset join_date
multi true
)
INSERT INTO unifacs (matricula nome
idade)
VALUES (032104211 ldquoJoanardquo 21)
dbunifacsinsert(
matricula 032104211 nome ldquoJoanardquo idade
21
)
SELECT FROM unifacs dbunifacsfind()
SELECT FROM unifacs WHERE idade =
21dbunifacsfind( idade 21 )
SELECT FROM unifacs WHERE nome =
ldquoJoanardquo
AND idade = 21
dbunifacsfind( nome ldquoJoanardquo idade 21 )
SELECT FROM unifacs WHERE idade gt
20dbunifacsfind( age $gt 20 )
SELECT COUNT() FROM unifacs
dbuserscount()
ou
dbunifacsfind()count()
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2329
UPDATE unifacs SET status = ldquoAprovadordquo
WHERE nota gt 7
dbunifacsupdate( nota $gt 7
$set status ldquoAprovadordquo multi true )
UPDATE unifacs SET nota = nota + 1
WHERE status = Aprovado
dbunifacsupdate( status Aprovado
$inc nota 1 multi true )
DELETE FROM unifacs WHERE status =
Reprovadodbunifacsremove( status Reprovado )
Tabela 5 Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
Eacute importante saber que cada documento de uma coleccedilatildeo no MongoDB tem um
tamanho maacuteximo de 16MB o que eacute mais do que suficiente para armazenar dados em
um documento No entanto o MongoDB ainda eacute capaz de armazenar arquivos no
banco de dados em uma coleccedilatildeo especifica que eacute a coleccedilatildeo do tipo GridFS
Ela eacute ideal para trabalhar com arquivos maiores de imagens viacutedeo e aacuteudio O GridFS
divide o arquivo em partes ou pedaccedilos e salva cada pedaccedilo em um documento
separado Quando vocecirc consulta um arquivo no GridFS eacute preciso remontar os
pedaccedilos conforme a necessidade
O MongoDB atinge o objetivo de ser amigaacutevel para o desenvolvedor Possui uma
documentaccedilatildeo bem escrita para a maioria dos principais idiomas Sua consulta
baseada em JavaScript eacute faacutecil para os desenvolvedores da Web e ele tambeacutem eacute faacutecil
de instalar Por estas razotildees o MongoDB eacute uma oacutetima opccedilatildeo de tecnologia para uso
em uma aplicaccedilatildeo
Um exemplo do sucesso deste banco eacute o depoimento do especialista em banco de
dados da Globocom Franklin Amorim Em um evento sobre o MongoDB em 2011 na
cidade de Satildeo Paulo Franklin apresentou o case de sucesso da adoccedilatildeo do MongoDB
para uma nova funccedilatildeo do ldquofantasy gamerdquo CartolaFC
O jogo eacute maior aplicaccedilatildeo dinacircmica do portal Globocom com mais de 2 milhotildees de
usuaacuterios cadastrados e quase 90 milhotildees de pageviews somente em um mecircs
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 629
alternativa para as empresas que necessitam de um modelo de banco de dados mais
flexiacutevel para suportar o seu volume de dados
A constante tendecircncia de computaccedilatildeo em nuvem e o crescimento das redes sociais
satildeo fatores importantes que levam ao desenvolvimento de armazenamento NoSQL
Apesar da existecircncia de muitos bancos de dados NoSQL o movimento ganhou forccedila
quando grandes empresas da tecnologia passaram a usar suas proacuteprias
implementaccedilotildees a fim de fornecer serviccedilos para seus sistemas distribuiacutedos
Buscando atender suas necessidades de armazenamento em 2004 o Google criou o
BigTable
Na sequecircncia buscando tambeacutem a alta disponibilidade a Amazon lanccedilou o Dynamo
Em 2008 o Facebook desenvolveu o Cassandra para tratar o grande volume de
dados e este se mostrou tatildeo eficiente que em 2010 o Twitter deixou o MySQL de
lado para usaacuteshylo
Outras soluccedilotildees lanccediladas satildeo o Apache CouchDB e o MongoDB que satildeo banco de
dados orientados a documentos e com caracteriacutesticas bem semelhantes como alta
performance e escalaacuteveis projetados para suportar sistemas distribuiacutedos em larga
escala
Todos os bancos citados satildeo considerados NoSQL possuem caracteriacutesticas
semelhantes mas tambeacutem possuem particularidades que os diferenciam A proacutexima
seccedilatildeo aborda justamente os diferentes modelos de bancos de dados NoSQL
mostrando suas caracteriacutesticas
31 Modelos de BD NoSQLMais e mais organizaccedilotildees tecircm adotado soluccedilotildees NoSQL para apoiar seus projetos
Estas soluccedilotildees apresentam caracteriacutesticas em comum como uma maior
escalabilidade e alta disponibilidade mas tambeacutem apresentam diversas
singularidades Os bancos de dados NoSQL satildeo subdivididos pela maneira como
armazenam as informaccedilotildees Os principais tipos satildeo Armazenamento ChaveshyValor
(KeyValue) Documento Coluna e Grafo
A soluccedilatildeo chaveshyvalor armazena qualquer coisa como pares de valoresshychave o que
implica valores armazenados recuperados por chaves uacutenicas Satildeo capazes de
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 729
armazenar grandes quantidades de dados e no entanto mantecircm o acesso simples
por uma chave primaacuteria
Este tipo de armazenamento funciona bem para listas como as categorias de
produtos os atributos de cada produto carrinho de compras conteuacutedos ou valores
individuais etc
Por conta disto o Amazon Dynamo eacute uma soluccedilatildeo que adota este modelo Os dados
deste sistema satildeo particionados e replicados usando hashing consistente a fim de
fornecer a escalabilidade e disponibilidade
O segundo modelo de soluccedilatildeo muda o tradicional paradigma de orientaccedilatildeo a
registros (ou tuplas) para orientaccedilatildeo a colunas (ou atributos) Aqui os dados seguem
uma indexaccedilatildeo tripla (linha coluna e timestamp) onde as linhas e as colunas satildeo
identificadas por chaves e o timestamp possibilita a diferenciaccedilatildeo de muacuteltiplas
versotildees de um mesmo dado
Alguns modelos deste tipo de armazenamento possuem colunas (registros que
possuem nome valor e timestamp) famiacutelias de colunas (uma coleccedilatildeo de colunas
equivalente a uma tabela do Modelo Relacional) e supershycolunas (formadas por
arrays de colunas)
O conceito de famiacutelia de colunas pode ser observado na Figura 1 onde
primeiroNome e sobrenome satildeo colunas pertencentes agrave famiacutelia de colunas
denominada nome e as colunas endereccedilo e cidade pertencem agrave famiacutelia local Dois
grandes exemplos de sistemas orientados a coluna satildeo o Cassandra e o BigTable
Figura 1 Exemplo de modelo baseado em colunas
Jaacute uma soluccedilatildeo baseada em documento eacute um tipo de banco de dados que armazena
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 829
coleccedilotildees de documentos Os documentos satildeo representados como objetos com um
uacutenico identificador e um conjunto de campos que podem ser strings listas ou
documentos aninhados Como esta base de dados eacute semiestruturada e natildeo possui
esquema uma informaccedilatildeo especiacutefica 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 temshyse 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 trecircs
componentes baacutesicos os veacutertices (satildeo os noacutes do grafo) as arestas (satildeo os
relacionamentos entre os noacutes) e os atributos dos noacutes e relacionamentos Os dados
satildeo armazenados nos noacutes do grafo e as arestas representam o tipo de associaccedilatildeo
entre eles
Novas arestas podem ser adicionadas (ou as antigas removidas) a qualquer
momento permitindo que relaccedilotildees 1shyN (um para muitos) e NshyN (muitos para muitos)
sejam expressas de forma faacutecil Construccedilotildees como amigos seguidores graus de
separaccedilatildeo listas satildeo muito naturalmente acomodadas em bancos de dados do tipo
grafo
A Figura 3 representa um exemplo de grafo de uma aplicaccedilatildeo que possui
informaccedilotildees 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
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 929
No exemplo da figura temos trecircs pessoas que satildeo noacutes do grafo e estatildeo conectados agrave
cidades que ou jaacute visitaram ou moraram Atraveacutes da representaccedilatildeo do grafo fica faacutecil
perceber que Maria e Joseacute jaacute visitaram o Rio de Janeiro
E que Joatildeo jaacute morou em Recife e Salvador Um exemplo de banco de dados baseado
em grafo eacute o Neo4j que eacute openshysource e implementado em Java
Figura 3 Exemplo de modelo baseado em grafo
Eacute importante ressaltar que nenhum dos modelos apresentados deve ser considerado
superior ao outro pois tudo depende da necessidade da aplicaccedilatildeo Eacute importante que
os desenvolvedores conheccedilam os diversos modelos de soluccedilatildeo para que seja
adotado aquele que mais se adequar ao que a aplicaccedilatildeo ou empresa precisa Isto
contribui para a diminuiccedilatildeo do custo de criaccedilatildeo do banco de dados e com o aumento
do desempenho no processamento dos dados
A Tabela 1 apresenta uma comparaccedilatildeo dos modelos apresentados destacando suas
principais vantagens e desvantagens e ainda citando seus principais exemplos e
suas disponibilidades
Tipo Vantagem Desvantagem Exemplos Disponibilidade
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1029
ChaveValor
Simplicidade
e
escalabilidade
Falta recursos
mais
avanccedilados de
consulta
Amazon
DynamoDB
O niacutevel gratuito da AWS inclui 100
MB de armazenamento 5 unidades
de capacidade de gravaccedilatildeo e 10
unidades de capacidade de leitura
com o Amazon DynamoDB
Disponiacutevel em
httpawsamazoncomptdynamodb
DocumentoFacilidade de
uso
Natildeo eacute
adequado para
dados
relacionais
Consulta
limitada a
chaves e
iacutendices
MongoDB
CouchDB
Como a maioria das licenccedilas de
software livre permite seja usado
modificado e distribuiacutedo por usuaacuterios
Podeshyse adquirir o MongoDB em
httpwwwmongodborg
e CouchDB
httpcouchdbapacheorg
ColunaEscalabilidade
e flexibilidadeComplexidade
Google Big
Table
Cassandra
BigTable foi desenvolvida no Google
em tem sido usado desde 2005 em
dezenas de serviccedilos do Google Uma
versatildeo de coacutedigo aberto HBase foi
criado pelo Apache
httphbaseapacheorg
Jaacute o Cassandra tambeacutem pode ser
adquirido de forma gratuita
httpcassandraapacheorg
Grafo
Modelo de
dados
poderoso e
raacutepido
Flexibilidade
Neo4j Como os demais acima o Neo4j
tambeacutem estaacute disponiacutevel para
download em httpwwwneo4jorg
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1129
Tabela 1 Anaacutelise comparativa dos modelos de BD NoSQL
Modelo Relacional x NoSQLAo se comparar os modelos em questatildeo uma grande diferenccedila a se notar eacute que as
tecnologias relacionais tecircm esquemas riacutegidos enquanto os modelos NoSQL satildeo
schemashyfree ou seja sem esquema O modelo relacional requer uma definiccedilatildeo
estrita de um esquema antes de armazenar todos os dados em um banco de dados
Alterar o esquema uma vez que os dados jaacute estatildeo inseridos eacute muito complicado e
por isso evitado No entanto isto eacute exatamente o oposto do comportamento
desejado na era ldquoBig Datardquo 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 trecircs criteacuterios satildeo
considerados relevantes para esta escolha escalonamento consistecircncia de dados e
disponibilidade E eacute isto que seraacute abordado a partir de agora
Basicamente pelo fato de terem sido criados para essa finalidade os bancos NoSQL
apresentam vantagens em relaccedilatildeo 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 cenaacuterios em que o escalonamento eacute
necessaacuterio
Eacute possiacutevel tornar um banco de dados relacional mais escalaacutevel atraveacutes da teacutecnica de
escalonamento vertical onde eacute feita uma atualizaccedilatildeo (upgrade) no servidor de
bancos de dados
Poreacutem este escalonamento fica limitado agrave capacidade de uma uacutenica maacutequina Jaacute o
escalonamento horizontal eacute feito com o aumento da quantidade de servidores que
iratildeo disponibilizar os dados paralelamente (Figura 4) facilitando o acesso aos dados
e garantindo que a queda de um servidor natildeo seja um problema de disponibilidade
dos dados
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1229
Figura 4 O uso do escalonamento horizontal
Outra caracteriacutestica a favor do NoSQL eacute o uso do sharding que consiste em trabalhar
com o escalonamento horizontal particionando e paralelizando seus dados em vaacuterios
servidores (Figura 5) Essa teacutecnica eacute complexa para se usar em SGBDs relacionais
devido a toda a sua estrutura loacutegica e devido ao uso da desnormalizaccedilatildeo dos dados
o contraacuterio usado no modelo relacional
O sharding traz benefiacutecios pois conjuntos de dados menores satildeo mais faacuteceis de
serem acessados atualizados e gerenciados O maior benefiacutecio em comparaccedilatildeo ao
modelo relacional eacute a otimizaccedilatildeo do grau de disponibilidade do sistema pois como
jaacute dito anteriormente a queda de uma maacutequina natildeo causaria a interrupccedilatildeo de todo o
sistema
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1329
Figura 5 Teacutecnica de sharding
O controle de concorrecircncia tambeacutem funciona de maneira distinta nos modelos em
questatildeo O modelo relacional utiliza bloqueios (locks) como garantia de que dois
usuaacuterios natildeo atualizem o mesmo dado ao mesmo tempo Jaacute no modelo NoSQL satildeo
usadas outras estrateacutegias para permitir um maior grau de concorrecircncia
Alguns bancos NoSQL usam o MVCC (Multiversion Concurrency Control) ou Controle
de Concorrecircncia Multishyversotildees Nesta teacutecnica o acesso aos dados pode ser realizado
em paralelo
Cada usuaacuterio que se conecta ao banco de dados visualiza uma coacutepia temporaacuteria do
banco de dados naquele instante Qualquer atualizaccedilatildeo que esteja sendo feita em
determinado momento por um usuaacuterio natildeo seraacute vista pelos demais que estatildeo
operando simultaneamente no banco de dados ateacute que a atualizaccedilatildeo tenha sido
concluiacuteda
Quando se opta por usar um modelo NoSQL haacute ganhos de performance flexibilidade
e disponibilidade mas haacute uma perda de consistecircncia Haacute um teorema na ciecircncia da
computaccedilatildeo criado Eric Brewer chamado Teorema CAP (Consistency Availability e
Partition Tolerance) que diz ser impossiacutevel para um sistema distribuiacutedo garantir
consistecircncia disponibilidade e toleracircncia ao particionamento De forma simultacircnea
soacute eacute possiacutevel conseguir duas destas trecircs caracteriacutesticas Vejamos exemplos de
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1429
SGBDs na Figura 6 segundo o Teorema CAP
Figura 6 Distribuiccedilatildeo relativa de alguns bancos de dados quanto ao Teorema CAP
As soluccedilotildees NoSQL seguem um paradigma denominado BASE (Basically Available
Soft state Eventual consistency) Este tem como caracteriacutesticas estar basicamente
disponiacutevel o tempo todo estar em estado leve ou seja natildeo sendo consistente o
tempo todo e possuir uma consistecircncia eventual o sistema se torna consistente no
momento apropriado
O modelo BASE eacute um contraste ao paradigma ACID (Atomicity Consistency
Isolation Durability) comumente associado aos bancos de dados de modelo
relacional Ao contraacuterio do modelo ACID que promove uma seguranccedila dos dados
forccedilando a consistecircncia ao final de cada operaccedilatildeo o modelo BASE permite que o
banco de dados esteja em um estado eventualmente consistente
A disponibilidade do modelo BASE estaacute associada justamente ao fato de que a falha
de uma maacutequina do sistema natildeo interrompe o sistema como um todo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1529
Para se analisar de forma mais raacutepida e comparativa a Tabela 2 apresenta as
principais caracteriacutesticas de ambos os modelos discutidos aqui
Modelo Relacional NoSQL
Escalonamento Possui sua natureza
estruturada e por conta disto
o escalonamento de bancos
tende a ser uma tarefa
complexa
Eacute livre de esquemas por isso
o NoSQL possui uma maior
flexibilidade e alta
escalabilidade considerada
uma das principais vantagens
desse modelo
Consistecircncia Possui uma estrutura mais
riacutegida e garante em suas
transaccedilotildees a existecircncia dessa
propriedade As diversas
regras deste modelo
possibilitam uma maior
rigidez quanto a garantia de
consistecircncia dos dados
sendo este o ponto mais
forte desse modelo
A consistecircncia nesse modelo
possui um caraacuteter eventual
o que natildeo garante que uma
determinada atualizaccedilatildeo em
um dado momento seja
percebida por todos os noacutes
Disponibilidade Haacute uma dificuldade de se
trabalhar de forma eficiente
com a distribuiccedilatildeo de dados
por causa de sua natureza
estruturada situaccedilotildees em
que exigem uma maior
demanda de um sistema que
utilizem esse modelo podem
natildeo ser bem suportadas por
ele
Considerada outra das
grandes vantagens do
modelo essa propriedade
junto com o alto grau de
distribuiccedilatildeo desse modelo
possibilita que o sistema
fique um menor periacuteodo de
tempo natildeoshydisponiacutevel assim
como tambeacutem permite que a
solicitaccedilatildeo aos dados por um
nuacutemero crescente de clientes
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1629
seja atendida
Toleracircncia a
Particionamento
Por natildeo terem sido
construiacutedo com a finalidade
de trabalhar com
particionamento de dados
este modelo natildeo possui um
grau muito alto de toleracircncia
ao particionamento cuja
razatildeo principal seria a
dificuldade de junccedilotildees entre
as tabelas
Trabalha de forma faacutecil e
eficiente com a distribuiccedilatildeo
de dados Este modelo eacute
capaz de suportar grandes
demandas de dados assim
como possui alta toleracircncia
ao particionamento dos
mesmos
Tabela 2 Anaacutelise 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 verificaccedilatildeo contiacutenua
da consistecircncia de cada transaccedilatildeo adiciona custos consideraacuteveis para um sistema
que tem milhares de transaccedilotildees ocorrendo
A consistecircncia eventual promovida pelo modelo BASE daacute agraves organizaccedilotildees a
capacidade de interagir com os clientes de forma contiacutenua com a necessaacuteria
disponibilidade e toleracircncia a particcedilatildeo mantendo baixos custos e o sistema rodando
sem interrupccedilotildees Sem duacutevida seria excelente ter consistecircncia completa o tempo
todo mas eacute preciso haver compensaccedilotildees e a consistecircncia eventual permite o
desenvolvimento eficaz de sistemas que podem lidar com o aumento exponencial de
dados devido agraves redes sociais computaccedilatildeo em nuvem e outros projetos de Big Data
Estudo de Caso shy MongoDBPara fins comparativos seratildeo analisadas nesta seccedilatildeo algumas diferenccedilas entre um
banco NoSQL o MongoDB e os bancos relacionais baseados em SQL O MongoDB eacute
um banco de dados NoSQL criado em 2009 pela empresa 10gen orientado a
documentos altamente escalaacutevel de alta performance e de coacutedigo aberto O
cofundador e diretor de tecnologia da 10gen define o MongoDB da seguinte forma ldquoO
MongoDB natildeo foi concebido em um laboratoacuterio
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1729
Noacutes construiacutemos o MongoDB com base em nossas experiecircncias na construccedilatildeo de
sistemas robustos de grande escala e alta disponibilidade Natildeo comeccedilamos do zero
noacutes tentamos descobrir o que estava problemaacutetico e solucionamos isso
Assim o que eu penso sobre MongoDB eacute que se vocecirc pegar o MySQL e alterar o
modelo de dados do relacional para orientado a documento vocecirc ganha uma grande
quantidade de recursos documentos embarcados para melhorar velocidade
facilidade de gerenciamento desenvolvimento aacutegil com bancos de dados sem
ldquoschemardquo escalabilidade horizontal mais faacutecil pois ldquojoinsrdquo natildeo satildeo tatildeo importantes
Haacute muitas coisas que funcionam muito bem nos bancos de dados relacionais iacutendices
consultas dinacircmicas e atualizaccedilotildees e noacutes natildeo mudamos muito neste ponto Por
exemplo a maneira de projetar seus iacutendices no MongoDB deve ser exatamente do
jeito que vocecirc faz isso no MySQL ou Oracle vocecirc soacute ganha a opccedilatildeo de indexar um
campo embarcadordquo
Como dito na seccedilatildeo de modelos de bancos de dados NoSQL um banco orientado a
documentos natildeo possui esquemas riacutegidos e estruturados sendo possiacutevel que ocorra
uma atualizaccedilatildeo na estrutura do documento Portanto inserir novos campos no
documento natildeo 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 coleccedilatildeo
iacutendice iacutendice
linha documento BSON
coluna campo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1829
joins documentos incorporados e vinculaccedilatildeo
primary key
(Especifica qualquer combinaccedilatildeo de colunas
ou coluna uacutenica como chave primaacuteria)
primary key
(No MongoDB a chave primaacuteria eacute definida
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 dinacircmicos ou seja sem a
necessidade de que cada registro tenha a mesma estrutura Estas estruturas satildeo
chamadas de coleccedilotildees (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 sobrenomeSilva idade22 bairroPituba
Outro documento para representar um aluno na mesma coleccedilatildeo
aluno2=nomeLiardquo sobrenomeSaacute cursoDireito materias[Civil Penal]
Podeshyse ter registros diferentes um do outro dentro de uma mesma coleccedilatildeo Parece
estranho este tipo de abordagem mas no modelo relacional usamos isto o tempo
inteiro e de maneira ineficiente com a formaccedilatildeo de tabelas esparsas
Estas satildeo tabelas incompletas onde algumas colunas satildeo sempre preenchidas e
outras nem sempre satildeo usadas Para ilustrar isto observe a Tabela 4 que apresenta
registros da construccedilatildeo civil
Coacutedigo Produto Altura Potecircncia Peso Diacircmetro
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1929
1 Britadeira 300cv 100kg
2 Cimento
3 Empilhadeira 15cv 300kg
4 Escada 3m
5 Tubulaccedilatildeo 20cm
Tabela 4 Cadastro de produtos da construccedilatildeo civil em banco de dados modelo
relacional
Neste exemplo haacute uma desvantagem no modelo relacional Haacute colunas cujo valor eacute
preenchido apenas uma vez como pode ser visto no exemplo das colunas Altura e
Diacircmetro Na construccedilatildeo das tabelas ao incluir colunas que satildeo pouco utilizadas
jogashyse fora espaccedilo de armazenamento e reduzshyse o desempenho do sistema como
um todo E ainda tratamos objetos diferentes como se fossem iguais o que nem
sempre eacute uma boa praacutetica Abaixo o exemplo de como ficaria este cadastro de
produtos no modelo documental
codigo1 produtoBritadeira potencia300cv peso100kg
codigo2 produtoCimento
codigo3 produtoEmpilhadeira potencia15cv peso300kg
codigo4 produtoEscada altura3m
codigo5 produtoTubulaccedilatildeo diametro20cm
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
Seratildeo apresentados agora alguns comandos comuns usados no MongoDB Voltando
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2029
ao primeiro exemplo de documento criado para alunos observe como ficaria o
comando para salvar os alunos em uma coleccedilatildeo
dbunifacssave(aluno1)
dbunifacssave(aluno2)
O comando acima salva os documentos aluno1 e aluno2 na coleccedilatildeo ldquounifacsrdquo Eacute
possiacutevel acessar os dados de uma coleccedilatildeo atraveacutes do comando find() basicamente
ele vai percorrer todos os registros da coleccedilatildeo e retornar os documentos listados No
exemplo dado o comando seria dbunifacsfind() E para apagar tudo que existe na
coleccedilatildeo dbunifacsremove()
Natildeo eacute necessaacuterio que se crie uma coleccedilatildeo ou mesmo que se configure uma estrutura
isso eacute feito automaticamente quando o primeiro registro eacute incluiacutedo No entanto eacute
possiacutevel usar o comando de criar uma coleccedilatildeo e isto pode ser utilizado para preacuteshy
atribuir espaccedilo para uma coleccedilatildeo Uma coleccedilatildeo de tamanho fixo usa o comando
ldquocappedrdquo e vem a substituir automaticamente as entradas mais antigas quando
atinge seu tamanho maacuteximo
Todas as coleccedilotildees limitadas e fixas devem especificar um tamanho maacuteximo e
tambeacutem podem especificar um nuacutemero maacuteximo de documentos O MongoDB remove
os documentos antigos se uma coleccedilatildeo atinge o limite de tamanho maacuteximo antes
que ele atinja a contagem maacutexima de documentos Considere o seguinte exemplo
dbcreateCollection (unifacs capped true size 5242880 max 5000)
Este comando cria uma coleccedilatildeo nomeada de ldquounifacsrdquo com uma dimensatildeo maacutexima
de 5 megabytes e um maacuteximo de 5000 documentos
Para visualizar todas as coleccedilotildees de um banco de dados MongoDB utilizashyse o
seguinte comando
dbgetCollectionNames()
Enfim haacute muitas diferenccedilas entre os comandos usados no MongoDB e no MySQL As
quatro operaccedilotildees baacutesicas usadas para criaccedilatildeo consulta atualizaccedilatildeo e destruiccedilatildeo de
dados conhecidas como CRUD (Create Read Update e Delete) apresentam
comandos bem distintos nos dois tipos de bancos em questatildeo A Tabela 5 compara
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2129
alguns comandos de CRUD em ambos os bancos
MySQL MongoDB
CREATE TABLE unifacs (
id MEDIUMINT NOT NULL
AUTO_INCREMENT
matricula Number
nome Varchar(30)
idade Number
PRIMARY KEY (id)
)
A coleccedilatildeo eacute criada implicitamente na primeira
inserccedilatildeo de dados O _id chave primaacuteria eacute
adicionada automaticamente se o campo _id natildeo
eacute especificado
dbunifacsinsert (
matricula 04217253
nome Paulo
idade 22
)
ALTER TABLE unifacs
ADD join_date DATETIME
Coleccedilotildees natildeo descrevem ou forccedilam a estrutura
dos seus documentos No entanto no niacutevel do
documento operaccedilotildees de update () podem
adicionar campos para documentos existentes
usando o operador $set e remover usando
$unset
dbunifacsupdate (
$set join_date new Date ()
multi true
)
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2229
ALTER TABLE unifacs
DROP COLUMN join_date
dbunifacsupdate(
$unset join_date
multi true
)
INSERT INTO unifacs (matricula nome
idade)
VALUES (032104211 ldquoJoanardquo 21)
dbunifacsinsert(
matricula 032104211 nome ldquoJoanardquo idade
21
)
SELECT FROM unifacs dbunifacsfind()
SELECT FROM unifacs WHERE idade =
21dbunifacsfind( idade 21 )
SELECT FROM unifacs WHERE nome =
ldquoJoanardquo
AND idade = 21
dbunifacsfind( nome ldquoJoanardquo idade 21 )
SELECT FROM unifacs WHERE idade gt
20dbunifacsfind( age $gt 20 )
SELECT COUNT() FROM unifacs
dbuserscount()
ou
dbunifacsfind()count()
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2329
UPDATE unifacs SET status = ldquoAprovadordquo
WHERE nota gt 7
dbunifacsupdate( nota $gt 7
$set status ldquoAprovadordquo multi true )
UPDATE unifacs SET nota = nota + 1
WHERE status = Aprovado
dbunifacsupdate( status Aprovado
$inc nota 1 multi true )
DELETE FROM unifacs WHERE status =
Reprovadodbunifacsremove( status Reprovado )
Tabela 5 Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
Eacute importante saber que cada documento de uma coleccedilatildeo no MongoDB tem um
tamanho maacuteximo de 16MB o que eacute mais do que suficiente para armazenar dados em
um documento No entanto o MongoDB ainda eacute capaz de armazenar arquivos no
banco de dados em uma coleccedilatildeo especifica que eacute a coleccedilatildeo do tipo GridFS
Ela eacute ideal para trabalhar com arquivos maiores de imagens viacutedeo e aacuteudio O GridFS
divide o arquivo em partes ou pedaccedilos e salva cada pedaccedilo em um documento
separado Quando vocecirc consulta um arquivo no GridFS eacute preciso remontar os
pedaccedilos conforme a necessidade
O MongoDB atinge o objetivo de ser amigaacutevel para o desenvolvedor Possui uma
documentaccedilatildeo bem escrita para a maioria dos principais idiomas Sua consulta
baseada em JavaScript eacute faacutecil para os desenvolvedores da Web e ele tambeacutem eacute faacutecil
de instalar Por estas razotildees o MongoDB eacute uma oacutetima opccedilatildeo de tecnologia para uso
em uma aplicaccedilatildeo
Um exemplo do sucesso deste banco eacute o depoimento do especialista em banco de
dados da Globocom Franklin Amorim Em um evento sobre o MongoDB em 2011 na
cidade de Satildeo Paulo Franklin apresentou o case de sucesso da adoccedilatildeo do MongoDB
para uma nova funccedilatildeo do ldquofantasy gamerdquo CartolaFC
O jogo eacute maior aplicaccedilatildeo dinacircmica do portal Globocom com mais de 2 milhotildees de
usuaacuterios cadastrados e quase 90 milhotildees de pageviews somente em um mecircs
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 729
armazenar grandes quantidades de dados e no entanto mantecircm o acesso simples
por uma chave primaacuteria
Este tipo de armazenamento funciona bem para listas como as categorias de
produtos os atributos de cada produto carrinho de compras conteuacutedos ou valores
individuais etc
Por conta disto o Amazon Dynamo eacute uma soluccedilatildeo que adota este modelo Os dados
deste sistema satildeo particionados e replicados usando hashing consistente a fim de
fornecer a escalabilidade e disponibilidade
O segundo modelo de soluccedilatildeo muda o tradicional paradigma de orientaccedilatildeo a
registros (ou tuplas) para orientaccedilatildeo a colunas (ou atributos) Aqui os dados seguem
uma indexaccedilatildeo tripla (linha coluna e timestamp) onde as linhas e as colunas satildeo
identificadas por chaves e o timestamp possibilita a diferenciaccedilatildeo de muacuteltiplas
versotildees de um mesmo dado
Alguns modelos deste tipo de armazenamento possuem colunas (registros que
possuem nome valor e timestamp) famiacutelias de colunas (uma coleccedilatildeo de colunas
equivalente a uma tabela do Modelo Relacional) e supershycolunas (formadas por
arrays de colunas)
O conceito de famiacutelia de colunas pode ser observado na Figura 1 onde
primeiroNome e sobrenome satildeo colunas pertencentes agrave famiacutelia de colunas
denominada nome e as colunas endereccedilo e cidade pertencem agrave famiacutelia local Dois
grandes exemplos de sistemas orientados a coluna satildeo o Cassandra e o BigTable
Figura 1 Exemplo de modelo baseado em colunas
Jaacute uma soluccedilatildeo baseada em documento eacute um tipo de banco de dados que armazena
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 829
coleccedilotildees de documentos Os documentos satildeo representados como objetos com um
uacutenico identificador e um conjunto de campos que podem ser strings listas ou
documentos aninhados Como esta base de dados eacute semiestruturada e natildeo possui
esquema uma informaccedilatildeo especiacutefica 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 temshyse 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 trecircs
componentes baacutesicos os veacutertices (satildeo os noacutes do grafo) as arestas (satildeo os
relacionamentos entre os noacutes) e os atributos dos noacutes e relacionamentos Os dados
satildeo armazenados nos noacutes do grafo e as arestas representam o tipo de associaccedilatildeo
entre eles
Novas arestas podem ser adicionadas (ou as antigas removidas) a qualquer
momento permitindo que relaccedilotildees 1shyN (um para muitos) e NshyN (muitos para muitos)
sejam expressas de forma faacutecil Construccedilotildees como amigos seguidores graus de
separaccedilatildeo listas satildeo muito naturalmente acomodadas em bancos de dados do tipo
grafo
A Figura 3 representa um exemplo de grafo de uma aplicaccedilatildeo que possui
informaccedilotildees 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
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 929
No exemplo da figura temos trecircs pessoas que satildeo noacutes do grafo e estatildeo conectados agrave
cidades que ou jaacute visitaram ou moraram Atraveacutes da representaccedilatildeo do grafo fica faacutecil
perceber que Maria e Joseacute jaacute visitaram o Rio de Janeiro
E que Joatildeo jaacute morou em Recife e Salvador Um exemplo de banco de dados baseado
em grafo eacute o Neo4j que eacute openshysource e implementado em Java
Figura 3 Exemplo de modelo baseado em grafo
Eacute importante ressaltar que nenhum dos modelos apresentados deve ser considerado
superior ao outro pois tudo depende da necessidade da aplicaccedilatildeo Eacute importante que
os desenvolvedores conheccedilam os diversos modelos de soluccedilatildeo para que seja
adotado aquele que mais se adequar ao que a aplicaccedilatildeo ou empresa precisa Isto
contribui para a diminuiccedilatildeo do custo de criaccedilatildeo do banco de dados e com o aumento
do desempenho no processamento dos dados
A Tabela 1 apresenta uma comparaccedilatildeo dos modelos apresentados destacando suas
principais vantagens e desvantagens e ainda citando seus principais exemplos e
suas disponibilidades
Tipo Vantagem Desvantagem Exemplos Disponibilidade
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1029
ChaveValor
Simplicidade
e
escalabilidade
Falta recursos
mais
avanccedilados de
consulta
Amazon
DynamoDB
O niacutevel gratuito da AWS inclui 100
MB de armazenamento 5 unidades
de capacidade de gravaccedilatildeo e 10
unidades de capacidade de leitura
com o Amazon DynamoDB
Disponiacutevel em
httpawsamazoncomptdynamodb
DocumentoFacilidade de
uso
Natildeo eacute
adequado para
dados
relacionais
Consulta
limitada a
chaves e
iacutendices
MongoDB
CouchDB
Como a maioria das licenccedilas de
software livre permite seja usado
modificado e distribuiacutedo por usuaacuterios
Podeshyse adquirir o MongoDB em
httpwwwmongodborg
e CouchDB
httpcouchdbapacheorg
ColunaEscalabilidade
e flexibilidadeComplexidade
Google Big
Table
Cassandra
BigTable foi desenvolvida no Google
em tem sido usado desde 2005 em
dezenas de serviccedilos do Google Uma
versatildeo de coacutedigo aberto HBase foi
criado pelo Apache
httphbaseapacheorg
Jaacute o Cassandra tambeacutem pode ser
adquirido de forma gratuita
httpcassandraapacheorg
Grafo
Modelo de
dados
poderoso e
raacutepido
Flexibilidade
Neo4j Como os demais acima o Neo4j
tambeacutem estaacute disponiacutevel para
download em httpwwwneo4jorg
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1129
Tabela 1 Anaacutelise comparativa dos modelos de BD NoSQL
Modelo Relacional x NoSQLAo se comparar os modelos em questatildeo uma grande diferenccedila a se notar eacute que as
tecnologias relacionais tecircm esquemas riacutegidos enquanto os modelos NoSQL satildeo
schemashyfree ou seja sem esquema O modelo relacional requer uma definiccedilatildeo
estrita de um esquema antes de armazenar todos os dados em um banco de dados
Alterar o esquema uma vez que os dados jaacute estatildeo inseridos eacute muito complicado e
por isso evitado No entanto isto eacute exatamente o oposto do comportamento
desejado na era ldquoBig Datardquo 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 trecircs criteacuterios satildeo
considerados relevantes para esta escolha escalonamento consistecircncia de dados e
disponibilidade E eacute isto que seraacute abordado a partir de agora
Basicamente pelo fato de terem sido criados para essa finalidade os bancos NoSQL
apresentam vantagens em relaccedilatildeo 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 cenaacuterios em que o escalonamento eacute
necessaacuterio
Eacute possiacutevel tornar um banco de dados relacional mais escalaacutevel atraveacutes da teacutecnica de
escalonamento vertical onde eacute feita uma atualizaccedilatildeo (upgrade) no servidor de
bancos de dados
Poreacutem este escalonamento fica limitado agrave capacidade de uma uacutenica maacutequina Jaacute o
escalonamento horizontal eacute feito com o aumento da quantidade de servidores que
iratildeo disponibilizar os dados paralelamente (Figura 4) facilitando o acesso aos dados
e garantindo que a queda de um servidor natildeo seja um problema de disponibilidade
dos dados
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1229
Figura 4 O uso do escalonamento horizontal
Outra caracteriacutestica a favor do NoSQL eacute o uso do sharding que consiste em trabalhar
com o escalonamento horizontal particionando e paralelizando seus dados em vaacuterios
servidores (Figura 5) Essa teacutecnica eacute complexa para se usar em SGBDs relacionais
devido a toda a sua estrutura loacutegica e devido ao uso da desnormalizaccedilatildeo dos dados
o contraacuterio usado no modelo relacional
O sharding traz benefiacutecios pois conjuntos de dados menores satildeo mais faacuteceis de
serem acessados atualizados e gerenciados O maior benefiacutecio em comparaccedilatildeo ao
modelo relacional eacute a otimizaccedilatildeo do grau de disponibilidade do sistema pois como
jaacute dito anteriormente a queda de uma maacutequina natildeo causaria a interrupccedilatildeo de todo o
sistema
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1329
Figura 5 Teacutecnica de sharding
O controle de concorrecircncia tambeacutem funciona de maneira distinta nos modelos em
questatildeo O modelo relacional utiliza bloqueios (locks) como garantia de que dois
usuaacuterios natildeo atualizem o mesmo dado ao mesmo tempo Jaacute no modelo NoSQL satildeo
usadas outras estrateacutegias para permitir um maior grau de concorrecircncia
Alguns bancos NoSQL usam o MVCC (Multiversion Concurrency Control) ou Controle
de Concorrecircncia Multishyversotildees Nesta teacutecnica o acesso aos dados pode ser realizado
em paralelo
Cada usuaacuterio que se conecta ao banco de dados visualiza uma coacutepia temporaacuteria do
banco de dados naquele instante Qualquer atualizaccedilatildeo que esteja sendo feita em
determinado momento por um usuaacuterio natildeo seraacute vista pelos demais que estatildeo
operando simultaneamente no banco de dados ateacute que a atualizaccedilatildeo tenha sido
concluiacuteda
Quando se opta por usar um modelo NoSQL haacute ganhos de performance flexibilidade
e disponibilidade mas haacute uma perda de consistecircncia Haacute um teorema na ciecircncia da
computaccedilatildeo criado Eric Brewer chamado Teorema CAP (Consistency Availability e
Partition Tolerance) que diz ser impossiacutevel para um sistema distribuiacutedo garantir
consistecircncia disponibilidade e toleracircncia ao particionamento De forma simultacircnea
soacute eacute possiacutevel conseguir duas destas trecircs caracteriacutesticas Vejamos exemplos de
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1429
SGBDs na Figura 6 segundo o Teorema CAP
Figura 6 Distribuiccedilatildeo relativa de alguns bancos de dados quanto ao Teorema CAP
As soluccedilotildees NoSQL seguem um paradigma denominado BASE (Basically Available
Soft state Eventual consistency) Este tem como caracteriacutesticas estar basicamente
disponiacutevel o tempo todo estar em estado leve ou seja natildeo sendo consistente o
tempo todo e possuir uma consistecircncia eventual o sistema se torna consistente no
momento apropriado
O modelo BASE eacute um contraste ao paradigma ACID (Atomicity Consistency
Isolation Durability) comumente associado aos bancos de dados de modelo
relacional Ao contraacuterio do modelo ACID que promove uma seguranccedila dos dados
forccedilando a consistecircncia ao final de cada operaccedilatildeo o modelo BASE permite que o
banco de dados esteja em um estado eventualmente consistente
A disponibilidade do modelo BASE estaacute associada justamente ao fato de que a falha
de uma maacutequina do sistema natildeo interrompe o sistema como um todo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1529
Para se analisar de forma mais raacutepida e comparativa a Tabela 2 apresenta as
principais caracteriacutesticas de ambos os modelos discutidos aqui
Modelo Relacional NoSQL
Escalonamento Possui sua natureza
estruturada e por conta disto
o escalonamento de bancos
tende a ser uma tarefa
complexa
Eacute livre de esquemas por isso
o NoSQL possui uma maior
flexibilidade e alta
escalabilidade considerada
uma das principais vantagens
desse modelo
Consistecircncia Possui uma estrutura mais
riacutegida e garante em suas
transaccedilotildees a existecircncia dessa
propriedade As diversas
regras deste modelo
possibilitam uma maior
rigidez quanto a garantia de
consistecircncia dos dados
sendo este o ponto mais
forte desse modelo
A consistecircncia nesse modelo
possui um caraacuteter eventual
o que natildeo garante que uma
determinada atualizaccedilatildeo em
um dado momento seja
percebida por todos os noacutes
Disponibilidade Haacute uma dificuldade de se
trabalhar de forma eficiente
com a distribuiccedilatildeo de dados
por causa de sua natureza
estruturada situaccedilotildees em
que exigem uma maior
demanda de um sistema que
utilizem esse modelo podem
natildeo ser bem suportadas por
ele
Considerada outra das
grandes vantagens do
modelo essa propriedade
junto com o alto grau de
distribuiccedilatildeo desse modelo
possibilita que o sistema
fique um menor periacuteodo de
tempo natildeoshydisponiacutevel assim
como tambeacutem permite que a
solicitaccedilatildeo aos dados por um
nuacutemero crescente de clientes
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1629
seja atendida
Toleracircncia a
Particionamento
Por natildeo terem sido
construiacutedo com a finalidade
de trabalhar com
particionamento de dados
este modelo natildeo possui um
grau muito alto de toleracircncia
ao particionamento cuja
razatildeo principal seria a
dificuldade de junccedilotildees entre
as tabelas
Trabalha de forma faacutecil e
eficiente com a distribuiccedilatildeo
de dados Este modelo eacute
capaz de suportar grandes
demandas de dados assim
como possui alta toleracircncia
ao particionamento dos
mesmos
Tabela 2 Anaacutelise 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 verificaccedilatildeo contiacutenua
da consistecircncia de cada transaccedilatildeo adiciona custos consideraacuteveis para um sistema
que tem milhares de transaccedilotildees ocorrendo
A consistecircncia eventual promovida pelo modelo BASE daacute agraves organizaccedilotildees a
capacidade de interagir com os clientes de forma contiacutenua com a necessaacuteria
disponibilidade e toleracircncia a particcedilatildeo mantendo baixos custos e o sistema rodando
sem interrupccedilotildees Sem duacutevida seria excelente ter consistecircncia completa o tempo
todo mas eacute preciso haver compensaccedilotildees e a consistecircncia eventual permite o
desenvolvimento eficaz de sistemas que podem lidar com o aumento exponencial de
dados devido agraves redes sociais computaccedilatildeo em nuvem e outros projetos de Big Data
Estudo de Caso shy MongoDBPara fins comparativos seratildeo analisadas nesta seccedilatildeo algumas diferenccedilas entre um
banco NoSQL o MongoDB e os bancos relacionais baseados em SQL O MongoDB eacute
um banco de dados NoSQL criado em 2009 pela empresa 10gen orientado a
documentos altamente escalaacutevel de alta performance e de coacutedigo aberto O
cofundador e diretor de tecnologia da 10gen define o MongoDB da seguinte forma ldquoO
MongoDB natildeo foi concebido em um laboratoacuterio
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1729
Noacutes construiacutemos o MongoDB com base em nossas experiecircncias na construccedilatildeo de
sistemas robustos de grande escala e alta disponibilidade Natildeo comeccedilamos do zero
noacutes tentamos descobrir o que estava problemaacutetico e solucionamos isso
Assim o que eu penso sobre MongoDB eacute que se vocecirc pegar o MySQL e alterar o
modelo de dados do relacional para orientado a documento vocecirc ganha uma grande
quantidade de recursos documentos embarcados para melhorar velocidade
facilidade de gerenciamento desenvolvimento aacutegil com bancos de dados sem
ldquoschemardquo escalabilidade horizontal mais faacutecil pois ldquojoinsrdquo natildeo satildeo tatildeo importantes
Haacute muitas coisas que funcionam muito bem nos bancos de dados relacionais iacutendices
consultas dinacircmicas e atualizaccedilotildees e noacutes natildeo mudamos muito neste ponto Por
exemplo a maneira de projetar seus iacutendices no MongoDB deve ser exatamente do
jeito que vocecirc faz isso no MySQL ou Oracle vocecirc soacute ganha a opccedilatildeo de indexar um
campo embarcadordquo
Como dito na seccedilatildeo de modelos de bancos de dados NoSQL um banco orientado a
documentos natildeo possui esquemas riacutegidos e estruturados sendo possiacutevel que ocorra
uma atualizaccedilatildeo na estrutura do documento Portanto inserir novos campos no
documento natildeo 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 coleccedilatildeo
iacutendice iacutendice
linha documento BSON
coluna campo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1829
joins documentos incorporados e vinculaccedilatildeo
primary key
(Especifica qualquer combinaccedilatildeo de colunas
ou coluna uacutenica como chave primaacuteria)
primary key
(No MongoDB a chave primaacuteria eacute definida
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 dinacircmicos ou seja sem a
necessidade de que cada registro tenha a mesma estrutura Estas estruturas satildeo
chamadas de coleccedilotildees (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 sobrenomeSilva idade22 bairroPituba
Outro documento para representar um aluno na mesma coleccedilatildeo
aluno2=nomeLiardquo sobrenomeSaacute cursoDireito materias[Civil Penal]
Podeshyse ter registros diferentes um do outro dentro de uma mesma coleccedilatildeo Parece
estranho este tipo de abordagem mas no modelo relacional usamos isto o tempo
inteiro e de maneira ineficiente com a formaccedilatildeo de tabelas esparsas
Estas satildeo tabelas incompletas onde algumas colunas satildeo sempre preenchidas e
outras nem sempre satildeo usadas Para ilustrar isto observe a Tabela 4 que apresenta
registros da construccedilatildeo civil
Coacutedigo Produto Altura Potecircncia Peso Diacircmetro
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1929
1 Britadeira 300cv 100kg
2 Cimento
3 Empilhadeira 15cv 300kg
4 Escada 3m
5 Tubulaccedilatildeo 20cm
Tabela 4 Cadastro de produtos da construccedilatildeo civil em banco de dados modelo
relacional
Neste exemplo haacute uma desvantagem no modelo relacional Haacute colunas cujo valor eacute
preenchido apenas uma vez como pode ser visto no exemplo das colunas Altura e
Diacircmetro Na construccedilatildeo das tabelas ao incluir colunas que satildeo pouco utilizadas
jogashyse fora espaccedilo de armazenamento e reduzshyse o desempenho do sistema como
um todo E ainda tratamos objetos diferentes como se fossem iguais o que nem
sempre eacute uma boa praacutetica Abaixo o exemplo de como ficaria este cadastro de
produtos no modelo documental
codigo1 produtoBritadeira potencia300cv peso100kg
codigo2 produtoCimento
codigo3 produtoEmpilhadeira potencia15cv peso300kg
codigo4 produtoEscada altura3m
codigo5 produtoTubulaccedilatildeo diametro20cm
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
Seratildeo apresentados agora alguns comandos comuns usados no MongoDB Voltando
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2029
ao primeiro exemplo de documento criado para alunos observe como ficaria o
comando para salvar os alunos em uma coleccedilatildeo
dbunifacssave(aluno1)
dbunifacssave(aluno2)
O comando acima salva os documentos aluno1 e aluno2 na coleccedilatildeo ldquounifacsrdquo Eacute
possiacutevel acessar os dados de uma coleccedilatildeo atraveacutes do comando find() basicamente
ele vai percorrer todos os registros da coleccedilatildeo e retornar os documentos listados No
exemplo dado o comando seria dbunifacsfind() E para apagar tudo que existe na
coleccedilatildeo dbunifacsremove()
Natildeo eacute necessaacuterio que se crie uma coleccedilatildeo ou mesmo que se configure uma estrutura
isso eacute feito automaticamente quando o primeiro registro eacute incluiacutedo No entanto eacute
possiacutevel usar o comando de criar uma coleccedilatildeo e isto pode ser utilizado para preacuteshy
atribuir espaccedilo para uma coleccedilatildeo Uma coleccedilatildeo de tamanho fixo usa o comando
ldquocappedrdquo e vem a substituir automaticamente as entradas mais antigas quando
atinge seu tamanho maacuteximo
Todas as coleccedilotildees limitadas e fixas devem especificar um tamanho maacuteximo e
tambeacutem podem especificar um nuacutemero maacuteximo de documentos O MongoDB remove
os documentos antigos se uma coleccedilatildeo atinge o limite de tamanho maacuteximo antes
que ele atinja a contagem maacutexima de documentos Considere o seguinte exemplo
dbcreateCollection (unifacs capped true size 5242880 max 5000)
Este comando cria uma coleccedilatildeo nomeada de ldquounifacsrdquo com uma dimensatildeo maacutexima
de 5 megabytes e um maacuteximo de 5000 documentos
Para visualizar todas as coleccedilotildees de um banco de dados MongoDB utilizashyse o
seguinte comando
dbgetCollectionNames()
Enfim haacute muitas diferenccedilas entre os comandos usados no MongoDB e no MySQL As
quatro operaccedilotildees baacutesicas usadas para criaccedilatildeo consulta atualizaccedilatildeo e destruiccedilatildeo de
dados conhecidas como CRUD (Create Read Update e Delete) apresentam
comandos bem distintos nos dois tipos de bancos em questatildeo A Tabela 5 compara
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2129
alguns comandos de CRUD em ambos os bancos
MySQL MongoDB
CREATE TABLE unifacs (
id MEDIUMINT NOT NULL
AUTO_INCREMENT
matricula Number
nome Varchar(30)
idade Number
PRIMARY KEY (id)
)
A coleccedilatildeo eacute criada implicitamente na primeira
inserccedilatildeo de dados O _id chave primaacuteria eacute
adicionada automaticamente se o campo _id natildeo
eacute especificado
dbunifacsinsert (
matricula 04217253
nome Paulo
idade 22
)
ALTER TABLE unifacs
ADD join_date DATETIME
Coleccedilotildees natildeo descrevem ou forccedilam a estrutura
dos seus documentos No entanto no niacutevel do
documento operaccedilotildees de update () podem
adicionar campos para documentos existentes
usando o operador $set e remover usando
$unset
dbunifacsupdate (
$set join_date new Date ()
multi true
)
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2229
ALTER TABLE unifacs
DROP COLUMN join_date
dbunifacsupdate(
$unset join_date
multi true
)
INSERT INTO unifacs (matricula nome
idade)
VALUES (032104211 ldquoJoanardquo 21)
dbunifacsinsert(
matricula 032104211 nome ldquoJoanardquo idade
21
)
SELECT FROM unifacs dbunifacsfind()
SELECT FROM unifacs WHERE idade =
21dbunifacsfind( idade 21 )
SELECT FROM unifacs WHERE nome =
ldquoJoanardquo
AND idade = 21
dbunifacsfind( nome ldquoJoanardquo idade 21 )
SELECT FROM unifacs WHERE idade gt
20dbunifacsfind( age $gt 20 )
SELECT COUNT() FROM unifacs
dbuserscount()
ou
dbunifacsfind()count()
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2329
UPDATE unifacs SET status = ldquoAprovadordquo
WHERE nota gt 7
dbunifacsupdate( nota $gt 7
$set status ldquoAprovadordquo multi true )
UPDATE unifacs SET nota = nota + 1
WHERE status = Aprovado
dbunifacsupdate( status Aprovado
$inc nota 1 multi true )
DELETE FROM unifacs WHERE status =
Reprovadodbunifacsremove( status Reprovado )
Tabela 5 Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
Eacute importante saber que cada documento de uma coleccedilatildeo no MongoDB tem um
tamanho maacuteximo de 16MB o que eacute mais do que suficiente para armazenar dados em
um documento No entanto o MongoDB ainda eacute capaz de armazenar arquivos no
banco de dados em uma coleccedilatildeo especifica que eacute a coleccedilatildeo do tipo GridFS
Ela eacute ideal para trabalhar com arquivos maiores de imagens viacutedeo e aacuteudio O GridFS
divide o arquivo em partes ou pedaccedilos e salva cada pedaccedilo em um documento
separado Quando vocecirc consulta um arquivo no GridFS eacute preciso remontar os
pedaccedilos conforme a necessidade
O MongoDB atinge o objetivo de ser amigaacutevel para o desenvolvedor Possui uma
documentaccedilatildeo bem escrita para a maioria dos principais idiomas Sua consulta
baseada em JavaScript eacute faacutecil para os desenvolvedores da Web e ele tambeacutem eacute faacutecil
de instalar Por estas razotildees o MongoDB eacute uma oacutetima opccedilatildeo de tecnologia para uso
em uma aplicaccedilatildeo
Um exemplo do sucesso deste banco eacute o depoimento do especialista em banco de
dados da Globocom Franklin Amorim Em um evento sobre o MongoDB em 2011 na
cidade de Satildeo Paulo Franklin apresentou o case de sucesso da adoccedilatildeo do MongoDB
para uma nova funccedilatildeo do ldquofantasy gamerdquo CartolaFC
O jogo eacute maior aplicaccedilatildeo dinacircmica do portal Globocom com mais de 2 milhotildees de
usuaacuterios cadastrados e quase 90 milhotildees de pageviews somente em um mecircs
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 829
coleccedilotildees de documentos Os documentos satildeo representados como objetos com um
uacutenico identificador e um conjunto de campos que podem ser strings listas ou
documentos aninhados Como esta base de dados eacute semiestruturada e natildeo possui
esquema uma informaccedilatildeo especiacutefica 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 temshyse 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 trecircs
componentes baacutesicos os veacutertices (satildeo os noacutes do grafo) as arestas (satildeo os
relacionamentos entre os noacutes) e os atributos dos noacutes e relacionamentos Os dados
satildeo armazenados nos noacutes do grafo e as arestas representam o tipo de associaccedilatildeo
entre eles
Novas arestas podem ser adicionadas (ou as antigas removidas) a qualquer
momento permitindo que relaccedilotildees 1shyN (um para muitos) e NshyN (muitos para muitos)
sejam expressas de forma faacutecil Construccedilotildees como amigos seguidores graus de
separaccedilatildeo listas satildeo muito naturalmente acomodadas em bancos de dados do tipo
grafo
A Figura 3 representa um exemplo de grafo de uma aplicaccedilatildeo que possui
informaccedilotildees 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
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 929
No exemplo da figura temos trecircs pessoas que satildeo noacutes do grafo e estatildeo conectados agrave
cidades que ou jaacute visitaram ou moraram Atraveacutes da representaccedilatildeo do grafo fica faacutecil
perceber que Maria e Joseacute jaacute visitaram o Rio de Janeiro
E que Joatildeo jaacute morou em Recife e Salvador Um exemplo de banco de dados baseado
em grafo eacute o Neo4j que eacute openshysource e implementado em Java
Figura 3 Exemplo de modelo baseado em grafo
Eacute importante ressaltar que nenhum dos modelos apresentados deve ser considerado
superior ao outro pois tudo depende da necessidade da aplicaccedilatildeo Eacute importante que
os desenvolvedores conheccedilam os diversos modelos de soluccedilatildeo para que seja
adotado aquele que mais se adequar ao que a aplicaccedilatildeo ou empresa precisa Isto
contribui para a diminuiccedilatildeo do custo de criaccedilatildeo do banco de dados e com o aumento
do desempenho no processamento dos dados
A Tabela 1 apresenta uma comparaccedilatildeo dos modelos apresentados destacando suas
principais vantagens e desvantagens e ainda citando seus principais exemplos e
suas disponibilidades
Tipo Vantagem Desvantagem Exemplos Disponibilidade
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1029
ChaveValor
Simplicidade
e
escalabilidade
Falta recursos
mais
avanccedilados de
consulta
Amazon
DynamoDB
O niacutevel gratuito da AWS inclui 100
MB de armazenamento 5 unidades
de capacidade de gravaccedilatildeo e 10
unidades de capacidade de leitura
com o Amazon DynamoDB
Disponiacutevel em
httpawsamazoncomptdynamodb
DocumentoFacilidade de
uso
Natildeo eacute
adequado para
dados
relacionais
Consulta
limitada a
chaves e
iacutendices
MongoDB
CouchDB
Como a maioria das licenccedilas de
software livre permite seja usado
modificado e distribuiacutedo por usuaacuterios
Podeshyse adquirir o MongoDB em
httpwwwmongodborg
e CouchDB
httpcouchdbapacheorg
ColunaEscalabilidade
e flexibilidadeComplexidade
Google Big
Table
Cassandra
BigTable foi desenvolvida no Google
em tem sido usado desde 2005 em
dezenas de serviccedilos do Google Uma
versatildeo de coacutedigo aberto HBase foi
criado pelo Apache
httphbaseapacheorg
Jaacute o Cassandra tambeacutem pode ser
adquirido de forma gratuita
httpcassandraapacheorg
Grafo
Modelo de
dados
poderoso e
raacutepido
Flexibilidade
Neo4j Como os demais acima o Neo4j
tambeacutem estaacute disponiacutevel para
download em httpwwwneo4jorg
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1129
Tabela 1 Anaacutelise comparativa dos modelos de BD NoSQL
Modelo Relacional x NoSQLAo se comparar os modelos em questatildeo uma grande diferenccedila a se notar eacute que as
tecnologias relacionais tecircm esquemas riacutegidos enquanto os modelos NoSQL satildeo
schemashyfree ou seja sem esquema O modelo relacional requer uma definiccedilatildeo
estrita de um esquema antes de armazenar todos os dados em um banco de dados
Alterar o esquema uma vez que os dados jaacute estatildeo inseridos eacute muito complicado e
por isso evitado No entanto isto eacute exatamente o oposto do comportamento
desejado na era ldquoBig Datardquo 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 trecircs criteacuterios satildeo
considerados relevantes para esta escolha escalonamento consistecircncia de dados e
disponibilidade E eacute isto que seraacute abordado a partir de agora
Basicamente pelo fato de terem sido criados para essa finalidade os bancos NoSQL
apresentam vantagens em relaccedilatildeo 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 cenaacuterios em que o escalonamento eacute
necessaacuterio
Eacute possiacutevel tornar um banco de dados relacional mais escalaacutevel atraveacutes da teacutecnica de
escalonamento vertical onde eacute feita uma atualizaccedilatildeo (upgrade) no servidor de
bancos de dados
Poreacutem este escalonamento fica limitado agrave capacidade de uma uacutenica maacutequina Jaacute o
escalonamento horizontal eacute feito com o aumento da quantidade de servidores que
iratildeo disponibilizar os dados paralelamente (Figura 4) facilitando o acesso aos dados
e garantindo que a queda de um servidor natildeo seja um problema de disponibilidade
dos dados
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1229
Figura 4 O uso do escalonamento horizontal
Outra caracteriacutestica a favor do NoSQL eacute o uso do sharding que consiste em trabalhar
com o escalonamento horizontal particionando e paralelizando seus dados em vaacuterios
servidores (Figura 5) Essa teacutecnica eacute complexa para se usar em SGBDs relacionais
devido a toda a sua estrutura loacutegica e devido ao uso da desnormalizaccedilatildeo dos dados
o contraacuterio usado no modelo relacional
O sharding traz benefiacutecios pois conjuntos de dados menores satildeo mais faacuteceis de
serem acessados atualizados e gerenciados O maior benefiacutecio em comparaccedilatildeo ao
modelo relacional eacute a otimizaccedilatildeo do grau de disponibilidade do sistema pois como
jaacute dito anteriormente a queda de uma maacutequina natildeo causaria a interrupccedilatildeo de todo o
sistema
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1329
Figura 5 Teacutecnica de sharding
O controle de concorrecircncia tambeacutem funciona de maneira distinta nos modelos em
questatildeo O modelo relacional utiliza bloqueios (locks) como garantia de que dois
usuaacuterios natildeo atualizem o mesmo dado ao mesmo tempo Jaacute no modelo NoSQL satildeo
usadas outras estrateacutegias para permitir um maior grau de concorrecircncia
Alguns bancos NoSQL usam o MVCC (Multiversion Concurrency Control) ou Controle
de Concorrecircncia Multishyversotildees Nesta teacutecnica o acesso aos dados pode ser realizado
em paralelo
Cada usuaacuterio que se conecta ao banco de dados visualiza uma coacutepia temporaacuteria do
banco de dados naquele instante Qualquer atualizaccedilatildeo que esteja sendo feita em
determinado momento por um usuaacuterio natildeo seraacute vista pelos demais que estatildeo
operando simultaneamente no banco de dados ateacute que a atualizaccedilatildeo tenha sido
concluiacuteda
Quando se opta por usar um modelo NoSQL haacute ganhos de performance flexibilidade
e disponibilidade mas haacute uma perda de consistecircncia Haacute um teorema na ciecircncia da
computaccedilatildeo criado Eric Brewer chamado Teorema CAP (Consistency Availability e
Partition Tolerance) que diz ser impossiacutevel para um sistema distribuiacutedo garantir
consistecircncia disponibilidade e toleracircncia ao particionamento De forma simultacircnea
soacute eacute possiacutevel conseguir duas destas trecircs caracteriacutesticas Vejamos exemplos de
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1429
SGBDs na Figura 6 segundo o Teorema CAP
Figura 6 Distribuiccedilatildeo relativa de alguns bancos de dados quanto ao Teorema CAP
As soluccedilotildees NoSQL seguem um paradigma denominado BASE (Basically Available
Soft state Eventual consistency) Este tem como caracteriacutesticas estar basicamente
disponiacutevel o tempo todo estar em estado leve ou seja natildeo sendo consistente o
tempo todo e possuir uma consistecircncia eventual o sistema se torna consistente no
momento apropriado
O modelo BASE eacute um contraste ao paradigma ACID (Atomicity Consistency
Isolation Durability) comumente associado aos bancos de dados de modelo
relacional Ao contraacuterio do modelo ACID que promove uma seguranccedila dos dados
forccedilando a consistecircncia ao final de cada operaccedilatildeo o modelo BASE permite que o
banco de dados esteja em um estado eventualmente consistente
A disponibilidade do modelo BASE estaacute associada justamente ao fato de que a falha
de uma maacutequina do sistema natildeo interrompe o sistema como um todo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1529
Para se analisar de forma mais raacutepida e comparativa a Tabela 2 apresenta as
principais caracteriacutesticas de ambos os modelos discutidos aqui
Modelo Relacional NoSQL
Escalonamento Possui sua natureza
estruturada e por conta disto
o escalonamento de bancos
tende a ser uma tarefa
complexa
Eacute livre de esquemas por isso
o NoSQL possui uma maior
flexibilidade e alta
escalabilidade considerada
uma das principais vantagens
desse modelo
Consistecircncia Possui uma estrutura mais
riacutegida e garante em suas
transaccedilotildees a existecircncia dessa
propriedade As diversas
regras deste modelo
possibilitam uma maior
rigidez quanto a garantia de
consistecircncia dos dados
sendo este o ponto mais
forte desse modelo
A consistecircncia nesse modelo
possui um caraacuteter eventual
o que natildeo garante que uma
determinada atualizaccedilatildeo em
um dado momento seja
percebida por todos os noacutes
Disponibilidade Haacute uma dificuldade de se
trabalhar de forma eficiente
com a distribuiccedilatildeo de dados
por causa de sua natureza
estruturada situaccedilotildees em
que exigem uma maior
demanda de um sistema que
utilizem esse modelo podem
natildeo ser bem suportadas por
ele
Considerada outra das
grandes vantagens do
modelo essa propriedade
junto com o alto grau de
distribuiccedilatildeo desse modelo
possibilita que o sistema
fique um menor periacuteodo de
tempo natildeoshydisponiacutevel assim
como tambeacutem permite que a
solicitaccedilatildeo aos dados por um
nuacutemero crescente de clientes
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1629
seja atendida
Toleracircncia a
Particionamento
Por natildeo terem sido
construiacutedo com a finalidade
de trabalhar com
particionamento de dados
este modelo natildeo possui um
grau muito alto de toleracircncia
ao particionamento cuja
razatildeo principal seria a
dificuldade de junccedilotildees entre
as tabelas
Trabalha de forma faacutecil e
eficiente com a distribuiccedilatildeo
de dados Este modelo eacute
capaz de suportar grandes
demandas de dados assim
como possui alta toleracircncia
ao particionamento dos
mesmos
Tabela 2 Anaacutelise 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 verificaccedilatildeo contiacutenua
da consistecircncia de cada transaccedilatildeo adiciona custos consideraacuteveis para um sistema
que tem milhares de transaccedilotildees ocorrendo
A consistecircncia eventual promovida pelo modelo BASE daacute agraves organizaccedilotildees a
capacidade de interagir com os clientes de forma contiacutenua com a necessaacuteria
disponibilidade e toleracircncia a particcedilatildeo mantendo baixos custos e o sistema rodando
sem interrupccedilotildees Sem duacutevida seria excelente ter consistecircncia completa o tempo
todo mas eacute preciso haver compensaccedilotildees e a consistecircncia eventual permite o
desenvolvimento eficaz de sistemas que podem lidar com o aumento exponencial de
dados devido agraves redes sociais computaccedilatildeo em nuvem e outros projetos de Big Data
Estudo de Caso shy MongoDBPara fins comparativos seratildeo analisadas nesta seccedilatildeo algumas diferenccedilas entre um
banco NoSQL o MongoDB e os bancos relacionais baseados em SQL O MongoDB eacute
um banco de dados NoSQL criado em 2009 pela empresa 10gen orientado a
documentos altamente escalaacutevel de alta performance e de coacutedigo aberto O
cofundador e diretor de tecnologia da 10gen define o MongoDB da seguinte forma ldquoO
MongoDB natildeo foi concebido em um laboratoacuterio
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1729
Noacutes construiacutemos o MongoDB com base em nossas experiecircncias na construccedilatildeo de
sistemas robustos de grande escala e alta disponibilidade Natildeo comeccedilamos do zero
noacutes tentamos descobrir o que estava problemaacutetico e solucionamos isso
Assim o que eu penso sobre MongoDB eacute que se vocecirc pegar o MySQL e alterar o
modelo de dados do relacional para orientado a documento vocecirc ganha uma grande
quantidade de recursos documentos embarcados para melhorar velocidade
facilidade de gerenciamento desenvolvimento aacutegil com bancos de dados sem
ldquoschemardquo escalabilidade horizontal mais faacutecil pois ldquojoinsrdquo natildeo satildeo tatildeo importantes
Haacute muitas coisas que funcionam muito bem nos bancos de dados relacionais iacutendices
consultas dinacircmicas e atualizaccedilotildees e noacutes natildeo mudamos muito neste ponto Por
exemplo a maneira de projetar seus iacutendices no MongoDB deve ser exatamente do
jeito que vocecirc faz isso no MySQL ou Oracle vocecirc soacute ganha a opccedilatildeo de indexar um
campo embarcadordquo
Como dito na seccedilatildeo de modelos de bancos de dados NoSQL um banco orientado a
documentos natildeo possui esquemas riacutegidos e estruturados sendo possiacutevel que ocorra
uma atualizaccedilatildeo na estrutura do documento Portanto inserir novos campos no
documento natildeo 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 coleccedilatildeo
iacutendice iacutendice
linha documento BSON
coluna campo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1829
joins documentos incorporados e vinculaccedilatildeo
primary key
(Especifica qualquer combinaccedilatildeo de colunas
ou coluna uacutenica como chave primaacuteria)
primary key
(No MongoDB a chave primaacuteria eacute definida
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 dinacircmicos ou seja sem a
necessidade de que cada registro tenha a mesma estrutura Estas estruturas satildeo
chamadas de coleccedilotildees (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 sobrenomeSilva idade22 bairroPituba
Outro documento para representar um aluno na mesma coleccedilatildeo
aluno2=nomeLiardquo sobrenomeSaacute cursoDireito materias[Civil Penal]
Podeshyse ter registros diferentes um do outro dentro de uma mesma coleccedilatildeo Parece
estranho este tipo de abordagem mas no modelo relacional usamos isto o tempo
inteiro e de maneira ineficiente com a formaccedilatildeo de tabelas esparsas
Estas satildeo tabelas incompletas onde algumas colunas satildeo sempre preenchidas e
outras nem sempre satildeo usadas Para ilustrar isto observe a Tabela 4 que apresenta
registros da construccedilatildeo civil
Coacutedigo Produto Altura Potecircncia Peso Diacircmetro
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1929
1 Britadeira 300cv 100kg
2 Cimento
3 Empilhadeira 15cv 300kg
4 Escada 3m
5 Tubulaccedilatildeo 20cm
Tabela 4 Cadastro de produtos da construccedilatildeo civil em banco de dados modelo
relacional
Neste exemplo haacute uma desvantagem no modelo relacional Haacute colunas cujo valor eacute
preenchido apenas uma vez como pode ser visto no exemplo das colunas Altura e
Diacircmetro Na construccedilatildeo das tabelas ao incluir colunas que satildeo pouco utilizadas
jogashyse fora espaccedilo de armazenamento e reduzshyse o desempenho do sistema como
um todo E ainda tratamos objetos diferentes como se fossem iguais o que nem
sempre eacute uma boa praacutetica Abaixo o exemplo de como ficaria este cadastro de
produtos no modelo documental
codigo1 produtoBritadeira potencia300cv peso100kg
codigo2 produtoCimento
codigo3 produtoEmpilhadeira potencia15cv peso300kg
codigo4 produtoEscada altura3m
codigo5 produtoTubulaccedilatildeo diametro20cm
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
Seratildeo apresentados agora alguns comandos comuns usados no MongoDB Voltando
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2029
ao primeiro exemplo de documento criado para alunos observe como ficaria o
comando para salvar os alunos em uma coleccedilatildeo
dbunifacssave(aluno1)
dbunifacssave(aluno2)
O comando acima salva os documentos aluno1 e aluno2 na coleccedilatildeo ldquounifacsrdquo Eacute
possiacutevel acessar os dados de uma coleccedilatildeo atraveacutes do comando find() basicamente
ele vai percorrer todos os registros da coleccedilatildeo e retornar os documentos listados No
exemplo dado o comando seria dbunifacsfind() E para apagar tudo que existe na
coleccedilatildeo dbunifacsremove()
Natildeo eacute necessaacuterio que se crie uma coleccedilatildeo ou mesmo que se configure uma estrutura
isso eacute feito automaticamente quando o primeiro registro eacute incluiacutedo No entanto eacute
possiacutevel usar o comando de criar uma coleccedilatildeo e isto pode ser utilizado para preacuteshy
atribuir espaccedilo para uma coleccedilatildeo Uma coleccedilatildeo de tamanho fixo usa o comando
ldquocappedrdquo e vem a substituir automaticamente as entradas mais antigas quando
atinge seu tamanho maacuteximo
Todas as coleccedilotildees limitadas e fixas devem especificar um tamanho maacuteximo e
tambeacutem podem especificar um nuacutemero maacuteximo de documentos O MongoDB remove
os documentos antigos se uma coleccedilatildeo atinge o limite de tamanho maacuteximo antes
que ele atinja a contagem maacutexima de documentos Considere o seguinte exemplo
dbcreateCollection (unifacs capped true size 5242880 max 5000)
Este comando cria uma coleccedilatildeo nomeada de ldquounifacsrdquo com uma dimensatildeo maacutexima
de 5 megabytes e um maacuteximo de 5000 documentos
Para visualizar todas as coleccedilotildees de um banco de dados MongoDB utilizashyse o
seguinte comando
dbgetCollectionNames()
Enfim haacute muitas diferenccedilas entre os comandos usados no MongoDB e no MySQL As
quatro operaccedilotildees baacutesicas usadas para criaccedilatildeo consulta atualizaccedilatildeo e destruiccedilatildeo de
dados conhecidas como CRUD (Create Read Update e Delete) apresentam
comandos bem distintos nos dois tipos de bancos em questatildeo A Tabela 5 compara
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2129
alguns comandos de CRUD em ambos os bancos
MySQL MongoDB
CREATE TABLE unifacs (
id MEDIUMINT NOT NULL
AUTO_INCREMENT
matricula Number
nome Varchar(30)
idade Number
PRIMARY KEY (id)
)
A coleccedilatildeo eacute criada implicitamente na primeira
inserccedilatildeo de dados O _id chave primaacuteria eacute
adicionada automaticamente se o campo _id natildeo
eacute especificado
dbunifacsinsert (
matricula 04217253
nome Paulo
idade 22
)
ALTER TABLE unifacs
ADD join_date DATETIME
Coleccedilotildees natildeo descrevem ou forccedilam a estrutura
dos seus documentos No entanto no niacutevel do
documento operaccedilotildees de update () podem
adicionar campos para documentos existentes
usando o operador $set e remover usando
$unset
dbunifacsupdate (
$set join_date new Date ()
multi true
)
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2229
ALTER TABLE unifacs
DROP COLUMN join_date
dbunifacsupdate(
$unset join_date
multi true
)
INSERT INTO unifacs (matricula nome
idade)
VALUES (032104211 ldquoJoanardquo 21)
dbunifacsinsert(
matricula 032104211 nome ldquoJoanardquo idade
21
)
SELECT FROM unifacs dbunifacsfind()
SELECT FROM unifacs WHERE idade =
21dbunifacsfind( idade 21 )
SELECT FROM unifacs WHERE nome =
ldquoJoanardquo
AND idade = 21
dbunifacsfind( nome ldquoJoanardquo idade 21 )
SELECT FROM unifacs WHERE idade gt
20dbunifacsfind( age $gt 20 )
SELECT COUNT() FROM unifacs
dbuserscount()
ou
dbunifacsfind()count()
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2329
UPDATE unifacs SET status = ldquoAprovadordquo
WHERE nota gt 7
dbunifacsupdate( nota $gt 7
$set status ldquoAprovadordquo multi true )
UPDATE unifacs SET nota = nota + 1
WHERE status = Aprovado
dbunifacsupdate( status Aprovado
$inc nota 1 multi true )
DELETE FROM unifacs WHERE status =
Reprovadodbunifacsremove( status Reprovado )
Tabela 5 Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
Eacute importante saber que cada documento de uma coleccedilatildeo no MongoDB tem um
tamanho maacuteximo de 16MB o que eacute mais do que suficiente para armazenar dados em
um documento No entanto o MongoDB ainda eacute capaz de armazenar arquivos no
banco de dados em uma coleccedilatildeo especifica que eacute a coleccedilatildeo do tipo GridFS
Ela eacute ideal para trabalhar com arquivos maiores de imagens viacutedeo e aacuteudio O GridFS
divide o arquivo em partes ou pedaccedilos e salva cada pedaccedilo em um documento
separado Quando vocecirc consulta um arquivo no GridFS eacute preciso remontar os
pedaccedilos conforme a necessidade
O MongoDB atinge o objetivo de ser amigaacutevel para o desenvolvedor Possui uma
documentaccedilatildeo bem escrita para a maioria dos principais idiomas Sua consulta
baseada em JavaScript eacute faacutecil para os desenvolvedores da Web e ele tambeacutem eacute faacutecil
de instalar Por estas razotildees o MongoDB eacute uma oacutetima opccedilatildeo de tecnologia para uso
em uma aplicaccedilatildeo
Um exemplo do sucesso deste banco eacute o depoimento do especialista em banco de
dados da Globocom Franklin Amorim Em um evento sobre o MongoDB em 2011 na
cidade de Satildeo Paulo Franklin apresentou o case de sucesso da adoccedilatildeo do MongoDB
para uma nova funccedilatildeo do ldquofantasy gamerdquo CartolaFC
O jogo eacute maior aplicaccedilatildeo dinacircmica do portal Globocom com mais de 2 milhotildees de
usuaacuterios cadastrados e quase 90 milhotildees de pageviews somente em um mecircs
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 929
No exemplo da figura temos trecircs pessoas que satildeo noacutes do grafo e estatildeo conectados agrave
cidades que ou jaacute visitaram ou moraram Atraveacutes da representaccedilatildeo do grafo fica faacutecil
perceber que Maria e Joseacute jaacute visitaram o Rio de Janeiro
E que Joatildeo jaacute morou em Recife e Salvador Um exemplo de banco de dados baseado
em grafo eacute o Neo4j que eacute openshysource e implementado em Java
Figura 3 Exemplo de modelo baseado em grafo
Eacute importante ressaltar que nenhum dos modelos apresentados deve ser considerado
superior ao outro pois tudo depende da necessidade da aplicaccedilatildeo Eacute importante que
os desenvolvedores conheccedilam os diversos modelos de soluccedilatildeo para que seja
adotado aquele que mais se adequar ao que a aplicaccedilatildeo ou empresa precisa Isto
contribui para a diminuiccedilatildeo do custo de criaccedilatildeo do banco de dados e com o aumento
do desempenho no processamento dos dados
A Tabela 1 apresenta uma comparaccedilatildeo dos modelos apresentados destacando suas
principais vantagens e desvantagens e ainda citando seus principais exemplos e
suas disponibilidades
Tipo Vantagem Desvantagem Exemplos Disponibilidade
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1029
ChaveValor
Simplicidade
e
escalabilidade
Falta recursos
mais
avanccedilados de
consulta
Amazon
DynamoDB
O niacutevel gratuito da AWS inclui 100
MB de armazenamento 5 unidades
de capacidade de gravaccedilatildeo e 10
unidades de capacidade de leitura
com o Amazon DynamoDB
Disponiacutevel em
httpawsamazoncomptdynamodb
DocumentoFacilidade de
uso
Natildeo eacute
adequado para
dados
relacionais
Consulta
limitada a
chaves e
iacutendices
MongoDB
CouchDB
Como a maioria das licenccedilas de
software livre permite seja usado
modificado e distribuiacutedo por usuaacuterios
Podeshyse adquirir o MongoDB em
httpwwwmongodborg
e CouchDB
httpcouchdbapacheorg
ColunaEscalabilidade
e flexibilidadeComplexidade
Google Big
Table
Cassandra
BigTable foi desenvolvida no Google
em tem sido usado desde 2005 em
dezenas de serviccedilos do Google Uma
versatildeo de coacutedigo aberto HBase foi
criado pelo Apache
httphbaseapacheorg
Jaacute o Cassandra tambeacutem pode ser
adquirido de forma gratuita
httpcassandraapacheorg
Grafo
Modelo de
dados
poderoso e
raacutepido
Flexibilidade
Neo4j Como os demais acima o Neo4j
tambeacutem estaacute disponiacutevel para
download em httpwwwneo4jorg
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1129
Tabela 1 Anaacutelise comparativa dos modelos de BD NoSQL
Modelo Relacional x NoSQLAo se comparar os modelos em questatildeo uma grande diferenccedila a se notar eacute que as
tecnologias relacionais tecircm esquemas riacutegidos enquanto os modelos NoSQL satildeo
schemashyfree ou seja sem esquema O modelo relacional requer uma definiccedilatildeo
estrita de um esquema antes de armazenar todos os dados em um banco de dados
Alterar o esquema uma vez que os dados jaacute estatildeo inseridos eacute muito complicado e
por isso evitado No entanto isto eacute exatamente o oposto do comportamento
desejado na era ldquoBig Datardquo 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 trecircs criteacuterios satildeo
considerados relevantes para esta escolha escalonamento consistecircncia de dados e
disponibilidade E eacute isto que seraacute abordado a partir de agora
Basicamente pelo fato de terem sido criados para essa finalidade os bancos NoSQL
apresentam vantagens em relaccedilatildeo 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 cenaacuterios em que o escalonamento eacute
necessaacuterio
Eacute possiacutevel tornar um banco de dados relacional mais escalaacutevel atraveacutes da teacutecnica de
escalonamento vertical onde eacute feita uma atualizaccedilatildeo (upgrade) no servidor de
bancos de dados
Poreacutem este escalonamento fica limitado agrave capacidade de uma uacutenica maacutequina Jaacute o
escalonamento horizontal eacute feito com o aumento da quantidade de servidores que
iratildeo disponibilizar os dados paralelamente (Figura 4) facilitando o acesso aos dados
e garantindo que a queda de um servidor natildeo seja um problema de disponibilidade
dos dados
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1229
Figura 4 O uso do escalonamento horizontal
Outra caracteriacutestica a favor do NoSQL eacute o uso do sharding que consiste em trabalhar
com o escalonamento horizontal particionando e paralelizando seus dados em vaacuterios
servidores (Figura 5) Essa teacutecnica eacute complexa para se usar em SGBDs relacionais
devido a toda a sua estrutura loacutegica e devido ao uso da desnormalizaccedilatildeo dos dados
o contraacuterio usado no modelo relacional
O sharding traz benefiacutecios pois conjuntos de dados menores satildeo mais faacuteceis de
serem acessados atualizados e gerenciados O maior benefiacutecio em comparaccedilatildeo ao
modelo relacional eacute a otimizaccedilatildeo do grau de disponibilidade do sistema pois como
jaacute dito anteriormente a queda de uma maacutequina natildeo causaria a interrupccedilatildeo de todo o
sistema
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1329
Figura 5 Teacutecnica de sharding
O controle de concorrecircncia tambeacutem funciona de maneira distinta nos modelos em
questatildeo O modelo relacional utiliza bloqueios (locks) como garantia de que dois
usuaacuterios natildeo atualizem o mesmo dado ao mesmo tempo Jaacute no modelo NoSQL satildeo
usadas outras estrateacutegias para permitir um maior grau de concorrecircncia
Alguns bancos NoSQL usam o MVCC (Multiversion Concurrency Control) ou Controle
de Concorrecircncia Multishyversotildees Nesta teacutecnica o acesso aos dados pode ser realizado
em paralelo
Cada usuaacuterio que se conecta ao banco de dados visualiza uma coacutepia temporaacuteria do
banco de dados naquele instante Qualquer atualizaccedilatildeo que esteja sendo feita em
determinado momento por um usuaacuterio natildeo seraacute vista pelos demais que estatildeo
operando simultaneamente no banco de dados ateacute que a atualizaccedilatildeo tenha sido
concluiacuteda
Quando se opta por usar um modelo NoSQL haacute ganhos de performance flexibilidade
e disponibilidade mas haacute uma perda de consistecircncia Haacute um teorema na ciecircncia da
computaccedilatildeo criado Eric Brewer chamado Teorema CAP (Consistency Availability e
Partition Tolerance) que diz ser impossiacutevel para um sistema distribuiacutedo garantir
consistecircncia disponibilidade e toleracircncia ao particionamento De forma simultacircnea
soacute eacute possiacutevel conseguir duas destas trecircs caracteriacutesticas Vejamos exemplos de
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1429
SGBDs na Figura 6 segundo o Teorema CAP
Figura 6 Distribuiccedilatildeo relativa de alguns bancos de dados quanto ao Teorema CAP
As soluccedilotildees NoSQL seguem um paradigma denominado BASE (Basically Available
Soft state Eventual consistency) Este tem como caracteriacutesticas estar basicamente
disponiacutevel o tempo todo estar em estado leve ou seja natildeo sendo consistente o
tempo todo e possuir uma consistecircncia eventual o sistema se torna consistente no
momento apropriado
O modelo BASE eacute um contraste ao paradigma ACID (Atomicity Consistency
Isolation Durability) comumente associado aos bancos de dados de modelo
relacional Ao contraacuterio do modelo ACID que promove uma seguranccedila dos dados
forccedilando a consistecircncia ao final de cada operaccedilatildeo o modelo BASE permite que o
banco de dados esteja em um estado eventualmente consistente
A disponibilidade do modelo BASE estaacute associada justamente ao fato de que a falha
de uma maacutequina do sistema natildeo interrompe o sistema como um todo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1529
Para se analisar de forma mais raacutepida e comparativa a Tabela 2 apresenta as
principais caracteriacutesticas de ambos os modelos discutidos aqui
Modelo Relacional NoSQL
Escalonamento Possui sua natureza
estruturada e por conta disto
o escalonamento de bancos
tende a ser uma tarefa
complexa
Eacute livre de esquemas por isso
o NoSQL possui uma maior
flexibilidade e alta
escalabilidade considerada
uma das principais vantagens
desse modelo
Consistecircncia Possui uma estrutura mais
riacutegida e garante em suas
transaccedilotildees a existecircncia dessa
propriedade As diversas
regras deste modelo
possibilitam uma maior
rigidez quanto a garantia de
consistecircncia dos dados
sendo este o ponto mais
forte desse modelo
A consistecircncia nesse modelo
possui um caraacuteter eventual
o que natildeo garante que uma
determinada atualizaccedilatildeo em
um dado momento seja
percebida por todos os noacutes
Disponibilidade Haacute uma dificuldade de se
trabalhar de forma eficiente
com a distribuiccedilatildeo de dados
por causa de sua natureza
estruturada situaccedilotildees em
que exigem uma maior
demanda de um sistema que
utilizem esse modelo podem
natildeo ser bem suportadas por
ele
Considerada outra das
grandes vantagens do
modelo essa propriedade
junto com o alto grau de
distribuiccedilatildeo desse modelo
possibilita que o sistema
fique um menor periacuteodo de
tempo natildeoshydisponiacutevel assim
como tambeacutem permite que a
solicitaccedilatildeo aos dados por um
nuacutemero crescente de clientes
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1629
seja atendida
Toleracircncia a
Particionamento
Por natildeo terem sido
construiacutedo com a finalidade
de trabalhar com
particionamento de dados
este modelo natildeo possui um
grau muito alto de toleracircncia
ao particionamento cuja
razatildeo principal seria a
dificuldade de junccedilotildees entre
as tabelas
Trabalha de forma faacutecil e
eficiente com a distribuiccedilatildeo
de dados Este modelo eacute
capaz de suportar grandes
demandas de dados assim
como possui alta toleracircncia
ao particionamento dos
mesmos
Tabela 2 Anaacutelise 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 verificaccedilatildeo contiacutenua
da consistecircncia de cada transaccedilatildeo adiciona custos consideraacuteveis para um sistema
que tem milhares de transaccedilotildees ocorrendo
A consistecircncia eventual promovida pelo modelo BASE daacute agraves organizaccedilotildees a
capacidade de interagir com os clientes de forma contiacutenua com a necessaacuteria
disponibilidade e toleracircncia a particcedilatildeo mantendo baixos custos e o sistema rodando
sem interrupccedilotildees Sem duacutevida seria excelente ter consistecircncia completa o tempo
todo mas eacute preciso haver compensaccedilotildees e a consistecircncia eventual permite o
desenvolvimento eficaz de sistemas que podem lidar com o aumento exponencial de
dados devido agraves redes sociais computaccedilatildeo em nuvem e outros projetos de Big Data
Estudo de Caso shy MongoDBPara fins comparativos seratildeo analisadas nesta seccedilatildeo algumas diferenccedilas entre um
banco NoSQL o MongoDB e os bancos relacionais baseados em SQL O MongoDB eacute
um banco de dados NoSQL criado em 2009 pela empresa 10gen orientado a
documentos altamente escalaacutevel de alta performance e de coacutedigo aberto O
cofundador e diretor de tecnologia da 10gen define o MongoDB da seguinte forma ldquoO
MongoDB natildeo foi concebido em um laboratoacuterio
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1729
Noacutes construiacutemos o MongoDB com base em nossas experiecircncias na construccedilatildeo de
sistemas robustos de grande escala e alta disponibilidade Natildeo comeccedilamos do zero
noacutes tentamos descobrir o que estava problemaacutetico e solucionamos isso
Assim o que eu penso sobre MongoDB eacute que se vocecirc pegar o MySQL e alterar o
modelo de dados do relacional para orientado a documento vocecirc ganha uma grande
quantidade de recursos documentos embarcados para melhorar velocidade
facilidade de gerenciamento desenvolvimento aacutegil com bancos de dados sem
ldquoschemardquo escalabilidade horizontal mais faacutecil pois ldquojoinsrdquo natildeo satildeo tatildeo importantes
Haacute muitas coisas que funcionam muito bem nos bancos de dados relacionais iacutendices
consultas dinacircmicas e atualizaccedilotildees e noacutes natildeo mudamos muito neste ponto Por
exemplo a maneira de projetar seus iacutendices no MongoDB deve ser exatamente do
jeito que vocecirc faz isso no MySQL ou Oracle vocecirc soacute ganha a opccedilatildeo de indexar um
campo embarcadordquo
Como dito na seccedilatildeo de modelos de bancos de dados NoSQL um banco orientado a
documentos natildeo possui esquemas riacutegidos e estruturados sendo possiacutevel que ocorra
uma atualizaccedilatildeo na estrutura do documento Portanto inserir novos campos no
documento natildeo 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 coleccedilatildeo
iacutendice iacutendice
linha documento BSON
coluna campo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1829
joins documentos incorporados e vinculaccedilatildeo
primary key
(Especifica qualquer combinaccedilatildeo de colunas
ou coluna uacutenica como chave primaacuteria)
primary key
(No MongoDB a chave primaacuteria eacute definida
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 dinacircmicos ou seja sem a
necessidade de que cada registro tenha a mesma estrutura Estas estruturas satildeo
chamadas de coleccedilotildees (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 sobrenomeSilva idade22 bairroPituba
Outro documento para representar um aluno na mesma coleccedilatildeo
aluno2=nomeLiardquo sobrenomeSaacute cursoDireito materias[Civil Penal]
Podeshyse ter registros diferentes um do outro dentro de uma mesma coleccedilatildeo Parece
estranho este tipo de abordagem mas no modelo relacional usamos isto o tempo
inteiro e de maneira ineficiente com a formaccedilatildeo de tabelas esparsas
Estas satildeo tabelas incompletas onde algumas colunas satildeo sempre preenchidas e
outras nem sempre satildeo usadas Para ilustrar isto observe a Tabela 4 que apresenta
registros da construccedilatildeo civil
Coacutedigo Produto Altura Potecircncia Peso Diacircmetro
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1929
1 Britadeira 300cv 100kg
2 Cimento
3 Empilhadeira 15cv 300kg
4 Escada 3m
5 Tubulaccedilatildeo 20cm
Tabela 4 Cadastro de produtos da construccedilatildeo civil em banco de dados modelo
relacional
Neste exemplo haacute uma desvantagem no modelo relacional Haacute colunas cujo valor eacute
preenchido apenas uma vez como pode ser visto no exemplo das colunas Altura e
Diacircmetro Na construccedilatildeo das tabelas ao incluir colunas que satildeo pouco utilizadas
jogashyse fora espaccedilo de armazenamento e reduzshyse o desempenho do sistema como
um todo E ainda tratamos objetos diferentes como se fossem iguais o que nem
sempre eacute uma boa praacutetica Abaixo o exemplo de como ficaria este cadastro de
produtos no modelo documental
codigo1 produtoBritadeira potencia300cv peso100kg
codigo2 produtoCimento
codigo3 produtoEmpilhadeira potencia15cv peso300kg
codigo4 produtoEscada altura3m
codigo5 produtoTubulaccedilatildeo diametro20cm
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
Seratildeo apresentados agora alguns comandos comuns usados no MongoDB Voltando
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2029
ao primeiro exemplo de documento criado para alunos observe como ficaria o
comando para salvar os alunos em uma coleccedilatildeo
dbunifacssave(aluno1)
dbunifacssave(aluno2)
O comando acima salva os documentos aluno1 e aluno2 na coleccedilatildeo ldquounifacsrdquo Eacute
possiacutevel acessar os dados de uma coleccedilatildeo atraveacutes do comando find() basicamente
ele vai percorrer todos os registros da coleccedilatildeo e retornar os documentos listados No
exemplo dado o comando seria dbunifacsfind() E para apagar tudo que existe na
coleccedilatildeo dbunifacsremove()
Natildeo eacute necessaacuterio que se crie uma coleccedilatildeo ou mesmo que se configure uma estrutura
isso eacute feito automaticamente quando o primeiro registro eacute incluiacutedo No entanto eacute
possiacutevel usar o comando de criar uma coleccedilatildeo e isto pode ser utilizado para preacuteshy
atribuir espaccedilo para uma coleccedilatildeo Uma coleccedilatildeo de tamanho fixo usa o comando
ldquocappedrdquo e vem a substituir automaticamente as entradas mais antigas quando
atinge seu tamanho maacuteximo
Todas as coleccedilotildees limitadas e fixas devem especificar um tamanho maacuteximo e
tambeacutem podem especificar um nuacutemero maacuteximo de documentos O MongoDB remove
os documentos antigos se uma coleccedilatildeo atinge o limite de tamanho maacuteximo antes
que ele atinja a contagem maacutexima de documentos Considere o seguinte exemplo
dbcreateCollection (unifacs capped true size 5242880 max 5000)
Este comando cria uma coleccedilatildeo nomeada de ldquounifacsrdquo com uma dimensatildeo maacutexima
de 5 megabytes e um maacuteximo de 5000 documentos
Para visualizar todas as coleccedilotildees de um banco de dados MongoDB utilizashyse o
seguinte comando
dbgetCollectionNames()
Enfim haacute muitas diferenccedilas entre os comandos usados no MongoDB e no MySQL As
quatro operaccedilotildees baacutesicas usadas para criaccedilatildeo consulta atualizaccedilatildeo e destruiccedilatildeo de
dados conhecidas como CRUD (Create Read Update e Delete) apresentam
comandos bem distintos nos dois tipos de bancos em questatildeo A Tabela 5 compara
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2129
alguns comandos de CRUD em ambos os bancos
MySQL MongoDB
CREATE TABLE unifacs (
id MEDIUMINT NOT NULL
AUTO_INCREMENT
matricula Number
nome Varchar(30)
idade Number
PRIMARY KEY (id)
)
A coleccedilatildeo eacute criada implicitamente na primeira
inserccedilatildeo de dados O _id chave primaacuteria eacute
adicionada automaticamente se o campo _id natildeo
eacute especificado
dbunifacsinsert (
matricula 04217253
nome Paulo
idade 22
)
ALTER TABLE unifacs
ADD join_date DATETIME
Coleccedilotildees natildeo descrevem ou forccedilam a estrutura
dos seus documentos No entanto no niacutevel do
documento operaccedilotildees de update () podem
adicionar campos para documentos existentes
usando o operador $set e remover usando
$unset
dbunifacsupdate (
$set join_date new Date ()
multi true
)
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2229
ALTER TABLE unifacs
DROP COLUMN join_date
dbunifacsupdate(
$unset join_date
multi true
)
INSERT INTO unifacs (matricula nome
idade)
VALUES (032104211 ldquoJoanardquo 21)
dbunifacsinsert(
matricula 032104211 nome ldquoJoanardquo idade
21
)
SELECT FROM unifacs dbunifacsfind()
SELECT FROM unifacs WHERE idade =
21dbunifacsfind( idade 21 )
SELECT FROM unifacs WHERE nome =
ldquoJoanardquo
AND idade = 21
dbunifacsfind( nome ldquoJoanardquo idade 21 )
SELECT FROM unifacs WHERE idade gt
20dbunifacsfind( age $gt 20 )
SELECT COUNT() FROM unifacs
dbuserscount()
ou
dbunifacsfind()count()
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2329
UPDATE unifacs SET status = ldquoAprovadordquo
WHERE nota gt 7
dbunifacsupdate( nota $gt 7
$set status ldquoAprovadordquo multi true )
UPDATE unifacs SET nota = nota + 1
WHERE status = Aprovado
dbunifacsupdate( status Aprovado
$inc nota 1 multi true )
DELETE FROM unifacs WHERE status =
Reprovadodbunifacsremove( status Reprovado )
Tabela 5 Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
Eacute importante saber que cada documento de uma coleccedilatildeo no MongoDB tem um
tamanho maacuteximo de 16MB o que eacute mais do que suficiente para armazenar dados em
um documento No entanto o MongoDB ainda eacute capaz de armazenar arquivos no
banco de dados em uma coleccedilatildeo especifica que eacute a coleccedilatildeo do tipo GridFS
Ela eacute ideal para trabalhar com arquivos maiores de imagens viacutedeo e aacuteudio O GridFS
divide o arquivo em partes ou pedaccedilos e salva cada pedaccedilo em um documento
separado Quando vocecirc consulta um arquivo no GridFS eacute preciso remontar os
pedaccedilos conforme a necessidade
O MongoDB atinge o objetivo de ser amigaacutevel para o desenvolvedor Possui uma
documentaccedilatildeo bem escrita para a maioria dos principais idiomas Sua consulta
baseada em JavaScript eacute faacutecil para os desenvolvedores da Web e ele tambeacutem eacute faacutecil
de instalar Por estas razotildees o MongoDB eacute uma oacutetima opccedilatildeo de tecnologia para uso
em uma aplicaccedilatildeo
Um exemplo do sucesso deste banco eacute o depoimento do especialista em banco de
dados da Globocom Franklin Amorim Em um evento sobre o MongoDB em 2011 na
cidade de Satildeo Paulo Franklin apresentou o case de sucesso da adoccedilatildeo do MongoDB
para uma nova funccedilatildeo do ldquofantasy gamerdquo CartolaFC
O jogo eacute maior aplicaccedilatildeo dinacircmica do portal Globocom com mais de 2 milhotildees de
usuaacuterios cadastrados e quase 90 milhotildees de pageviews somente em um mecircs
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1029
ChaveValor
Simplicidade
e
escalabilidade
Falta recursos
mais
avanccedilados de
consulta
Amazon
DynamoDB
O niacutevel gratuito da AWS inclui 100
MB de armazenamento 5 unidades
de capacidade de gravaccedilatildeo e 10
unidades de capacidade de leitura
com o Amazon DynamoDB
Disponiacutevel em
httpawsamazoncomptdynamodb
DocumentoFacilidade de
uso
Natildeo eacute
adequado para
dados
relacionais
Consulta
limitada a
chaves e
iacutendices
MongoDB
CouchDB
Como a maioria das licenccedilas de
software livre permite seja usado
modificado e distribuiacutedo por usuaacuterios
Podeshyse adquirir o MongoDB em
httpwwwmongodborg
e CouchDB
httpcouchdbapacheorg
ColunaEscalabilidade
e flexibilidadeComplexidade
Google Big
Table
Cassandra
BigTable foi desenvolvida no Google
em tem sido usado desde 2005 em
dezenas de serviccedilos do Google Uma
versatildeo de coacutedigo aberto HBase foi
criado pelo Apache
httphbaseapacheorg
Jaacute o Cassandra tambeacutem pode ser
adquirido de forma gratuita
httpcassandraapacheorg
Grafo
Modelo de
dados
poderoso e
raacutepido
Flexibilidade
Neo4j Como os demais acima o Neo4j
tambeacutem estaacute disponiacutevel para
download em httpwwwneo4jorg
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1129
Tabela 1 Anaacutelise comparativa dos modelos de BD NoSQL
Modelo Relacional x NoSQLAo se comparar os modelos em questatildeo uma grande diferenccedila a se notar eacute que as
tecnologias relacionais tecircm esquemas riacutegidos enquanto os modelos NoSQL satildeo
schemashyfree ou seja sem esquema O modelo relacional requer uma definiccedilatildeo
estrita de um esquema antes de armazenar todos os dados em um banco de dados
Alterar o esquema uma vez que os dados jaacute estatildeo inseridos eacute muito complicado e
por isso evitado No entanto isto eacute exatamente o oposto do comportamento
desejado na era ldquoBig Datardquo 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 trecircs criteacuterios satildeo
considerados relevantes para esta escolha escalonamento consistecircncia de dados e
disponibilidade E eacute isto que seraacute abordado a partir de agora
Basicamente pelo fato de terem sido criados para essa finalidade os bancos NoSQL
apresentam vantagens em relaccedilatildeo 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 cenaacuterios em que o escalonamento eacute
necessaacuterio
Eacute possiacutevel tornar um banco de dados relacional mais escalaacutevel atraveacutes da teacutecnica de
escalonamento vertical onde eacute feita uma atualizaccedilatildeo (upgrade) no servidor de
bancos de dados
Poreacutem este escalonamento fica limitado agrave capacidade de uma uacutenica maacutequina Jaacute o
escalonamento horizontal eacute feito com o aumento da quantidade de servidores que
iratildeo disponibilizar os dados paralelamente (Figura 4) facilitando o acesso aos dados
e garantindo que a queda de um servidor natildeo seja um problema de disponibilidade
dos dados
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1229
Figura 4 O uso do escalonamento horizontal
Outra caracteriacutestica a favor do NoSQL eacute o uso do sharding que consiste em trabalhar
com o escalonamento horizontal particionando e paralelizando seus dados em vaacuterios
servidores (Figura 5) Essa teacutecnica eacute complexa para se usar em SGBDs relacionais
devido a toda a sua estrutura loacutegica e devido ao uso da desnormalizaccedilatildeo dos dados
o contraacuterio usado no modelo relacional
O sharding traz benefiacutecios pois conjuntos de dados menores satildeo mais faacuteceis de
serem acessados atualizados e gerenciados O maior benefiacutecio em comparaccedilatildeo ao
modelo relacional eacute a otimizaccedilatildeo do grau de disponibilidade do sistema pois como
jaacute dito anteriormente a queda de uma maacutequina natildeo causaria a interrupccedilatildeo de todo o
sistema
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1329
Figura 5 Teacutecnica de sharding
O controle de concorrecircncia tambeacutem funciona de maneira distinta nos modelos em
questatildeo O modelo relacional utiliza bloqueios (locks) como garantia de que dois
usuaacuterios natildeo atualizem o mesmo dado ao mesmo tempo Jaacute no modelo NoSQL satildeo
usadas outras estrateacutegias para permitir um maior grau de concorrecircncia
Alguns bancos NoSQL usam o MVCC (Multiversion Concurrency Control) ou Controle
de Concorrecircncia Multishyversotildees Nesta teacutecnica o acesso aos dados pode ser realizado
em paralelo
Cada usuaacuterio que se conecta ao banco de dados visualiza uma coacutepia temporaacuteria do
banco de dados naquele instante Qualquer atualizaccedilatildeo que esteja sendo feita em
determinado momento por um usuaacuterio natildeo seraacute vista pelos demais que estatildeo
operando simultaneamente no banco de dados ateacute que a atualizaccedilatildeo tenha sido
concluiacuteda
Quando se opta por usar um modelo NoSQL haacute ganhos de performance flexibilidade
e disponibilidade mas haacute uma perda de consistecircncia Haacute um teorema na ciecircncia da
computaccedilatildeo criado Eric Brewer chamado Teorema CAP (Consistency Availability e
Partition Tolerance) que diz ser impossiacutevel para um sistema distribuiacutedo garantir
consistecircncia disponibilidade e toleracircncia ao particionamento De forma simultacircnea
soacute eacute possiacutevel conseguir duas destas trecircs caracteriacutesticas Vejamos exemplos de
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1429
SGBDs na Figura 6 segundo o Teorema CAP
Figura 6 Distribuiccedilatildeo relativa de alguns bancos de dados quanto ao Teorema CAP
As soluccedilotildees NoSQL seguem um paradigma denominado BASE (Basically Available
Soft state Eventual consistency) Este tem como caracteriacutesticas estar basicamente
disponiacutevel o tempo todo estar em estado leve ou seja natildeo sendo consistente o
tempo todo e possuir uma consistecircncia eventual o sistema se torna consistente no
momento apropriado
O modelo BASE eacute um contraste ao paradigma ACID (Atomicity Consistency
Isolation Durability) comumente associado aos bancos de dados de modelo
relacional Ao contraacuterio do modelo ACID que promove uma seguranccedila dos dados
forccedilando a consistecircncia ao final de cada operaccedilatildeo o modelo BASE permite que o
banco de dados esteja em um estado eventualmente consistente
A disponibilidade do modelo BASE estaacute associada justamente ao fato de que a falha
de uma maacutequina do sistema natildeo interrompe o sistema como um todo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1529
Para se analisar de forma mais raacutepida e comparativa a Tabela 2 apresenta as
principais caracteriacutesticas de ambos os modelos discutidos aqui
Modelo Relacional NoSQL
Escalonamento Possui sua natureza
estruturada e por conta disto
o escalonamento de bancos
tende a ser uma tarefa
complexa
Eacute livre de esquemas por isso
o NoSQL possui uma maior
flexibilidade e alta
escalabilidade considerada
uma das principais vantagens
desse modelo
Consistecircncia Possui uma estrutura mais
riacutegida e garante em suas
transaccedilotildees a existecircncia dessa
propriedade As diversas
regras deste modelo
possibilitam uma maior
rigidez quanto a garantia de
consistecircncia dos dados
sendo este o ponto mais
forte desse modelo
A consistecircncia nesse modelo
possui um caraacuteter eventual
o que natildeo garante que uma
determinada atualizaccedilatildeo em
um dado momento seja
percebida por todos os noacutes
Disponibilidade Haacute uma dificuldade de se
trabalhar de forma eficiente
com a distribuiccedilatildeo de dados
por causa de sua natureza
estruturada situaccedilotildees em
que exigem uma maior
demanda de um sistema que
utilizem esse modelo podem
natildeo ser bem suportadas por
ele
Considerada outra das
grandes vantagens do
modelo essa propriedade
junto com o alto grau de
distribuiccedilatildeo desse modelo
possibilita que o sistema
fique um menor periacuteodo de
tempo natildeoshydisponiacutevel assim
como tambeacutem permite que a
solicitaccedilatildeo aos dados por um
nuacutemero crescente de clientes
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1629
seja atendida
Toleracircncia a
Particionamento
Por natildeo terem sido
construiacutedo com a finalidade
de trabalhar com
particionamento de dados
este modelo natildeo possui um
grau muito alto de toleracircncia
ao particionamento cuja
razatildeo principal seria a
dificuldade de junccedilotildees entre
as tabelas
Trabalha de forma faacutecil e
eficiente com a distribuiccedilatildeo
de dados Este modelo eacute
capaz de suportar grandes
demandas de dados assim
como possui alta toleracircncia
ao particionamento dos
mesmos
Tabela 2 Anaacutelise 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 verificaccedilatildeo contiacutenua
da consistecircncia de cada transaccedilatildeo adiciona custos consideraacuteveis para um sistema
que tem milhares de transaccedilotildees ocorrendo
A consistecircncia eventual promovida pelo modelo BASE daacute agraves organizaccedilotildees a
capacidade de interagir com os clientes de forma contiacutenua com a necessaacuteria
disponibilidade e toleracircncia a particcedilatildeo mantendo baixos custos e o sistema rodando
sem interrupccedilotildees Sem duacutevida seria excelente ter consistecircncia completa o tempo
todo mas eacute preciso haver compensaccedilotildees e a consistecircncia eventual permite o
desenvolvimento eficaz de sistemas que podem lidar com o aumento exponencial de
dados devido agraves redes sociais computaccedilatildeo em nuvem e outros projetos de Big Data
Estudo de Caso shy MongoDBPara fins comparativos seratildeo analisadas nesta seccedilatildeo algumas diferenccedilas entre um
banco NoSQL o MongoDB e os bancos relacionais baseados em SQL O MongoDB eacute
um banco de dados NoSQL criado em 2009 pela empresa 10gen orientado a
documentos altamente escalaacutevel de alta performance e de coacutedigo aberto O
cofundador e diretor de tecnologia da 10gen define o MongoDB da seguinte forma ldquoO
MongoDB natildeo foi concebido em um laboratoacuterio
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1729
Noacutes construiacutemos o MongoDB com base em nossas experiecircncias na construccedilatildeo de
sistemas robustos de grande escala e alta disponibilidade Natildeo comeccedilamos do zero
noacutes tentamos descobrir o que estava problemaacutetico e solucionamos isso
Assim o que eu penso sobre MongoDB eacute que se vocecirc pegar o MySQL e alterar o
modelo de dados do relacional para orientado a documento vocecirc ganha uma grande
quantidade de recursos documentos embarcados para melhorar velocidade
facilidade de gerenciamento desenvolvimento aacutegil com bancos de dados sem
ldquoschemardquo escalabilidade horizontal mais faacutecil pois ldquojoinsrdquo natildeo satildeo tatildeo importantes
Haacute muitas coisas que funcionam muito bem nos bancos de dados relacionais iacutendices
consultas dinacircmicas e atualizaccedilotildees e noacutes natildeo mudamos muito neste ponto Por
exemplo a maneira de projetar seus iacutendices no MongoDB deve ser exatamente do
jeito que vocecirc faz isso no MySQL ou Oracle vocecirc soacute ganha a opccedilatildeo de indexar um
campo embarcadordquo
Como dito na seccedilatildeo de modelos de bancos de dados NoSQL um banco orientado a
documentos natildeo possui esquemas riacutegidos e estruturados sendo possiacutevel que ocorra
uma atualizaccedilatildeo na estrutura do documento Portanto inserir novos campos no
documento natildeo 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 coleccedilatildeo
iacutendice iacutendice
linha documento BSON
coluna campo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1829
joins documentos incorporados e vinculaccedilatildeo
primary key
(Especifica qualquer combinaccedilatildeo de colunas
ou coluna uacutenica como chave primaacuteria)
primary key
(No MongoDB a chave primaacuteria eacute definida
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 dinacircmicos ou seja sem a
necessidade de que cada registro tenha a mesma estrutura Estas estruturas satildeo
chamadas de coleccedilotildees (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 sobrenomeSilva idade22 bairroPituba
Outro documento para representar um aluno na mesma coleccedilatildeo
aluno2=nomeLiardquo sobrenomeSaacute cursoDireito materias[Civil Penal]
Podeshyse ter registros diferentes um do outro dentro de uma mesma coleccedilatildeo Parece
estranho este tipo de abordagem mas no modelo relacional usamos isto o tempo
inteiro e de maneira ineficiente com a formaccedilatildeo de tabelas esparsas
Estas satildeo tabelas incompletas onde algumas colunas satildeo sempre preenchidas e
outras nem sempre satildeo usadas Para ilustrar isto observe a Tabela 4 que apresenta
registros da construccedilatildeo civil
Coacutedigo Produto Altura Potecircncia Peso Diacircmetro
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1929
1 Britadeira 300cv 100kg
2 Cimento
3 Empilhadeira 15cv 300kg
4 Escada 3m
5 Tubulaccedilatildeo 20cm
Tabela 4 Cadastro de produtos da construccedilatildeo civil em banco de dados modelo
relacional
Neste exemplo haacute uma desvantagem no modelo relacional Haacute colunas cujo valor eacute
preenchido apenas uma vez como pode ser visto no exemplo das colunas Altura e
Diacircmetro Na construccedilatildeo das tabelas ao incluir colunas que satildeo pouco utilizadas
jogashyse fora espaccedilo de armazenamento e reduzshyse o desempenho do sistema como
um todo E ainda tratamos objetos diferentes como se fossem iguais o que nem
sempre eacute uma boa praacutetica Abaixo o exemplo de como ficaria este cadastro de
produtos no modelo documental
codigo1 produtoBritadeira potencia300cv peso100kg
codigo2 produtoCimento
codigo3 produtoEmpilhadeira potencia15cv peso300kg
codigo4 produtoEscada altura3m
codigo5 produtoTubulaccedilatildeo diametro20cm
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
Seratildeo apresentados agora alguns comandos comuns usados no MongoDB Voltando
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2029
ao primeiro exemplo de documento criado para alunos observe como ficaria o
comando para salvar os alunos em uma coleccedilatildeo
dbunifacssave(aluno1)
dbunifacssave(aluno2)
O comando acima salva os documentos aluno1 e aluno2 na coleccedilatildeo ldquounifacsrdquo Eacute
possiacutevel acessar os dados de uma coleccedilatildeo atraveacutes do comando find() basicamente
ele vai percorrer todos os registros da coleccedilatildeo e retornar os documentos listados No
exemplo dado o comando seria dbunifacsfind() E para apagar tudo que existe na
coleccedilatildeo dbunifacsremove()
Natildeo eacute necessaacuterio que se crie uma coleccedilatildeo ou mesmo que se configure uma estrutura
isso eacute feito automaticamente quando o primeiro registro eacute incluiacutedo No entanto eacute
possiacutevel usar o comando de criar uma coleccedilatildeo e isto pode ser utilizado para preacuteshy
atribuir espaccedilo para uma coleccedilatildeo Uma coleccedilatildeo de tamanho fixo usa o comando
ldquocappedrdquo e vem a substituir automaticamente as entradas mais antigas quando
atinge seu tamanho maacuteximo
Todas as coleccedilotildees limitadas e fixas devem especificar um tamanho maacuteximo e
tambeacutem podem especificar um nuacutemero maacuteximo de documentos O MongoDB remove
os documentos antigos se uma coleccedilatildeo atinge o limite de tamanho maacuteximo antes
que ele atinja a contagem maacutexima de documentos Considere o seguinte exemplo
dbcreateCollection (unifacs capped true size 5242880 max 5000)
Este comando cria uma coleccedilatildeo nomeada de ldquounifacsrdquo com uma dimensatildeo maacutexima
de 5 megabytes e um maacuteximo de 5000 documentos
Para visualizar todas as coleccedilotildees de um banco de dados MongoDB utilizashyse o
seguinte comando
dbgetCollectionNames()
Enfim haacute muitas diferenccedilas entre os comandos usados no MongoDB e no MySQL As
quatro operaccedilotildees baacutesicas usadas para criaccedilatildeo consulta atualizaccedilatildeo e destruiccedilatildeo de
dados conhecidas como CRUD (Create Read Update e Delete) apresentam
comandos bem distintos nos dois tipos de bancos em questatildeo A Tabela 5 compara
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2129
alguns comandos de CRUD em ambos os bancos
MySQL MongoDB
CREATE TABLE unifacs (
id MEDIUMINT NOT NULL
AUTO_INCREMENT
matricula Number
nome Varchar(30)
idade Number
PRIMARY KEY (id)
)
A coleccedilatildeo eacute criada implicitamente na primeira
inserccedilatildeo de dados O _id chave primaacuteria eacute
adicionada automaticamente se o campo _id natildeo
eacute especificado
dbunifacsinsert (
matricula 04217253
nome Paulo
idade 22
)
ALTER TABLE unifacs
ADD join_date DATETIME
Coleccedilotildees natildeo descrevem ou forccedilam a estrutura
dos seus documentos No entanto no niacutevel do
documento operaccedilotildees de update () podem
adicionar campos para documentos existentes
usando o operador $set e remover usando
$unset
dbunifacsupdate (
$set join_date new Date ()
multi true
)
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2229
ALTER TABLE unifacs
DROP COLUMN join_date
dbunifacsupdate(
$unset join_date
multi true
)
INSERT INTO unifacs (matricula nome
idade)
VALUES (032104211 ldquoJoanardquo 21)
dbunifacsinsert(
matricula 032104211 nome ldquoJoanardquo idade
21
)
SELECT FROM unifacs dbunifacsfind()
SELECT FROM unifacs WHERE idade =
21dbunifacsfind( idade 21 )
SELECT FROM unifacs WHERE nome =
ldquoJoanardquo
AND idade = 21
dbunifacsfind( nome ldquoJoanardquo idade 21 )
SELECT FROM unifacs WHERE idade gt
20dbunifacsfind( age $gt 20 )
SELECT COUNT() FROM unifacs
dbuserscount()
ou
dbunifacsfind()count()
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2329
UPDATE unifacs SET status = ldquoAprovadordquo
WHERE nota gt 7
dbunifacsupdate( nota $gt 7
$set status ldquoAprovadordquo multi true )
UPDATE unifacs SET nota = nota + 1
WHERE status = Aprovado
dbunifacsupdate( status Aprovado
$inc nota 1 multi true )
DELETE FROM unifacs WHERE status =
Reprovadodbunifacsremove( status Reprovado )
Tabela 5 Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
Eacute importante saber que cada documento de uma coleccedilatildeo no MongoDB tem um
tamanho maacuteximo de 16MB o que eacute mais do que suficiente para armazenar dados em
um documento No entanto o MongoDB ainda eacute capaz de armazenar arquivos no
banco de dados em uma coleccedilatildeo especifica que eacute a coleccedilatildeo do tipo GridFS
Ela eacute ideal para trabalhar com arquivos maiores de imagens viacutedeo e aacuteudio O GridFS
divide o arquivo em partes ou pedaccedilos e salva cada pedaccedilo em um documento
separado Quando vocecirc consulta um arquivo no GridFS eacute preciso remontar os
pedaccedilos conforme a necessidade
O MongoDB atinge o objetivo de ser amigaacutevel para o desenvolvedor Possui uma
documentaccedilatildeo bem escrita para a maioria dos principais idiomas Sua consulta
baseada em JavaScript eacute faacutecil para os desenvolvedores da Web e ele tambeacutem eacute faacutecil
de instalar Por estas razotildees o MongoDB eacute uma oacutetima opccedilatildeo de tecnologia para uso
em uma aplicaccedilatildeo
Um exemplo do sucesso deste banco eacute o depoimento do especialista em banco de
dados da Globocom Franklin Amorim Em um evento sobre o MongoDB em 2011 na
cidade de Satildeo Paulo Franklin apresentou o case de sucesso da adoccedilatildeo do MongoDB
para uma nova funccedilatildeo do ldquofantasy gamerdquo CartolaFC
O jogo eacute maior aplicaccedilatildeo dinacircmica do portal Globocom com mais de 2 milhotildees de
usuaacuterios cadastrados e quase 90 milhotildees de pageviews somente em um mecircs
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1129
Tabela 1 Anaacutelise comparativa dos modelos de BD NoSQL
Modelo Relacional x NoSQLAo se comparar os modelos em questatildeo uma grande diferenccedila a se notar eacute que as
tecnologias relacionais tecircm esquemas riacutegidos enquanto os modelos NoSQL satildeo
schemashyfree ou seja sem esquema O modelo relacional requer uma definiccedilatildeo
estrita de um esquema antes de armazenar todos os dados em um banco de dados
Alterar o esquema uma vez que os dados jaacute estatildeo inseridos eacute muito complicado e
por isso evitado No entanto isto eacute exatamente o oposto do comportamento
desejado na era ldquoBig Datardquo 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 trecircs criteacuterios satildeo
considerados relevantes para esta escolha escalonamento consistecircncia de dados e
disponibilidade E eacute isto que seraacute abordado a partir de agora
Basicamente pelo fato de terem sido criados para essa finalidade os bancos NoSQL
apresentam vantagens em relaccedilatildeo 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 cenaacuterios em que o escalonamento eacute
necessaacuterio
Eacute possiacutevel tornar um banco de dados relacional mais escalaacutevel atraveacutes da teacutecnica de
escalonamento vertical onde eacute feita uma atualizaccedilatildeo (upgrade) no servidor de
bancos de dados
Poreacutem este escalonamento fica limitado agrave capacidade de uma uacutenica maacutequina Jaacute o
escalonamento horizontal eacute feito com o aumento da quantidade de servidores que
iratildeo disponibilizar os dados paralelamente (Figura 4) facilitando o acesso aos dados
e garantindo que a queda de um servidor natildeo seja um problema de disponibilidade
dos dados
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1229
Figura 4 O uso do escalonamento horizontal
Outra caracteriacutestica a favor do NoSQL eacute o uso do sharding que consiste em trabalhar
com o escalonamento horizontal particionando e paralelizando seus dados em vaacuterios
servidores (Figura 5) Essa teacutecnica eacute complexa para se usar em SGBDs relacionais
devido a toda a sua estrutura loacutegica e devido ao uso da desnormalizaccedilatildeo dos dados
o contraacuterio usado no modelo relacional
O sharding traz benefiacutecios pois conjuntos de dados menores satildeo mais faacuteceis de
serem acessados atualizados e gerenciados O maior benefiacutecio em comparaccedilatildeo ao
modelo relacional eacute a otimizaccedilatildeo do grau de disponibilidade do sistema pois como
jaacute dito anteriormente a queda de uma maacutequina natildeo causaria a interrupccedilatildeo de todo o
sistema
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1329
Figura 5 Teacutecnica de sharding
O controle de concorrecircncia tambeacutem funciona de maneira distinta nos modelos em
questatildeo O modelo relacional utiliza bloqueios (locks) como garantia de que dois
usuaacuterios natildeo atualizem o mesmo dado ao mesmo tempo Jaacute no modelo NoSQL satildeo
usadas outras estrateacutegias para permitir um maior grau de concorrecircncia
Alguns bancos NoSQL usam o MVCC (Multiversion Concurrency Control) ou Controle
de Concorrecircncia Multishyversotildees Nesta teacutecnica o acesso aos dados pode ser realizado
em paralelo
Cada usuaacuterio que se conecta ao banco de dados visualiza uma coacutepia temporaacuteria do
banco de dados naquele instante Qualquer atualizaccedilatildeo que esteja sendo feita em
determinado momento por um usuaacuterio natildeo seraacute vista pelos demais que estatildeo
operando simultaneamente no banco de dados ateacute que a atualizaccedilatildeo tenha sido
concluiacuteda
Quando se opta por usar um modelo NoSQL haacute ganhos de performance flexibilidade
e disponibilidade mas haacute uma perda de consistecircncia Haacute um teorema na ciecircncia da
computaccedilatildeo criado Eric Brewer chamado Teorema CAP (Consistency Availability e
Partition Tolerance) que diz ser impossiacutevel para um sistema distribuiacutedo garantir
consistecircncia disponibilidade e toleracircncia ao particionamento De forma simultacircnea
soacute eacute possiacutevel conseguir duas destas trecircs caracteriacutesticas Vejamos exemplos de
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1429
SGBDs na Figura 6 segundo o Teorema CAP
Figura 6 Distribuiccedilatildeo relativa de alguns bancos de dados quanto ao Teorema CAP
As soluccedilotildees NoSQL seguem um paradigma denominado BASE (Basically Available
Soft state Eventual consistency) Este tem como caracteriacutesticas estar basicamente
disponiacutevel o tempo todo estar em estado leve ou seja natildeo sendo consistente o
tempo todo e possuir uma consistecircncia eventual o sistema se torna consistente no
momento apropriado
O modelo BASE eacute um contraste ao paradigma ACID (Atomicity Consistency
Isolation Durability) comumente associado aos bancos de dados de modelo
relacional Ao contraacuterio do modelo ACID que promove uma seguranccedila dos dados
forccedilando a consistecircncia ao final de cada operaccedilatildeo o modelo BASE permite que o
banco de dados esteja em um estado eventualmente consistente
A disponibilidade do modelo BASE estaacute associada justamente ao fato de que a falha
de uma maacutequina do sistema natildeo interrompe o sistema como um todo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1529
Para se analisar de forma mais raacutepida e comparativa a Tabela 2 apresenta as
principais caracteriacutesticas de ambos os modelos discutidos aqui
Modelo Relacional NoSQL
Escalonamento Possui sua natureza
estruturada e por conta disto
o escalonamento de bancos
tende a ser uma tarefa
complexa
Eacute livre de esquemas por isso
o NoSQL possui uma maior
flexibilidade e alta
escalabilidade considerada
uma das principais vantagens
desse modelo
Consistecircncia Possui uma estrutura mais
riacutegida e garante em suas
transaccedilotildees a existecircncia dessa
propriedade As diversas
regras deste modelo
possibilitam uma maior
rigidez quanto a garantia de
consistecircncia dos dados
sendo este o ponto mais
forte desse modelo
A consistecircncia nesse modelo
possui um caraacuteter eventual
o que natildeo garante que uma
determinada atualizaccedilatildeo em
um dado momento seja
percebida por todos os noacutes
Disponibilidade Haacute uma dificuldade de se
trabalhar de forma eficiente
com a distribuiccedilatildeo de dados
por causa de sua natureza
estruturada situaccedilotildees em
que exigem uma maior
demanda de um sistema que
utilizem esse modelo podem
natildeo ser bem suportadas por
ele
Considerada outra das
grandes vantagens do
modelo essa propriedade
junto com o alto grau de
distribuiccedilatildeo desse modelo
possibilita que o sistema
fique um menor periacuteodo de
tempo natildeoshydisponiacutevel assim
como tambeacutem permite que a
solicitaccedilatildeo aos dados por um
nuacutemero crescente de clientes
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1629
seja atendida
Toleracircncia a
Particionamento
Por natildeo terem sido
construiacutedo com a finalidade
de trabalhar com
particionamento de dados
este modelo natildeo possui um
grau muito alto de toleracircncia
ao particionamento cuja
razatildeo principal seria a
dificuldade de junccedilotildees entre
as tabelas
Trabalha de forma faacutecil e
eficiente com a distribuiccedilatildeo
de dados Este modelo eacute
capaz de suportar grandes
demandas de dados assim
como possui alta toleracircncia
ao particionamento dos
mesmos
Tabela 2 Anaacutelise 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 verificaccedilatildeo contiacutenua
da consistecircncia de cada transaccedilatildeo adiciona custos consideraacuteveis para um sistema
que tem milhares de transaccedilotildees ocorrendo
A consistecircncia eventual promovida pelo modelo BASE daacute agraves organizaccedilotildees a
capacidade de interagir com os clientes de forma contiacutenua com a necessaacuteria
disponibilidade e toleracircncia a particcedilatildeo mantendo baixos custos e o sistema rodando
sem interrupccedilotildees Sem duacutevida seria excelente ter consistecircncia completa o tempo
todo mas eacute preciso haver compensaccedilotildees e a consistecircncia eventual permite o
desenvolvimento eficaz de sistemas que podem lidar com o aumento exponencial de
dados devido agraves redes sociais computaccedilatildeo em nuvem e outros projetos de Big Data
Estudo de Caso shy MongoDBPara fins comparativos seratildeo analisadas nesta seccedilatildeo algumas diferenccedilas entre um
banco NoSQL o MongoDB e os bancos relacionais baseados em SQL O MongoDB eacute
um banco de dados NoSQL criado em 2009 pela empresa 10gen orientado a
documentos altamente escalaacutevel de alta performance e de coacutedigo aberto O
cofundador e diretor de tecnologia da 10gen define o MongoDB da seguinte forma ldquoO
MongoDB natildeo foi concebido em um laboratoacuterio
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1729
Noacutes construiacutemos o MongoDB com base em nossas experiecircncias na construccedilatildeo de
sistemas robustos de grande escala e alta disponibilidade Natildeo comeccedilamos do zero
noacutes tentamos descobrir o que estava problemaacutetico e solucionamos isso
Assim o que eu penso sobre MongoDB eacute que se vocecirc pegar o MySQL e alterar o
modelo de dados do relacional para orientado a documento vocecirc ganha uma grande
quantidade de recursos documentos embarcados para melhorar velocidade
facilidade de gerenciamento desenvolvimento aacutegil com bancos de dados sem
ldquoschemardquo escalabilidade horizontal mais faacutecil pois ldquojoinsrdquo natildeo satildeo tatildeo importantes
Haacute muitas coisas que funcionam muito bem nos bancos de dados relacionais iacutendices
consultas dinacircmicas e atualizaccedilotildees e noacutes natildeo mudamos muito neste ponto Por
exemplo a maneira de projetar seus iacutendices no MongoDB deve ser exatamente do
jeito que vocecirc faz isso no MySQL ou Oracle vocecirc soacute ganha a opccedilatildeo de indexar um
campo embarcadordquo
Como dito na seccedilatildeo de modelos de bancos de dados NoSQL um banco orientado a
documentos natildeo possui esquemas riacutegidos e estruturados sendo possiacutevel que ocorra
uma atualizaccedilatildeo na estrutura do documento Portanto inserir novos campos no
documento natildeo 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 coleccedilatildeo
iacutendice iacutendice
linha documento BSON
coluna campo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1829
joins documentos incorporados e vinculaccedilatildeo
primary key
(Especifica qualquer combinaccedilatildeo de colunas
ou coluna uacutenica como chave primaacuteria)
primary key
(No MongoDB a chave primaacuteria eacute definida
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 dinacircmicos ou seja sem a
necessidade de que cada registro tenha a mesma estrutura Estas estruturas satildeo
chamadas de coleccedilotildees (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 sobrenomeSilva idade22 bairroPituba
Outro documento para representar um aluno na mesma coleccedilatildeo
aluno2=nomeLiardquo sobrenomeSaacute cursoDireito materias[Civil Penal]
Podeshyse ter registros diferentes um do outro dentro de uma mesma coleccedilatildeo Parece
estranho este tipo de abordagem mas no modelo relacional usamos isto o tempo
inteiro e de maneira ineficiente com a formaccedilatildeo de tabelas esparsas
Estas satildeo tabelas incompletas onde algumas colunas satildeo sempre preenchidas e
outras nem sempre satildeo usadas Para ilustrar isto observe a Tabela 4 que apresenta
registros da construccedilatildeo civil
Coacutedigo Produto Altura Potecircncia Peso Diacircmetro
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1929
1 Britadeira 300cv 100kg
2 Cimento
3 Empilhadeira 15cv 300kg
4 Escada 3m
5 Tubulaccedilatildeo 20cm
Tabela 4 Cadastro de produtos da construccedilatildeo civil em banco de dados modelo
relacional
Neste exemplo haacute uma desvantagem no modelo relacional Haacute colunas cujo valor eacute
preenchido apenas uma vez como pode ser visto no exemplo das colunas Altura e
Diacircmetro Na construccedilatildeo das tabelas ao incluir colunas que satildeo pouco utilizadas
jogashyse fora espaccedilo de armazenamento e reduzshyse o desempenho do sistema como
um todo E ainda tratamos objetos diferentes como se fossem iguais o que nem
sempre eacute uma boa praacutetica Abaixo o exemplo de como ficaria este cadastro de
produtos no modelo documental
codigo1 produtoBritadeira potencia300cv peso100kg
codigo2 produtoCimento
codigo3 produtoEmpilhadeira potencia15cv peso300kg
codigo4 produtoEscada altura3m
codigo5 produtoTubulaccedilatildeo diametro20cm
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
Seratildeo apresentados agora alguns comandos comuns usados no MongoDB Voltando
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2029
ao primeiro exemplo de documento criado para alunos observe como ficaria o
comando para salvar os alunos em uma coleccedilatildeo
dbunifacssave(aluno1)
dbunifacssave(aluno2)
O comando acima salva os documentos aluno1 e aluno2 na coleccedilatildeo ldquounifacsrdquo Eacute
possiacutevel acessar os dados de uma coleccedilatildeo atraveacutes do comando find() basicamente
ele vai percorrer todos os registros da coleccedilatildeo e retornar os documentos listados No
exemplo dado o comando seria dbunifacsfind() E para apagar tudo que existe na
coleccedilatildeo dbunifacsremove()
Natildeo eacute necessaacuterio que se crie uma coleccedilatildeo ou mesmo que se configure uma estrutura
isso eacute feito automaticamente quando o primeiro registro eacute incluiacutedo No entanto eacute
possiacutevel usar o comando de criar uma coleccedilatildeo e isto pode ser utilizado para preacuteshy
atribuir espaccedilo para uma coleccedilatildeo Uma coleccedilatildeo de tamanho fixo usa o comando
ldquocappedrdquo e vem a substituir automaticamente as entradas mais antigas quando
atinge seu tamanho maacuteximo
Todas as coleccedilotildees limitadas e fixas devem especificar um tamanho maacuteximo e
tambeacutem podem especificar um nuacutemero maacuteximo de documentos O MongoDB remove
os documentos antigos se uma coleccedilatildeo atinge o limite de tamanho maacuteximo antes
que ele atinja a contagem maacutexima de documentos Considere o seguinte exemplo
dbcreateCollection (unifacs capped true size 5242880 max 5000)
Este comando cria uma coleccedilatildeo nomeada de ldquounifacsrdquo com uma dimensatildeo maacutexima
de 5 megabytes e um maacuteximo de 5000 documentos
Para visualizar todas as coleccedilotildees de um banco de dados MongoDB utilizashyse o
seguinte comando
dbgetCollectionNames()
Enfim haacute muitas diferenccedilas entre os comandos usados no MongoDB e no MySQL As
quatro operaccedilotildees baacutesicas usadas para criaccedilatildeo consulta atualizaccedilatildeo e destruiccedilatildeo de
dados conhecidas como CRUD (Create Read Update e Delete) apresentam
comandos bem distintos nos dois tipos de bancos em questatildeo A Tabela 5 compara
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2129
alguns comandos de CRUD em ambos os bancos
MySQL MongoDB
CREATE TABLE unifacs (
id MEDIUMINT NOT NULL
AUTO_INCREMENT
matricula Number
nome Varchar(30)
idade Number
PRIMARY KEY (id)
)
A coleccedilatildeo eacute criada implicitamente na primeira
inserccedilatildeo de dados O _id chave primaacuteria eacute
adicionada automaticamente se o campo _id natildeo
eacute especificado
dbunifacsinsert (
matricula 04217253
nome Paulo
idade 22
)
ALTER TABLE unifacs
ADD join_date DATETIME
Coleccedilotildees natildeo descrevem ou forccedilam a estrutura
dos seus documentos No entanto no niacutevel do
documento operaccedilotildees de update () podem
adicionar campos para documentos existentes
usando o operador $set e remover usando
$unset
dbunifacsupdate (
$set join_date new Date ()
multi true
)
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2229
ALTER TABLE unifacs
DROP COLUMN join_date
dbunifacsupdate(
$unset join_date
multi true
)
INSERT INTO unifacs (matricula nome
idade)
VALUES (032104211 ldquoJoanardquo 21)
dbunifacsinsert(
matricula 032104211 nome ldquoJoanardquo idade
21
)
SELECT FROM unifacs dbunifacsfind()
SELECT FROM unifacs WHERE idade =
21dbunifacsfind( idade 21 )
SELECT FROM unifacs WHERE nome =
ldquoJoanardquo
AND idade = 21
dbunifacsfind( nome ldquoJoanardquo idade 21 )
SELECT FROM unifacs WHERE idade gt
20dbunifacsfind( age $gt 20 )
SELECT COUNT() FROM unifacs
dbuserscount()
ou
dbunifacsfind()count()
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2329
UPDATE unifacs SET status = ldquoAprovadordquo
WHERE nota gt 7
dbunifacsupdate( nota $gt 7
$set status ldquoAprovadordquo multi true )
UPDATE unifacs SET nota = nota + 1
WHERE status = Aprovado
dbunifacsupdate( status Aprovado
$inc nota 1 multi true )
DELETE FROM unifacs WHERE status =
Reprovadodbunifacsremove( status Reprovado )
Tabela 5 Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
Eacute importante saber que cada documento de uma coleccedilatildeo no MongoDB tem um
tamanho maacuteximo de 16MB o que eacute mais do que suficiente para armazenar dados em
um documento No entanto o MongoDB ainda eacute capaz de armazenar arquivos no
banco de dados em uma coleccedilatildeo especifica que eacute a coleccedilatildeo do tipo GridFS
Ela eacute ideal para trabalhar com arquivos maiores de imagens viacutedeo e aacuteudio O GridFS
divide o arquivo em partes ou pedaccedilos e salva cada pedaccedilo em um documento
separado Quando vocecirc consulta um arquivo no GridFS eacute preciso remontar os
pedaccedilos conforme a necessidade
O MongoDB atinge o objetivo de ser amigaacutevel para o desenvolvedor Possui uma
documentaccedilatildeo bem escrita para a maioria dos principais idiomas Sua consulta
baseada em JavaScript eacute faacutecil para os desenvolvedores da Web e ele tambeacutem eacute faacutecil
de instalar Por estas razotildees o MongoDB eacute uma oacutetima opccedilatildeo de tecnologia para uso
em uma aplicaccedilatildeo
Um exemplo do sucesso deste banco eacute o depoimento do especialista em banco de
dados da Globocom Franklin Amorim Em um evento sobre o MongoDB em 2011 na
cidade de Satildeo Paulo Franklin apresentou o case de sucesso da adoccedilatildeo do MongoDB
para uma nova funccedilatildeo do ldquofantasy gamerdquo CartolaFC
O jogo eacute maior aplicaccedilatildeo dinacircmica do portal Globocom com mais de 2 milhotildees de
usuaacuterios cadastrados e quase 90 milhotildees de pageviews somente em um mecircs
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1229
Figura 4 O uso do escalonamento horizontal
Outra caracteriacutestica a favor do NoSQL eacute o uso do sharding que consiste em trabalhar
com o escalonamento horizontal particionando e paralelizando seus dados em vaacuterios
servidores (Figura 5) Essa teacutecnica eacute complexa para se usar em SGBDs relacionais
devido a toda a sua estrutura loacutegica e devido ao uso da desnormalizaccedilatildeo dos dados
o contraacuterio usado no modelo relacional
O sharding traz benefiacutecios pois conjuntos de dados menores satildeo mais faacuteceis de
serem acessados atualizados e gerenciados O maior benefiacutecio em comparaccedilatildeo ao
modelo relacional eacute a otimizaccedilatildeo do grau de disponibilidade do sistema pois como
jaacute dito anteriormente a queda de uma maacutequina natildeo causaria a interrupccedilatildeo de todo o
sistema
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1329
Figura 5 Teacutecnica de sharding
O controle de concorrecircncia tambeacutem funciona de maneira distinta nos modelos em
questatildeo O modelo relacional utiliza bloqueios (locks) como garantia de que dois
usuaacuterios natildeo atualizem o mesmo dado ao mesmo tempo Jaacute no modelo NoSQL satildeo
usadas outras estrateacutegias para permitir um maior grau de concorrecircncia
Alguns bancos NoSQL usam o MVCC (Multiversion Concurrency Control) ou Controle
de Concorrecircncia Multishyversotildees Nesta teacutecnica o acesso aos dados pode ser realizado
em paralelo
Cada usuaacuterio que se conecta ao banco de dados visualiza uma coacutepia temporaacuteria do
banco de dados naquele instante Qualquer atualizaccedilatildeo que esteja sendo feita em
determinado momento por um usuaacuterio natildeo seraacute vista pelos demais que estatildeo
operando simultaneamente no banco de dados ateacute que a atualizaccedilatildeo tenha sido
concluiacuteda
Quando se opta por usar um modelo NoSQL haacute ganhos de performance flexibilidade
e disponibilidade mas haacute uma perda de consistecircncia Haacute um teorema na ciecircncia da
computaccedilatildeo criado Eric Brewer chamado Teorema CAP (Consistency Availability e
Partition Tolerance) que diz ser impossiacutevel para um sistema distribuiacutedo garantir
consistecircncia disponibilidade e toleracircncia ao particionamento De forma simultacircnea
soacute eacute possiacutevel conseguir duas destas trecircs caracteriacutesticas Vejamos exemplos de
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1429
SGBDs na Figura 6 segundo o Teorema CAP
Figura 6 Distribuiccedilatildeo relativa de alguns bancos de dados quanto ao Teorema CAP
As soluccedilotildees NoSQL seguem um paradigma denominado BASE (Basically Available
Soft state Eventual consistency) Este tem como caracteriacutesticas estar basicamente
disponiacutevel o tempo todo estar em estado leve ou seja natildeo sendo consistente o
tempo todo e possuir uma consistecircncia eventual o sistema se torna consistente no
momento apropriado
O modelo BASE eacute um contraste ao paradigma ACID (Atomicity Consistency
Isolation Durability) comumente associado aos bancos de dados de modelo
relacional Ao contraacuterio do modelo ACID que promove uma seguranccedila dos dados
forccedilando a consistecircncia ao final de cada operaccedilatildeo o modelo BASE permite que o
banco de dados esteja em um estado eventualmente consistente
A disponibilidade do modelo BASE estaacute associada justamente ao fato de que a falha
de uma maacutequina do sistema natildeo interrompe o sistema como um todo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1529
Para se analisar de forma mais raacutepida e comparativa a Tabela 2 apresenta as
principais caracteriacutesticas de ambos os modelos discutidos aqui
Modelo Relacional NoSQL
Escalonamento Possui sua natureza
estruturada e por conta disto
o escalonamento de bancos
tende a ser uma tarefa
complexa
Eacute livre de esquemas por isso
o NoSQL possui uma maior
flexibilidade e alta
escalabilidade considerada
uma das principais vantagens
desse modelo
Consistecircncia Possui uma estrutura mais
riacutegida e garante em suas
transaccedilotildees a existecircncia dessa
propriedade As diversas
regras deste modelo
possibilitam uma maior
rigidez quanto a garantia de
consistecircncia dos dados
sendo este o ponto mais
forte desse modelo
A consistecircncia nesse modelo
possui um caraacuteter eventual
o que natildeo garante que uma
determinada atualizaccedilatildeo em
um dado momento seja
percebida por todos os noacutes
Disponibilidade Haacute uma dificuldade de se
trabalhar de forma eficiente
com a distribuiccedilatildeo de dados
por causa de sua natureza
estruturada situaccedilotildees em
que exigem uma maior
demanda de um sistema que
utilizem esse modelo podem
natildeo ser bem suportadas por
ele
Considerada outra das
grandes vantagens do
modelo essa propriedade
junto com o alto grau de
distribuiccedilatildeo desse modelo
possibilita que o sistema
fique um menor periacuteodo de
tempo natildeoshydisponiacutevel assim
como tambeacutem permite que a
solicitaccedilatildeo aos dados por um
nuacutemero crescente de clientes
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1629
seja atendida
Toleracircncia a
Particionamento
Por natildeo terem sido
construiacutedo com a finalidade
de trabalhar com
particionamento de dados
este modelo natildeo possui um
grau muito alto de toleracircncia
ao particionamento cuja
razatildeo principal seria a
dificuldade de junccedilotildees entre
as tabelas
Trabalha de forma faacutecil e
eficiente com a distribuiccedilatildeo
de dados Este modelo eacute
capaz de suportar grandes
demandas de dados assim
como possui alta toleracircncia
ao particionamento dos
mesmos
Tabela 2 Anaacutelise 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 verificaccedilatildeo contiacutenua
da consistecircncia de cada transaccedilatildeo adiciona custos consideraacuteveis para um sistema
que tem milhares de transaccedilotildees ocorrendo
A consistecircncia eventual promovida pelo modelo BASE daacute agraves organizaccedilotildees a
capacidade de interagir com os clientes de forma contiacutenua com a necessaacuteria
disponibilidade e toleracircncia a particcedilatildeo mantendo baixos custos e o sistema rodando
sem interrupccedilotildees Sem duacutevida seria excelente ter consistecircncia completa o tempo
todo mas eacute preciso haver compensaccedilotildees e a consistecircncia eventual permite o
desenvolvimento eficaz de sistemas que podem lidar com o aumento exponencial de
dados devido agraves redes sociais computaccedilatildeo em nuvem e outros projetos de Big Data
Estudo de Caso shy MongoDBPara fins comparativos seratildeo analisadas nesta seccedilatildeo algumas diferenccedilas entre um
banco NoSQL o MongoDB e os bancos relacionais baseados em SQL O MongoDB eacute
um banco de dados NoSQL criado em 2009 pela empresa 10gen orientado a
documentos altamente escalaacutevel de alta performance e de coacutedigo aberto O
cofundador e diretor de tecnologia da 10gen define o MongoDB da seguinte forma ldquoO
MongoDB natildeo foi concebido em um laboratoacuterio
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1729
Noacutes construiacutemos o MongoDB com base em nossas experiecircncias na construccedilatildeo de
sistemas robustos de grande escala e alta disponibilidade Natildeo comeccedilamos do zero
noacutes tentamos descobrir o que estava problemaacutetico e solucionamos isso
Assim o que eu penso sobre MongoDB eacute que se vocecirc pegar o MySQL e alterar o
modelo de dados do relacional para orientado a documento vocecirc ganha uma grande
quantidade de recursos documentos embarcados para melhorar velocidade
facilidade de gerenciamento desenvolvimento aacutegil com bancos de dados sem
ldquoschemardquo escalabilidade horizontal mais faacutecil pois ldquojoinsrdquo natildeo satildeo tatildeo importantes
Haacute muitas coisas que funcionam muito bem nos bancos de dados relacionais iacutendices
consultas dinacircmicas e atualizaccedilotildees e noacutes natildeo mudamos muito neste ponto Por
exemplo a maneira de projetar seus iacutendices no MongoDB deve ser exatamente do
jeito que vocecirc faz isso no MySQL ou Oracle vocecirc soacute ganha a opccedilatildeo de indexar um
campo embarcadordquo
Como dito na seccedilatildeo de modelos de bancos de dados NoSQL um banco orientado a
documentos natildeo possui esquemas riacutegidos e estruturados sendo possiacutevel que ocorra
uma atualizaccedilatildeo na estrutura do documento Portanto inserir novos campos no
documento natildeo 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 coleccedilatildeo
iacutendice iacutendice
linha documento BSON
coluna campo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1829
joins documentos incorporados e vinculaccedilatildeo
primary key
(Especifica qualquer combinaccedilatildeo de colunas
ou coluna uacutenica como chave primaacuteria)
primary key
(No MongoDB a chave primaacuteria eacute definida
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 dinacircmicos ou seja sem a
necessidade de que cada registro tenha a mesma estrutura Estas estruturas satildeo
chamadas de coleccedilotildees (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 sobrenomeSilva idade22 bairroPituba
Outro documento para representar um aluno na mesma coleccedilatildeo
aluno2=nomeLiardquo sobrenomeSaacute cursoDireito materias[Civil Penal]
Podeshyse ter registros diferentes um do outro dentro de uma mesma coleccedilatildeo Parece
estranho este tipo de abordagem mas no modelo relacional usamos isto o tempo
inteiro e de maneira ineficiente com a formaccedilatildeo de tabelas esparsas
Estas satildeo tabelas incompletas onde algumas colunas satildeo sempre preenchidas e
outras nem sempre satildeo usadas Para ilustrar isto observe a Tabela 4 que apresenta
registros da construccedilatildeo civil
Coacutedigo Produto Altura Potecircncia Peso Diacircmetro
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1929
1 Britadeira 300cv 100kg
2 Cimento
3 Empilhadeira 15cv 300kg
4 Escada 3m
5 Tubulaccedilatildeo 20cm
Tabela 4 Cadastro de produtos da construccedilatildeo civil em banco de dados modelo
relacional
Neste exemplo haacute uma desvantagem no modelo relacional Haacute colunas cujo valor eacute
preenchido apenas uma vez como pode ser visto no exemplo das colunas Altura e
Diacircmetro Na construccedilatildeo das tabelas ao incluir colunas que satildeo pouco utilizadas
jogashyse fora espaccedilo de armazenamento e reduzshyse o desempenho do sistema como
um todo E ainda tratamos objetos diferentes como se fossem iguais o que nem
sempre eacute uma boa praacutetica Abaixo o exemplo de como ficaria este cadastro de
produtos no modelo documental
codigo1 produtoBritadeira potencia300cv peso100kg
codigo2 produtoCimento
codigo3 produtoEmpilhadeira potencia15cv peso300kg
codigo4 produtoEscada altura3m
codigo5 produtoTubulaccedilatildeo diametro20cm
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
Seratildeo apresentados agora alguns comandos comuns usados no MongoDB Voltando
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2029
ao primeiro exemplo de documento criado para alunos observe como ficaria o
comando para salvar os alunos em uma coleccedilatildeo
dbunifacssave(aluno1)
dbunifacssave(aluno2)
O comando acima salva os documentos aluno1 e aluno2 na coleccedilatildeo ldquounifacsrdquo Eacute
possiacutevel acessar os dados de uma coleccedilatildeo atraveacutes do comando find() basicamente
ele vai percorrer todos os registros da coleccedilatildeo e retornar os documentos listados No
exemplo dado o comando seria dbunifacsfind() E para apagar tudo que existe na
coleccedilatildeo dbunifacsremove()
Natildeo eacute necessaacuterio que se crie uma coleccedilatildeo ou mesmo que se configure uma estrutura
isso eacute feito automaticamente quando o primeiro registro eacute incluiacutedo No entanto eacute
possiacutevel usar o comando de criar uma coleccedilatildeo e isto pode ser utilizado para preacuteshy
atribuir espaccedilo para uma coleccedilatildeo Uma coleccedilatildeo de tamanho fixo usa o comando
ldquocappedrdquo e vem a substituir automaticamente as entradas mais antigas quando
atinge seu tamanho maacuteximo
Todas as coleccedilotildees limitadas e fixas devem especificar um tamanho maacuteximo e
tambeacutem podem especificar um nuacutemero maacuteximo de documentos O MongoDB remove
os documentos antigos se uma coleccedilatildeo atinge o limite de tamanho maacuteximo antes
que ele atinja a contagem maacutexima de documentos Considere o seguinte exemplo
dbcreateCollection (unifacs capped true size 5242880 max 5000)
Este comando cria uma coleccedilatildeo nomeada de ldquounifacsrdquo com uma dimensatildeo maacutexima
de 5 megabytes e um maacuteximo de 5000 documentos
Para visualizar todas as coleccedilotildees de um banco de dados MongoDB utilizashyse o
seguinte comando
dbgetCollectionNames()
Enfim haacute muitas diferenccedilas entre os comandos usados no MongoDB e no MySQL As
quatro operaccedilotildees baacutesicas usadas para criaccedilatildeo consulta atualizaccedilatildeo e destruiccedilatildeo de
dados conhecidas como CRUD (Create Read Update e Delete) apresentam
comandos bem distintos nos dois tipos de bancos em questatildeo A Tabela 5 compara
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2129
alguns comandos de CRUD em ambos os bancos
MySQL MongoDB
CREATE TABLE unifacs (
id MEDIUMINT NOT NULL
AUTO_INCREMENT
matricula Number
nome Varchar(30)
idade Number
PRIMARY KEY (id)
)
A coleccedilatildeo eacute criada implicitamente na primeira
inserccedilatildeo de dados O _id chave primaacuteria eacute
adicionada automaticamente se o campo _id natildeo
eacute especificado
dbunifacsinsert (
matricula 04217253
nome Paulo
idade 22
)
ALTER TABLE unifacs
ADD join_date DATETIME
Coleccedilotildees natildeo descrevem ou forccedilam a estrutura
dos seus documentos No entanto no niacutevel do
documento operaccedilotildees de update () podem
adicionar campos para documentos existentes
usando o operador $set e remover usando
$unset
dbunifacsupdate (
$set join_date new Date ()
multi true
)
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2229
ALTER TABLE unifacs
DROP COLUMN join_date
dbunifacsupdate(
$unset join_date
multi true
)
INSERT INTO unifacs (matricula nome
idade)
VALUES (032104211 ldquoJoanardquo 21)
dbunifacsinsert(
matricula 032104211 nome ldquoJoanardquo idade
21
)
SELECT FROM unifacs dbunifacsfind()
SELECT FROM unifacs WHERE idade =
21dbunifacsfind( idade 21 )
SELECT FROM unifacs WHERE nome =
ldquoJoanardquo
AND idade = 21
dbunifacsfind( nome ldquoJoanardquo idade 21 )
SELECT FROM unifacs WHERE idade gt
20dbunifacsfind( age $gt 20 )
SELECT COUNT() FROM unifacs
dbuserscount()
ou
dbunifacsfind()count()
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2329
UPDATE unifacs SET status = ldquoAprovadordquo
WHERE nota gt 7
dbunifacsupdate( nota $gt 7
$set status ldquoAprovadordquo multi true )
UPDATE unifacs SET nota = nota + 1
WHERE status = Aprovado
dbunifacsupdate( status Aprovado
$inc nota 1 multi true )
DELETE FROM unifacs WHERE status =
Reprovadodbunifacsremove( status Reprovado )
Tabela 5 Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
Eacute importante saber que cada documento de uma coleccedilatildeo no MongoDB tem um
tamanho maacuteximo de 16MB o que eacute mais do que suficiente para armazenar dados em
um documento No entanto o MongoDB ainda eacute capaz de armazenar arquivos no
banco de dados em uma coleccedilatildeo especifica que eacute a coleccedilatildeo do tipo GridFS
Ela eacute ideal para trabalhar com arquivos maiores de imagens viacutedeo e aacuteudio O GridFS
divide o arquivo em partes ou pedaccedilos e salva cada pedaccedilo em um documento
separado Quando vocecirc consulta um arquivo no GridFS eacute preciso remontar os
pedaccedilos conforme a necessidade
O MongoDB atinge o objetivo de ser amigaacutevel para o desenvolvedor Possui uma
documentaccedilatildeo bem escrita para a maioria dos principais idiomas Sua consulta
baseada em JavaScript eacute faacutecil para os desenvolvedores da Web e ele tambeacutem eacute faacutecil
de instalar Por estas razotildees o MongoDB eacute uma oacutetima opccedilatildeo de tecnologia para uso
em uma aplicaccedilatildeo
Um exemplo do sucesso deste banco eacute o depoimento do especialista em banco de
dados da Globocom Franklin Amorim Em um evento sobre o MongoDB em 2011 na
cidade de Satildeo Paulo Franklin apresentou o case de sucesso da adoccedilatildeo do MongoDB
para uma nova funccedilatildeo do ldquofantasy gamerdquo CartolaFC
O jogo eacute maior aplicaccedilatildeo dinacircmica do portal Globocom com mais de 2 milhotildees de
usuaacuterios cadastrados e quase 90 milhotildees de pageviews somente em um mecircs
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1329
Figura 5 Teacutecnica de sharding
O controle de concorrecircncia tambeacutem funciona de maneira distinta nos modelos em
questatildeo O modelo relacional utiliza bloqueios (locks) como garantia de que dois
usuaacuterios natildeo atualizem o mesmo dado ao mesmo tempo Jaacute no modelo NoSQL satildeo
usadas outras estrateacutegias para permitir um maior grau de concorrecircncia
Alguns bancos NoSQL usam o MVCC (Multiversion Concurrency Control) ou Controle
de Concorrecircncia Multishyversotildees Nesta teacutecnica o acesso aos dados pode ser realizado
em paralelo
Cada usuaacuterio que se conecta ao banco de dados visualiza uma coacutepia temporaacuteria do
banco de dados naquele instante Qualquer atualizaccedilatildeo que esteja sendo feita em
determinado momento por um usuaacuterio natildeo seraacute vista pelos demais que estatildeo
operando simultaneamente no banco de dados ateacute que a atualizaccedilatildeo tenha sido
concluiacuteda
Quando se opta por usar um modelo NoSQL haacute ganhos de performance flexibilidade
e disponibilidade mas haacute uma perda de consistecircncia Haacute um teorema na ciecircncia da
computaccedilatildeo criado Eric Brewer chamado Teorema CAP (Consistency Availability e
Partition Tolerance) que diz ser impossiacutevel para um sistema distribuiacutedo garantir
consistecircncia disponibilidade e toleracircncia ao particionamento De forma simultacircnea
soacute eacute possiacutevel conseguir duas destas trecircs caracteriacutesticas Vejamos exemplos de
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1429
SGBDs na Figura 6 segundo o Teorema CAP
Figura 6 Distribuiccedilatildeo relativa de alguns bancos de dados quanto ao Teorema CAP
As soluccedilotildees NoSQL seguem um paradigma denominado BASE (Basically Available
Soft state Eventual consistency) Este tem como caracteriacutesticas estar basicamente
disponiacutevel o tempo todo estar em estado leve ou seja natildeo sendo consistente o
tempo todo e possuir uma consistecircncia eventual o sistema se torna consistente no
momento apropriado
O modelo BASE eacute um contraste ao paradigma ACID (Atomicity Consistency
Isolation Durability) comumente associado aos bancos de dados de modelo
relacional Ao contraacuterio do modelo ACID que promove uma seguranccedila dos dados
forccedilando a consistecircncia ao final de cada operaccedilatildeo o modelo BASE permite que o
banco de dados esteja em um estado eventualmente consistente
A disponibilidade do modelo BASE estaacute associada justamente ao fato de que a falha
de uma maacutequina do sistema natildeo interrompe o sistema como um todo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1529
Para se analisar de forma mais raacutepida e comparativa a Tabela 2 apresenta as
principais caracteriacutesticas de ambos os modelos discutidos aqui
Modelo Relacional NoSQL
Escalonamento Possui sua natureza
estruturada e por conta disto
o escalonamento de bancos
tende a ser uma tarefa
complexa
Eacute livre de esquemas por isso
o NoSQL possui uma maior
flexibilidade e alta
escalabilidade considerada
uma das principais vantagens
desse modelo
Consistecircncia Possui uma estrutura mais
riacutegida e garante em suas
transaccedilotildees a existecircncia dessa
propriedade As diversas
regras deste modelo
possibilitam uma maior
rigidez quanto a garantia de
consistecircncia dos dados
sendo este o ponto mais
forte desse modelo
A consistecircncia nesse modelo
possui um caraacuteter eventual
o que natildeo garante que uma
determinada atualizaccedilatildeo em
um dado momento seja
percebida por todos os noacutes
Disponibilidade Haacute uma dificuldade de se
trabalhar de forma eficiente
com a distribuiccedilatildeo de dados
por causa de sua natureza
estruturada situaccedilotildees em
que exigem uma maior
demanda de um sistema que
utilizem esse modelo podem
natildeo ser bem suportadas por
ele
Considerada outra das
grandes vantagens do
modelo essa propriedade
junto com o alto grau de
distribuiccedilatildeo desse modelo
possibilita que o sistema
fique um menor periacuteodo de
tempo natildeoshydisponiacutevel assim
como tambeacutem permite que a
solicitaccedilatildeo aos dados por um
nuacutemero crescente de clientes
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1629
seja atendida
Toleracircncia a
Particionamento
Por natildeo terem sido
construiacutedo com a finalidade
de trabalhar com
particionamento de dados
este modelo natildeo possui um
grau muito alto de toleracircncia
ao particionamento cuja
razatildeo principal seria a
dificuldade de junccedilotildees entre
as tabelas
Trabalha de forma faacutecil e
eficiente com a distribuiccedilatildeo
de dados Este modelo eacute
capaz de suportar grandes
demandas de dados assim
como possui alta toleracircncia
ao particionamento dos
mesmos
Tabela 2 Anaacutelise 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 verificaccedilatildeo contiacutenua
da consistecircncia de cada transaccedilatildeo adiciona custos consideraacuteveis para um sistema
que tem milhares de transaccedilotildees ocorrendo
A consistecircncia eventual promovida pelo modelo BASE daacute agraves organizaccedilotildees a
capacidade de interagir com os clientes de forma contiacutenua com a necessaacuteria
disponibilidade e toleracircncia a particcedilatildeo mantendo baixos custos e o sistema rodando
sem interrupccedilotildees Sem duacutevida seria excelente ter consistecircncia completa o tempo
todo mas eacute preciso haver compensaccedilotildees e a consistecircncia eventual permite o
desenvolvimento eficaz de sistemas que podem lidar com o aumento exponencial de
dados devido agraves redes sociais computaccedilatildeo em nuvem e outros projetos de Big Data
Estudo de Caso shy MongoDBPara fins comparativos seratildeo analisadas nesta seccedilatildeo algumas diferenccedilas entre um
banco NoSQL o MongoDB e os bancos relacionais baseados em SQL O MongoDB eacute
um banco de dados NoSQL criado em 2009 pela empresa 10gen orientado a
documentos altamente escalaacutevel de alta performance e de coacutedigo aberto O
cofundador e diretor de tecnologia da 10gen define o MongoDB da seguinte forma ldquoO
MongoDB natildeo foi concebido em um laboratoacuterio
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1729
Noacutes construiacutemos o MongoDB com base em nossas experiecircncias na construccedilatildeo de
sistemas robustos de grande escala e alta disponibilidade Natildeo comeccedilamos do zero
noacutes tentamos descobrir o que estava problemaacutetico e solucionamos isso
Assim o que eu penso sobre MongoDB eacute que se vocecirc pegar o MySQL e alterar o
modelo de dados do relacional para orientado a documento vocecirc ganha uma grande
quantidade de recursos documentos embarcados para melhorar velocidade
facilidade de gerenciamento desenvolvimento aacutegil com bancos de dados sem
ldquoschemardquo escalabilidade horizontal mais faacutecil pois ldquojoinsrdquo natildeo satildeo tatildeo importantes
Haacute muitas coisas que funcionam muito bem nos bancos de dados relacionais iacutendices
consultas dinacircmicas e atualizaccedilotildees e noacutes natildeo mudamos muito neste ponto Por
exemplo a maneira de projetar seus iacutendices no MongoDB deve ser exatamente do
jeito que vocecirc faz isso no MySQL ou Oracle vocecirc soacute ganha a opccedilatildeo de indexar um
campo embarcadordquo
Como dito na seccedilatildeo de modelos de bancos de dados NoSQL um banco orientado a
documentos natildeo possui esquemas riacutegidos e estruturados sendo possiacutevel que ocorra
uma atualizaccedilatildeo na estrutura do documento Portanto inserir novos campos no
documento natildeo 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 coleccedilatildeo
iacutendice iacutendice
linha documento BSON
coluna campo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1829
joins documentos incorporados e vinculaccedilatildeo
primary key
(Especifica qualquer combinaccedilatildeo de colunas
ou coluna uacutenica como chave primaacuteria)
primary key
(No MongoDB a chave primaacuteria eacute definida
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 dinacircmicos ou seja sem a
necessidade de que cada registro tenha a mesma estrutura Estas estruturas satildeo
chamadas de coleccedilotildees (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 sobrenomeSilva idade22 bairroPituba
Outro documento para representar um aluno na mesma coleccedilatildeo
aluno2=nomeLiardquo sobrenomeSaacute cursoDireito materias[Civil Penal]
Podeshyse ter registros diferentes um do outro dentro de uma mesma coleccedilatildeo Parece
estranho este tipo de abordagem mas no modelo relacional usamos isto o tempo
inteiro e de maneira ineficiente com a formaccedilatildeo de tabelas esparsas
Estas satildeo tabelas incompletas onde algumas colunas satildeo sempre preenchidas e
outras nem sempre satildeo usadas Para ilustrar isto observe a Tabela 4 que apresenta
registros da construccedilatildeo civil
Coacutedigo Produto Altura Potecircncia Peso Diacircmetro
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1929
1 Britadeira 300cv 100kg
2 Cimento
3 Empilhadeira 15cv 300kg
4 Escada 3m
5 Tubulaccedilatildeo 20cm
Tabela 4 Cadastro de produtos da construccedilatildeo civil em banco de dados modelo
relacional
Neste exemplo haacute uma desvantagem no modelo relacional Haacute colunas cujo valor eacute
preenchido apenas uma vez como pode ser visto no exemplo das colunas Altura e
Diacircmetro Na construccedilatildeo das tabelas ao incluir colunas que satildeo pouco utilizadas
jogashyse fora espaccedilo de armazenamento e reduzshyse o desempenho do sistema como
um todo E ainda tratamos objetos diferentes como se fossem iguais o que nem
sempre eacute uma boa praacutetica Abaixo o exemplo de como ficaria este cadastro de
produtos no modelo documental
codigo1 produtoBritadeira potencia300cv peso100kg
codigo2 produtoCimento
codigo3 produtoEmpilhadeira potencia15cv peso300kg
codigo4 produtoEscada altura3m
codigo5 produtoTubulaccedilatildeo diametro20cm
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
Seratildeo apresentados agora alguns comandos comuns usados no MongoDB Voltando
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2029
ao primeiro exemplo de documento criado para alunos observe como ficaria o
comando para salvar os alunos em uma coleccedilatildeo
dbunifacssave(aluno1)
dbunifacssave(aluno2)
O comando acima salva os documentos aluno1 e aluno2 na coleccedilatildeo ldquounifacsrdquo Eacute
possiacutevel acessar os dados de uma coleccedilatildeo atraveacutes do comando find() basicamente
ele vai percorrer todos os registros da coleccedilatildeo e retornar os documentos listados No
exemplo dado o comando seria dbunifacsfind() E para apagar tudo que existe na
coleccedilatildeo dbunifacsremove()
Natildeo eacute necessaacuterio que se crie uma coleccedilatildeo ou mesmo que se configure uma estrutura
isso eacute feito automaticamente quando o primeiro registro eacute incluiacutedo No entanto eacute
possiacutevel usar o comando de criar uma coleccedilatildeo e isto pode ser utilizado para preacuteshy
atribuir espaccedilo para uma coleccedilatildeo Uma coleccedilatildeo de tamanho fixo usa o comando
ldquocappedrdquo e vem a substituir automaticamente as entradas mais antigas quando
atinge seu tamanho maacuteximo
Todas as coleccedilotildees limitadas e fixas devem especificar um tamanho maacuteximo e
tambeacutem podem especificar um nuacutemero maacuteximo de documentos O MongoDB remove
os documentos antigos se uma coleccedilatildeo atinge o limite de tamanho maacuteximo antes
que ele atinja a contagem maacutexima de documentos Considere o seguinte exemplo
dbcreateCollection (unifacs capped true size 5242880 max 5000)
Este comando cria uma coleccedilatildeo nomeada de ldquounifacsrdquo com uma dimensatildeo maacutexima
de 5 megabytes e um maacuteximo de 5000 documentos
Para visualizar todas as coleccedilotildees de um banco de dados MongoDB utilizashyse o
seguinte comando
dbgetCollectionNames()
Enfim haacute muitas diferenccedilas entre os comandos usados no MongoDB e no MySQL As
quatro operaccedilotildees baacutesicas usadas para criaccedilatildeo consulta atualizaccedilatildeo e destruiccedilatildeo de
dados conhecidas como CRUD (Create Read Update e Delete) apresentam
comandos bem distintos nos dois tipos de bancos em questatildeo A Tabela 5 compara
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2129
alguns comandos de CRUD em ambos os bancos
MySQL MongoDB
CREATE TABLE unifacs (
id MEDIUMINT NOT NULL
AUTO_INCREMENT
matricula Number
nome Varchar(30)
idade Number
PRIMARY KEY (id)
)
A coleccedilatildeo eacute criada implicitamente na primeira
inserccedilatildeo de dados O _id chave primaacuteria eacute
adicionada automaticamente se o campo _id natildeo
eacute especificado
dbunifacsinsert (
matricula 04217253
nome Paulo
idade 22
)
ALTER TABLE unifacs
ADD join_date DATETIME
Coleccedilotildees natildeo descrevem ou forccedilam a estrutura
dos seus documentos No entanto no niacutevel do
documento operaccedilotildees de update () podem
adicionar campos para documentos existentes
usando o operador $set e remover usando
$unset
dbunifacsupdate (
$set join_date new Date ()
multi true
)
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2229
ALTER TABLE unifacs
DROP COLUMN join_date
dbunifacsupdate(
$unset join_date
multi true
)
INSERT INTO unifacs (matricula nome
idade)
VALUES (032104211 ldquoJoanardquo 21)
dbunifacsinsert(
matricula 032104211 nome ldquoJoanardquo idade
21
)
SELECT FROM unifacs dbunifacsfind()
SELECT FROM unifacs WHERE idade =
21dbunifacsfind( idade 21 )
SELECT FROM unifacs WHERE nome =
ldquoJoanardquo
AND idade = 21
dbunifacsfind( nome ldquoJoanardquo idade 21 )
SELECT FROM unifacs WHERE idade gt
20dbunifacsfind( age $gt 20 )
SELECT COUNT() FROM unifacs
dbuserscount()
ou
dbunifacsfind()count()
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2329
UPDATE unifacs SET status = ldquoAprovadordquo
WHERE nota gt 7
dbunifacsupdate( nota $gt 7
$set status ldquoAprovadordquo multi true )
UPDATE unifacs SET nota = nota + 1
WHERE status = Aprovado
dbunifacsupdate( status Aprovado
$inc nota 1 multi true )
DELETE FROM unifacs WHERE status =
Reprovadodbunifacsremove( status Reprovado )
Tabela 5 Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
Eacute importante saber que cada documento de uma coleccedilatildeo no MongoDB tem um
tamanho maacuteximo de 16MB o que eacute mais do que suficiente para armazenar dados em
um documento No entanto o MongoDB ainda eacute capaz de armazenar arquivos no
banco de dados em uma coleccedilatildeo especifica que eacute a coleccedilatildeo do tipo GridFS
Ela eacute ideal para trabalhar com arquivos maiores de imagens viacutedeo e aacuteudio O GridFS
divide o arquivo em partes ou pedaccedilos e salva cada pedaccedilo em um documento
separado Quando vocecirc consulta um arquivo no GridFS eacute preciso remontar os
pedaccedilos conforme a necessidade
O MongoDB atinge o objetivo de ser amigaacutevel para o desenvolvedor Possui uma
documentaccedilatildeo bem escrita para a maioria dos principais idiomas Sua consulta
baseada em JavaScript eacute faacutecil para os desenvolvedores da Web e ele tambeacutem eacute faacutecil
de instalar Por estas razotildees o MongoDB eacute uma oacutetima opccedilatildeo de tecnologia para uso
em uma aplicaccedilatildeo
Um exemplo do sucesso deste banco eacute o depoimento do especialista em banco de
dados da Globocom Franklin Amorim Em um evento sobre o MongoDB em 2011 na
cidade de Satildeo Paulo Franklin apresentou o case de sucesso da adoccedilatildeo do MongoDB
para uma nova funccedilatildeo do ldquofantasy gamerdquo CartolaFC
O jogo eacute maior aplicaccedilatildeo dinacircmica do portal Globocom com mais de 2 milhotildees de
usuaacuterios cadastrados e quase 90 milhotildees de pageviews somente em um mecircs
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1429
SGBDs na Figura 6 segundo o Teorema CAP
Figura 6 Distribuiccedilatildeo relativa de alguns bancos de dados quanto ao Teorema CAP
As soluccedilotildees NoSQL seguem um paradigma denominado BASE (Basically Available
Soft state Eventual consistency) Este tem como caracteriacutesticas estar basicamente
disponiacutevel o tempo todo estar em estado leve ou seja natildeo sendo consistente o
tempo todo e possuir uma consistecircncia eventual o sistema se torna consistente no
momento apropriado
O modelo BASE eacute um contraste ao paradigma ACID (Atomicity Consistency
Isolation Durability) comumente associado aos bancos de dados de modelo
relacional Ao contraacuterio do modelo ACID que promove uma seguranccedila dos dados
forccedilando a consistecircncia ao final de cada operaccedilatildeo o modelo BASE permite que o
banco de dados esteja em um estado eventualmente consistente
A disponibilidade do modelo BASE estaacute associada justamente ao fato de que a falha
de uma maacutequina do sistema natildeo interrompe o sistema como um todo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1529
Para se analisar de forma mais raacutepida e comparativa a Tabela 2 apresenta as
principais caracteriacutesticas de ambos os modelos discutidos aqui
Modelo Relacional NoSQL
Escalonamento Possui sua natureza
estruturada e por conta disto
o escalonamento de bancos
tende a ser uma tarefa
complexa
Eacute livre de esquemas por isso
o NoSQL possui uma maior
flexibilidade e alta
escalabilidade considerada
uma das principais vantagens
desse modelo
Consistecircncia Possui uma estrutura mais
riacutegida e garante em suas
transaccedilotildees a existecircncia dessa
propriedade As diversas
regras deste modelo
possibilitam uma maior
rigidez quanto a garantia de
consistecircncia dos dados
sendo este o ponto mais
forte desse modelo
A consistecircncia nesse modelo
possui um caraacuteter eventual
o que natildeo garante que uma
determinada atualizaccedilatildeo em
um dado momento seja
percebida por todos os noacutes
Disponibilidade Haacute uma dificuldade de se
trabalhar de forma eficiente
com a distribuiccedilatildeo de dados
por causa de sua natureza
estruturada situaccedilotildees em
que exigem uma maior
demanda de um sistema que
utilizem esse modelo podem
natildeo ser bem suportadas por
ele
Considerada outra das
grandes vantagens do
modelo essa propriedade
junto com o alto grau de
distribuiccedilatildeo desse modelo
possibilita que o sistema
fique um menor periacuteodo de
tempo natildeoshydisponiacutevel assim
como tambeacutem permite que a
solicitaccedilatildeo aos dados por um
nuacutemero crescente de clientes
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1629
seja atendida
Toleracircncia a
Particionamento
Por natildeo terem sido
construiacutedo com a finalidade
de trabalhar com
particionamento de dados
este modelo natildeo possui um
grau muito alto de toleracircncia
ao particionamento cuja
razatildeo principal seria a
dificuldade de junccedilotildees entre
as tabelas
Trabalha de forma faacutecil e
eficiente com a distribuiccedilatildeo
de dados Este modelo eacute
capaz de suportar grandes
demandas de dados assim
como possui alta toleracircncia
ao particionamento dos
mesmos
Tabela 2 Anaacutelise 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 verificaccedilatildeo contiacutenua
da consistecircncia de cada transaccedilatildeo adiciona custos consideraacuteveis para um sistema
que tem milhares de transaccedilotildees ocorrendo
A consistecircncia eventual promovida pelo modelo BASE daacute agraves organizaccedilotildees a
capacidade de interagir com os clientes de forma contiacutenua com a necessaacuteria
disponibilidade e toleracircncia a particcedilatildeo mantendo baixos custos e o sistema rodando
sem interrupccedilotildees Sem duacutevida seria excelente ter consistecircncia completa o tempo
todo mas eacute preciso haver compensaccedilotildees e a consistecircncia eventual permite o
desenvolvimento eficaz de sistemas que podem lidar com o aumento exponencial de
dados devido agraves redes sociais computaccedilatildeo em nuvem e outros projetos de Big Data
Estudo de Caso shy MongoDBPara fins comparativos seratildeo analisadas nesta seccedilatildeo algumas diferenccedilas entre um
banco NoSQL o MongoDB e os bancos relacionais baseados em SQL O MongoDB eacute
um banco de dados NoSQL criado em 2009 pela empresa 10gen orientado a
documentos altamente escalaacutevel de alta performance e de coacutedigo aberto O
cofundador e diretor de tecnologia da 10gen define o MongoDB da seguinte forma ldquoO
MongoDB natildeo foi concebido em um laboratoacuterio
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1729
Noacutes construiacutemos o MongoDB com base em nossas experiecircncias na construccedilatildeo de
sistemas robustos de grande escala e alta disponibilidade Natildeo comeccedilamos do zero
noacutes tentamos descobrir o que estava problemaacutetico e solucionamos isso
Assim o que eu penso sobre MongoDB eacute que se vocecirc pegar o MySQL e alterar o
modelo de dados do relacional para orientado a documento vocecirc ganha uma grande
quantidade de recursos documentos embarcados para melhorar velocidade
facilidade de gerenciamento desenvolvimento aacutegil com bancos de dados sem
ldquoschemardquo escalabilidade horizontal mais faacutecil pois ldquojoinsrdquo natildeo satildeo tatildeo importantes
Haacute muitas coisas que funcionam muito bem nos bancos de dados relacionais iacutendices
consultas dinacircmicas e atualizaccedilotildees e noacutes natildeo mudamos muito neste ponto Por
exemplo a maneira de projetar seus iacutendices no MongoDB deve ser exatamente do
jeito que vocecirc faz isso no MySQL ou Oracle vocecirc soacute ganha a opccedilatildeo de indexar um
campo embarcadordquo
Como dito na seccedilatildeo de modelos de bancos de dados NoSQL um banco orientado a
documentos natildeo possui esquemas riacutegidos e estruturados sendo possiacutevel que ocorra
uma atualizaccedilatildeo na estrutura do documento Portanto inserir novos campos no
documento natildeo 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 coleccedilatildeo
iacutendice iacutendice
linha documento BSON
coluna campo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1829
joins documentos incorporados e vinculaccedilatildeo
primary key
(Especifica qualquer combinaccedilatildeo de colunas
ou coluna uacutenica como chave primaacuteria)
primary key
(No MongoDB a chave primaacuteria eacute definida
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 dinacircmicos ou seja sem a
necessidade de que cada registro tenha a mesma estrutura Estas estruturas satildeo
chamadas de coleccedilotildees (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 sobrenomeSilva idade22 bairroPituba
Outro documento para representar um aluno na mesma coleccedilatildeo
aluno2=nomeLiardquo sobrenomeSaacute cursoDireito materias[Civil Penal]
Podeshyse ter registros diferentes um do outro dentro de uma mesma coleccedilatildeo Parece
estranho este tipo de abordagem mas no modelo relacional usamos isto o tempo
inteiro e de maneira ineficiente com a formaccedilatildeo de tabelas esparsas
Estas satildeo tabelas incompletas onde algumas colunas satildeo sempre preenchidas e
outras nem sempre satildeo usadas Para ilustrar isto observe a Tabela 4 que apresenta
registros da construccedilatildeo civil
Coacutedigo Produto Altura Potecircncia Peso Diacircmetro
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1929
1 Britadeira 300cv 100kg
2 Cimento
3 Empilhadeira 15cv 300kg
4 Escada 3m
5 Tubulaccedilatildeo 20cm
Tabela 4 Cadastro de produtos da construccedilatildeo civil em banco de dados modelo
relacional
Neste exemplo haacute uma desvantagem no modelo relacional Haacute colunas cujo valor eacute
preenchido apenas uma vez como pode ser visto no exemplo das colunas Altura e
Diacircmetro Na construccedilatildeo das tabelas ao incluir colunas que satildeo pouco utilizadas
jogashyse fora espaccedilo de armazenamento e reduzshyse o desempenho do sistema como
um todo E ainda tratamos objetos diferentes como se fossem iguais o que nem
sempre eacute uma boa praacutetica Abaixo o exemplo de como ficaria este cadastro de
produtos no modelo documental
codigo1 produtoBritadeira potencia300cv peso100kg
codigo2 produtoCimento
codigo3 produtoEmpilhadeira potencia15cv peso300kg
codigo4 produtoEscada altura3m
codigo5 produtoTubulaccedilatildeo diametro20cm
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
Seratildeo apresentados agora alguns comandos comuns usados no MongoDB Voltando
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2029
ao primeiro exemplo de documento criado para alunos observe como ficaria o
comando para salvar os alunos em uma coleccedilatildeo
dbunifacssave(aluno1)
dbunifacssave(aluno2)
O comando acima salva os documentos aluno1 e aluno2 na coleccedilatildeo ldquounifacsrdquo Eacute
possiacutevel acessar os dados de uma coleccedilatildeo atraveacutes do comando find() basicamente
ele vai percorrer todos os registros da coleccedilatildeo e retornar os documentos listados No
exemplo dado o comando seria dbunifacsfind() E para apagar tudo que existe na
coleccedilatildeo dbunifacsremove()
Natildeo eacute necessaacuterio que se crie uma coleccedilatildeo ou mesmo que se configure uma estrutura
isso eacute feito automaticamente quando o primeiro registro eacute incluiacutedo No entanto eacute
possiacutevel usar o comando de criar uma coleccedilatildeo e isto pode ser utilizado para preacuteshy
atribuir espaccedilo para uma coleccedilatildeo Uma coleccedilatildeo de tamanho fixo usa o comando
ldquocappedrdquo e vem a substituir automaticamente as entradas mais antigas quando
atinge seu tamanho maacuteximo
Todas as coleccedilotildees limitadas e fixas devem especificar um tamanho maacuteximo e
tambeacutem podem especificar um nuacutemero maacuteximo de documentos O MongoDB remove
os documentos antigos se uma coleccedilatildeo atinge o limite de tamanho maacuteximo antes
que ele atinja a contagem maacutexima de documentos Considere o seguinte exemplo
dbcreateCollection (unifacs capped true size 5242880 max 5000)
Este comando cria uma coleccedilatildeo nomeada de ldquounifacsrdquo com uma dimensatildeo maacutexima
de 5 megabytes e um maacuteximo de 5000 documentos
Para visualizar todas as coleccedilotildees de um banco de dados MongoDB utilizashyse o
seguinte comando
dbgetCollectionNames()
Enfim haacute muitas diferenccedilas entre os comandos usados no MongoDB e no MySQL As
quatro operaccedilotildees baacutesicas usadas para criaccedilatildeo consulta atualizaccedilatildeo e destruiccedilatildeo de
dados conhecidas como CRUD (Create Read Update e Delete) apresentam
comandos bem distintos nos dois tipos de bancos em questatildeo A Tabela 5 compara
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2129
alguns comandos de CRUD em ambos os bancos
MySQL MongoDB
CREATE TABLE unifacs (
id MEDIUMINT NOT NULL
AUTO_INCREMENT
matricula Number
nome Varchar(30)
idade Number
PRIMARY KEY (id)
)
A coleccedilatildeo eacute criada implicitamente na primeira
inserccedilatildeo de dados O _id chave primaacuteria eacute
adicionada automaticamente se o campo _id natildeo
eacute especificado
dbunifacsinsert (
matricula 04217253
nome Paulo
idade 22
)
ALTER TABLE unifacs
ADD join_date DATETIME
Coleccedilotildees natildeo descrevem ou forccedilam a estrutura
dos seus documentos No entanto no niacutevel do
documento operaccedilotildees de update () podem
adicionar campos para documentos existentes
usando o operador $set e remover usando
$unset
dbunifacsupdate (
$set join_date new Date ()
multi true
)
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2229
ALTER TABLE unifacs
DROP COLUMN join_date
dbunifacsupdate(
$unset join_date
multi true
)
INSERT INTO unifacs (matricula nome
idade)
VALUES (032104211 ldquoJoanardquo 21)
dbunifacsinsert(
matricula 032104211 nome ldquoJoanardquo idade
21
)
SELECT FROM unifacs dbunifacsfind()
SELECT FROM unifacs WHERE idade =
21dbunifacsfind( idade 21 )
SELECT FROM unifacs WHERE nome =
ldquoJoanardquo
AND idade = 21
dbunifacsfind( nome ldquoJoanardquo idade 21 )
SELECT FROM unifacs WHERE idade gt
20dbunifacsfind( age $gt 20 )
SELECT COUNT() FROM unifacs
dbuserscount()
ou
dbunifacsfind()count()
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2329
UPDATE unifacs SET status = ldquoAprovadordquo
WHERE nota gt 7
dbunifacsupdate( nota $gt 7
$set status ldquoAprovadordquo multi true )
UPDATE unifacs SET nota = nota + 1
WHERE status = Aprovado
dbunifacsupdate( status Aprovado
$inc nota 1 multi true )
DELETE FROM unifacs WHERE status =
Reprovadodbunifacsremove( status Reprovado )
Tabela 5 Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
Eacute importante saber que cada documento de uma coleccedilatildeo no MongoDB tem um
tamanho maacuteximo de 16MB o que eacute mais do que suficiente para armazenar dados em
um documento No entanto o MongoDB ainda eacute capaz de armazenar arquivos no
banco de dados em uma coleccedilatildeo especifica que eacute a coleccedilatildeo do tipo GridFS
Ela eacute ideal para trabalhar com arquivos maiores de imagens viacutedeo e aacuteudio O GridFS
divide o arquivo em partes ou pedaccedilos e salva cada pedaccedilo em um documento
separado Quando vocecirc consulta um arquivo no GridFS eacute preciso remontar os
pedaccedilos conforme a necessidade
O MongoDB atinge o objetivo de ser amigaacutevel para o desenvolvedor Possui uma
documentaccedilatildeo bem escrita para a maioria dos principais idiomas Sua consulta
baseada em JavaScript eacute faacutecil para os desenvolvedores da Web e ele tambeacutem eacute faacutecil
de instalar Por estas razotildees o MongoDB eacute uma oacutetima opccedilatildeo de tecnologia para uso
em uma aplicaccedilatildeo
Um exemplo do sucesso deste banco eacute o depoimento do especialista em banco de
dados da Globocom Franklin Amorim Em um evento sobre o MongoDB em 2011 na
cidade de Satildeo Paulo Franklin apresentou o case de sucesso da adoccedilatildeo do MongoDB
para uma nova funccedilatildeo do ldquofantasy gamerdquo CartolaFC
O jogo eacute maior aplicaccedilatildeo dinacircmica do portal Globocom com mais de 2 milhotildees de
usuaacuterios cadastrados e quase 90 milhotildees de pageviews somente em um mecircs
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1529
Para se analisar de forma mais raacutepida e comparativa a Tabela 2 apresenta as
principais caracteriacutesticas de ambos os modelos discutidos aqui
Modelo Relacional NoSQL
Escalonamento Possui sua natureza
estruturada e por conta disto
o escalonamento de bancos
tende a ser uma tarefa
complexa
Eacute livre de esquemas por isso
o NoSQL possui uma maior
flexibilidade e alta
escalabilidade considerada
uma das principais vantagens
desse modelo
Consistecircncia Possui uma estrutura mais
riacutegida e garante em suas
transaccedilotildees a existecircncia dessa
propriedade As diversas
regras deste modelo
possibilitam uma maior
rigidez quanto a garantia de
consistecircncia dos dados
sendo este o ponto mais
forte desse modelo
A consistecircncia nesse modelo
possui um caraacuteter eventual
o que natildeo garante que uma
determinada atualizaccedilatildeo em
um dado momento seja
percebida por todos os noacutes
Disponibilidade Haacute uma dificuldade de se
trabalhar de forma eficiente
com a distribuiccedilatildeo de dados
por causa de sua natureza
estruturada situaccedilotildees em
que exigem uma maior
demanda de um sistema que
utilizem esse modelo podem
natildeo ser bem suportadas por
ele
Considerada outra das
grandes vantagens do
modelo essa propriedade
junto com o alto grau de
distribuiccedilatildeo desse modelo
possibilita que o sistema
fique um menor periacuteodo de
tempo natildeoshydisponiacutevel assim
como tambeacutem permite que a
solicitaccedilatildeo aos dados por um
nuacutemero crescente de clientes
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1629
seja atendida
Toleracircncia a
Particionamento
Por natildeo terem sido
construiacutedo com a finalidade
de trabalhar com
particionamento de dados
este modelo natildeo possui um
grau muito alto de toleracircncia
ao particionamento cuja
razatildeo principal seria a
dificuldade de junccedilotildees entre
as tabelas
Trabalha de forma faacutecil e
eficiente com a distribuiccedilatildeo
de dados Este modelo eacute
capaz de suportar grandes
demandas de dados assim
como possui alta toleracircncia
ao particionamento dos
mesmos
Tabela 2 Anaacutelise 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 verificaccedilatildeo contiacutenua
da consistecircncia de cada transaccedilatildeo adiciona custos consideraacuteveis para um sistema
que tem milhares de transaccedilotildees ocorrendo
A consistecircncia eventual promovida pelo modelo BASE daacute agraves organizaccedilotildees a
capacidade de interagir com os clientes de forma contiacutenua com a necessaacuteria
disponibilidade e toleracircncia a particcedilatildeo mantendo baixos custos e o sistema rodando
sem interrupccedilotildees Sem duacutevida seria excelente ter consistecircncia completa o tempo
todo mas eacute preciso haver compensaccedilotildees e a consistecircncia eventual permite o
desenvolvimento eficaz de sistemas que podem lidar com o aumento exponencial de
dados devido agraves redes sociais computaccedilatildeo em nuvem e outros projetos de Big Data
Estudo de Caso shy MongoDBPara fins comparativos seratildeo analisadas nesta seccedilatildeo algumas diferenccedilas entre um
banco NoSQL o MongoDB e os bancos relacionais baseados em SQL O MongoDB eacute
um banco de dados NoSQL criado em 2009 pela empresa 10gen orientado a
documentos altamente escalaacutevel de alta performance e de coacutedigo aberto O
cofundador e diretor de tecnologia da 10gen define o MongoDB da seguinte forma ldquoO
MongoDB natildeo foi concebido em um laboratoacuterio
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1729
Noacutes construiacutemos o MongoDB com base em nossas experiecircncias na construccedilatildeo de
sistemas robustos de grande escala e alta disponibilidade Natildeo comeccedilamos do zero
noacutes tentamos descobrir o que estava problemaacutetico e solucionamos isso
Assim o que eu penso sobre MongoDB eacute que se vocecirc pegar o MySQL e alterar o
modelo de dados do relacional para orientado a documento vocecirc ganha uma grande
quantidade de recursos documentos embarcados para melhorar velocidade
facilidade de gerenciamento desenvolvimento aacutegil com bancos de dados sem
ldquoschemardquo escalabilidade horizontal mais faacutecil pois ldquojoinsrdquo natildeo satildeo tatildeo importantes
Haacute muitas coisas que funcionam muito bem nos bancos de dados relacionais iacutendices
consultas dinacircmicas e atualizaccedilotildees e noacutes natildeo mudamos muito neste ponto Por
exemplo a maneira de projetar seus iacutendices no MongoDB deve ser exatamente do
jeito que vocecirc faz isso no MySQL ou Oracle vocecirc soacute ganha a opccedilatildeo de indexar um
campo embarcadordquo
Como dito na seccedilatildeo de modelos de bancos de dados NoSQL um banco orientado a
documentos natildeo possui esquemas riacutegidos e estruturados sendo possiacutevel que ocorra
uma atualizaccedilatildeo na estrutura do documento Portanto inserir novos campos no
documento natildeo 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 coleccedilatildeo
iacutendice iacutendice
linha documento BSON
coluna campo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1829
joins documentos incorporados e vinculaccedilatildeo
primary key
(Especifica qualquer combinaccedilatildeo de colunas
ou coluna uacutenica como chave primaacuteria)
primary key
(No MongoDB a chave primaacuteria eacute definida
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 dinacircmicos ou seja sem a
necessidade de que cada registro tenha a mesma estrutura Estas estruturas satildeo
chamadas de coleccedilotildees (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 sobrenomeSilva idade22 bairroPituba
Outro documento para representar um aluno na mesma coleccedilatildeo
aluno2=nomeLiardquo sobrenomeSaacute cursoDireito materias[Civil Penal]
Podeshyse ter registros diferentes um do outro dentro de uma mesma coleccedilatildeo Parece
estranho este tipo de abordagem mas no modelo relacional usamos isto o tempo
inteiro e de maneira ineficiente com a formaccedilatildeo de tabelas esparsas
Estas satildeo tabelas incompletas onde algumas colunas satildeo sempre preenchidas e
outras nem sempre satildeo usadas Para ilustrar isto observe a Tabela 4 que apresenta
registros da construccedilatildeo civil
Coacutedigo Produto Altura Potecircncia Peso Diacircmetro
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1929
1 Britadeira 300cv 100kg
2 Cimento
3 Empilhadeira 15cv 300kg
4 Escada 3m
5 Tubulaccedilatildeo 20cm
Tabela 4 Cadastro de produtos da construccedilatildeo civil em banco de dados modelo
relacional
Neste exemplo haacute uma desvantagem no modelo relacional Haacute colunas cujo valor eacute
preenchido apenas uma vez como pode ser visto no exemplo das colunas Altura e
Diacircmetro Na construccedilatildeo das tabelas ao incluir colunas que satildeo pouco utilizadas
jogashyse fora espaccedilo de armazenamento e reduzshyse o desempenho do sistema como
um todo E ainda tratamos objetos diferentes como se fossem iguais o que nem
sempre eacute uma boa praacutetica Abaixo o exemplo de como ficaria este cadastro de
produtos no modelo documental
codigo1 produtoBritadeira potencia300cv peso100kg
codigo2 produtoCimento
codigo3 produtoEmpilhadeira potencia15cv peso300kg
codigo4 produtoEscada altura3m
codigo5 produtoTubulaccedilatildeo diametro20cm
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
Seratildeo apresentados agora alguns comandos comuns usados no MongoDB Voltando
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2029
ao primeiro exemplo de documento criado para alunos observe como ficaria o
comando para salvar os alunos em uma coleccedilatildeo
dbunifacssave(aluno1)
dbunifacssave(aluno2)
O comando acima salva os documentos aluno1 e aluno2 na coleccedilatildeo ldquounifacsrdquo Eacute
possiacutevel acessar os dados de uma coleccedilatildeo atraveacutes do comando find() basicamente
ele vai percorrer todos os registros da coleccedilatildeo e retornar os documentos listados No
exemplo dado o comando seria dbunifacsfind() E para apagar tudo que existe na
coleccedilatildeo dbunifacsremove()
Natildeo eacute necessaacuterio que se crie uma coleccedilatildeo ou mesmo que se configure uma estrutura
isso eacute feito automaticamente quando o primeiro registro eacute incluiacutedo No entanto eacute
possiacutevel usar o comando de criar uma coleccedilatildeo e isto pode ser utilizado para preacuteshy
atribuir espaccedilo para uma coleccedilatildeo Uma coleccedilatildeo de tamanho fixo usa o comando
ldquocappedrdquo e vem a substituir automaticamente as entradas mais antigas quando
atinge seu tamanho maacuteximo
Todas as coleccedilotildees limitadas e fixas devem especificar um tamanho maacuteximo e
tambeacutem podem especificar um nuacutemero maacuteximo de documentos O MongoDB remove
os documentos antigos se uma coleccedilatildeo atinge o limite de tamanho maacuteximo antes
que ele atinja a contagem maacutexima de documentos Considere o seguinte exemplo
dbcreateCollection (unifacs capped true size 5242880 max 5000)
Este comando cria uma coleccedilatildeo nomeada de ldquounifacsrdquo com uma dimensatildeo maacutexima
de 5 megabytes e um maacuteximo de 5000 documentos
Para visualizar todas as coleccedilotildees de um banco de dados MongoDB utilizashyse o
seguinte comando
dbgetCollectionNames()
Enfim haacute muitas diferenccedilas entre os comandos usados no MongoDB e no MySQL As
quatro operaccedilotildees baacutesicas usadas para criaccedilatildeo consulta atualizaccedilatildeo e destruiccedilatildeo de
dados conhecidas como CRUD (Create Read Update e Delete) apresentam
comandos bem distintos nos dois tipos de bancos em questatildeo A Tabela 5 compara
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2129
alguns comandos de CRUD em ambos os bancos
MySQL MongoDB
CREATE TABLE unifacs (
id MEDIUMINT NOT NULL
AUTO_INCREMENT
matricula Number
nome Varchar(30)
idade Number
PRIMARY KEY (id)
)
A coleccedilatildeo eacute criada implicitamente na primeira
inserccedilatildeo de dados O _id chave primaacuteria eacute
adicionada automaticamente se o campo _id natildeo
eacute especificado
dbunifacsinsert (
matricula 04217253
nome Paulo
idade 22
)
ALTER TABLE unifacs
ADD join_date DATETIME
Coleccedilotildees natildeo descrevem ou forccedilam a estrutura
dos seus documentos No entanto no niacutevel do
documento operaccedilotildees de update () podem
adicionar campos para documentos existentes
usando o operador $set e remover usando
$unset
dbunifacsupdate (
$set join_date new Date ()
multi true
)
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2229
ALTER TABLE unifacs
DROP COLUMN join_date
dbunifacsupdate(
$unset join_date
multi true
)
INSERT INTO unifacs (matricula nome
idade)
VALUES (032104211 ldquoJoanardquo 21)
dbunifacsinsert(
matricula 032104211 nome ldquoJoanardquo idade
21
)
SELECT FROM unifacs dbunifacsfind()
SELECT FROM unifacs WHERE idade =
21dbunifacsfind( idade 21 )
SELECT FROM unifacs WHERE nome =
ldquoJoanardquo
AND idade = 21
dbunifacsfind( nome ldquoJoanardquo idade 21 )
SELECT FROM unifacs WHERE idade gt
20dbunifacsfind( age $gt 20 )
SELECT COUNT() FROM unifacs
dbuserscount()
ou
dbunifacsfind()count()
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2329
UPDATE unifacs SET status = ldquoAprovadordquo
WHERE nota gt 7
dbunifacsupdate( nota $gt 7
$set status ldquoAprovadordquo multi true )
UPDATE unifacs SET nota = nota + 1
WHERE status = Aprovado
dbunifacsupdate( status Aprovado
$inc nota 1 multi true )
DELETE FROM unifacs WHERE status =
Reprovadodbunifacsremove( status Reprovado )
Tabela 5 Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
Eacute importante saber que cada documento de uma coleccedilatildeo no MongoDB tem um
tamanho maacuteximo de 16MB o que eacute mais do que suficiente para armazenar dados em
um documento No entanto o MongoDB ainda eacute capaz de armazenar arquivos no
banco de dados em uma coleccedilatildeo especifica que eacute a coleccedilatildeo do tipo GridFS
Ela eacute ideal para trabalhar com arquivos maiores de imagens viacutedeo e aacuteudio O GridFS
divide o arquivo em partes ou pedaccedilos e salva cada pedaccedilo em um documento
separado Quando vocecirc consulta um arquivo no GridFS eacute preciso remontar os
pedaccedilos conforme a necessidade
O MongoDB atinge o objetivo de ser amigaacutevel para o desenvolvedor Possui uma
documentaccedilatildeo bem escrita para a maioria dos principais idiomas Sua consulta
baseada em JavaScript eacute faacutecil para os desenvolvedores da Web e ele tambeacutem eacute faacutecil
de instalar Por estas razotildees o MongoDB eacute uma oacutetima opccedilatildeo de tecnologia para uso
em uma aplicaccedilatildeo
Um exemplo do sucesso deste banco eacute o depoimento do especialista em banco de
dados da Globocom Franklin Amorim Em um evento sobre o MongoDB em 2011 na
cidade de Satildeo Paulo Franklin apresentou o case de sucesso da adoccedilatildeo do MongoDB
para uma nova funccedilatildeo do ldquofantasy gamerdquo CartolaFC
O jogo eacute maior aplicaccedilatildeo dinacircmica do portal Globocom com mais de 2 milhotildees de
usuaacuterios cadastrados e quase 90 milhotildees de pageviews somente em um mecircs
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1629
seja atendida
Toleracircncia a
Particionamento
Por natildeo terem sido
construiacutedo com a finalidade
de trabalhar com
particionamento de dados
este modelo natildeo possui um
grau muito alto de toleracircncia
ao particionamento cuja
razatildeo principal seria a
dificuldade de junccedilotildees entre
as tabelas
Trabalha de forma faacutecil e
eficiente com a distribuiccedilatildeo
de dados Este modelo eacute
capaz de suportar grandes
demandas de dados assim
como possui alta toleracircncia
ao particionamento dos
mesmos
Tabela 2 Anaacutelise 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 verificaccedilatildeo contiacutenua
da consistecircncia de cada transaccedilatildeo adiciona custos consideraacuteveis para um sistema
que tem milhares de transaccedilotildees ocorrendo
A consistecircncia eventual promovida pelo modelo BASE daacute agraves organizaccedilotildees a
capacidade de interagir com os clientes de forma contiacutenua com a necessaacuteria
disponibilidade e toleracircncia a particcedilatildeo mantendo baixos custos e o sistema rodando
sem interrupccedilotildees Sem duacutevida seria excelente ter consistecircncia completa o tempo
todo mas eacute preciso haver compensaccedilotildees e a consistecircncia eventual permite o
desenvolvimento eficaz de sistemas que podem lidar com o aumento exponencial de
dados devido agraves redes sociais computaccedilatildeo em nuvem e outros projetos de Big Data
Estudo de Caso shy MongoDBPara fins comparativos seratildeo analisadas nesta seccedilatildeo algumas diferenccedilas entre um
banco NoSQL o MongoDB e os bancos relacionais baseados em SQL O MongoDB eacute
um banco de dados NoSQL criado em 2009 pela empresa 10gen orientado a
documentos altamente escalaacutevel de alta performance e de coacutedigo aberto O
cofundador e diretor de tecnologia da 10gen define o MongoDB da seguinte forma ldquoO
MongoDB natildeo foi concebido em um laboratoacuterio
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1729
Noacutes construiacutemos o MongoDB com base em nossas experiecircncias na construccedilatildeo de
sistemas robustos de grande escala e alta disponibilidade Natildeo comeccedilamos do zero
noacutes tentamos descobrir o que estava problemaacutetico e solucionamos isso
Assim o que eu penso sobre MongoDB eacute que se vocecirc pegar o MySQL e alterar o
modelo de dados do relacional para orientado a documento vocecirc ganha uma grande
quantidade de recursos documentos embarcados para melhorar velocidade
facilidade de gerenciamento desenvolvimento aacutegil com bancos de dados sem
ldquoschemardquo escalabilidade horizontal mais faacutecil pois ldquojoinsrdquo natildeo satildeo tatildeo importantes
Haacute muitas coisas que funcionam muito bem nos bancos de dados relacionais iacutendices
consultas dinacircmicas e atualizaccedilotildees e noacutes natildeo mudamos muito neste ponto Por
exemplo a maneira de projetar seus iacutendices no MongoDB deve ser exatamente do
jeito que vocecirc faz isso no MySQL ou Oracle vocecirc soacute ganha a opccedilatildeo de indexar um
campo embarcadordquo
Como dito na seccedilatildeo de modelos de bancos de dados NoSQL um banco orientado a
documentos natildeo possui esquemas riacutegidos e estruturados sendo possiacutevel que ocorra
uma atualizaccedilatildeo na estrutura do documento Portanto inserir novos campos no
documento natildeo 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 coleccedilatildeo
iacutendice iacutendice
linha documento BSON
coluna campo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1829
joins documentos incorporados e vinculaccedilatildeo
primary key
(Especifica qualquer combinaccedilatildeo de colunas
ou coluna uacutenica como chave primaacuteria)
primary key
(No MongoDB a chave primaacuteria eacute definida
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 dinacircmicos ou seja sem a
necessidade de que cada registro tenha a mesma estrutura Estas estruturas satildeo
chamadas de coleccedilotildees (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 sobrenomeSilva idade22 bairroPituba
Outro documento para representar um aluno na mesma coleccedilatildeo
aluno2=nomeLiardquo sobrenomeSaacute cursoDireito materias[Civil Penal]
Podeshyse ter registros diferentes um do outro dentro de uma mesma coleccedilatildeo Parece
estranho este tipo de abordagem mas no modelo relacional usamos isto o tempo
inteiro e de maneira ineficiente com a formaccedilatildeo de tabelas esparsas
Estas satildeo tabelas incompletas onde algumas colunas satildeo sempre preenchidas e
outras nem sempre satildeo usadas Para ilustrar isto observe a Tabela 4 que apresenta
registros da construccedilatildeo civil
Coacutedigo Produto Altura Potecircncia Peso Diacircmetro
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1929
1 Britadeira 300cv 100kg
2 Cimento
3 Empilhadeira 15cv 300kg
4 Escada 3m
5 Tubulaccedilatildeo 20cm
Tabela 4 Cadastro de produtos da construccedilatildeo civil em banco de dados modelo
relacional
Neste exemplo haacute uma desvantagem no modelo relacional Haacute colunas cujo valor eacute
preenchido apenas uma vez como pode ser visto no exemplo das colunas Altura e
Diacircmetro Na construccedilatildeo das tabelas ao incluir colunas que satildeo pouco utilizadas
jogashyse fora espaccedilo de armazenamento e reduzshyse o desempenho do sistema como
um todo E ainda tratamos objetos diferentes como se fossem iguais o que nem
sempre eacute uma boa praacutetica Abaixo o exemplo de como ficaria este cadastro de
produtos no modelo documental
codigo1 produtoBritadeira potencia300cv peso100kg
codigo2 produtoCimento
codigo3 produtoEmpilhadeira potencia15cv peso300kg
codigo4 produtoEscada altura3m
codigo5 produtoTubulaccedilatildeo diametro20cm
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
Seratildeo apresentados agora alguns comandos comuns usados no MongoDB Voltando
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2029
ao primeiro exemplo de documento criado para alunos observe como ficaria o
comando para salvar os alunos em uma coleccedilatildeo
dbunifacssave(aluno1)
dbunifacssave(aluno2)
O comando acima salva os documentos aluno1 e aluno2 na coleccedilatildeo ldquounifacsrdquo Eacute
possiacutevel acessar os dados de uma coleccedilatildeo atraveacutes do comando find() basicamente
ele vai percorrer todos os registros da coleccedilatildeo e retornar os documentos listados No
exemplo dado o comando seria dbunifacsfind() E para apagar tudo que existe na
coleccedilatildeo dbunifacsremove()
Natildeo eacute necessaacuterio que se crie uma coleccedilatildeo ou mesmo que se configure uma estrutura
isso eacute feito automaticamente quando o primeiro registro eacute incluiacutedo No entanto eacute
possiacutevel usar o comando de criar uma coleccedilatildeo e isto pode ser utilizado para preacuteshy
atribuir espaccedilo para uma coleccedilatildeo Uma coleccedilatildeo de tamanho fixo usa o comando
ldquocappedrdquo e vem a substituir automaticamente as entradas mais antigas quando
atinge seu tamanho maacuteximo
Todas as coleccedilotildees limitadas e fixas devem especificar um tamanho maacuteximo e
tambeacutem podem especificar um nuacutemero maacuteximo de documentos O MongoDB remove
os documentos antigos se uma coleccedilatildeo atinge o limite de tamanho maacuteximo antes
que ele atinja a contagem maacutexima de documentos Considere o seguinte exemplo
dbcreateCollection (unifacs capped true size 5242880 max 5000)
Este comando cria uma coleccedilatildeo nomeada de ldquounifacsrdquo com uma dimensatildeo maacutexima
de 5 megabytes e um maacuteximo de 5000 documentos
Para visualizar todas as coleccedilotildees de um banco de dados MongoDB utilizashyse o
seguinte comando
dbgetCollectionNames()
Enfim haacute muitas diferenccedilas entre os comandos usados no MongoDB e no MySQL As
quatro operaccedilotildees baacutesicas usadas para criaccedilatildeo consulta atualizaccedilatildeo e destruiccedilatildeo de
dados conhecidas como CRUD (Create Read Update e Delete) apresentam
comandos bem distintos nos dois tipos de bancos em questatildeo A Tabela 5 compara
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2129
alguns comandos de CRUD em ambos os bancos
MySQL MongoDB
CREATE TABLE unifacs (
id MEDIUMINT NOT NULL
AUTO_INCREMENT
matricula Number
nome Varchar(30)
idade Number
PRIMARY KEY (id)
)
A coleccedilatildeo eacute criada implicitamente na primeira
inserccedilatildeo de dados O _id chave primaacuteria eacute
adicionada automaticamente se o campo _id natildeo
eacute especificado
dbunifacsinsert (
matricula 04217253
nome Paulo
idade 22
)
ALTER TABLE unifacs
ADD join_date DATETIME
Coleccedilotildees natildeo descrevem ou forccedilam a estrutura
dos seus documentos No entanto no niacutevel do
documento operaccedilotildees de update () podem
adicionar campos para documentos existentes
usando o operador $set e remover usando
$unset
dbunifacsupdate (
$set join_date new Date ()
multi true
)
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2229
ALTER TABLE unifacs
DROP COLUMN join_date
dbunifacsupdate(
$unset join_date
multi true
)
INSERT INTO unifacs (matricula nome
idade)
VALUES (032104211 ldquoJoanardquo 21)
dbunifacsinsert(
matricula 032104211 nome ldquoJoanardquo idade
21
)
SELECT FROM unifacs dbunifacsfind()
SELECT FROM unifacs WHERE idade =
21dbunifacsfind( idade 21 )
SELECT FROM unifacs WHERE nome =
ldquoJoanardquo
AND idade = 21
dbunifacsfind( nome ldquoJoanardquo idade 21 )
SELECT FROM unifacs WHERE idade gt
20dbunifacsfind( age $gt 20 )
SELECT COUNT() FROM unifacs
dbuserscount()
ou
dbunifacsfind()count()
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2329
UPDATE unifacs SET status = ldquoAprovadordquo
WHERE nota gt 7
dbunifacsupdate( nota $gt 7
$set status ldquoAprovadordquo multi true )
UPDATE unifacs SET nota = nota + 1
WHERE status = Aprovado
dbunifacsupdate( status Aprovado
$inc nota 1 multi true )
DELETE FROM unifacs WHERE status =
Reprovadodbunifacsremove( status Reprovado )
Tabela 5 Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
Eacute importante saber que cada documento de uma coleccedilatildeo no MongoDB tem um
tamanho maacuteximo de 16MB o que eacute mais do que suficiente para armazenar dados em
um documento No entanto o MongoDB ainda eacute capaz de armazenar arquivos no
banco de dados em uma coleccedilatildeo especifica que eacute a coleccedilatildeo do tipo GridFS
Ela eacute ideal para trabalhar com arquivos maiores de imagens viacutedeo e aacuteudio O GridFS
divide o arquivo em partes ou pedaccedilos e salva cada pedaccedilo em um documento
separado Quando vocecirc consulta um arquivo no GridFS eacute preciso remontar os
pedaccedilos conforme a necessidade
O MongoDB atinge o objetivo de ser amigaacutevel para o desenvolvedor Possui uma
documentaccedilatildeo bem escrita para a maioria dos principais idiomas Sua consulta
baseada em JavaScript eacute faacutecil para os desenvolvedores da Web e ele tambeacutem eacute faacutecil
de instalar Por estas razotildees o MongoDB eacute uma oacutetima opccedilatildeo de tecnologia para uso
em uma aplicaccedilatildeo
Um exemplo do sucesso deste banco eacute o depoimento do especialista em banco de
dados da Globocom Franklin Amorim Em um evento sobre o MongoDB em 2011 na
cidade de Satildeo Paulo Franklin apresentou o case de sucesso da adoccedilatildeo do MongoDB
para uma nova funccedilatildeo do ldquofantasy gamerdquo CartolaFC
O jogo eacute maior aplicaccedilatildeo dinacircmica do portal Globocom com mais de 2 milhotildees de
usuaacuterios cadastrados e quase 90 milhotildees de pageviews somente em um mecircs
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1729
Noacutes construiacutemos o MongoDB com base em nossas experiecircncias na construccedilatildeo de
sistemas robustos de grande escala e alta disponibilidade Natildeo comeccedilamos do zero
noacutes tentamos descobrir o que estava problemaacutetico e solucionamos isso
Assim o que eu penso sobre MongoDB eacute que se vocecirc pegar o MySQL e alterar o
modelo de dados do relacional para orientado a documento vocecirc ganha uma grande
quantidade de recursos documentos embarcados para melhorar velocidade
facilidade de gerenciamento desenvolvimento aacutegil com bancos de dados sem
ldquoschemardquo escalabilidade horizontal mais faacutecil pois ldquojoinsrdquo natildeo satildeo tatildeo importantes
Haacute muitas coisas que funcionam muito bem nos bancos de dados relacionais iacutendices
consultas dinacircmicas e atualizaccedilotildees e noacutes natildeo mudamos muito neste ponto Por
exemplo a maneira de projetar seus iacutendices no MongoDB deve ser exatamente do
jeito que vocecirc faz isso no MySQL ou Oracle vocecirc soacute ganha a opccedilatildeo de indexar um
campo embarcadordquo
Como dito na seccedilatildeo de modelos de bancos de dados NoSQL um banco orientado a
documentos natildeo possui esquemas riacutegidos e estruturados sendo possiacutevel que ocorra
uma atualizaccedilatildeo na estrutura do documento Portanto inserir novos campos no
documento natildeo 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 coleccedilatildeo
iacutendice iacutendice
linha documento BSON
coluna campo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1829
joins documentos incorporados e vinculaccedilatildeo
primary key
(Especifica qualquer combinaccedilatildeo de colunas
ou coluna uacutenica como chave primaacuteria)
primary key
(No MongoDB a chave primaacuteria eacute definida
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 dinacircmicos ou seja sem a
necessidade de que cada registro tenha a mesma estrutura Estas estruturas satildeo
chamadas de coleccedilotildees (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 sobrenomeSilva idade22 bairroPituba
Outro documento para representar um aluno na mesma coleccedilatildeo
aluno2=nomeLiardquo sobrenomeSaacute cursoDireito materias[Civil Penal]
Podeshyse ter registros diferentes um do outro dentro de uma mesma coleccedilatildeo Parece
estranho este tipo de abordagem mas no modelo relacional usamos isto o tempo
inteiro e de maneira ineficiente com a formaccedilatildeo de tabelas esparsas
Estas satildeo tabelas incompletas onde algumas colunas satildeo sempre preenchidas e
outras nem sempre satildeo usadas Para ilustrar isto observe a Tabela 4 que apresenta
registros da construccedilatildeo civil
Coacutedigo Produto Altura Potecircncia Peso Diacircmetro
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1929
1 Britadeira 300cv 100kg
2 Cimento
3 Empilhadeira 15cv 300kg
4 Escada 3m
5 Tubulaccedilatildeo 20cm
Tabela 4 Cadastro de produtos da construccedilatildeo civil em banco de dados modelo
relacional
Neste exemplo haacute uma desvantagem no modelo relacional Haacute colunas cujo valor eacute
preenchido apenas uma vez como pode ser visto no exemplo das colunas Altura e
Diacircmetro Na construccedilatildeo das tabelas ao incluir colunas que satildeo pouco utilizadas
jogashyse fora espaccedilo de armazenamento e reduzshyse o desempenho do sistema como
um todo E ainda tratamos objetos diferentes como se fossem iguais o que nem
sempre eacute uma boa praacutetica Abaixo o exemplo de como ficaria este cadastro de
produtos no modelo documental
codigo1 produtoBritadeira potencia300cv peso100kg
codigo2 produtoCimento
codigo3 produtoEmpilhadeira potencia15cv peso300kg
codigo4 produtoEscada altura3m
codigo5 produtoTubulaccedilatildeo diametro20cm
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
Seratildeo apresentados agora alguns comandos comuns usados no MongoDB Voltando
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2029
ao primeiro exemplo de documento criado para alunos observe como ficaria o
comando para salvar os alunos em uma coleccedilatildeo
dbunifacssave(aluno1)
dbunifacssave(aluno2)
O comando acima salva os documentos aluno1 e aluno2 na coleccedilatildeo ldquounifacsrdquo Eacute
possiacutevel acessar os dados de uma coleccedilatildeo atraveacutes do comando find() basicamente
ele vai percorrer todos os registros da coleccedilatildeo e retornar os documentos listados No
exemplo dado o comando seria dbunifacsfind() E para apagar tudo que existe na
coleccedilatildeo dbunifacsremove()
Natildeo eacute necessaacuterio que se crie uma coleccedilatildeo ou mesmo que se configure uma estrutura
isso eacute feito automaticamente quando o primeiro registro eacute incluiacutedo No entanto eacute
possiacutevel usar o comando de criar uma coleccedilatildeo e isto pode ser utilizado para preacuteshy
atribuir espaccedilo para uma coleccedilatildeo Uma coleccedilatildeo de tamanho fixo usa o comando
ldquocappedrdquo e vem a substituir automaticamente as entradas mais antigas quando
atinge seu tamanho maacuteximo
Todas as coleccedilotildees limitadas e fixas devem especificar um tamanho maacuteximo e
tambeacutem podem especificar um nuacutemero maacuteximo de documentos O MongoDB remove
os documentos antigos se uma coleccedilatildeo atinge o limite de tamanho maacuteximo antes
que ele atinja a contagem maacutexima de documentos Considere o seguinte exemplo
dbcreateCollection (unifacs capped true size 5242880 max 5000)
Este comando cria uma coleccedilatildeo nomeada de ldquounifacsrdquo com uma dimensatildeo maacutexima
de 5 megabytes e um maacuteximo de 5000 documentos
Para visualizar todas as coleccedilotildees de um banco de dados MongoDB utilizashyse o
seguinte comando
dbgetCollectionNames()
Enfim haacute muitas diferenccedilas entre os comandos usados no MongoDB e no MySQL As
quatro operaccedilotildees baacutesicas usadas para criaccedilatildeo consulta atualizaccedilatildeo e destruiccedilatildeo de
dados conhecidas como CRUD (Create Read Update e Delete) apresentam
comandos bem distintos nos dois tipos de bancos em questatildeo A Tabela 5 compara
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2129
alguns comandos de CRUD em ambos os bancos
MySQL MongoDB
CREATE TABLE unifacs (
id MEDIUMINT NOT NULL
AUTO_INCREMENT
matricula Number
nome Varchar(30)
idade Number
PRIMARY KEY (id)
)
A coleccedilatildeo eacute criada implicitamente na primeira
inserccedilatildeo de dados O _id chave primaacuteria eacute
adicionada automaticamente se o campo _id natildeo
eacute especificado
dbunifacsinsert (
matricula 04217253
nome Paulo
idade 22
)
ALTER TABLE unifacs
ADD join_date DATETIME
Coleccedilotildees natildeo descrevem ou forccedilam a estrutura
dos seus documentos No entanto no niacutevel do
documento operaccedilotildees de update () podem
adicionar campos para documentos existentes
usando o operador $set e remover usando
$unset
dbunifacsupdate (
$set join_date new Date ()
multi true
)
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2229
ALTER TABLE unifacs
DROP COLUMN join_date
dbunifacsupdate(
$unset join_date
multi true
)
INSERT INTO unifacs (matricula nome
idade)
VALUES (032104211 ldquoJoanardquo 21)
dbunifacsinsert(
matricula 032104211 nome ldquoJoanardquo idade
21
)
SELECT FROM unifacs dbunifacsfind()
SELECT FROM unifacs WHERE idade =
21dbunifacsfind( idade 21 )
SELECT FROM unifacs WHERE nome =
ldquoJoanardquo
AND idade = 21
dbunifacsfind( nome ldquoJoanardquo idade 21 )
SELECT FROM unifacs WHERE idade gt
20dbunifacsfind( age $gt 20 )
SELECT COUNT() FROM unifacs
dbuserscount()
ou
dbunifacsfind()count()
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2329
UPDATE unifacs SET status = ldquoAprovadordquo
WHERE nota gt 7
dbunifacsupdate( nota $gt 7
$set status ldquoAprovadordquo multi true )
UPDATE unifacs SET nota = nota + 1
WHERE status = Aprovado
dbunifacsupdate( status Aprovado
$inc nota 1 multi true )
DELETE FROM unifacs WHERE status =
Reprovadodbunifacsremove( status Reprovado )
Tabela 5 Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
Eacute importante saber que cada documento de uma coleccedilatildeo no MongoDB tem um
tamanho maacuteximo de 16MB o que eacute mais do que suficiente para armazenar dados em
um documento No entanto o MongoDB ainda eacute capaz de armazenar arquivos no
banco de dados em uma coleccedilatildeo especifica que eacute a coleccedilatildeo do tipo GridFS
Ela eacute ideal para trabalhar com arquivos maiores de imagens viacutedeo e aacuteudio O GridFS
divide o arquivo em partes ou pedaccedilos e salva cada pedaccedilo em um documento
separado Quando vocecirc consulta um arquivo no GridFS eacute preciso remontar os
pedaccedilos conforme a necessidade
O MongoDB atinge o objetivo de ser amigaacutevel para o desenvolvedor Possui uma
documentaccedilatildeo bem escrita para a maioria dos principais idiomas Sua consulta
baseada em JavaScript eacute faacutecil para os desenvolvedores da Web e ele tambeacutem eacute faacutecil
de instalar Por estas razotildees o MongoDB eacute uma oacutetima opccedilatildeo de tecnologia para uso
em uma aplicaccedilatildeo
Um exemplo do sucesso deste banco eacute o depoimento do especialista em banco de
dados da Globocom Franklin Amorim Em um evento sobre o MongoDB em 2011 na
cidade de Satildeo Paulo Franklin apresentou o case de sucesso da adoccedilatildeo do MongoDB
para uma nova funccedilatildeo do ldquofantasy gamerdquo CartolaFC
O jogo eacute maior aplicaccedilatildeo dinacircmica do portal Globocom com mais de 2 milhotildees de
usuaacuterios cadastrados e quase 90 milhotildees de pageviews somente em um mecircs
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1829
joins documentos incorporados e vinculaccedilatildeo
primary key
(Especifica qualquer combinaccedilatildeo de colunas
ou coluna uacutenica como chave primaacuteria)
primary key
(No MongoDB a chave primaacuteria eacute definida
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 dinacircmicos ou seja sem a
necessidade de que cada registro tenha a mesma estrutura Estas estruturas satildeo
chamadas de coleccedilotildees (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 sobrenomeSilva idade22 bairroPituba
Outro documento para representar um aluno na mesma coleccedilatildeo
aluno2=nomeLiardquo sobrenomeSaacute cursoDireito materias[Civil Penal]
Podeshyse ter registros diferentes um do outro dentro de uma mesma coleccedilatildeo Parece
estranho este tipo de abordagem mas no modelo relacional usamos isto o tempo
inteiro e de maneira ineficiente com a formaccedilatildeo de tabelas esparsas
Estas satildeo tabelas incompletas onde algumas colunas satildeo sempre preenchidas e
outras nem sempre satildeo usadas Para ilustrar isto observe a Tabela 4 que apresenta
registros da construccedilatildeo civil
Coacutedigo Produto Altura Potecircncia Peso Diacircmetro
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1929
1 Britadeira 300cv 100kg
2 Cimento
3 Empilhadeira 15cv 300kg
4 Escada 3m
5 Tubulaccedilatildeo 20cm
Tabela 4 Cadastro de produtos da construccedilatildeo civil em banco de dados modelo
relacional
Neste exemplo haacute uma desvantagem no modelo relacional Haacute colunas cujo valor eacute
preenchido apenas uma vez como pode ser visto no exemplo das colunas Altura e
Diacircmetro Na construccedilatildeo das tabelas ao incluir colunas que satildeo pouco utilizadas
jogashyse fora espaccedilo de armazenamento e reduzshyse o desempenho do sistema como
um todo E ainda tratamos objetos diferentes como se fossem iguais o que nem
sempre eacute uma boa praacutetica Abaixo o exemplo de como ficaria este cadastro de
produtos no modelo documental
codigo1 produtoBritadeira potencia300cv peso100kg
codigo2 produtoCimento
codigo3 produtoEmpilhadeira potencia15cv peso300kg
codigo4 produtoEscada altura3m
codigo5 produtoTubulaccedilatildeo diametro20cm
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
Seratildeo apresentados agora alguns comandos comuns usados no MongoDB Voltando
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2029
ao primeiro exemplo de documento criado para alunos observe como ficaria o
comando para salvar os alunos em uma coleccedilatildeo
dbunifacssave(aluno1)
dbunifacssave(aluno2)
O comando acima salva os documentos aluno1 e aluno2 na coleccedilatildeo ldquounifacsrdquo Eacute
possiacutevel acessar os dados de uma coleccedilatildeo atraveacutes do comando find() basicamente
ele vai percorrer todos os registros da coleccedilatildeo e retornar os documentos listados No
exemplo dado o comando seria dbunifacsfind() E para apagar tudo que existe na
coleccedilatildeo dbunifacsremove()
Natildeo eacute necessaacuterio que se crie uma coleccedilatildeo ou mesmo que se configure uma estrutura
isso eacute feito automaticamente quando o primeiro registro eacute incluiacutedo No entanto eacute
possiacutevel usar o comando de criar uma coleccedilatildeo e isto pode ser utilizado para preacuteshy
atribuir espaccedilo para uma coleccedilatildeo Uma coleccedilatildeo de tamanho fixo usa o comando
ldquocappedrdquo e vem a substituir automaticamente as entradas mais antigas quando
atinge seu tamanho maacuteximo
Todas as coleccedilotildees limitadas e fixas devem especificar um tamanho maacuteximo e
tambeacutem podem especificar um nuacutemero maacuteximo de documentos O MongoDB remove
os documentos antigos se uma coleccedilatildeo atinge o limite de tamanho maacuteximo antes
que ele atinja a contagem maacutexima de documentos Considere o seguinte exemplo
dbcreateCollection (unifacs capped true size 5242880 max 5000)
Este comando cria uma coleccedilatildeo nomeada de ldquounifacsrdquo com uma dimensatildeo maacutexima
de 5 megabytes e um maacuteximo de 5000 documentos
Para visualizar todas as coleccedilotildees de um banco de dados MongoDB utilizashyse o
seguinte comando
dbgetCollectionNames()
Enfim haacute muitas diferenccedilas entre os comandos usados no MongoDB e no MySQL As
quatro operaccedilotildees baacutesicas usadas para criaccedilatildeo consulta atualizaccedilatildeo e destruiccedilatildeo de
dados conhecidas como CRUD (Create Read Update e Delete) apresentam
comandos bem distintos nos dois tipos de bancos em questatildeo A Tabela 5 compara
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2129
alguns comandos de CRUD em ambos os bancos
MySQL MongoDB
CREATE TABLE unifacs (
id MEDIUMINT NOT NULL
AUTO_INCREMENT
matricula Number
nome Varchar(30)
idade Number
PRIMARY KEY (id)
)
A coleccedilatildeo eacute criada implicitamente na primeira
inserccedilatildeo de dados O _id chave primaacuteria eacute
adicionada automaticamente se o campo _id natildeo
eacute especificado
dbunifacsinsert (
matricula 04217253
nome Paulo
idade 22
)
ALTER TABLE unifacs
ADD join_date DATETIME
Coleccedilotildees natildeo descrevem ou forccedilam a estrutura
dos seus documentos No entanto no niacutevel do
documento operaccedilotildees de update () podem
adicionar campos para documentos existentes
usando o operador $set e remover usando
$unset
dbunifacsupdate (
$set join_date new Date ()
multi true
)
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2229
ALTER TABLE unifacs
DROP COLUMN join_date
dbunifacsupdate(
$unset join_date
multi true
)
INSERT INTO unifacs (matricula nome
idade)
VALUES (032104211 ldquoJoanardquo 21)
dbunifacsinsert(
matricula 032104211 nome ldquoJoanardquo idade
21
)
SELECT FROM unifacs dbunifacsfind()
SELECT FROM unifacs WHERE idade =
21dbunifacsfind( idade 21 )
SELECT FROM unifacs WHERE nome =
ldquoJoanardquo
AND idade = 21
dbunifacsfind( nome ldquoJoanardquo idade 21 )
SELECT FROM unifacs WHERE idade gt
20dbunifacsfind( age $gt 20 )
SELECT COUNT() FROM unifacs
dbuserscount()
ou
dbunifacsfind()count()
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2329
UPDATE unifacs SET status = ldquoAprovadordquo
WHERE nota gt 7
dbunifacsupdate( nota $gt 7
$set status ldquoAprovadordquo multi true )
UPDATE unifacs SET nota = nota + 1
WHERE status = Aprovado
dbunifacsupdate( status Aprovado
$inc nota 1 multi true )
DELETE FROM unifacs WHERE status =
Reprovadodbunifacsremove( status Reprovado )
Tabela 5 Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
Eacute importante saber que cada documento de uma coleccedilatildeo no MongoDB tem um
tamanho maacuteximo de 16MB o que eacute mais do que suficiente para armazenar dados em
um documento No entanto o MongoDB ainda eacute capaz de armazenar arquivos no
banco de dados em uma coleccedilatildeo especifica que eacute a coleccedilatildeo do tipo GridFS
Ela eacute ideal para trabalhar com arquivos maiores de imagens viacutedeo e aacuteudio O GridFS
divide o arquivo em partes ou pedaccedilos e salva cada pedaccedilo em um documento
separado Quando vocecirc consulta um arquivo no GridFS eacute preciso remontar os
pedaccedilos conforme a necessidade
O MongoDB atinge o objetivo de ser amigaacutevel para o desenvolvedor Possui uma
documentaccedilatildeo bem escrita para a maioria dos principais idiomas Sua consulta
baseada em JavaScript eacute faacutecil para os desenvolvedores da Web e ele tambeacutem eacute faacutecil
de instalar Por estas razotildees o MongoDB eacute uma oacutetima opccedilatildeo de tecnologia para uso
em uma aplicaccedilatildeo
Um exemplo do sucesso deste banco eacute o depoimento do especialista em banco de
dados da Globocom Franklin Amorim Em um evento sobre o MongoDB em 2011 na
cidade de Satildeo Paulo Franklin apresentou o case de sucesso da adoccedilatildeo do MongoDB
para uma nova funccedilatildeo do ldquofantasy gamerdquo CartolaFC
O jogo eacute maior aplicaccedilatildeo dinacircmica do portal Globocom com mais de 2 milhotildees de
usuaacuterios cadastrados e quase 90 milhotildees de pageviews somente em um mecircs
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 1929
1 Britadeira 300cv 100kg
2 Cimento
3 Empilhadeira 15cv 300kg
4 Escada 3m
5 Tubulaccedilatildeo 20cm
Tabela 4 Cadastro de produtos da construccedilatildeo civil em banco de dados modelo
relacional
Neste exemplo haacute uma desvantagem no modelo relacional Haacute colunas cujo valor eacute
preenchido apenas uma vez como pode ser visto no exemplo das colunas Altura e
Diacircmetro Na construccedilatildeo das tabelas ao incluir colunas que satildeo pouco utilizadas
jogashyse fora espaccedilo de armazenamento e reduzshyse o desempenho do sistema como
um todo E ainda tratamos objetos diferentes como se fossem iguais o que nem
sempre eacute uma boa praacutetica Abaixo o exemplo de como ficaria este cadastro de
produtos no modelo documental
codigo1 produtoBritadeira potencia300cv peso100kg
codigo2 produtoCimento
codigo3 produtoEmpilhadeira potencia15cv peso300kg
codigo4 produtoEscada altura3m
codigo5 produtoTubulaccedilatildeo diametro20cm
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
Seratildeo apresentados agora alguns comandos comuns usados no MongoDB Voltando
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2029
ao primeiro exemplo de documento criado para alunos observe como ficaria o
comando para salvar os alunos em uma coleccedilatildeo
dbunifacssave(aluno1)
dbunifacssave(aluno2)
O comando acima salva os documentos aluno1 e aluno2 na coleccedilatildeo ldquounifacsrdquo Eacute
possiacutevel acessar os dados de uma coleccedilatildeo atraveacutes do comando find() basicamente
ele vai percorrer todos os registros da coleccedilatildeo e retornar os documentos listados No
exemplo dado o comando seria dbunifacsfind() E para apagar tudo que existe na
coleccedilatildeo dbunifacsremove()
Natildeo eacute necessaacuterio que se crie uma coleccedilatildeo ou mesmo que se configure uma estrutura
isso eacute feito automaticamente quando o primeiro registro eacute incluiacutedo No entanto eacute
possiacutevel usar o comando de criar uma coleccedilatildeo e isto pode ser utilizado para preacuteshy
atribuir espaccedilo para uma coleccedilatildeo Uma coleccedilatildeo de tamanho fixo usa o comando
ldquocappedrdquo e vem a substituir automaticamente as entradas mais antigas quando
atinge seu tamanho maacuteximo
Todas as coleccedilotildees limitadas e fixas devem especificar um tamanho maacuteximo e
tambeacutem podem especificar um nuacutemero maacuteximo de documentos O MongoDB remove
os documentos antigos se uma coleccedilatildeo atinge o limite de tamanho maacuteximo antes
que ele atinja a contagem maacutexima de documentos Considere o seguinte exemplo
dbcreateCollection (unifacs capped true size 5242880 max 5000)
Este comando cria uma coleccedilatildeo nomeada de ldquounifacsrdquo com uma dimensatildeo maacutexima
de 5 megabytes e um maacuteximo de 5000 documentos
Para visualizar todas as coleccedilotildees de um banco de dados MongoDB utilizashyse o
seguinte comando
dbgetCollectionNames()
Enfim haacute muitas diferenccedilas entre os comandos usados no MongoDB e no MySQL As
quatro operaccedilotildees baacutesicas usadas para criaccedilatildeo consulta atualizaccedilatildeo e destruiccedilatildeo de
dados conhecidas como CRUD (Create Read Update e Delete) apresentam
comandos bem distintos nos dois tipos de bancos em questatildeo A Tabela 5 compara
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2129
alguns comandos de CRUD em ambos os bancos
MySQL MongoDB
CREATE TABLE unifacs (
id MEDIUMINT NOT NULL
AUTO_INCREMENT
matricula Number
nome Varchar(30)
idade Number
PRIMARY KEY (id)
)
A coleccedilatildeo eacute criada implicitamente na primeira
inserccedilatildeo de dados O _id chave primaacuteria eacute
adicionada automaticamente se o campo _id natildeo
eacute especificado
dbunifacsinsert (
matricula 04217253
nome Paulo
idade 22
)
ALTER TABLE unifacs
ADD join_date DATETIME
Coleccedilotildees natildeo descrevem ou forccedilam a estrutura
dos seus documentos No entanto no niacutevel do
documento operaccedilotildees de update () podem
adicionar campos para documentos existentes
usando o operador $set e remover usando
$unset
dbunifacsupdate (
$set join_date new Date ()
multi true
)
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2229
ALTER TABLE unifacs
DROP COLUMN join_date
dbunifacsupdate(
$unset join_date
multi true
)
INSERT INTO unifacs (matricula nome
idade)
VALUES (032104211 ldquoJoanardquo 21)
dbunifacsinsert(
matricula 032104211 nome ldquoJoanardquo idade
21
)
SELECT FROM unifacs dbunifacsfind()
SELECT FROM unifacs WHERE idade =
21dbunifacsfind( idade 21 )
SELECT FROM unifacs WHERE nome =
ldquoJoanardquo
AND idade = 21
dbunifacsfind( nome ldquoJoanardquo idade 21 )
SELECT FROM unifacs WHERE idade gt
20dbunifacsfind( age $gt 20 )
SELECT COUNT() FROM unifacs
dbuserscount()
ou
dbunifacsfind()count()
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2329
UPDATE unifacs SET status = ldquoAprovadordquo
WHERE nota gt 7
dbunifacsupdate( nota $gt 7
$set status ldquoAprovadordquo multi true )
UPDATE unifacs SET nota = nota + 1
WHERE status = Aprovado
dbunifacsupdate( status Aprovado
$inc nota 1 multi true )
DELETE FROM unifacs WHERE status =
Reprovadodbunifacsremove( status Reprovado )
Tabela 5 Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
Eacute importante saber que cada documento de uma coleccedilatildeo no MongoDB tem um
tamanho maacuteximo de 16MB o que eacute mais do que suficiente para armazenar dados em
um documento No entanto o MongoDB ainda eacute capaz de armazenar arquivos no
banco de dados em uma coleccedilatildeo especifica que eacute a coleccedilatildeo do tipo GridFS
Ela eacute ideal para trabalhar com arquivos maiores de imagens viacutedeo e aacuteudio O GridFS
divide o arquivo em partes ou pedaccedilos e salva cada pedaccedilo em um documento
separado Quando vocecirc consulta um arquivo no GridFS eacute preciso remontar os
pedaccedilos conforme a necessidade
O MongoDB atinge o objetivo de ser amigaacutevel para o desenvolvedor Possui uma
documentaccedilatildeo bem escrita para a maioria dos principais idiomas Sua consulta
baseada em JavaScript eacute faacutecil para os desenvolvedores da Web e ele tambeacutem eacute faacutecil
de instalar Por estas razotildees o MongoDB eacute uma oacutetima opccedilatildeo de tecnologia para uso
em uma aplicaccedilatildeo
Um exemplo do sucesso deste banco eacute o depoimento do especialista em banco de
dados da Globocom Franklin Amorim Em um evento sobre o MongoDB em 2011 na
cidade de Satildeo Paulo Franklin apresentou o case de sucesso da adoccedilatildeo do MongoDB
para uma nova funccedilatildeo do ldquofantasy gamerdquo CartolaFC
O jogo eacute maior aplicaccedilatildeo dinacircmica do portal Globocom com mais de 2 milhotildees de
usuaacuterios cadastrados e quase 90 milhotildees de pageviews somente em um mecircs
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2029
ao primeiro exemplo de documento criado para alunos observe como ficaria o
comando para salvar os alunos em uma coleccedilatildeo
dbunifacssave(aluno1)
dbunifacssave(aluno2)
O comando acima salva os documentos aluno1 e aluno2 na coleccedilatildeo ldquounifacsrdquo Eacute
possiacutevel acessar os dados de uma coleccedilatildeo atraveacutes do comando find() basicamente
ele vai percorrer todos os registros da coleccedilatildeo e retornar os documentos listados No
exemplo dado o comando seria dbunifacsfind() E para apagar tudo que existe na
coleccedilatildeo dbunifacsremove()
Natildeo eacute necessaacuterio que se crie uma coleccedilatildeo ou mesmo que se configure uma estrutura
isso eacute feito automaticamente quando o primeiro registro eacute incluiacutedo No entanto eacute
possiacutevel usar o comando de criar uma coleccedilatildeo e isto pode ser utilizado para preacuteshy
atribuir espaccedilo para uma coleccedilatildeo Uma coleccedilatildeo de tamanho fixo usa o comando
ldquocappedrdquo e vem a substituir automaticamente as entradas mais antigas quando
atinge seu tamanho maacuteximo
Todas as coleccedilotildees limitadas e fixas devem especificar um tamanho maacuteximo e
tambeacutem podem especificar um nuacutemero maacuteximo de documentos O MongoDB remove
os documentos antigos se uma coleccedilatildeo atinge o limite de tamanho maacuteximo antes
que ele atinja a contagem maacutexima de documentos Considere o seguinte exemplo
dbcreateCollection (unifacs capped true size 5242880 max 5000)
Este comando cria uma coleccedilatildeo nomeada de ldquounifacsrdquo com uma dimensatildeo maacutexima
de 5 megabytes e um maacuteximo de 5000 documentos
Para visualizar todas as coleccedilotildees de um banco de dados MongoDB utilizashyse o
seguinte comando
dbgetCollectionNames()
Enfim haacute muitas diferenccedilas entre os comandos usados no MongoDB e no MySQL As
quatro operaccedilotildees baacutesicas usadas para criaccedilatildeo consulta atualizaccedilatildeo e destruiccedilatildeo de
dados conhecidas como CRUD (Create Read Update e Delete) apresentam
comandos bem distintos nos dois tipos de bancos em questatildeo A Tabela 5 compara
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2129
alguns comandos de CRUD em ambos os bancos
MySQL MongoDB
CREATE TABLE unifacs (
id MEDIUMINT NOT NULL
AUTO_INCREMENT
matricula Number
nome Varchar(30)
idade Number
PRIMARY KEY (id)
)
A coleccedilatildeo eacute criada implicitamente na primeira
inserccedilatildeo de dados O _id chave primaacuteria eacute
adicionada automaticamente se o campo _id natildeo
eacute especificado
dbunifacsinsert (
matricula 04217253
nome Paulo
idade 22
)
ALTER TABLE unifacs
ADD join_date DATETIME
Coleccedilotildees natildeo descrevem ou forccedilam a estrutura
dos seus documentos No entanto no niacutevel do
documento operaccedilotildees de update () podem
adicionar campos para documentos existentes
usando o operador $set e remover usando
$unset
dbunifacsupdate (
$set join_date new Date ()
multi true
)
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2229
ALTER TABLE unifacs
DROP COLUMN join_date
dbunifacsupdate(
$unset join_date
multi true
)
INSERT INTO unifacs (matricula nome
idade)
VALUES (032104211 ldquoJoanardquo 21)
dbunifacsinsert(
matricula 032104211 nome ldquoJoanardquo idade
21
)
SELECT FROM unifacs dbunifacsfind()
SELECT FROM unifacs WHERE idade =
21dbunifacsfind( idade 21 )
SELECT FROM unifacs WHERE nome =
ldquoJoanardquo
AND idade = 21
dbunifacsfind( nome ldquoJoanardquo idade 21 )
SELECT FROM unifacs WHERE idade gt
20dbunifacsfind( age $gt 20 )
SELECT COUNT() FROM unifacs
dbuserscount()
ou
dbunifacsfind()count()
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2329
UPDATE unifacs SET status = ldquoAprovadordquo
WHERE nota gt 7
dbunifacsupdate( nota $gt 7
$set status ldquoAprovadordquo multi true )
UPDATE unifacs SET nota = nota + 1
WHERE status = Aprovado
dbunifacsupdate( status Aprovado
$inc nota 1 multi true )
DELETE FROM unifacs WHERE status =
Reprovadodbunifacsremove( status Reprovado )
Tabela 5 Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
Eacute importante saber que cada documento de uma coleccedilatildeo no MongoDB tem um
tamanho maacuteximo de 16MB o que eacute mais do que suficiente para armazenar dados em
um documento No entanto o MongoDB ainda eacute capaz de armazenar arquivos no
banco de dados em uma coleccedilatildeo especifica que eacute a coleccedilatildeo do tipo GridFS
Ela eacute ideal para trabalhar com arquivos maiores de imagens viacutedeo e aacuteudio O GridFS
divide o arquivo em partes ou pedaccedilos e salva cada pedaccedilo em um documento
separado Quando vocecirc consulta um arquivo no GridFS eacute preciso remontar os
pedaccedilos conforme a necessidade
O MongoDB atinge o objetivo de ser amigaacutevel para o desenvolvedor Possui uma
documentaccedilatildeo bem escrita para a maioria dos principais idiomas Sua consulta
baseada em JavaScript eacute faacutecil para os desenvolvedores da Web e ele tambeacutem eacute faacutecil
de instalar Por estas razotildees o MongoDB eacute uma oacutetima opccedilatildeo de tecnologia para uso
em uma aplicaccedilatildeo
Um exemplo do sucesso deste banco eacute o depoimento do especialista em banco de
dados da Globocom Franklin Amorim Em um evento sobre o MongoDB em 2011 na
cidade de Satildeo Paulo Franklin apresentou o case de sucesso da adoccedilatildeo do MongoDB
para uma nova funccedilatildeo do ldquofantasy gamerdquo CartolaFC
O jogo eacute maior aplicaccedilatildeo dinacircmica do portal Globocom com mais de 2 milhotildees de
usuaacuterios cadastrados e quase 90 milhotildees de pageviews somente em um mecircs
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2129
alguns comandos de CRUD em ambos os bancos
MySQL MongoDB
CREATE TABLE unifacs (
id MEDIUMINT NOT NULL
AUTO_INCREMENT
matricula Number
nome Varchar(30)
idade Number
PRIMARY KEY (id)
)
A coleccedilatildeo eacute criada implicitamente na primeira
inserccedilatildeo de dados O _id chave primaacuteria eacute
adicionada automaticamente se o campo _id natildeo
eacute especificado
dbunifacsinsert (
matricula 04217253
nome Paulo
idade 22
)
ALTER TABLE unifacs
ADD join_date DATETIME
Coleccedilotildees natildeo descrevem ou forccedilam a estrutura
dos seus documentos No entanto no niacutevel do
documento operaccedilotildees de update () podem
adicionar campos para documentos existentes
usando o operador $set e remover usando
$unset
dbunifacsupdate (
$set join_date new Date ()
multi true
)
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2229
ALTER TABLE unifacs
DROP COLUMN join_date
dbunifacsupdate(
$unset join_date
multi true
)
INSERT INTO unifacs (matricula nome
idade)
VALUES (032104211 ldquoJoanardquo 21)
dbunifacsinsert(
matricula 032104211 nome ldquoJoanardquo idade
21
)
SELECT FROM unifacs dbunifacsfind()
SELECT FROM unifacs WHERE idade =
21dbunifacsfind( idade 21 )
SELECT FROM unifacs WHERE nome =
ldquoJoanardquo
AND idade = 21
dbunifacsfind( nome ldquoJoanardquo idade 21 )
SELECT FROM unifacs WHERE idade gt
20dbunifacsfind( age $gt 20 )
SELECT COUNT() FROM unifacs
dbuserscount()
ou
dbunifacsfind()count()
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2329
UPDATE unifacs SET status = ldquoAprovadordquo
WHERE nota gt 7
dbunifacsupdate( nota $gt 7
$set status ldquoAprovadordquo multi true )
UPDATE unifacs SET nota = nota + 1
WHERE status = Aprovado
dbunifacsupdate( status Aprovado
$inc nota 1 multi true )
DELETE FROM unifacs WHERE status =
Reprovadodbunifacsremove( status Reprovado )
Tabela 5 Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
Eacute importante saber que cada documento de uma coleccedilatildeo no MongoDB tem um
tamanho maacuteximo de 16MB o que eacute mais do que suficiente para armazenar dados em
um documento No entanto o MongoDB ainda eacute capaz de armazenar arquivos no
banco de dados em uma coleccedilatildeo especifica que eacute a coleccedilatildeo do tipo GridFS
Ela eacute ideal para trabalhar com arquivos maiores de imagens viacutedeo e aacuteudio O GridFS
divide o arquivo em partes ou pedaccedilos e salva cada pedaccedilo em um documento
separado Quando vocecirc consulta um arquivo no GridFS eacute preciso remontar os
pedaccedilos conforme a necessidade
O MongoDB atinge o objetivo de ser amigaacutevel para o desenvolvedor Possui uma
documentaccedilatildeo bem escrita para a maioria dos principais idiomas Sua consulta
baseada em JavaScript eacute faacutecil para os desenvolvedores da Web e ele tambeacutem eacute faacutecil
de instalar Por estas razotildees o MongoDB eacute uma oacutetima opccedilatildeo de tecnologia para uso
em uma aplicaccedilatildeo
Um exemplo do sucesso deste banco eacute o depoimento do especialista em banco de
dados da Globocom Franklin Amorim Em um evento sobre o MongoDB em 2011 na
cidade de Satildeo Paulo Franklin apresentou o case de sucesso da adoccedilatildeo do MongoDB
para uma nova funccedilatildeo do ldquofantasy gamerdquo CartolaFC
O jogo eacute maior aplicaccedilatildeo dinacircmica do portal Globocom com mais de 2 milhotildees de
usuaacuterios cadastrados e quase 90 milhotildees de pageviews somente em um mecircs
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2229
ALTER TABLE unifacs
DROP COLUMN join_date
dbunifacsupdate(
$unset join_date
multi true
)
INSERT INTO unifacs (matricula nome
idade)
VALUES (032104211 ldquoJoanardquo 21)
dbunifacsinsert(
matricula 032104211 nome ldquoJoanardquo idade
21
)
SELECT FROM unifacs dbunifacsfind()
SELECT FROM unifacs WHERE idade =
21dbunifacsfind( idade 21 )
SELECT FROM unifacs WHERE nome =
ldquoJoanardquo
AND idade = 21
dbunifacsfind( nome ldquoJoanardquo idade 21 )
SELECT FROM unifacs WHERE idade gt
20dbunifacsfind( age $gt 20 )
SELECT COUNT() FROM unifacs
dbuserscount()
ou
dbunifacsfind()count()
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2329
UPDATE unifacs SET status = ldquoAprovadordquo
WHERE nota gt 7
dbunifacsupdate( nota $gt 7
$set status ldquoAprovadordquo multi true )
UPDATE unifacs SET nota = nota + 1
WHERE status = Aprovado
dbunifacsupdate( status Aprovado
$inc nota 1 multi true )
DELETE FROM unifacs WHERE status =
Reprovadodbunifacsremove( status Reprovado )
Tabela 5 Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
Eacute importante saber que cada documento de uma coleccedilatildeo no MongoDB tem um
tamanho maacuteximo de 16MB o que eacute mais do que suficiente para armazenar dados em
um documento No entanto o MongoDB ainda eacute capaz de armazenar arquivos no
banco de dados em uma coleccedilatildeo especifica que eacute a coleccedilatildeo do tipo GridFS
Ela eacute ideal para trabalhar com arquivos maiores de imagens viacutedeo e aacuteudio O GridFS
divide o arquivo em partes ou pedaccedilos e salva cada pedaccedilo em um documento
separado Quando vocecirc consulta um arquivo no GridFS eacute preciso remontar os
pedaccedilos conforme a necessidade
O MongoDB atinge o objetivo de ser amigaacutevel para o desenvolvedor Possui uma
documentaccedilatildeo bem escrita para a maioria dos principais idiomas Sua consulta
baseada em JavaScript eacute faacutecil para os desenvolvedores da Web e ele tambeacutem eacute faacutecil
de instalar Por estas razotildees o MongoDB eacute uma oacutetima opccedilatildeo de tecnologia para uso
em uma aplicaccedilatildeo
Um exemplo do sucesso deste banco eacute o depoimento do especialista em banco de
dados da Globocom Franklin Amorim Em um evento sobre o MongoDB em 2011 na
cidade de Satildeo Paulo Franklin apresentou o case de sucesso da adoccedilatildeo do MongoDB
para uma nova funccedilatildeo do ldquofantasy gamerdquo CartolaFC
O jogo eacute maior aplicaccedilatildeo dinacircmica do portal Globocom com mais de 2 milhotildees de
usuaacuterios cadastrados e quase 90 milhotildees de pageviews somente em um mecircs
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2329
UPDATE unifacs SET status = ldquoAprovadordquo
WHERE nota gt 7
dbunifacsupdate( nota $gt 7
$set status ldquoAprovadordquo multi true )
UPDATE unifacs SET nota = nota + 1
WHERE status = Aprovado
dbunifacsupdate( status Aprovado
$inc nota 1 multi true )
DELETE FROM unifacs WHERE status =
Reprovadodbunifacsremove( status Reprovado )
Tabela 5 Comparativo de alguns exemplos de comandos CRUD em ambos os
bancos
Eacute importante saber que cada documento de uma coleccedilatildeo no MongoDB tem um
tamanho maacuteximo de 16MB o que eacute mais do que suficiente para armazenar dados em
um documento No entanto o MongoDB ainda eacute capaz de armazenar arquivos no
banco de dados em uma coleccedilatildeo especifica que eacute a coleccedilatildeo do tipo GridFS
Ela eacute ideal para trabalhar com arquivos maiores de imagens viacutedeo e aacuteudio O GridFS
divide o arquivo em partes ou pedaccedilos e salva cada pedaccedilo em um documento
separado Quando vocecirc consulta um arquivo no GridFS eacute preciso remontar os
pedaccedilos conforme a necessidade
O MongoDB atinge o objetivo de ser amigaacutevel para o desenvolvedor Possui uma
documentaccedilatildeo bem escrita para a maioria dos principais idiomas Sua consulta
baseada em JavaScript eacute faacutecil para os desenvolvedores da Web e ele tambeacutem eacute faacutecil
de instalar Por estas razotildees o MongoDB eacute uma oacutetima opccedilatildeo de tecnologia para uso
em uma aplicaccedilatildeo
Um exemplo do sucesso deste banco eacute o depoimento do especialista em banco de
dados da Globocom Franklin Amorim Em um evento sobre o MongoDB em 2011 na
cidade de Satildeo Paulo Franklin apresentou o case de sucesso da adoccedilatildeo do MongoDB
para uma nova funccedilatildeo do ldquofantasy gamerdquo CartolaFC
O jogo eacute maior aplicaccedilatildeo dinacircmica do portal Globocom com mais de 2 milhotildees de
usuaacuterios cadastrados e quase 90 milhotildees de pageviews somente em um mecircs
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2429
A ideia da aplicaccedilatildeo era criar uma espeacutecie de ldquotwitterrdquo para os usuaacuterios do jogo com
a finalidade de promover uma maior interaccedilatildeo entre os usuaacuterios aleacutem de aumentar o
seu tempo de permanecircncia no site
Na Globocom a maioria dos projetos satildeo em banco de dados relacional poreacutem
resolveram tentar algo novo para o CartolaFC jaacute que em alguns testes de
performance as vantagens do MongoDB foram mais atrativas do que o MySQL Nos
testes realizados pela equipe da Globo conseguiushyse 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 abstraccedilotildees
de tabelas foi considerado atrativo pelos desenvolvedores Natildeo possuir schema
tambeacutem foi fator de vantagem pela flexibilidade dos documentos criados E o fato de
o sistema estar sempre ativo devido ao ldquoFailoverrdquo automaacutetico que manteacutem o sistema
sempre disponiacutevel e a possibilidade de escalar escritas com Sharding foram outros
fatores que levaram a equipe a escolher o MongoDB para a aplicaccedilatildeo
A partir desta experiecircncia de sucesso outros projetos na Globocom passaram a usar
o MongoDB Atualmente temshyse o receitascom e o novo cataacutelogo de viacutedeos da
emissora que possui cerca de 800 mil arquivos cadastrados
Este artigo discutiu as soluccedilotildees NoSQL como modelo de banco de dados em cenaacuterios
onde escalabilidade eacute a questatildeo principal O objetivo foi mostrar aos mais
conservadores a existecircncia de uma tecnologia que pode ser uma alternativa ao
tradicional modelo relacional O desenvolvedor precisa portanto observar o cenaacuterio
em que estaacute trabalhando para tomar uma decisatildeo coerente de qual modelo de banco
de dados deve usar
No cenaacuterio atual da Web 20 Big Data computaccedilatildeo em nuvem e redes sociais os
modelos tradicionais para gerenciamento de dados tecircm apresentado limitaccedilotildees
principalmente no quesito escalabilidade e assim o NoSQL surgiu como opccedilatildeo
Atualmente podemos observar grandes empresas e negoacutecios de escala global
fazendo uso dessa tecnologia Como jaacute citado como exemplos o Cassandra eacute usado
no Facebook e Twitter e o MongoDB estaacute em uso no Foursquare SourceForge e na
Globocom Isto eacute um indicativo de que esse tipo de tecnologia certamente natildeo seraacute
descartada facilmente como um modismo
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2529
Gostei (12) (0)
O que vocecirc achou deste post
Postar duacutevida Comentaacuterio
O NoSQL natildeo eacute uma tecnologia de banco de dados totalmente nova e haacute indiacutecios de
que seu futuro eacute bastante promissor Ela oferece a possibilidade e flexibilidade de
manipulaccedilatildeo de dados semiestruturados complexos e otimiza soluccedilotildees para
diferentes tipos de dados nesta era da computaccedilatildeo em larga escala Este artigo
buscou fomentar um estudo sobre o NoSQL e mostrar a necessidade de um maior
conhecimento das tecnologias disponiacuteveis como soluccedilatildeo no quesito banco de dados
DevMedia
A DevMedia eacute um portal para analistas desenvolvedores de sistemas gerentes e DBAs com milhares deartigos dicas cursos e videoaulas gratuitos e exclusivos para assinantes
Todos os comentarios (2)Meus comentarios
Rafael Dantas Silva
Achei o artigo excelente Parabeacutens No entanto gostaria de tirar 3 duacutevidas
1ordm) Eacute possiacutevel criar um coleccedilatildeo com atributos obrigatoacuterios Ex Colocar como obrigatoacuterio o
preenchimento dos atributos matricula e nome na coleccedilatildeo [unifacs]
2ordm) Na modelagem NoSQL Documental eacute possiacutevel criar relacionamentos Algo similar a uma FK
3ordm) Todos os artigos que vejo sobre NoSQL sempre satildeo com o foco em Desenvolvimento Gostaria
de saber mais a respeito das tarefas administrativas necessaacuterias para um BD desse tipo Em um
Banco SQL precisamos coletar estatiacutesticas realizar rebuild de iacutendices desfragmentaccedilatildeo de
segmentos Quais tarefas administrativas satildeo necessaacuterias em um BD NoSQL
[haacute +1 mecircs] shy Responder
Daniella Adriana Da Costa
Olaacute Rafael
conforme vc jaacute enviou feedback para o autor vamos postar abaixo a mesma resposta dada
por ele para as suas duacutevidas
Andreacute
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2629
Parabeacutens mais uma vez pelo bom trabalho e pelo empenho e proatividade em esclarecer as
duacutevidas Vou ler os links que vocecirc enviou com calma
Rafael Dantas
[RESPOSTA DO AUTOR]
Olaacute Rafael Dantas
Fico contente de ter gostado do artigo
A pesquisa que realizei foi bem focada em fazer uma comparaccedilatildeo entre os modelos
portanto natildeo busquei e nem me preocupei com algumas outras demandas da aacuterea
Tentei dar uma pesquisada no assunto sobre as perguntas feitas
1shy No desenvolvimento do meu artigo ao estudar o mongo e o NoSQL em si natildeo observei
em nenhum dos artigos que utilizei como referecircncia um relato de possibilidade de tornar
um atributo obrigatoacuterio Pesquisando sobre o assunto vejo que haacute gem de mapeamento
objetoshydocumento usadas pra acessar o MongoDB como Mongoose e MongoID e nelas haacute
a possibilidade de usar um validador para verificar se um campo foi definido antes de
salvaacuteshylo e tambeacutem eacute possiacutevel definir um campo como obrigatoacuterio na definiccedilatildeo de esquema
(httpstackoverflowcomquestions17943609canshyishyrequireshyanshyattributeshytoshybeshysetshyinshyashy
mongodbshycollectionshynotshynull)
2shy Uma diferenccedila fundamental entre os dois modelos surge quando precisamos criar
relacionamentos nos bancos de dados relacionais diferente dos bancos orientados a
documentos que natildeo fornecem relacionamentos entre documentos o que manteacutem seu
design sem esquemas
Leia mais em Introduccedilatildeo ao MongoDB httpwwwdevmediacombrintroducaoshyaoshy
mongodb30792ixzz3A0lWPu00
No entanto buscando sobre o assunto vi que haacute a possibilidade de criar algum tipo de
relacionamento quando se usa uma gem como o Mongoid
httpmongoidorgenmongoiddocsrelationshtml
3shy Os bancos de dados NoSQL satildeo caracterizados por afastar a complexidade dos bancos
SQL A loacutegica de validaccedilatildeo controle de acesso mapeamento de consultas de dados
indexados correlaccedilatildeo entre os dados relacionados resoluccedilatildeo de conflitos manutenccedilatildeo de
restriccedilotildees de integridade (constraint) e procedimentos engatilhados satildeo movidos para
fora da camada de banco de dados Isto permite o foco em performance e escalabilidade
Uma das grandes vantagens da arquitetura NoSQL eacute que a loacutegica pode ser codificada em
qualquer linguagem de programaccedilatildeo ao inveacutes de depender da grande variedade de APIs
complexas em um servidor SQL
4shy Sobre as tarefas administrativas natildeo achei nada a respeito Vi que no proacuteprio site do
Mongodb haacute um serviccedilo de gerenciamento httpsmmsmongodbcom
Espero ter ajudado
Att
Andreacute Simotildees
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2729
[haacute +1 mecircs] shy Responder
Serviccedilos
Inclua um comentaacuterio
Adicionar aos Favoritos
Marcar como lidoassistido
Incluir anotaccedilatildeo pessoal
Versatildeo para impressatildeo
+SQL
Mais postsVideo aula
Terceira Forma Normal - Curso Modelagem de Dados - Aula 26
Video aula
Aplicaccedilotildees da Segunda Forma Normal - Curso Modelagem deDados - Aula 25
Video aula
Segunda Forma Normal - Curso Modelagem de Dados - Aula
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2829
24
Video aula
Primeira Forma Normal - Curso Modelagem de Dados - Aula 23
Video aula
Normalizaccedilatildeo e Anomalias - Curso Modelagem de Dados -Aula 22
Video aula
Dependecircncias Funcionais - Curso Modelagem de Dados - Aula21
Video aula
MySQL Administrador - Curso Completo de MySQL - Aula 16
Video aula
Ferramentas e Utilitaacuterios - Curso Completo de MySQL - Aula 15
Video aula
Mais sobre o Prompt de Comando - Curso Completo deMySQL - Aula 14
Listar mais conteuacutedo
Anuncie | Loja | Publique | Assine | Fale conosco
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
08042015 Comparando o NoSQL ao modelo relacional
httpwwwdevmediacombrcomparandoshyoshynosqlshyaoshymodeloshyrelacional30917 2929
Hospedagem web por Porta 80 Web Hosting
DevMediaVocecirc curtiu isso
Vocecirc e outras 63895 pessoas curtiram DevMedia
Plugshyin social do Facebook
Curtir
