Web Scale Data Management
0 gostou1,015 visualizações
O documento resume a evolução dos sistemas de gerenciamento de dados, desde os primórdios dos bancos de dados até os sistemas atuais de grande escala. Começa com os modelos de rede e ISAM nos anos 1960, passa pelo modelo relacional e sistemas como System R e Ingres, a popularização dos SGBDs relacionais, e as limitações impostas pelas novas aplicações da Web. Apresenta então o renascimento dos sistemas de armazenamento chave-valor, projetos como Bigtable e Dynamo, e a categoria de sistemas
Web Scale Data Management
- 1. Web Scale Data Management An Historical Perspective Harvard Extension School CSCI E-109 - Data Science, Lecture 17 Margo Seltzer Regis Pires Magalhães regismagalhaes@ufc.br
- 2. Apresentação baseada na aula 17 de: • Harvard Extension School CSCI E-109 - Data Science Web Scale Data Management An Historical Perspective http://www.cs109.org/ http://cm.dce.harvard.edu/2014/01/14328/publicationListin g.shtml
- 3. Agenda • Início • O auge dos SGBDs Relacionais • Renascimento do armazenamento chave-valor • Armazenamento chave-valor hoje: NoSQL • Casos de uso
- 4. Introdução • Ideias do passado ressurgem ao longo tempo empacotadas com outros nomes.
- 5. No início • Década de 1960 • Computadores ▫ Sistemas centralizados ▫ Canais de dados permitindo CPU e IO ao mesmo tempo. ▫ Armazenamento persistente em tambores. ▫ Buffering e manipulação de interrupções pelo SO ▫ Foco da pesquisa: tornar esses sistemas rápidos.
- 6. No início • Dados ▫ ISAM - Indexed Sequencial Access Method Iniciado pela IBM para seus mainframes Registros de tamanho fixo Cada registro em uma localização específica Acesso rápido mesmo em mídia sequencial (fita) ▫ Todos os índices secundários Não correspondem à organização física Chave serve para construir estruturas de índice pequenas e eficientes. ▫ Método de acesso fundamental em COBOL.
- 7. Organização dos dados: Modelo Rede • Familiar para quem usa bancos de dados em grafo e bancos chave-valor. • Dados representados por coleções de registros (hoje chamaríamos pares chave-valor). • Relacionamentos entre registros expressos através de links entre registros (hoje chamaríamos ponteiros). • Aplicações interagiam com os dados navegando por eles: ▫ Encontre um registro ▫ Siga links ▫ Encontre outros registros ▫ Repita
- 8. Modelo Rede: Registros • Registros compostos de atributos • Atributos com valor único • Links conectam dois registros • Links armazenam posições físicas e não valores (principal diferença em relação aos SGBDRs) • Relacionamentos de múltiplos caminhos representados por registros de links.
- 9. Modelo Rede: Registros • Problema: para reorganizar os dados era necessário mudar a aplicação. ▫ Organização física muito ligada à aplicação. ▫ As aplicações precisavam conhecer a estrutura dos dados.
- 10. Modelo Relacional • 1968: Ted Codd propôs o modelo relacional ▫ Desacoplar a representação física da representação lógica ▫ Armezena “registros” como “tabelas”. ▫ Substitui links por junções implícitas entre tabelas. • Grande debate sobre desempenho, após o artigo de Codd. • Dois grupos transformaram a ideia em software: ▫ IBM: System/R ▫ U.C. Berkeley (Michael Stonebraker e Eugene Wong): INGRES (INteractive Graphics REtrieval System) POSTGRES = POST inGRES
- 11. Modelo Relacional • Os dois grupos exploravam a viabilidade de implementar o modelo relacional. • Ambos tiveram grande sucesso e impacto.
- 12. System R RSS Trabalho semelhante ao do Modelo Rede em termos de manipulação de ponteiros para encontrar registros de forma eficiente.
- 13. Ingres Implementação muito diferente do System R.
- 14. Armazenamento Chave/Valor por dentro • Sistemas relacionais têm escondido alguma forma de engine de armazenamento chave-valor. • Por muitos anos buscou-se esconder o armazenamento chave-valor por trás de uma linguagem de consulta e de um nível de esquema. • A exceção era o COBOL que continuava a usar ISAM.
- 15. Evolução dos SGBDs • Novas características: SQL-86, 89, 92, 99, 2003, 2008) ▫ Triggers ▫ Stored Procedures ▫ Report generators ▫ Rules ▫ ... • Incorporação de novos modelos de dados: ▫ Sistemas Objeto-relacionais ▫ XML • Tornou-se extremamente grande e complexo ao incorporar as sucessivas novidades que iam aparecendo ao longo do tempo.
- 16. SGBDRs • Vantagens ▫ Linguagem declarativa que desacopla os layouts físico e lógico. ▫ Modificação fácil do esquema. ▫ Bom suporte a consultas ad hoc. • Desvantagens ▫ Pagar pelo overhead de processar consultas, mesmo quando as consultas não são complexas. Aplicações muito simples terminam usando um SGBD, mas sem muita necessidade. ▫ Requer sintonia e manutenção por parte do DBA. ▫ Quase sempre é usada IPC (Inter Process Communication) para acessar o servidor de banco de dados. ▫ Requer definição do esquema. ▫ Não adequado para gerenciar relacionamentos hierárquicos ou outros relacionamentos complexos.
- 17. O advento da Internet • Novos tipos de aplicações surgiram ▫ Busca ▫ Autenticação (LDAP) ▫ Email ▫ Navegação ▫ Mensagens instantâneas ▫ Servidores Web ▫ Vendas online ▫ Gerenciamento de chave pública
- 18. Essas aplicações são diferentes • Fazem uso intensivo de dados • Consultas especificadas na aplicação • Não ad hoc • Usuários interagem com a aplicação • Esquemas relativamente simples • Relatórios não sofisticados • Desempenho é algo crítico Os SGBDs relacionais não estavam entregando as funcionalidades necessárias, mas estavam trazendo overhead.
- 19. Surgimento do armazenamento chave-valor • 1997 – Sleepcat Software iniciou o primeiro banco comercial para armazenamento chave-valor (atualmente Oracle Berkeley BD). ▫ Deixar algumas características de lado. ▫ Embutido: links diretamente no espaço de endereçamento da aplicação. ▫ Rápido: evita ‘parse’ e otimização da consulta ▫ Escalável: executa desde equipamentos móveis a data centers. ▫ Flexível: ajuste entre funcionalidade e desempenho. ▫ Confiável: recuperação de falhas da aplicação ou do sistema.
- 20. SGBD Relacional x Chave-Valor BDB – Berkeley DB TCO – Total Cost of Ownership
- 21. De local a distribuído • Dos mainframes caros aos PCs baratos ▫ Argumento econômico • Com a evolução da Web, volume, velocidade e necessidades dos clientes cresceram exponencialmente • Excederam a capacidade de um único sistema • Necessidade de escalabilidade
- 22. NoSQL • Not-only-SQL (2009) • Provedores (Google, Amazon, Ebay, Facebook, Yahoo) começaram a se deparar com os limites das soluções de gerenciamento de dados existentes. • Sharding (particionamento – muitas partições): dividir os dados em múltiplos hosts para dividir a carga. • Replicação ▫ Permite acesso de vários sites. ▫ Aumenta a disponibilidade. • Relaxar a consistência: nem sempre é preciso usar a semântica transacional.
- 23. NoSQL • SGBDs Relacionais focam nas propriedades ACID. • NoSQL foca em BASE: ▫ Basic Availability: usar replicação para reduzir a probabilidade de falta de disponibilidade e sharding para tornar as falhas parciais e não totais. ▫ Soft State: Permitir dados ficarem inconsistentes e deixar a resolução de tais inconsistências por conta dos desenvolvedores de aplicações. ▫ Eventually Consistent: Garantir que em um tempo no futuro o dado assume um estado consistente.
- 24. NoSQL • Problemas comuns ▫ Volumes de transações sem precedentes ▫ Necessidade crítica de baixo tempo de latência ▫ 100% de disponibilidade • Mudança de hardware ▫ Multiprocessamento simétrico blades • Teorema CAP ▫ Escolher dois: Consistência: todos os nós vêem o mesmo dado ao mesmo tempo. Disponibilidade: Toda requisição recebe uma resposta sucesso / falha. Tolerância a partição: O sistema continua a operar mesmo com perdas de mensagens arbitrárias. ▫ SGBDRs (sistemas transacionais) escolhem CA ▫ NoSQL tipicamente escolhe AP ou CP
- 26. DB-Engines • Cálculo do Ranking ▫ Número de menções em websites ▫ Interesse geral do sistemas ▫ Frequência de discussões técnicas sobre o sistema ▫ Número de ofertas de emprego no qual o sistema é mencionado ▫ Número de perfis em redes profissionais no qual o sistema é mencionado.
- 28. Maio 2014
- 29. Maio 2014
- 30. Maio 2014
- 31. Maio 2014
- 32. Maio 2014
- 33. Evolução • 1997: Berkeley DB armazenamento chave/valor transacional • 2001: Berkeley DB introduz replicação para alta disponibilidade. • 2006: Google publica artigos sobre Chubby e BigTable. ▫ The Chubby Lock Service for Loosely-Coupled Distributed Systems Mike Burrows ▫ Bigtable: A Distributed Storage System for Structured Data Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes, and Robert E. Gruber • 2007: Amazon publica artigo sobre Dynamo ▫ Distributed Hash Table (DHT) ▫ Armazenamento chave-valor eventualmente consistente
- 34. Evolução • 2008+: Vários projetos Open Source buscando semelhança com BigTable/Dynamo ▫ HBase: projeto do Apache Hadoop implementação do BigTable (2008) ▫ CouchDB: Document Store em Erlang. Controle de concorrência Multiversão e versionamento (2008) ▫ Cassandra: otimizado a escritas, orientado a coluna, índices secundários (2009) ▫ MongoDB: Document Store baseada em JSON, indexação, auto- shardind (2009) • 2009+: Comercialização ▫ Empresas dando suporte aos produtos Open Source: DataStax/Cassandra, Basho/Riak, Cloudera/HBase, 10Gen/MongoDB Empresas desenvolvendo produtos comerciais: Oracle, Citrusleaf
- 35. Escolha • Escolher o sistema correto para o problema pode fazer uma grande diferença.
- 36. Projeto de sistemas NoSQL • Sistema de armazenamento usando nós • Distribuição • Modelo de Dados • Modelo de Consistência ▫ Consistência Eventual ▫ Sem consistência ▫ Consistência Transacional
- 37. Sistemas de Armazenamento • Armazenamento Chave-Valor Nativo ▫ Oracle NoSQL Database: Berkeley DB Java Edition ▫ Basho: Bitcask do Riak, uma hash table estruturada como log ▫ Amazon: Dynamo, BDB Data Store, BDB JE (ou MySQL) ▫ Log-structured Merge Trees LevelDB ▫ Custom BigTables (e clones): explorando sistemas semelhantes ao Google File System (GFS).
- 38. Distribuição • Questões principais ▫ Como particionar os dados? ▫ Quantas cópias manter? ▫ Todas as cópias são iguais? • Como particionar os dados? ▫ Particionamento baseado em chave ▫ Particionamento Hash (frequentemente chamado Sharding) ▫ Partcionamento Geográfico (também chamado sharding) Para evitar problemas com falhas / desastres
- 39. Distribuição • Quantas cópias manter e como? ▫ Usar o sistema de arquivos subjacente (GFS, HDFS) E ele cuida de fazer as cópias necessárias. ▫ Três é bom, cinco é melhor, ... Por que números ímpares? Em caso de divergência, fazer votação pela maioria ▫ Dados de saída (calculáveis / gerados) podem ter apenas uma cópia • Igualdade das cópias ▫ Single-Master Envio ao master e ele copia MongoDB, Oracle NoSQL DB Preocupação com consistência ▫ Multi-master / Masterless Envio a qualquer máquina e ela copia Gerenciamento mais complexo Pode ser difícil descobrir onde está o dado correto em caso de falha (escolher o maior?) Riak, CouchDB, Couchbase
- 40. Modelos de Dados • Comum ▫ Desnormalização Redundância - valores duplicados para melhor desempenho ▫ Sem junções Se necessário, a aplicação deve fazer as junções • Chave/Valor: Pouco esquema ou sem esquema, suporte a consultas com intervalos pequenos ▫ Oracle NoSQL DB, Dynamo DB, Couchbase, Riak ▫ Alguns: chave segmentada (Major key / Minor key) • Família de coluna ▫ Muitas colunas ▫ Colunas agrupadas em famílias para que possam ser armazenadas juntas ▫ Esquema “relaxado” ▫ BigTable, HBase, Cassandra ▫ Meio termo entre sem esquema (modelo chave-valor) e com esquema rígido (modelo relacional) • Document Stores ▫ MongoDB, CouchDB ▫ Armazenamento de XML, JSON. ▫ A partir de uma chave, encontrar um documento.
- 41. Consistência • Sistemas consistentes / particionáveis ▫ BigTable, HBase, HyperTable, MongoDB, Redis, MemcacheDB • Sistemas disponíveis / particionáveis ▫ Cassandra, SimpleDB, CouchDB, Riak, TokyoCabinet, Dynamo • Consistência Eventual ▫ Há várias definições. ▫ Mais popular (Vogels): Se não forem realizadas novas atualizações ao objeto eventualmente (após o fechamento da janela de inconsistência), todos os acessos retornam ao último valor atualizado. ▫ É possível ser AP e eventualmente consistente. • Variável ▫ Ajustar o nível de consistência a partir de uma configuração. ▫ Exemplo: Oracle NoSQL DB: Pode ser CP, quando configurado para política de maioria simples. Em caso contrário, é AP.
- 42. Netflix migra para Cassandra • Global Netflix – Replacing Datacenter Oracle with Global Apache Cassandra on AWS ▫ Out/2011 ▫ Adrian Cockcroft ▫ http://hpts.ws/papers/2011/sessions_2011/GlobalNetflixH PTS.pdf • Usando Cassandra para: ▫ Clientes ▫ Filmes ▫ Histórico ▫ Configuração • Migração gradativa • Por que? ▫ Sem necessidade de mudanças no esquema ▫ Alto desempenho ▫ Escalabilidade
- 43. Netflix API
- 44. Netflix usando Amazon AWS
- 45. Netflix antes e depois
- 46. Netflix antes
- 47. Netflix depois
- 49. Atividade por nó
- 50. Facebook usa HBase - Mensagens • Storage Infrastructure Behind Facebook Messages ▫ Big Data Experiences & Scars, HPTS 2011 ▫ Kannan Muthukkaruppan ▫ http://mvdirona.com/jrh/TalksAndPapers/KannanMuthu kkaruppan_StorageInfraBehindMessages.pdf • Mensagens, chat, email e SMS em um único framework de mensagens. • Por que? ▫ Alto throughput de escrita ▫ Bom desempenho de leitura ▫ Escalabilidade horizontal ▫ Consistência forte • O que usa o HBase? ▫ Mensagens pequenas ▫ Metadados de mensagens ▫ Índice de busca
- 51. Viber Media usa MongoDB • MongoDB at Viber Media: The Platform Enabling Free Phone Calls and Text Messaging for Over 18 Million Active Users ▫ Jan/2012 ▫ http://nosql.mypopescu.com/post/16058009985/mo ngodb-at-viber-media-the-platform-enabling-free • Por quê? ▫ Escalabilidade ▫ Redundância • Que usa? ▫ Documentos de tamanhos variáveis ▫ Índices dicionário
- 52. Além do NoSQL - NewSQL • Spanner: Google’s Globally-Distributed Database ▫ OSDI 2012 ▫ http://static.googleusercontent.com/media/research.google.com/pt- BR//archive/spanner-osdi2012.pdf • Google Spanner: BD SQL distribuído globalmente com transações atômicas, replicação síncrona e consistência • Dado é “sharded” ▫ Replicado com máquinas de estado Paxos ▫ Algoritmo de consenso Paxos – confiável. Garante Consistência. ▫ Two Phase Commit usado para garantir Atomicidade. • Múltiplos modelos de consistência ▫ Snapshot reads ▫ Transações somente leitura ▫ Transações ACID • Permite TrueTime ▫ Mecanismo de clock entre nós do sistema
- 53. Quando usar NoSQL? • Escalabilidade • Baixa latência • Redundância • Consultas não adhoc • Junções facilmente implementáveis na aplicação
- 54. Conclusão • Não há uma solução perfeita para tudo (bala de prata) • Use a ferramenta mais adequada ao seu problema
- 55. Regis Pires Magalhães regismagalhaes@ufc.br Obrigado! Dúvidas, comentários, sugestões?