Marcio Victorino. Análise de Informações TCU - TI

Transcrição

1 1 Análise de Informações TCU - TI

2 2

3 3 Bibliografia Essencial Martin Fowler ACM. IEEE.

4 4 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ãoestruturados disponíveis.

5 5 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).

6 Escalabilidade: Horizontal (ir para fora). Vertical (ir para cima). 6

7 7 Incompatibilidade de impedância:

8 8 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.

9 O termo "" 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. 9

10 10 O uso do termo 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.

11 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 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. 11

12 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. 12

13 13 Modelo de Dados Agregados:

14 14 Modelo de Dados Agregados:

15 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. 15

16 16 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.

17 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. 17

18 18 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.

19 19 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).

20 20 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.

21 Transações: Normalmente os SGBDs orientados a agregados não suportam transações ACID. Os SGBDs 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). 21

22 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). 22

23 23 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).

24 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. 24

25 25 ACID x BASE: BASE - Basically Available, Soft state, Eventual consistency. SGBDs 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 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.

26 Relaxamento da Durabilidade em SGBDs : 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. 26

27 27 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.

28 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. 28

29 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. 29

30 30 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.

31 31 Banco de Dados de Chave-Valor

32 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.

33 33 BD Chave-Valor São os depósitos de dados 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.

34 34 BD Chave-Valor Riak. Redis. MemcachedDB. HamsterDB. AmazonDynamoDB.

35 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.

36 36 Banco de Dados de Documentos

37 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.

38 38 BD de Documentos MomgoDB. CouchDB. RavenDB.

39 39 BD de Documentos 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.

40 40 Banco de Dados de Família de Colunas

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. 41

42 BD Família de Colunas 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. 42

43 43 BD Família de Colunas Cassandra. Hbase. Hypertable. Amazon SimpleDB.

44 44 BD Família de Colunas 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.

45 45 Banco de Dados de Grafos

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. 46

47 47 BD de Grafos

48 BD de Grafos 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. 48

49 49 BD de Grafos Neo4J. Infinite Graph.

50 50 BD de Grafos 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.

51 51 Fim