Web Scale Data Management

491 views
365 views

Published on

Apresentação baseada na aula 17 de:
Harvard Extension School CSCI E-109 - Data Science
Web Scale Data Management - An Historical Perspective

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
491
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Web Scale Data Management

  1. 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. 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. 3. Agenda • Início • O auge dos SGBDs Relacionais • Renascimento do armazenamento chave-valor • Armazenamento chave-valor hoje: NoSQL • Casos de uso
  4. 4. Introdução • Ideias do passado ressurgem ao longo tempo empacotadas com outros nomes.
  5. 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. 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. 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. 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. 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. 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. 11. Modelo Relacional • Os dois grupos exploravam a viabilidade de implementar o modelo relacional. • Ambos tiveram grande sucesso e impacto.
  12. 12. System R RSS  Trabalho semelhante ao do Modelo Rede em termos de manipulação de ponteiros para encontrar registros de forma eficiente.
  13. 13. Ingres Implementação muito diferente do System R.
  14. 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. 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. 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. 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. 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. 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. 20. SGBD Relacional x Chave-Valor BDB – Berkeley DB TCO – Total Cost of Ownership
  21. 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. 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. 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. 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
  25. 25. 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.
  26. 26. http://db-engines.com/en/ranking
  27. 27. Maio 2014
  28. 28. Maio 2014
  29. 29. Maio 2014
  30. 30. Maio 2014
  31. 31. Maio 2014
  32. 32. 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
  33. 33. 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
  34. 34. Escolha • Escolher o sistema correto para o problema pode fazer uma grande diferença.
  35. 35. 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
  36. 36. 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).
  37. 37. 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
  38. 38. 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
  39. 39. 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.
  40. 40. 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.
  41. 41. 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
  42. 42. Netflix API
  43. 43. Netflix usando Amazon AWS
  44. 44. Netflix antes e depois
  45. 45. Netflix antes
  46. 46. Netflix depois
  47. 47. Escalabilidade linear
  48. 48. Atividade por nó
  49. 49. 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
  50. 50. 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
  51. 51. 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
  52. 52. Quando usar NoSQL? • Escalabilidade • Baixa latência • Redundância • Consultas não adhoc • Junções facilmente implementáveis na aplicação
  53. 53. Conclusão • Não há uma solução perfeita para tudo (bala de prata) • Use a ferramenta mais adequada ao seu problema
  54. 54. Regis Pires Magalhães regismagalhaes@ufc.br Obrigado! Dúvidas, comentários, sugestões?

×