1

Análise de Informações

Marcio Victorino

TCU - TI

2

NoSQL

Marcio Victorino

3

Bibliografia

Marcio Victorino

NoSQL Essencial – Martin Fowler.

http://nosql-database.org/

http://hadoop.apache.org/

http://bigdatauniversity.com/

http://bigdataprojects.org/

ACM.

IEEE.

4

NoSQL

Sofisticação crescente dos serviços disponibilizados na web: – Facebook, uma rede social com mais de 1 bilhão

de usuários; – Google, um serviço de busca com mais de 190

milhões de visitantes únicos por mês; – Amazon, uma loja de varejo on-line com picos

que chegam a mais de 1 milhão de transações por segundo.

O grande desafio: armazenar, recuperar e processar, de forma eficaz, a grande quantidade de dados estruturados e não-estruturados disponíveis.

Marcio Victorino

5

NoSQL

Necessidades: processar o volume crescente de dados;

esquemas flexíveis;

maior distribuição do processamento;

flexibilização das estruturas de armazenamento desses dados;

escalabilidade horizontal;

minimizar a incompatibilidade de impedância;

lidar com documentos XML e JSON (JavaScript Object Notation).

Marcio Victorino

6

NoSQL

Escalabilidade:

Horizontal (ir para fora).

Vertical (ir para cima).

Marcio Victorino

7

NoSQL

Incompatibilidade de impedância:

Marcio Victorino

8

NoSQL

Para atender a essas novas demandas surgiu uma nova geração de bancos de dados sem esquemas rígidos baseados em modelos não-relacionais, chamados bancos de dados NoSQL.

Marcio Victorino

9

NoSQL O termo "NoSQL" foi utilizado pela primeira vez em 1990

por Carlo Strozzi para designer um BD relacional de código aberto que armazenava suas tabelas sob a forma de arquivos ASCII, e cada tupla era representada por uma linha com os campos separados por tabulação.

O nome vem do fato de que o BD não utilizava SQL como linguagem de consulta. Em vez disso, ele era manipulado por shell scripts.

Apenas em 2011 esse termo passou a representar uma família de bancos de dados que podem ser categorizados nos seguintes modelos: grafos, documentos, família de colunas e par chave/valor.

Marcio Victorino

10

NoSQL O uso do termo “NoSQL” como conhecemos hoje é

resultado de uma reunião realizada no dia 11 de julho de 2009, em São Francisco, organizada por Johan Oskarsson.

Surgiu como um hashtag para o Twitter: curto, fácil de lembrar e sem muitos semelhantes no Google.

O autor não esperava que se tornasse o nome da tendência tecnológica, pois o nome não descreve verdadeiramente esses sistemas.

Marcio Victorino

11

NoSQL

Características dos SGBDs: Não utilizam o SQL (possuem linguagens semelhantes).

Geralmente são projetos de código aberto.

A maioria dos BDs é orientada pela necessidade de execução em clusters.

Oferecem uma gama de opções para consistência e distribuição.

Não possuem esquemas rígidos.

Obs: Alguns autores alegam que “NoSQL” significa “Not Only SQL”. No

entanto Fowler alega que, nesse caso, a escrita correta seria “NOSQL” . Além disso, essa definição causaria uma grande confusão, pois o Oracle e o Postgres se enquadrariam nela.

Marcio Victorino

12

NoSQL Modelo de Dados Agregados:

É um conjunto de objetos relacionados que desejamos tratar como uma unidade. É uma unidade de manipulação de dados e gerenciamento de consistência.

Possuem uma estrutura mais complexa que um conjunto de tuplas.

Auxilia a execução em um cluster. Não possuem transações ACID que se

espalham por múltiplos agregados. Suportam manipulação atômica em um único

agregado por vez. Exemplos: modelo de dados chave/valor, de

documentos e família de colunas. Marcio Victorino

13

NoSQL Modelo de Dados Agregados:

Marcio Victorino

14

NoSQL Modelo de Dados Agregados:

Marcio Victorino

15

NoSQL

Esquemas: Esses SGBDs não utilizam esquemas.

O armazenamento torna-se muito mais informal.

Facilidade de lidar com dados não uniformes.

Cada registro contém apenas o necessário.

Transfere o esquema para o código do aplicativo.

Marcio Victorino

16

NoSQL Visão Materializada:

Esse SGBDs não possuem visões tal como os bancos relacionais. No entanto, eles podem ter consultas pré-computadas, postas em cache, reutilizando o termo “visão materializada” para descrevê-las.

Uteis quando se pretende consolidar dados existentes em vários agregados.

Existem duas abordagens: antecipada: a tabela e a visão são atualizadas

simultaneamente.

em intervalos regulares: é determinado um intervalo de tempo entre as atualizações da visão.

Marcio Victorino

17

NoSQL

Modelos de Distribuição:

Replicação: obtém os mesmos dados e os copia em múltiplos nodos (mestre escravo e p2p).

Fragmentação: coloca dados diferente em nodos diferentes.

São duas técnicas ortogonais: pode-se utilizar cada uma ou ambas.

Marcio Victorino

18

NoSQL Replicação Mestre escravo:

Replica os dados em múltiplos nodos.

Um nodo é designado como o mestre, ou primário, o qual é a fonte oficial dos dados e, geralmente, fica responsável por processar quaisquer atualizações nesses dados.

Os demais nodos são escravos, ou secundários.

Um processo de replicação sincroniza os escravos com o mestre.

É mais útil para a escalabilidade quando há um conjunto de dados com muitas leituras.

Caso o mestre falhe, os escravos ainda podem lidar com as solicitações de leitura (resiliência de leitura).

Os mestres podem ser designados manual ou automaticamente.

Pode causar inconsistência de leitura, caso todos os escravos não estejam sincronizados.

Ajuda com a escalabilidade de leitura, mas não com a de gravação.

Marcio Victorino

19

NoSQL Replicação ponto a ponto (p2p):

Não possui um mestre.

Todas as réplicas têm o mesmo peso.

Todas as réplicas podem receber gravações.

A perda de algumas réplicas não impede o acesso ao armazenamento de dados.

Pode adicionar facilmente novos nodos para melhorar o seu desempenho.

Pode gerar gravações inconsistentes.

Um bom ponto de partida para a replicação p2p é ter uma replicação de fator 3 (três cópias de cada fragmento).

Marcio Victorino

20

NoSQL Consistência de Replicação:

Garante que o mesmo item de dados tenha o mesmo valor lido a partir de diferentes réplicas.

Eventualmente consistente: em algum momento, todos os nodos podem ter inconsistência de replicação, mas, se não houver mais atualizações, todos os nodos acabarão atualizados com o mesmo valor.

Postagem de comentários em blog.

Marcio Victorino

21

NoSQL Transações:

Normalmente os SGBDs NoSQL orientados a agregados não suportam transações ACID.

Os SGBDs NoSQL orientados a agregados suportam transações atômicas, mas apenas dentro de um único agregado.

Uma alteração que afete múltiplos agregados deixa aberto um período de tempo no qual os clientes poderiam executar uma leitura inconsistente (janela de inconsistência, no SimpleDB da Amazon < 1seg).

Marcio Victorino

22

NoSQL Transações:

SGBDs orientado a grafos suportam transações ACID.

Abordagens otimistas detectam conflitos e os resolvem.

Abordagens pessimistas bloqueiam os registros para evitar conflitos.

Abordagens pessimistas, muitas vezes, degradam severamente a capacidade de resposta de um sistema em um nível que se torna inapropriado para o seu propósito (programação concorrente).

Marcio Victorino

23

NoSQL Teorema CAP:

Dadas três propriedades, Consistência, Disponibilidade (Availability) e de Particionamento, somente é possível obter duas delas.

Disponibilidade: se for possível coversar com um nodo do cluster, então pode-se ler e gravar.

Tolerância a partições:o cluster pode suportar falhas na comunicação que o dividam em múltiplas partições incapazes de se comunicar entre si, situação conhecida como divisão cerebral (split brain).

Marcio Victorino

24

NoSQL Teorema CAP:

Servidor único: possui Consistência e Disponibilidade, mas não possui Particionamento.

Embora o teorema CAP seja, muitas vezes, declarado como “só pode ter dois dos três”, na prática ele afirma que, em um sistema que possa sofrer partições, como os sistemas distribuídos, você tem que balancear a consistência com disponibilidade. Nesse caso, o sistema resultante não seria nem perfeitamente consistente nem perfeitamente disponível, mas teria uma combinação razoável para suas necessidades específicas.

Marcio Victorino

25

NoSQL ACID x BASE:

BASE - Basically Available, Soft state, Eventual consistency.

SGBDs NoSQL seguem as propriedades BASE. Não há definição consensual para “basicamente disponível” nem para “estado soft”.

Consistência eventual significa que, em algum momento, todos os nodos em um sistema NoSQL podem ter inconsistências de replicação, mas, se não houver mais atualizações, todos os nodos acabarão atualizados com o mesmo valor.

BASE é um acrônimo artificial. Há um balanceamento entre ACID e BASE, não são

uma escolha binária.

Marcio Victorino

26

NoSQL Relaxamento da Durabilidade em SGBDs

NoSQL: Há casos em que se deseja trocar um pouco de

durabilidade por desempenho melhor. O estado de seção de usuários podem ser não

duráveis em troca de uma maior responsividade do web site.

O banco de dados é executado, em sua maior parte, em memória e de tempos em tempos as atualizações são salvas em disco. Neste caso, se o servidor falhar dados serão perdidos.

Uma falha na durabilidade da replicação ocorre quando um nodo processa uma atualização, mas falha antes que essa atualização seja replicada para os outros nodos.

Marcio Victorino

27

NoSQL Quórum de gravação:

No caso de dados replicados em três nodos, não é necessário que todos eles reconheçam uma gravação para assegurar alta consistência, apenas dois deles, a maioria, já é o suficiente.

W > N/2: o número de nodos participantes da gravação (W) deve ser maior do que a metade do número de nodos envolvidos na replicação. O número de réplicas, muitas vezes, é chamado de fator de replicação.

Quórum de leitura: Depende de quantos nodos precisam confirmar uma

gravação. Pode-se ter leituras fortemente consistentes, mesmo sem

ter alta consistência de gravações. Leitura altamente consistente: R + W > N.

Marcio Victorino

28

NoSQL

Marcador de Versão:

Consiste de um campo que muda a cada vez que os dados subjacentes no registro sejam alterados.

A versão deve ser anotada durante a leitura do dado, de modo, que quando for gravar dados possa verificar se a versão sofreu alterações.

Marcio Victorino

29

NoSQL Marcador de Versão:

Há diversas formas de criar marcadores de versão: Contador: precisam de um único servidor mestre

para garantir unicidade. Permite descobrir qual versão é mais recente.

GUID: grande número aleatório com a garantia de que seja único, utiliza combinações de fontes aleatórias. São grandes e não podem ser comparados diretamente para saber qual é o mais recente.

Hash: pode ser criado a partir do dados armazenado. São grandes e não podem ser comparados diretamente para saber qual é o mais recente.

Timestamp: são razoavelmente curtos e podem ser comparados para descobrir qual é o mais recente.

Marcio Victorino

30

NoSQL

Marcador de Versão em múltiplos nodos: Um único mestre: contador.

Múltiplos mestres: marcador vetorial. Consiste de um conjunto de contadores,

um para cada nodo.

Um contador para três nodos seria similar a [n1: 45, n2: 54, n3: 29].

Cada vez que um nodo sofre uma atualização interna, ele atualiza o seu próprio contador.

Marcio Victorino

31

Banco de Dados de Chave-Valor

Marcio Victorino

32

BD Chave-Valor Um depósito chave-valor é uma tabela

hash simples, utilizada principalmente quando todo o acesso ao BD é feito por meio da chave primária.

Equivale a uma tabela em um SGBDR tradicional com duas colunas, ID e Nome, sendo a coluna ID a chave e a coluna Nome, Armazenando o Valor.

Se um ID já existir, o Valor atual é sobrescrito, caso contrário, cria-se um novo registro.

Marcio Victorino

33

BD Chave-Valor São os depósitos de dados NoSQL mais

simples de utilizar da perspectiva de uma API.

O valor é um dado que o depósito apenas armazena, sem se preocupar ou saber seu conteúdo. É responsabilidade do aplicativo entender o que foi armazenado. O valor pode ser blob, texto, JSON, XML, etc.

O acesso sempre é feito pela chave e, por isso, esses BDs geralmente apresentam um ótimo desempenho e escalabilidade.

Marcio Victorino

34

BD Chave-Valor

Riak.

Redis.

MemcachedDB.

HamsterDB.

AmazonDynamoDB.

Marcio Victorino

35

BD Chave-Valor Todos os armazenamentos de chave-valor só

podem ser consultados pela chave.

Muito utilizados para armazenar: – dados de sessão;

– dados de carrinhos de compras;

– perfis de usuário.

Não deve ser utilizado: – Quando houver relacionamentos entre os dados;

– Transações com várias chaves de uma vez;

– Consulta por dados.

Marcio Victorino

36

Banco de Dados de Documentos

Marcio Victorino

37

BD de Documentos

Os documentos armazenados podem ser JSON, BSON, XML, entre outros.

Os documentos armazenados são semelhantes entre si, mas não têm de ser exatamente os mesmos.

Armazenam documentos na parte do valor do armazenamento de chave-valor. Nesses bancos a parte valor pode ser consultada.

A chave pode ser atribuída pelo usuário, desde que seja única.

Marcio Victorino

38

MomgoDB.

CouchDB.

RavenDB.

BD de Documentos

Marcio Victorino

39

Muito utilizados para armazenar: – Registro de eventos (log);

– Sistemas gerenciadores de conteúdo;

– Blog;

– Análises web em tempo real;

– Comércio eletrônico.

Não deve ser utilizado: – Transações com vários documentos de uma vez;

– Consulta em estruturas agregadas variáves.

BD de Documentos

Marcio Victorino

40

Banco de Dados de Família de Colunas

Marcio Victorino

41

BD Família de Colunas Permitem o armazenamento de dados com chaves

mapeadas para valores, e os valores são agrupados em múltiplas famílias de colunas, cada uma dessas famílias de colunas funcionando como um mapa de dados.

Famílias de colunas são grupos de dados relacionados que, frequentemente, são acessados juntos.

Marcio Victorino

42

Cada família de colunas pode ser comparada a um contêiner de linhas em uma tabela de SGBDR, onde a chave identifica a linha, que é constituída de múltiplas colunas.

Linhas diferentes não precisam possuir as mesmas colunas, e novas colunas podem ser adicionadas a qualquer linha, a qualquer momento, sem a obrigatoriedade de ter de adicioná-las às outras linhas também.

Famílias de colunas são eficazes para manter dados relacionados agrupados.

BD Família de Colunas

Marcio Victorino

43

Cassandra.

Hbase.

Hypertable.

Amazon SimpleDB.

BD Família de Colunas

Marcio Victorino

44

Muito utilizados para armazenar: – Registro de eventos (log);

– Sistemas gerenciadores de conteúdo;

– Blog;

– Contadores (visitante de paginas);

– Uso expirado (banners).

Não deve ser utilizado: – Transações ACID;

– Consulta em estruturas agregadas variáveis.

BD Família de Colunas

Marcio Victorino

45

Banco de Dados de Grafos

Marcio Victorino

46

BD de Grafos

Armazenam entidades e relacionamento entre essas entidades.

Entidades são nós que possuem propriedades.

Relacionamento são arestas que podem possuir várias propriedades.

As arestas possuem significado direcional.

Uma consulta é conhecida como travessia do grafo.

Não há limites para o número e tipos de relacionamento que um nodo pode ter.

Não são orientados a agregados.

Marcio Victorino

47

BD de Grafos

Marcio Victorino

48

Operam em nodos conectados, então, a maioria dos BDs, geralmente, não suporta a distribuição de nodos em servidores diferentes.

Há algumas soluções que suportam a distribuição de nodos em um cluster de servidores.

Podem ser compatíveis com as propriedades ACID (Neo4J).

Por serem orientados a relacionamentos, sua fragmentação é difícil.

BD de Grafos

Marcio Victorino

49

Neo4J.

Infinite Graph.

BD de Grafos

Marcio Victorino

50

Muito utilizados para armazenar:

– Redes sociais;

– Roteamento, envio e serviços baseados em localização;

–Mecanismos de recomendação;

Não deve ser utilizado:

–Quando é comum se alterar propriedades em todas as entidades do domínio modelado.

BD de Grafos

Marcio Victorino

51

Fim

Marcio Victorino