• Like
  • Save
Web Scale Data Management
Upcoming SlideShare
Loading in...5
×
 

Web Scale Data Management

on

  • 127 views

Apresentação baseada na aula 17 de:

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

Statistics

Views

Total Views
127
Views on SlideShare
94
Embed Views
33

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 33

http://ufc-data-science-laboratory.blogspot.com.br 33

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Web Scale Data Management Web Scale Data Management Presentation Transcript

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