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)

▫ 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/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?