SGBD NoSQL. Débora Souza in940

Transcrição

1 SGBD NoSQL Débora Souza in940

2 Roteiro Introdução Motivação O que é NoSQL? Modelos de dados NoSQL Chave-valor Colunas Documentos Grafos Quem usa que modelo de dados? Como escolher um modelo? Teorema CAP Persistência Poliglota Alguns SGBDs NoSQL Desafios de Pesquisa

3 Introdução Banco de Dados Relacionais tem sido o amplamente adotados desde a década de 70. Bem sucedidos! Contudo, devemos nos fazer algumas perguntas: Que tipos de aplicações tínhamos na década de 70? Volume de dados produzido?

4 Introdução E hoje, com as novas gerações de aplicações? Cloud Computing Web 2.0 Redes Sociais Business Intelligence

5 Introdução (exemplo) Retirado de: Visto em: 19/05/2016.

6 Motivação Várias das novas gerações de aplicações requerem o armazenamento e processamento de um grande montante de dados (tera/peta bytes). O processamento e armazenamento de dados tem-se tornado cada vez mais complexo: Big Data

7 Motivação Por que BDs Relacionais não são adequado para armazenamento de dados de qualquer tipo de aplicação? Baseados em estruturas que permite relacionar informações de diferentes tabelas. Esquema estático. Usa linguagem de consulta padrão. Trabalha com dados estruturados. Não trabalha bem com escalamento horizontal. ACID (Atomicidade, Consistência, Isolamento e Durabilidade)

8 NoSQL Not only SQL. O que é NoSQL? Uma nova variedade de bancos de dados que não seguem o Modelo Relacional. O termo NoSQL foi primeiramente usado informalmente em Strozzi em Apresenta: Flexibilidade Ausência de esquema

9 O que é NoSQL? NoSQL não diz respeito a um modelo de dados específico. Agrupamento de alguns modelos de dados que se distanciam da abordagem relacional. Tais modelos podem ser código-aberto, distribuídos, horizontalmente escaláveis.

10 O que é NoSQL? Desenvolvidos para solucionar problemas tais como: manipulação de dados como o gerenciamento de grandes bases de dados demandas por alta disponibilidade possibilidade de escalar para proporções maiores Fornece sistema BASE (Basically Available, Soft State, Eventual consistent)

11 Chave-valor Modelos de dados NoSQL Colunas Modelos de dados Documentos Grafos

12 Chave-valor Dentre os sistemas de bancos de dados conhecidos como NoSQL, o Chave-valor é o que apresenta o modelo mais simples. Sua estrutura é composta por uma chave e um valor. Esse modelo pode ser comparado com a estrutura de dados Tabela Hash.

13 Além dos tipos básicos de dados como numerais e cadeias de caracteres, algumas soluções desse modelo de banco de dados permitem listas e conjuntos de valores dos tipos básicos. Chave-valor Não costuma permitir que consultas sejam realizadas sobre os seus dados, apenas sobre as chaves. O que o modelo chave valor não grupa dados por entidades (tabelas), tão pouco por diferentes tipos (coluna).

14 Chave-valor Exemplo:

15 Chave-valor Algumas características: Não é possível a definição de um esquema. Formado por uma única tabela composta por duas colunas: uma correspondente à chave e a outra ao valor associado. A chave precisa ser única. O valor da chave é definida pelo usuário. Não são agrupados por tipos de dados. Os dados estão armazenados em uma única coluna de uma mesma tabela.

16 Algumas características (cont.): Chave-valor Não existe a possibilidade ou mesmo necessidade de uso de junções. Não existe referência de chaves. Não dá suporte a relacionamentos entre os itens de dados. Não se tem uma linguagem de consulta padrão. Por que usar esse modelo de dados? Menor tempo de resposta permitindo que a capacidade de armazenamento de suas bases de dados seja uma das maiores dos sistemas enquadrados no conceito NoSQL.

17 Organizado em linhas e colunas. Colunas Essa abordagem é projetada para tratar os dados de maneira não normalizada. Normalmente não privilegia a consistência das informações.

18 Colunas Comparando com o modelo relacional o modelo em colunas faz uma inversão na organização de seus dados. Os atributos que compõem uma instância são organizados em colunas e as linhas passam a conter as ocorrências de determinado atributo para cada instância de dados. As linhas não mais armazenam uma tupla, mas sim um conjunto de atributos de mesmo tipo, enquanto que o conjunto de atributos de uma coluna contém a informação de uma instância por completo.

19 CPF Exemplo: Nome Telefone Colunas CPF Nome Telefone

20 Os atributos de uma mesma categoria são priorizados. Colunas Essa priorização permite que consultas que façam análises em subconjuntos de dados possam ser mais eficientes. A obtenção de itens inteiros passa a ser mais custosa.

21 Instâncias de uma entidade fazem parte da mesma família de colunas. Colunas Família de coluna: Permite a existência de atributos não atômicos Podem apresentar quantidades de atributos diferentes Não sendo necessário reservar espaços de armazenamento para valores nulos. Não permite consultas com a junção de famílias de colunas. Não da suporte ao uso de chaves estrangeiras.

22 Faz uso de associações entre pares chaves e valores. Documentos Os dados não são dispostos em uma única estrutura de dados (diferente do Chave-valor). Os dados de uma entidade são agrupados em documentos que podem seguir a codificação XML ou JSON, por exemplo.

23 Um documento é uma coleção de chaves e valores que está relacionado a uma instância de dados. Documentos Documentos de um mesmo domínio são armazenados em uma coleção. Modelo é flexível: Documentos de uma mesma coleção podem apresentar campos distintos.

24 Documentos Exemplo:

25 Documentos Permite que consultas mais complexas envolvendo documentos de coleções distintas ocorram. É necessário que um documento possua um DBRef (Database References) do documento relacionado. DBRef é uma estrutura que armazena as informações da coleção de documentos e ObjectId do documento referenciado.

26 Documentos Exemplo:

27 DBRef não garantem integridade referencial. Documentos Consultas com DBRef podem ser muito custosas em termos de desempenho. Como alternativa pode-se optar por aninhar mais dados por documento. Dados relacionados são persistidos dentro do mesmo documento.

28 Documentos Exemplo:

29 Chave-valor, colunas e documentos têm seu foco no armazenamento dos dados. Grafos No modelo em grafo o foco é no relacionamentos que ocorrem entre as entidades de sua base. Abordagem estar baseada na teoria dos grafos.

30 Grafos Exemplo:

31 Grafos Esse modelo possui três tipos de informações: os nós, arestas e propriedades. Nós: instâncias de dados. Arestas: relacionamentos mantidos entre instâncias. Propriedades: valores de dados contidos nas instâncias. Podendo assumir valores como: booleanos, inteiros, caracteres e conjunto de valores.

32 Grafos Os nós e arestas podem conter rótulos. Nós: podem ser usados para diferenciarem instâncias como funcionário e cliente, por exemplo. Arestas: determinar o tipo de relacionamento que está ocorrendo como, por exemplo, a venda ou o aluguel de um veículo.

33 Arestas também podem conter propriedades que as descrevem que assim como os nós. Grafos Exemplo:

34 Garante a integridade referencial. O nó de entrada sempre fará referência ao nó de saída. Grafos As chaves de acesso aos nós são definidas automaticamente pelo sistema de banco de dados. Excelentes para aplicações com dados muito relacionados Ex. serviços baseados em localização, sistemas de recomendação.

35 Consultas complexas menos custosas do que o relacional Uso de algoritmos bem definidos para percorrer grafos Grafos Pode tornar consultas rápidas: Utilização de propriedades de grafos Algoritmos de menor caminho

36 Quem usa que modelo de dados?

37 Como escolher um modelo? Depende dos requisitos da aplicação Tamanho dos Dados Complexidade Teorema CAP Formato de Dados

38 Teorema CAP Os modelos NoSQL não objetivam substituir os bancos de dados baseados no modelo Relacional. Visa solucionar uma nova e diferente demanda de necessidades de manipulação de dados. No ano 2000, o Profº Eric Brewer apresentou o teorema CAP (Consistency, Availability and PartitionTolerance).

39 Teorema CAP A ideia central do teorema CAP diz que um sistema distribuído não pode oferecer a consistência, disponibilidade e tolerância a falhas ao mesmo tempo em um dado momento. Apenas é possível a garantia de duas das propriedades por vez.

40 Ferramentas pertencentes a modelos de dados semelhantes podem oferecer princípios diferentes. Teorema CAP Chave-valor Colunas

41 Persistência Poliglota Os BD classificados como NoSQL podem conviver com outros modelos bancos de dados? Persistência poliglota Aplicações com persistência poliglota são aquelas que precisam que seus dados sejam representados e armazenados segundo múltiplos modelos de bancos de dados. Aplicações que utilizam mais de um SGBD para armazenamento de dados. SGBD multi modelos.

42 Persistência Poliglota Exemplo:

43 ArangoDB: Modelo orientado a documento, chave-valor e grafo. ArangoDB query language (AQL). Permite o uso de joins. Alguns SGBDs NoSQL MongoDB: Modelo orientado a documento. A chave de uma instância, neste caso o documento, é chamada de oid (ObjectId). Pode ser definida no momento da persistência do documento, ou pode ter seu valor gerado aleatoriamente pelo próprio banco. Alta velocidade no acesso a dados. Suporta complexos tipos de dados. Oferece alto desempenho e alta disponibilidade.

44 Alguns SGBDs NoSQL Cassandra: Modelo orientado a coluna. Open-source Originalmente criado pelo Facebook. Projetado para oferecer alta escalabilidade, sem pontos de falhas e com customizável nível de consistência. Rendimento de gravação muito alto e bom rendimento de leitura Linguagem de consulta semelhante a SQL (desde Cassandra Query Language) e suporte para procura por índices secundários Consistência ajustável e suporte para replicação Esquema flexível.

45 Desafios de Pesquisa Modelagem de Dados NoSQL Migração de Banco de Dados Relacional para NoSQL Migração de Banco de Dados NoSQL na Nuvem

46 Desafios de Pesquisa Modelagem de Dados NoSQL: Como modelar os dados de modo a não aumentar a complexidade das consultas? Alguns trabalhos tem sido propostos para modelagem de NoSQL. Entretanto, eles consideram apenas qual o modelo mais viável para o BD NoSQL. Não tratam de como modelar o NoSQL para uma aplicação.

47 Desafios de Pesquisa Modelagem de Dados NoSQL (cont.): Outros trabalhos propõe abordagens para a modelagem orientada a consulta. Desenvolvedor deve considerar quais consultas ele utilizará quando estiver modelando o BD. Entretanto, mudanças nos requisitos de negócio/aplicação podem tornar o modelo obsoleto.

48 Desafios de Pesquisa Migração de Banco de Dados Relacional para NoSQL Mudanças: Demanda no gerenciamento de dados Requisitos das aplicações Popularização da computação em nuvem.

49 Desafios de Pesquisa Migração de Banco de Dados Relacional para NoSQL Algumas empresas que adotam DBs Relacionais se deparam com a necessidade de novas abordagens para persistência: Devido a ampliação de seus serviços Caso da Netflix: Em 2012 possuía 288 servidores distribuídos e operava com o MySQL Passou a utilizar o Cassandra É interessante desenvolver abordagens que realizem essa migração automática.

50 Desafios de Pesquisa Migração de Banco de Dados NoSQL na Nuvem: Tem provido Database-as-a-Service aos usuários. Diferentes modelos de dados têm inserido heterogeneidade nos serviços da nuvem. Provedores desenvolvem suas soluções de BDs NoSQL para gerenciar seus dados Falta de portabilidade e interoperabilidade entre elas é um desafio: Quando o cliente está insatisfeito com o serviço e muda de provedor Devido a mudanças nos requisitos de negócio.

51 Desafios de Pesquisa Migração de Banco de Dados NoSQL na Nuvem: Migração automática de dados entre diferentes modelos de Banco de Dados NoSQL é um tópico em aberto Em geral duas abordagens para migração tem sido adotadas: Migração Direta Migração Intermediária Soluções tem sido propostas na literatura: Em geral, trabalham apenas com um subconjunto de tipos de BD NoSQL Abordagem que engloba todos os tipos é necessária.

52 Referências FREITAS, Myller Claudino; SOUZA, DamiresYluska; SALGADO, Ana Carolina Brandão. Mapeamentos conceituais entre os modelos relacional e NoSQL: Uma abordagem comparativa. Revista Principia - Divulgação Científica e Tecnológica do IFPB, [S.l.], n. 28, p , dez ISSN F. M. Schmidt, C. Geyer, A. Schaeffer-Filho, S. DeBloch andy. Hu, "Change data capture in NoSQL databases: A functional and performance comparison," 2015 IEEE Symposium on Computers and Communication (ISCC), Larnaca, 2015, pp Jing Han, Haihong E, Guan Le and Jian Du, "Survey on NoSQL database," Pervasive Computing and Applications (ICPCA), th International Conference on, Port Elizabeth, 2011, pp Vieira, M. R., Figueiredo, J. M., Liberatti, G. and Viebrantz, A. F. M. (2012) Bancos de Dados NoSQL: Conceitos, Ferramentas, Linguagens e Estudos de Casos no Contexto de Big Data. Minicurso SBBD 2012, São Paulo, 2012.

53