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:

1. Consistência: cada leitura recebe a gravação mais recente ou um erro.

2. Disponibilidade: cada pedido recebe uma resposta (sem erro), mas sem garantia de que contém a gravação mais recente.

3. 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', '[e-mail]')

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' => "[e-mail]");

$db->collection->insert\($this->query\);

d) $db->collection->update(array('Usuario'=> 'suissa'), array('$set' => array('Tarefa' => 'Terminar artigo')));

e) $db->collection->remove(array('Usuario'=> 'suissa'));

References:


https://docs.microsoft.com/pt-br/azure/documentdb/documentdb-nosql-vs-sql
http://www.devmedia.com.br/modelagem-sql-x-nosql/29446
https://imasters.com.br/artigo/17308/mongodb/como-utilizar-selects-com-mongodb?trace=1519021197&source=single