View
246
Download
0
Category
Tags:
Preview:
DESCRIPTION
Apresentação baseada na aula 17 de: Harvard Extension SchoolCSCI E-109 - Data Science Web Scale Data Management - An Historical Perspective
Citation preview
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/publicationListing.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)
▫ 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/mongodb-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?
Recommended