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

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.

27. http://db-engines.com/en/ranking

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

48. Escalabilidade linear

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?