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