Rascunho_Introduction_referenciar_corretamente
Os bancos de dados NoSQL oferecem algumas funcionalidades a mais que os bancos de dados relacionais tradicionais.
Neste capítulo introdutório faremos uma comparação de uso dos NoSQL SGBDs em comparação com os SGBDs relacionais.
Sistemas de Gerenciamento de bancos de dados
Os SGBDs são espaços logicamente modelados para armazenar todos os tipos de informação. Cada banco de dados possui uma estrutura na qual os dados são gerenciados com diversos formatos, tipos e tamanhos. Segundo Navathe
SGBDs NoSQL
Bases de dados relacionais tem sido a escolha padrão de muitos desenvolvedores e administradores para uma ampla variedade de aplicações e razões. apesar de não ser exatamente flexivel, o poder natural
==============================
Principais diferêncas entre bancos de dados NoSQL e SQL.
NoSQL
SQL
Modelo
Não relacional
Relacional
Armazena dados em documentos JSON, pares de chave/valor, grandes colunas de armazenamento, ou grafos
Armazena dados em tabelas
Dados
Oferece flexibilidade e registros não precisam armazenar as mesmas propriedades
Melhor para soluções onde cada registro tem as mesmas propriedades
Novas propriedades podem ser adicionadas sem alterações no esquema ("on the fly")
Adicionar uma nova propriedade pode requerer alterações no schema ou até mesmo utilizar campos existentes para armazenar dados novos
Relacionamentos são frequentemente obtidos por dados desnormalizados e apresentando todos dados por meio de um único objeto em um único registro
Relacionamentos são obtidos em modelos normalizados usando junções e usando-se de referências (chaves primárias e estrangeiras) entre as tabelas
bom para dados aninhados, semi-estruturados e complexos
bom para dados estruturados
Esquema
Esquemas dinâmicos ou flexíveis
Esquemas rígidos/rigorosos
Bancos de dados possui um esquema não definido sendo o esquema ditado pela aplicação
Esquema deve ser gerenciado e mantida a sincronia estrutural entre aplicação e o banco de dados
Transações
Transações ACID suportadas por várias soluções (mas não todas)
Suporta transações ACID
Consistência e Disponibilidade
Eventualmente forte consistência é suportada dependendo da solução
Forte consistência é obrigatória (forçada)
Consistência, disponibilidade e performance podem ser tratadas para encontrar as necessidades da aplicação. (Teoria de CAP*)
Consistência é priorizada sobre disponibilidade e performance
Performance
Performance pode ser maximizada pela redução de consistência, se necessário.
A performance do Insert e update são dependentes de quão rápida a escrita é confirmada (committed), visto que forte consistência e requerida. Desempenho pode ser maximizado pelo uso de escalonamento de recursos disponíveis e uso de estruturas na memória
Toda informação sobre uma entidade está tipicamente em um único registro, então uma atualização pode acontecer em uma única operação
Informação sobre uma entidade pode estar espalhada entre muitas tabelas ou linhas, requerendo muitas junções para completar uma atualização ou consulta
Scale
Escalamento é tipicamente alcançado horizontalmente com particionamento de dados em vários servidores
Escalonamento é tipicamente alcançado verticalmente com mais recursos do servidor
Objetos
Entidade/Tabela
Coleção
Instâncias da entidade/Linhas/Registros
Documentos
colunas da tabela/atributos státicos
atributos flexiveis (em NoSQL são criados de acordo com os dados de modo flexivel). Isto torna possível ter um uma mesma coleção um documento com 10 atributos e outro com 4 atributos por exemplo.
Obs: Teoria de CAP*
Eric Brewer afirma que é impossível em um armazenamento de dados distribuídos simultaneamente fornecer mais de duas das seguintes garantias:
Consistência: cada leitura recebe a gravação mais recente ou um erro.
Disponibilidade: cada pedido recebe uma resposta (sem erro), mas sem garantia de que contém a gravação mais recente.
Tolerância de partição: o sistema continua a funcionar apesar de um número arbitrário de mensagens sendo descartadas (ou atrasadas) pela rede entre nós.
Ou seja num sistema tolerante a falhas é preciso escolher entre consistência e disponibilidade.
Exemplo de flexibilidade dos bancos NoSQL
Em uma abordagem onde trabalhamos com vários produtos diferentes, é necessário no modelo relacional que tenhamos uma tabela produto com as mesmas características para todos os produtos. Já nos databases NoSQL cada produto pode ter sua características peculiares armazendas sem quaisquer dificuldades ou problemas. Outra característica interessante é que para um mesmo atributo podemos ter domínios diferentes (String para um determinado registro/documento do atributo e integer para outro registro/documento do mesmo atributo), isto poderia ocorrer em situações onde vários fabricantes de produtos são cadastrados e cada um tem seu pŕoprio código, por exemplo. Outro ponto em que os NoSQL divergem dos SQL Relacionais tradicionais é que não é necessário o uso de Joins e restrições de chave primária e estrangeira, pois os dados são tratados de forma diferenciada.
Figura 1. Relacionamento clássico entre usuários e habilidades (Fonte: Devmedia.com)
Figura 2. Representação do relacionamento entre usuários e habilidades em um grafo (fonte: Devmedia.com)
Figura 3. Exemplo de um relacionamento tradicional versus representação NoSQL embutido no formato JSON das entidades Book Album, Jeans e Track (fonte: Devmedia.com).
Observe que cada tipo de produto no formato JSON possui características diferentes details.
É certo que cada tipo de modelagem possui pontos fortes e fracos. Os Modelos NoSQL tem sido bastante utilizados em cenários onde o algoritmo percorre um grafo ou rotina recursiva para chegar até um nível específico de dados dentro de vários documentos, e portanto aplicados em situações de modelagem com dados provenientes de redes sociais, relacionamentos entre pessoas, objetos, situações, eventos, preferências e comportamentos.
Exemplos de SQL comparados com MongoDB
SQL
a) select * from tabela where nome LIKE '%Nasc%'
b) select * from usuarios where UsuarioID IN (2,14,16)
c) insert into usuario(login, email) VALUES('sissa', 'jnascimento@gmail.com')
d) update tarefas set Tarefa='Terminar artigo' where Usuario='suissa'
e) delete tarefas where name='suissa'
MongoDB
a) $filter = array( 'title' => new MongoRegex('/.Nasc./i') );
b) $filter = array("UsuarioID" => array('$in' => array(2,14,16)));
c) $query = array( 'usuario' => "suissa", 'email' => "jnascimento@gmail.com");
d) $db->collection->update(array('Usuario'=> 'suissa'), array('$set' => array('Tarefa' => 'Terminar artigo')));
e) $db->collection->remove(array('Usuario'=> 'suissa'));
Last updated
Was this helpful?
