Banco de Dados NoSQL e Big Data Professor Marcio Victorino – mcvictorino@uol.com.br Bibliografia NoSQL Essencial – Martin Fowler. http://nosql-database.org/ http://hadoop.apache.org/ http://bigdatauniversity.com/ http://bigdataprojects.org/ ACM. IEEE. Professor Marcio Victorino 2 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. Professor Marcio Victorino 3 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). Professor Marcio Victorino 4 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. Professor Marcio Victorino 5 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. Professor Marcio Victorino 6 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. Professor Marcio Victorino 7 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. Professor Marcio Victorino 8 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. Professor Marcio Victorino 9 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. Professor Marcio Victorino 10 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 e em intervalos regulares. Professor Marcio Victorino 11 NoSQL Modelos de Distribuição: Replicação: obtém os mesmos dados e os copias 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. Professor Marcio Victorino 12 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. Professor Marcio Victorino 13 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 fragmanto). Professor Marcio Victorino 14 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). SGBDs orientado a grafos suportam transações ACID. Abordagens pessimistas bloqueiam os registros para evitar conflitos. Abordagens otimistas detectam conflitos e os resolvem. Professor Marcio Victorino 15 NoSQL Teorema CAP: Dadas três propriedades, Consistência, Disponibilidade (Availability) e de Particionamento, somente é possível obter duas delas. 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 diz 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. Professor Marcio Victorino 16 NoSQL ACID x BASE: BASE - Basically Available, Soft state, Eventual consistency. SGBDs NoSQL seguem as propriedades BASE. Não 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. Professor Marcio Victorino 17 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. Professor Marcio Victorino 18 Banco de Dados de Chave-Valor Professor Marcio Victorino 19 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. Professor Marcio Victorino 20 BD Chave-Valor São os depósitos de dados No SQL 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. Professor Marcio Victorino 21 BD Chave-Valor Riak. Redis. MemcachedDB. HamsterDB. AmazonDynamoDB. Professor Marcio Victorino 22 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. Professor Marcio Victorino 23 Banco de Dados de Documentos Professor Marcio Victorino 24 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, ou seja, a parte valor pode ser consultada. A chave pode ser atribuída pelo usuário, desde que seja única. Professor Marcio Victorino 25 BD de Documentos MomgoDB. CouchDB. RavenDB. Professor Marcio Victorino 26 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. Professor Marcio Victorino 27 Banco de Dados de Família de Colunas Professor Marcio Victorino 28 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. Professor Marcio Victorino 29 BD Família de Colunas Cada família de counas 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. Professor Marcio Victorino 30 BD Família de Colunas Cassandra. Hbase. Hypertable. Amazon SimpleDB. Professor Marcio Victorino 31 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áves. Professor Marcio Victorino 32 Banco de Dados de Grafos Professor Marcio Victorino 33 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. Professor Marcio Victorino 34 BD de Grafos Professor Marcio Victorino 35 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. Professor Marcio Victorino 36 BD de Grafos Neo4J. Infinite Graph. Professor Marcio Victorino 37 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 modeloado. Professor Marcio Victorino 38 Big Data Professor Marcio Victorino 39 Big Data Estima-se que, do início da civilização até 2003, a humanidade tenha criado cinco exabytes (10 bytes elevados a 18ª potência) de dados. Atualmente cria-se esse mesmo volume a cada dois dias. Um estudo da International Data Corporation (IDC) indica que, de 2012 até 2020, o volume de dado armazenado na internet deverá dobrar a cada dois anos. Professor Marcio Victorino 40 Big Data Baseado nesses domínios de aplicação em que há um volume massivo de dados, nos mais variados formatos e que precisam ser processados em uma determinada velocidade, a International Business Machines (IBM) criou o termo “Big Data”. Esse termo faz menção aos 3Vs: enorme volume de dados; enorme variedade de dados; velocidade necessária para o seu processamento. Obs: já existem autores citando mais dois V’s: veracidade e valor. Professor Marcio Victorino 41 Big Data Obs: Já existem autores citando mais dois V’s: veracidade e valor. Professor Marcio Victorino 42 Big Data Para fazer frente a esses novos desafios uma nova geração de arquiteturas tem sido proposta, como por exemplo, o conceito de MapReduce apresentado pelo Google. Essa abordagem busca dividir os problemas complexos do Big Data em pequenas unidades de trabalho e processa-las em paralelo. Professor Marcio Victorino 43 Big Data O Map-Reduce pode ser dividido em dois estágios: Passo de mapeamento: o nó mestre divide os dados em vários subconjuntos menores, um nó trabalhador processa um subconjunto de dados menor sob o controle de um rastreador de trabalho e armazena o resultado no sistema de arquivos local, onde um redutor será capaz de acessá-lo. Passo de redução: esta etapa analisa e reúne os dados de entrada a partir das etapas de mapeamento. Podem haver múltiplas tarefas de redução para paralelizar a agregação, e essas tarefas são executadas nos nós trabalhadores sob o controle do rastreador de trabalho. Professor Marcio Victorino 44 Map-Reduce A função map lê registros do banco de dados e emite pares de chave-valor. A função reduce recebe diversos pares de chave-valor com a mesma chave e os agrega em um. Professor Marcio Victorino 45 Map-Reduce Particionar permite que funções reduce sejam executadas em paralelo sobre diferentes chaves. Professor Marcio Victorino 46 Big Data Professor Marcio Victorino 47 Criado por Doug Cutting, o Hadoop foi inspirado no BigTable, que é o sistema de armazenamento de dados do Google, no Google File System e no MapReduce. O Hadoop é um framework baseado em Java e uma plataforma heterogênea com licença open source. Professor Marcio Victorino 48 Embora os subprojetos do Hadoop mais conhecidos sejam o MapReduce e seu sistema de arquivos distribuídos, Hadoop Distributed File System (HDFS), outros subprojetos oferecem uma série de serviços complementares ou adicionam abstrações de maior nível, ou seja, facilitando o desenvolvimento. Entre os demais subprojetos, vale destacar: Avro: um sistema de serialização de dados que fornece RPCs (Remote Procedure Calls) eficientes e independentes de linguagem, armazenamento persistente de dados, estruturas de dados ricas, entre outros recursos; Professor Marcio Victorino 49 Pig: uma plataforma para grandes conjuntos de dados que possui uma linguagem de programação de alto nível para realizar a análise desses dados. Além disso, possui a infraestrutura necessária para avaliar os programas criados, como um compilador especial que transforma as aplicações desenvolvidas nessa linguagem em uma sequência de programas MapReduce; HBase: uma base de dados distribuída, criada para armazenar tabelas muito grandes (milhões de colunas x bilhões de linhas). Trata-se de um modelo de armazenamento orientado a colunas, muito fácil de utilizar com a API Java; Professor Marcio Victorino 50 ZooKeeper: um serviço centralizado para coordenação de aplicações distribuídas. Mantém informações de configuração das aplicações distribuídas, além de fornecer a sincronização das mesmas. Esse tipo de serviço é comumente utilizado em aplicações distribuídas, o ZooKeeper fornece uma interface simples para auxiliar o desenvolvedor; Hive: uma espécie de Data Warehouse distribuído, facilita a utilização de grandes conjuntos de dados (datasets) em ambientes de armazenamento paralelo. Provê uma linguagem baseada em SQL, chamada HiveQL, que serve para facilitar a estruturação dos e pesquisa nos dados. Professor Marcio Victorino 51 Big Data Analytics Big Data Analytics pode ser interpretado como procedimentos complexos que são executados em larga escala sobre grandes repositórios de dados, cujo principal objetivo é o de extração de conhecimento útil mantido em tais repositórios. Em outras palavras é a aplicação de técnicas analíticas avançadas a conjuntos de dados muito grandes. Professor Marcio Victorino 52 Fim Professor Marcio Victorino 53