Você está na página 1de 25
Aula 01 - Apresentação da Disciplina e NoSQL
Aula 01 - Apresentação da Disciplina e NoSQL
Aula 01 - Apresentação da
Disciplina e NoSQL
Aula 01 - Apresentação da Disciplina e NoSQL
Aula 01 - Apresentação da Disciplina e NoSQL
Aula 01 - Apresentação da Disciplina e NoSQL
Roteiro
Roteiro

Objetivo da Disciplina

Relacional Vs Não Relacional

Persistência poliglota

Armazenamento em Documentos

Armazenamento Colunar

Armazenamento Chave-Valor

Arquitetura em Grafos

Time-series

Multi-modelo

Objetivo da Disciplina
Objetivo da Disciplina

Esta disciplina visa introduzir novos modelos de organização de dados. Estudando e desenvolvendo projetos utilizando ferramentas que aplicam os conceitos de banco de dados não relacionais. Analisando as diferenças, vantagens e desvantagens da estruturação de dados em forma de documentos e arquivos.

Além de aprofundar os conhecimentos da disciplina de Banco de Dados I e ter uma visão geral de banco de dados não-relacionais, banco de dados orientados a documentos, estrutura de arquivos e de armazenamento, banco de dados chave-valor e novas aplicações de banco de dados.

Relacional Vs Não Relacional
Relacional Vs Não Relacional

O termo banco de dados NoSQL vem do inglês Not Only SQL (Não Apenas SQL) e refere-se a todos os banco de dados Não-Relacionais existentes. O nome é uma tentativa de descrever o surgimento de vários novos banco de dados que não tinham a preocupação de fornecer garantias de Atomicidade, Consistência, Isolamento e Durabilidade (ACID), características presentes em qualquer banco de dados relacional.

Consistência , Isolamento e Durabilidade (ACID) , características presentes em qualquer banco de dados relacional. 4
Banco de Dados
Banco de Dados

Considere uma caixa de ferramentas com alicate, martelo e chave de fenda, qual é a melhor ferramenta de todas?

e chave de fenda, qual é a melhor ferramenta de todas? Caixa de Ferramentas A resposta

Caixa de Ferramentas

A resposta mais coerente é: depende. Se você tem de apertar um parafuso, a chave de fenda. Quando tem de pregar um prego, o martelo. Para cada atividade, existe uma ferramenta adequada.

Persistência Poliglota
Persistência Poliglota

NoSQL não é melhor que SQL

SQL não não é melhor que NoSQL.

Um martelo não é, necessariamente, melhor que uma chave de fenda.

Persistência Poliglota: Diferentes bancos de dados são desenhados e utilizados em conjunto para resolver diversos problemas. (Sadalage e Fowler, 2013).

OBS: Existem diversos cenários em que você DEVE usar bancos SQL tradicionais, seja por questões legais (auditorias, certificações ou necessidades mais elementares).

Passo 1: entenda o seu problema
Passo 1: entenda o seu problema

Está com problema de performance no banco SQL?

Já pensou em fazer um upgrade no servidor?

Botar mais memória, um SSD?

Em muitos casos, isso é mais fácil, rápido e mais barato do que migrar todo o banco para um NoSQL.

Muitas vezes você vai trocar problemas antigos por problemas novos, em uma ferramenta que pode ser nova para a equipe.

Passo 2: analise as opções
Passo 2: analise as opções

Existem dezenas de bancos NoSQL no mercado, porque existem dezenas de problemas de persistência de dados que o SQL tradicional não resolve.

Aqui segue algumas classificações utilizadas nos bancos NoSQL:

1. Armazenamento em Documentos

2. Armazenamento Colunar

3. Armazenamento Chave-Valor

4. Arquitetura em Grafos

5. Time-series

6. Multi-modelo

1. Armazenamento em Documentos
1. Armazenamento em Documentos

Estes são os mais comuns e mais proeminentes de todos, sendo o seu maior expoente o banco MongoDB.

Definição (Orientado a documentos): coleções de documentos, nas quais cada documento é autossuficiente, contém todos os dados que possa precisar, ao invés do conceito de não repetição + chaves estrangeiras do modelo relacional.

 

A ideia é que não tenha de fazer JOINs, pois eles prejudicam muito

a performance em suas queries (são um mal necessário no modelo

relacional). Vai uma vez no banco e com apenas uma chave primária pega tudo que precisa.

Custo: armazenamento em disco. Não é raro bancos MongoDB consumirem muitas vezes mais disco do que suas contrapartes relacionais.

1.1 Quando usar o MongoDB
1.1 Quando usar o MongoDB

Quando o seu schema é variável, é livre. Os documentos BSON (semelhante ao JSON) do Mongo são schema-less e aceitam quase qualquer coisa que você quiser armazenar, sendo um mecanismo

de persistência perfeito para uso com tecnologias que trabalham com JSON nativamente, como Javascript.

de persistência perfeito para uso com tecnologias que trabalham com JSON nativamente, como Javascript. Documento JSON
Documento JSON
Documento JSON
1.2 Quando NÃO usar o MongoDB
1.2 Quando NÃO usar o MongoDB

Quando relacionamentos entre diversas entidades são importantes ao sistema.

Se for necessário usar chave estrangeiras e JOINs no MongoDB é porque algo deve estar errado.

Ler este post sobre:

1.3 Outros exemplos Documents DBs
1.3 Outros exemplos Documents DBs

RethinkDB (https://www.rethinkdb.com/)

RavenDB (https://ravendb.net/)

Elasticsearch (https://www.elastic.co/)

2. Armazenamento Colunar
2. Armazenamento Colunar

O maior expoente nesta categoria é o Cassandra, criado pelo Facebook. A maior rede social do mundo rapidamente percebeu que manter uma base de 1.5 bi de usuários criando milhares de registros todos os dias (likes, posts, fotos, amizades, etc) e depois ter de consultar tudo isso de maneira rápida e coerente, fazendo muitas agregações, não era uma tarefa que cabia aos bancos relacionais.

não era uma tarefa que cabia aos bancos relacionais. Enquanto um banco de dados relacional é

Enquanto um banco de dados relacional é otimizado para armazenar linhas de dados, geralmente para aplicativos transacionais, um banco de dados colunar é otimizado para recuperação rápida de colunas de dados, normalmente em aplicativos analíticos. O armazenamento orientado a colunas para tabelas do banco de dados é um fator importante para a performance de consulta analítica, pois ele reduz expressivamente os requisitos gerais de E/S de disco e diminui a quantidade de dados que você precisa carregar do disco.

aumentar a escala horizontal

clusters distribuídos de hardware de baixo

Fonte: https://aws.amazon.com/pt/nosql/columnar/

de baixo ● data warehousing e processamento de big data . Fonte: https://aws.amazon.com/pt/nosql/columnar/ 13

13

2.1 Quando utilizar o Cassandra?
2.1 Quando utilizar o Cassandra?
● Quando existe muitas operações de agregação nas colunas. ● GROUP BY do SQL tradicional
● Quando existe muitas operações de agregação nas colunas.
● GROUP BY do SQL tradicional também tem um custo alto.

Quando não usar? Quando for necessário que as consultas retornem dados completos, ao invés de apenas informações colunares

14

3. Armazenamento chave-valor
3. Armazenamento chave-valor
Estes bancos não-relacionais são o mais distante que você pode imaginar de um “banco de
Estes bancos não-relacionais são o mais distante que
você pode imaginar de um “banco de dados”, por isso
que chamamos de mecanismos de persistência de dados,
ao invés de “banco”. Vamos pegar como exemplo o
Redis, o mais famoso mecanismo de chave-valor da
atualidade.
o mais famoso mecanismo de chave-valor da atualidade. Aqui temos uma arquitetura baseada em coleções de

Aqui temos uma arquitetura baseada em coleções de chaves. Cada registro possui uma única chave, até aqui tudo normal, mas cada chave está associada a um valor, que pode ser um valor literal, atômico, ou um objeto mais complexo, não importa. É um índice, geralmente sendo usado memory-only, mas que pode ser híbrido também (disco e memória).

15

3.1 Quando usar o Redis?
3.1 Quando usar o Redis?

Quando você precisa subir um índice em memória que seja estupidamente rápido, que permita queries complexas baseadas na teoria dos conjuntos e que, após essa consulta no índice, você vá usar alguma outra base de dados com os dados completos do(s) registro(s) que está buscando.

Quando não preciso?

Você não deve usar como único mecanismo de persistência na sua aplicação, pois se subir todos os seus dados para um Redis memória você não terá alguns benefícios de outros modelos e gastará muito, mas muito dinheiro, pagando por memória RAM (muito mais cara que SSDs, por exemplo). Use-o como cache de índices. Ponto.

4. Arquitetura em Grafos
4. Arquitetura em Grafos

Indicado quando precisamos de relacionamentos complexos ou relacionamentos com propriedades

As tabelas meios não fazem isso?

Fazem porém não é uma solução muito boa devido ao uso aumentado de JOINs.

Ex.:

O que acontece se a relação entre o registro do Huguinho e do Zezinho tiver o tempo que eles são amigos, o grau de parentesco entre ambos, ou pior, os filmes que eles gostam em comum ou os amigos que possuem em comum? Como fazer isso com um banco relacional?

4. Arquitetura em Grafos
4. Arquitetura em Grafos

Neo4J é o banco orientado a grafos mais famoso

4. Arquitetura em Grafos Neo4J é o banco orientado a grafos mais famoso 18

18

4.1 Quando eu preciso de um Neo4J?
4.1 Quando eu preciso de um Neo4J?

Quando seus relacionamentos possuem características próprias e você terá de fazer consultas complexas baseadas nessas características e ordená-las pela proximidade de um registro do outro no mapa de relacionamentos (grafo) deles. Mais resumidamente: você desenha seu problema como um grafo? Pode ser uma boa considerar o Neo4J.

5. Time-series
5. Time-series

Estes bancos são muito específicos para o problema de retornar séries de dados baseados em intervalos de tempo. Mas não estou falando de qualquer série de dados, mas um volume muito grande, como dados estatísticos e métricas analíticas que são capturadas e consultadas a todo instante. E quando falo a todo instante, quero dizer tempo-real.

analíticas que são capturadas e consultadas a todo instante. E quando falo a todo instante, quero

20

6. Multi-modelo
6. Multi-modelo

Bancos multi-modelo estão cada vez mais poderosos e famosos.

Desde add-ons de implementações tradicionais como MySQL + Memcached ou Oracle 12c + Oracle NOSQL até bancos NOSQL inovadores como o OrientDB(documento + grafos), ArangoDB (document, grafo e chave-valor) e CouchBase (relacional + document + chave-valor).

Persistência Poliglota na Programação?
Persistência Poliglota na Programação?

Não é uma coisa simples de se fazer

Primeiro e mais importante conceito é a separação de camadas. Você irá precisar isolar completamente sua camada de dados e abstrair completamente os diversos mecanismos sob uma única biblioteca de classes de entidades, para que as camadas superiores à de dados não tenham de lidar com complexidade alguma de dados.

Algumas abordagens:

ESB + SOA

Casos de Uso
Casos de Uso

E-commerce e redes sociais.

O Grupo B2W, o maior grupo do Brasil neste segmento, com sites como Shoptime, Submarino e Americanas.com usam persistência poliglota em sua arquitetura. Eles usam:

entidade-relacional: dados dos clientes, informações de pagamento, transações, etc, toda a parte mais crítica e sensível dos dados, até por uma questão legal para poderem ter certificados de segurança e confiabilidade e poderem oferecer bandeiras como VISA e Master aos clientes.

document-based: catálogo de produtos. Como cada categoria de produto possuem características completamente diferentes das outras categorias (tente montar uma tabela ER onde você possa salvar vestuário e eletrônicos juntos…), o modelo de documentos JSON schemaless é perfeito pra isso. Também é muito comum usarem mecanismos focados em busca como Elasticsearch para que a pesquisa

do site seja rápida e eficiente.

Casos de Uso
Casos de Uso

key-value: carrinho de compras. Até que o cliente da compra seja identificado e a compra finalizada, essa informação não precisa estar no banco de dados, pois é temporária. Sendo assim, manter esses dados em memória é uma opção muito mais rápida do que ir no disco cada vez que o cliente indeciso mudar de opinião.

grafo: produtos relacionados, recomendações, upsell, cross-sell, etc. Cada produto se relaciona a outros produtos de diversas maneiras: seja por características semelhantes, seja porque são complementares, seja porque são comprados frequentemente em conjunto, etc. Guardar e consultar todas essas variáveis é dificílimo em um ER e importantíssimo para aumentar o ticket de venda, fidelizar clientes, maximizar o ROI, etc.

https://db-engines.com/en/ranking 25

https://db-engines.com/en/ranking

25