Gerenciamento de Dados em Sistemas Par-a-par

Transcrição

1 Gerenciamento de Dados em Sistemas Par-a-par Rebeca Schroeder Freitas UFPR Vidal Martins - PUCPR ERBD 2011 Novo Hamburgo/RS

2 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Motivação Processamento compartilhado Comunicação ICQ Compartilhamento de dados Napster Gnutella Kazaa Gerenciamento de dados distribuídos ActiveXML Edutella Piazza PIER Rebeca Schroeder Freitas/Vidal Martins Gerenciamento de Dados em Sistemas Par-a-par a 2

3 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Motivação Características dos sistemas par-a-par (P2P) Sistemas distribuídos, cooperativos, de larga escala e heterogêneos Operam sobre uma rede lógica (overlay network) sobreposta a uma rede física (normalmente, Internet) Os nós são autônomos, podendo conectar ou desconectar a qualquer momento A rede sofre mudanças frequentes Os nós oferecem recursos e recebem recursos em troca Os nós não são confiáveis Não há controle centralizado Alta escalabilidade sem depender de servidores robustos Cada nodo pode suportar a mesma funcionalidade, ser cliente e servidor, e comunicar com qualquer outro nodo da rede Normalmente, os nodos não compartilham um schema global Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 3

4 Agenda Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Redes par-a-par (P2P) Fundamentos de replicação de dados Replicação de dados em sistemas P2P Rebeca Schroeder Freitas/Vidal Martins Gerenciamento de Dados em Sistemas Par-a-par a 4

5 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Redes par-a-par Introdução Tipos de redes P2P Não estruturada Estruturada Super-peer Rebeca Schroeder Freitas/Vidal Martins Gerenciamento de Dados em Sistemas Par-a-par a 5

6 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Introdução Redes não estruturadas Redes estruturadas Redes super-peer Redes par-a-par Apresentam diferentes graus de distribuição Possuem diferentes topologias A distribuição e a topologia da rede P2P afetam as propriedades não funcionais dos sistemas P2P Tolerância a falhas Autoajuste Desempenho Escalabilidade Segurança Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 6

7 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Introdução Redes não estruturadas Redes estruturadas Redes super-peer Redes P2P não estruturadas A rede é criada de maneira não determinística O local onde os dados são armazenados é independente da topologia da rede Cada nodo conhece seus vizinhos, mas não sabe os recursos que eles possuem Mecanismos de busca variados Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 7

8 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Introdução Redes não estruturadas Redes estruturadas Redes super-peer Redes P2P não estruturadas Mecanismo de busca simples e caro Propagação de consultas na rede até que o dado desejado seja encontrado (flooding) Mecanismo de busca sofisticado e eficiente Random walks múltiplos e paralelos: cada nodo escolhe um vizinho aleatoriamente e propaga a consulta para ele Seleção de vizinhos para repassar a consulta com base em histórico recente e índices locais Adaptação dinâmica da topologia da rede Índices de roteamento que fornecem uma lista de vizinhos mais prováveis de estarem na direção do dado procurado Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 8

9 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Introdução Redes não estruturadas Redes estruturadas Redes super-peer Redes P2P não estruturadas Exemplos de sistemas P2P suportados por redes P2P não estruturadas Gnutella Kazaa FreeHaven Rebeca Schroeder Freitas/Vidal Martins Gerenciamento de Dados em Sistemas Par-a-par a 9

10 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Introdução Redes não estruturadas Redes estruturadas Redes super-peer Redes P2P não estruturadas Gnutella Rebeca Schroeder Freitas/Vidal Martins Gerenciamento de Dados em Sistemas Par-a-par a 1 0

11 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Introdução Redes não estruturadas Redes estruturadas Redes super-peer Redes P2P não estruturadas Aspectos positivos Expressividade das consultas: busca por palavras-chave, consulta no estilo SQL, etc. Alta tolerância a falhas: os nós fornecem funcionalidade igual e replicam dados Autonomia: cada nodo é livre para decidir qual dado armazenar Principais problemas Escalabilidade Resultados incompletos para consultas Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 11

12 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Introdução Redes não estruturadas Redes estruturadas Redes super-peer Redes P2P estruturadas Surgiram para resolver o problema de falta de escalabilidade das redes não estruturadas Estratégia Controle rigoroso da topologia da rede Armazenamento dos dados em locais precisamente determinados Mapeamento entre os dados e suas localizações por meio de tabela de roteamento distribuída A principal representante desta classe de rede P2P é a DHT (Distributed Hash Table) Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 12

13 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Introdução Redes não estruturadas Redes estruturadas Redes super-peer Redes P2P estruturadas DHT Fornece uma interface com as seguintes primitivas put (key, value) get (key) delete(key) Cada nodo é responsável por armazenar os valores (values) correspondentes a um certo intervalo de chaves (keys) Cada nodo conhece alguns nodos vizinhos Cada nodo mantém uma tabela de roteamento que associa os identificadores dos seus vizinhos aos endereços correspondentes Operações de acesso a dados ocorrem em duas etapas Lookup: encontra o nodo n que armazena o objeto requisitado Comunicação direta com n Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 13

14 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Introdução Redes não estruturadas Redes estruturadas Redes super-peer Redes P2P estruturadas Exemplos de sistemas P2P suportados por redes P2P estruturadas Chord CAN Tapestry Pastry PIER OceanStore P-Grid (árvore distribuída) Rebeca Schroeder Freitas/Vidal Martins Gerenciamento de Dados em Sistemas Par-a-par a 14

15 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Introdução Redes não estruturadas Redes estruturadas Redes super-peer Redes P2P estruturadas Chord successor(k) = (n + 2 i-1 ) mod 2 m Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 15

16 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Introdução Redes não estruturadas Redes estruturadas Redes super-peer Redes P2P estruturadas CAN Rebeca Schroeder Freitas/Vidal Martins Gerenciamento de Dados em Sistemas Par-a-par a 16

17 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Introdução Redes não estruturadas Redes estruturadas Redes super-peer Redes P2P estruturadas Tapestry Rebeca Schroeder Freitas/Vidal Martins Gerenciamento de Dados em Sistemas Par-a-par a 17

18 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Introdução Redes não estruturadas Redes estruturadas Redes super-peer Redes P2P estruturadas Pastry Os identificadores dos nós são ordenados em um círculo como os identificadores da rede Chord A localização dos dados também é similar ao Chord Pastry leva em conta a latência entre os nós para estabelecer as vizinhanças (nós fisicamente próximos se tornam vizinhos na rede P2P) Para rotear uma mensagem que procura a chave k, cada nodo repassa a mensagem para o seu vizinho cujo identificador é mais parecido com k (similar ao Tapestry) Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 18

19 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Introdução Redes não estruturadas Redes estruturadas Redes super-peer Redes P2P estruturadas OceanStore Rebeca Schroeder Freitas/Vidal Martins Gerenciamento de Dados em Sistemas Par-a-par a 19

20 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Introdução Redes não estruturadas Redes estruturadas Redes super-peer Redes P2P estruturadas P-Grid Rebeca Schroeder Freitas/Vidal Martins Gerenciamento de Dados em Sistemas Par-a-par a 20

21 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Introdução Redes não estruturadas Redes estruturadas Redes super-peer Redes P2P estruturadas Aspectos positivos Roteamento eficiente das consultas O(log N), onde N é o número de nós da rede Principais problemas Autonomia limitada Cada nodo tem de armazenar os valores que correspondem ao seu intervalo de chaves Inicialmente, as consultas eram limitadas a busca por valor exato de palavras-chave Já existem soluções para consulta por intervalo de valores e consultas com junções Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 21

22 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Introdução Redes não estruturadas Redes estruturadas Redes super-peer Redes super-peer Redes P2P estruturadas e não-estruturadas são consideradas puras porque todos os peers têm a mesma funcionalidade Redes super-peer são hibridas entre sistemas cliente-servidor e redes P2P puras Alguns peers (super-peers) atuam como servidores e realizam funções complexas, como: indexação, processamento de consulta, controle de acesso e gerenciamento de metadados Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 22

23 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Introdução Redes não estruturadas Redes estruturadas Redes super-peer Redes super-peer Rebeca Schroeder Freitas/Vidal Martins Gerenciamento de Dados em Sistemas Par-a-par a 23

24 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Introdução Redes não estruturadas Redes estruturadas Redes super-peer Redes super-peer Exemplos de sistemas P2P suportados por redes super-peer Napster Publius Edutella JXTA Gnutella (uma das versões) Rebeca Schroeder Freitas/Vidal Martins Gerenciamento de Dados em Sistemas Par-a-par a 24

25 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Introdução Redes não estruturadas Redes estruturadas Redes super-peer Redes super-peer Aspectos positivos Eficiência Qualidade de serviço (resultados completos para pesquisas, tempo de resposta, controle de acesso, etc.) Principais problemas Autonomia limitada (login em super-peer específico) Baixa tolerância a falhas Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 25

26 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Resumo Requisitos Não estruturada Estruturada Super-peer Autonomia Alta Baixa Moderada Expressividade das consultas Alta Baixa Alta Eficiência Baixa Alta Alta QoS Baixa Alta Alta Tolerância a falhas Alta Alta Baixa Segurança Baixa Baixa Alta Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 26

27 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Fundamentos de replicação de dados Single-master vs multi-master Replicação total vs replicação parcial Propagação síncrona vs propagação assíncrona Propagação assíncrona otimista Rebeca Schroeder Freitas/Vidal Martins Gerenciamento de Dados em Sistemas Par-a-par a 27

28 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Single-master vs multi-master Replicação total vs replicação parcial Propagação síncrona vs propagação assíncrona Propagação assíncrona otimista Single-master vs Multi-master Rebeca Schroeder Freitas/Vidal Martins Gerenciamento de Dados em Sistemas Par-a-par a 28

29 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Single-master vs multi-master Replicação total vs replicação parcial Propagação síncrona vs propagação assíncrona Propagação assíncrona otimista Single-master vs Multi-master Single-master Multi-master Principal diferença Uma cópia primária Múltiplas cópias primárias Sinônimo Master/Slave Update anywhere Controle de concorrência distribuído Não se aplica Coordenação, Reconciliação Valores atualizados em Cópia primária Cópia desconhecida Modelo de atualização Centralizado Distribuído Bloqueio da atualização Queda do site mestre Queda de todos os sites Possível gargalo Sim Não Rebeca Schroeder Freitas/Vidal Martins Gerenciamento de Dados em Sistemas Par-a-par a 29

30 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Single-master vs multi-master Replicação total vs replicação parcial Propagação síncrona vs propagação assíncrona Propagação assíncrona otimista Replicação total vs Replicação parcial Rebeca Schroeder Freitas/Vidal Martins Gerenciamento de Dados em Sistemas Par-a-par a 30

31 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Single-master vs multi-master Replicação total vs replicação parcial Propagação síncrona vs propagação assíncrona Propagação assíncrona otimista Replicação total vs Replicação parcial Replicação total Replicação parcial Principal diferença Todos os sites mantêm cópias de todos os objetos copartilhados Balanceamento de carga Simples Complexo Disponibilidade Máxima Menor Espaço de armazenamento Pode ser caro Reduzido Custos de comunicação Pode ser caro Reduzido Cada site mantém uma cópia de um subconjunto dos objetos compartilhados Rebeca Schroeder Freitas/Vidal Martins Gerenciamento de Dados em Sistemas Par-a-par a 31

32 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Single-master vs multi-master Replicação total vs replicação parcial Propagação síncrona vs propagação assíncrona Propagação assíncrona otimista Propagação síncrona vs Propagação assíncrona Rebeca Schroeder Freitas/Vidal Martins Gerenciamento de Dados em Sistemas Par-a-par a 32

33 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Single-master vs multi-master Replicação total vs replicação parcial Propagação síncrona vs propagação assíncrona Propagação assíncrona otimista Propagação assíncrona Abordagens não otimistas Objetivo: prover one-copy-serializability Premissas A rede provê FIFO reliable multicast Existe um limite máximo (Max) no tempo necessário para propagar uma mensagem de um nodo a outro A diferença entre 2 relógios corretos não é maior que ε Uma transação é propagada em no máximo Max + ε unidades de tempo Assegura-se ordem total sem coordenação entre os sites Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 33

34 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Single-master vs multi-master Replicação total vs replicação parcial Propagação síncrona vs propagação assíncrona Propagação assíncrona otimista Propagação assíncrona Abordagens otimistas Não pretende prover one-copy-serializability Assume que os conflitos são raros ou não acontecem A propagação é feita em background e pode haver divergências entre réplicas Atualizações conflitantes são reconciliadas a posteriori Consistência eventual Definição baseada em equivalência de schedule Dois schedules são equivalentes quando, começando do mesmo estado inicial, produzem o mesmo estado final Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 34

35 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Single-master vs multi-master Replicação total vs replicação parcial Propagação síncrona vs propagação assíncrona Propagação assíncrona otimista Propagação assíncrona Aplicações Serviço de nomes da Internet (DNS) Sistemas de bancos de dados móveis Desenvolvimento colaborativo de software Sistemas colaborativos em geral Rebeca Schroeder Freitas/Vidal Martins Gerenciamento de Dados em Sistemas Par-a-par a 35

36 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Single-master vs multi-master Replicação total vs replicação parcial Propagação síncrona vs propagação assíncrona Propagação assíncrona otimista Propagação síncrona vs assíncrona Síncrona Assíncrona Não otimista Otimista Característica principal Todas as réplicas mudam na mesma transação Commit tão logo quanto possível, depois propagação Commit, depois propagação em background Sinônimos Eager propagation Lazy propagation Lazy propagation Critério de consistência One-copy-serializability Freshness Consistência eventual Leituras locais Controle distribuído de concorrência Retorna valores atualizados Retorna valores atualizados com alta probabilidade Sim Não Não Sem garantias Escalabilidade Dezenas de sites Centenas de sites Maior número de sites Ambiente LAN e cluster LAN, cluster e WAN Qualquer ambiente Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 36

37 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Single-master vs multi-master Replicação total vs replicação parcial Propagação síncrona vs propagação assíncrona Propagação assíncrona otimista Propagação assíncrona otimista Armazenamento das operações Persistente: arquivo de log, propagação da operação Transiente: propagação do estado do objeto Relacionamentos entre operações Happens-before: ordem parcial entre eventos distribuídos Concurrency: não há ordem entre os eventos Explicit constraint Inclusão dinâmica. Determina a semântica do sistema Exemplos: dependência, implicação, escolha,... Implicit constraint Inclusão estática (engine) Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 37

38 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Single-master vs multi-master Replicação total vs replicação parcial Propagação síncrona vs propagação assíncrona Propagação assíncrona otimista Propagação assíncrona otimista Frequência de propagação Quanto mais rápida a propagação, menor a divergência entre as réplicas e a taxa de conflitos Pull On demand Periodicamente Push Tão logo quanto possível Hibrido Propagação push provê o melhor grau de consistência Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 38

39 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Single-master vs multi-master Replicação total vs replicação parcial Propagação síncrona vs propagação assíncrona Propagação assíncrona otimista Propagação assíncrona otimista Detecção e resolução de conflitos Uma operação está em conflito se não pode ser executada com sucesso na ordem estabelecida pelo schedule ao qual pertence Detecção consiste em reconhecer conflitos no schedule Resolução de conflito é a mudança do schedule a fim de remover os conflitos Políticas de detecção de conflitos Sobreposição de atualizações Baseadas em concorrência: tempo da operação Baseadas em semântica: constraints Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 39

40 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Single-master vs multi-master Replicação total vs replicação parcial Propagação síncrona vs propagação assíncrona Propagação assíncrona otimista Propagação assíncrona otimista Resolução de conflitos Manual Operações em conflito são retiradas do schedule Duas versões do objeto são apresentadas ao usuário Usuário cria uma nova versão do objeto (mesclada) Automática Não requer intervenção do usuário Reconciliação Baseada em estado do objeto ou em operação Reconciliador ordinal ou reconciliador semântico Rebeca Schroeder Freitas/Vidal Martins Gerenciamento de Dados em Sistemas Par-a-par a 40

41 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Single-master vs multi-master Replicação total vs replicação parcial Propagação síncrona vs propagação assíncrona Propagação assíncrona otimista Propagação assíncrona otimista Objeto Armazenamento das operações Relacionamento entre operações IceCube Específico da aplicação (documento XML, tabela relacional, etc.) Operações persistentes (ações e restrições são armazenadas em log) Restrições explícitas entre operações; Restrições são criadas dinamicamente pelos usuários e pelo motor de reconciliação Harmony Árvore (documento XML, sistema de arquivo, bookmarks de navegadores web, etc.) Operações transientes (operações de atualização não estão disponíveis) Restrições implícitas para estruturas em árvore; Restrições estão embutidas no motor de reconciliação Propagação Transferência periódica de operações (pull) Transferência de estado, sob demanda Detecção e resolução de conflitos Detecção de conflitos baseada em semântica; Resolução automática de conflito Detecção de conflito baseada em semântica; Resolução manual de conflitos (nós da árvore em conflito não são reconciliados) Reconciliação Abordagem semântica baseada em operação; Recupera ações e restrições de diversos logs locais e constrói um schedule global que é aplicado a todas as réplicas Abordagem semântica baseada em estado; Reconcilia nós correspondentes das árvores de duas réplicas cujos conteúdos divergentes não violam restrições implícitas Consistência Consistêncial eventual Sem garantias Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 41

42 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Replicação em sistemas P2P Napster (super-peer) Replicação passiva: ocorre naturalmente à medida em que os peers requisitam e copiam arquivos uns dos outros JXTA (super-peer) Não oferece replicação de dados Gnutella (versão não-estruturada) Replicação passiva Arquivos estáticos Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 42

43 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Replicação em sistemas P2P Chord Não implementa replicação (delega para a aplicação) Armazenamento do objeto sob diversos identificadores, derivados da chave em nível de aplicação Recriação proativa de replicas perdidas Múltiplas funções de hash para produzir diversos identificadores a partir de uma única chave Replicação multi-master usando timestamp para resolver conflitos de atualização Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 43

44 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Replicação em sistemas P2P CAN Duas abordagens para replicação Usar m funções de hash para mapear uma única chave em m pontos no espaço de coordenadas Otimização do projeto básico da rede CAN que consiste em o nodo n replicar proativamente chaves populares para os seus vizinhos quando n está sobrecarregado Chaves replicadas têm associado um campo time-tolive para desfazer automaticamente o efeito da replicação no final do período de sobrecarga Assume conteúdos read-only Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 44

45 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Replicação em sistemas P2P Tapestry Não implementa diretamente a replicação de objetos, mas oferece toda a infraestrutura necessária a replicação As aplicações podem replicar os dados em múltiplos nodos servidores e depender do Tapestry para recuperar as réplicas mais próximas Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 45

46 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Replicação em sistemas P2P Tapestry Rebeca Schroeder Freitas/Vidal Martins Gerenciamento de Dados em Sistemas Par-a-par a 46

47 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Replicação em sistemas P2P OceanStore Utiliza Tapestry e assume infraestrutura com servidores e links rápidos (aproxima-se da arquitetura em nuvem) Permite atualização concorrente nas réplicas de um objeto (replicação multi-master) Utiliza reconciliação para assegurar consistência A reconciliação é baseada em timestamps O gerenciamento de réplicas ajusta o número e a localização das réplicas de modo a responder com maior eficiência as requisições Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 47

48 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Replicação em sistemas P2P Pastry Não implementa replicação diretamente, mas provê as funcionalidades necessárias para uma aplicação sobre Pastry produzir e recuperar réplicas A aplicação pode armazenar réplicas de um objeto com chave key nos k nodos que possuem identificadores próximos de key Pastry roteia uma mensagem que procura pela chave key para os k nodos cujos identificadores são próximos de key Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 48

49 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Replicação em sistemas P2P P-Grid A replicação é feita por meio de rumor spreading Provê garantias probabilísticas de consistência A propagação das atualizações é feita em duas fases Push: quando o peer p recebe uma atualização no objeto replicado R, p propaga a atualização para um conjunto de peers que mantêm réplicas de R que, por sua vez, repetem essa operação Pull: peers que desconectaram e reconectaram, que ficaram muito tempo sem update e que receberam uma requisição pull, entram na fase pull e fazem reconciliação Rebeca Schroeder Freitas/Vidal Martins rebeca.schroeder@gmail.com/vidal.martins@pucpr.br Gerenciamento de Dados em Sistemas Par-a-par a 49

50 Motivação Redes par-a-par Fundamentos de replicação de dados Replicação de dados em sistemas par-a-par Replicação em sistemas P2P Sistema Rede Data Autonomia Tipo de Detecção de Consistência Premissas P2P P2P Type Replicação conflito da Rede Napster Super-peer File Moderada Dado estático Fraca JXTA Super-peer Any Alta Fraca Gnutella Não-estruturada File Alta Dado estático Fraca Chord Estruturada (DHT) Any Baixa Single-master Concurrency Probabilística Multi-master None Probabilística Fraca CAN Estruturada (DHT) Any Baixa Dado estático Multi-master None Probabilística Fraca Tapestry Estruturada (DHT) Any Alta Fraca Pastry Estruturada (DHT) Any Baixa Fraca OceanStore Estruturada (DHT) Any Alta Multi-master Concurrency Eventual Forte P-Grid Structured File Alta Multi-master None Probabilística Fraca Rebeca Schroeder Freitas/Vidal Martins Gerenciamento de Dados em Sistemas Par-a-par a 50

51 Gerenciamento de Dados em Sistemas Par-a-Par (Parte II) Rebeca Schroeder Freitas UFPR Vidal Martins - PUC-PR ERBD 2011 Novo Hamburgo/RS

52 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Apresentação Introdução Roteiro Sistemas P2P e Banco de Dados Segundo [Valduriez, P e Pacitti E. 2004]: SGBDs Distribuído Federado Paralelo baseado em P2P Escalabilidade Até dezenas de BDs Até centenas de fontes de dados Até centenas de nodos Ilimitada Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 5 2

53 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Apresentação Introdução Roteiro Sistemas P2P e Banco de Dados Tornar bancos de dados altamente escaláveis e tolerantes a falhas; Sustentar um serviço de consulta e armazenamento sobre um grande conjunto de dados; Alavancar diversas tecnologias existentes: Exemplo: DHT sob um banco de dados relacional. Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 5 3

54 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Apresentação Introdução Roteiro Roteiro (Parte II) Classificação de BDs P2P; : OLTP; OLAP; Arquiteturas para o Gerenciamento de Dados: Clássica; Particionamento; Replicação; Controle distribuído; Caching; Serviços para o gerenciamento de dados: Amazon Web Services; Google AppEngine; MS Azure; Considerações Finais. Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 5 4

55 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Chave-valor Classificação de BDs P2P Classificação conforme modelo empregado: Chave-valor; Documento; Tabular; Chave-valor: baseados em valores e um índice para encontrá-los a partir de uma chave definida pelo usuário: chave rua valor Piratuba número 3212 cep Exemplos de alguns datastores: Voldemort (LinkedIn), Dynamo, Riak, Redis, Scalaris, Bamboo Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 5 5

56 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Orientados a Documento Classificação de BDs P2P Orientados a Documento: definem uma chave para um conjunto de pares atributovalor domínio Atributo valor endereço rua Piratuba número 3212 cep Exemplos de alguns datastores: SimpleDB, CouchDB, MongoDB. Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 5 6

57 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Tabulares Classificação de BDs P2P Tabulares: seu modelo de dados base contém linhas e colunas, sendo que ambos são fragmentados sobre os nós da rede. Rua número Cep Piratuba Dr Paulo Colin XV de novembro Exemplos de alguns datastores: BigTable, HBase, HyperTable, Cassandra. Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 5 7

58 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais OLTP OLAP Requisitos gerais: Altamente dinâmico; Disponibilidade; Desempenho; Escalabilidade; Consistência; Custo; Funcionalidades comuns em SGBDs tradicionais são implementadas por aplicações sobre o sistema. Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 5 8

59 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais OLTP OLAP OLTP (Online Transaction Processing): O mais comum; Transações curtas; Em geral, acessam pequenas porções de dados; Requer tempo de resposta baixo; Operações de atualização são freqüentes; Exige consistência forte. Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 59

60 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais OLTP OLAP OLAP (Online Analytical Processing) Grandes volumes de dados; Processamento paralelo; Transações longas; Workload principal de leitura; Requisitos de consistência são relaxados; Arquitetura em cluster; Processamento comum neste contexto: Hadoop (MapReduce). Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 60

61 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais OLTP OLAP Hadoop: Inspirado no Google MapReduce e no Google File System; Consegue ordenar 100 TB em 173 minutos sobre 3400 nodos; MapReduce: um modelo de programação: Automaticamente distribui consultas para executar em paralelo; Função Map: Entrada: chave, valor: Saída: lista de resultados intermediários (chave e valor ); Função Reduce Entrada: lista de resultados intermediários (chave e valor ); Saída: lista de valores finais. Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 61

62 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais OLTP OLAP Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 62

63 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Clássica com Particionamento com Replicação com Controle Distribuído com Caching Arquiteturas para Gerenciamento de Dados Oferta de serviços como um pacote de tecnologias da computação nas nuvens; Redução de custos com modelo pay-as-you-go: Melhor utilização de recursos computacionais; Throughput ilimitado: Adição de servidores a medida que o workload aumenta; Foco em processamento de transações (OLTP); Players: Amazon AWS RDS, AWS SimpleDB e AWS S3; Google Google AppEngine; Microsoft MS Azure. Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 63

64 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Clássica com Particionamento com Replicação com Controle Distribuído com Caching Arquitetura Clássica Fonte: [Kossmann et al 2010] Escalabilidade e elasticidade: Servidores de requisição; Sistemas de armazenamento; Servidor de BD: Único ponto de falha; Limitações de custo e escalabilidade. Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 64

65 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Clássica com Particionamento com Replicação com Controle Distribuído com Caching Arquitetura com Particionamento Fonte: [Kossmann et al 2010] Servidores de BD podem rodar em máquinas mais baratas; Mais máquinas operando sobre conjuntos de dados menores; Limitações de escalabilidade: workloads dinâmicos; reparticionamento de dados; Combinado com replicação pode melhorar escalabilidade e tolerância a falhas. Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 65

66 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Clássica com Particionamento com Replicação com Controle Distribuído com Caching Particionamento Abordagens tradicionais de particionamento/fragmentação: Alunos: código Horizontal (seleções); Vertical (projeções); Mista. nome sexo idade horizontal Chave Alunos/1 Alunos/2... n valor (nome:igor, sexo:m, idade:21) (nome:rute, sexo:f, idade:19)... (nome:nome n, sexo:sexo n, idade:idade n ) n Igor Rute Ivan... nome n m f m idade n vertical mista Chave Alunos/nome Alunos/sexo Alunos/idade Chave valor (1, Igor) (2, Rute)... (n, nome n ) (1, m) (2, f)... (n, sexo n ) (1, 21) (2, 19)... (n, idade n ) valor Alunos/idade/20 (código:2, nome:rute) Vidal Martins Rebeca Schroeder Freitas Alunos/idade/30 (código:1, nome:igor) (código:3, nome:ivan)..

67 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Clássica com Particionamento com Replicação com Controle Distribuído com Caching Particionamento Experimento 1 [Ribas, E. et al 2010]: Uma relação com 2000 tuplas e 51 atributos; 70 nodos; Operações de leitura que selecionam todas as tuplas, variando o número de atributos na projeção. Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 67

68 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Clássica com Particionamento com Replicação com Controle Distribuído com Caching Particionamento Diversos níveis de granularidade: Alunos: código nome sexo idade 1 Igor m 21 2 Rute f 19 alta Chave Alunos/1/nome Alunos/1/sexo... valor Igor M 3... n Ivan... nome n m idade n baixa Chave Alunos Valor (código:1, nome:igor, sexo:m, idade:21) (código:2, nome:rute, sexo:f, idade:19) (código:3, nome:ivan, sexo:m, idade:22)... Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 68

69 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Clássica com Particionamento com Replicação com Controle Distribuído com Caching Agrupamento Alguns repositórios chave-valor mantêm localidade de dados; Torna possível diferentes formas de agrupamento de acordo com as chaves; Executar transações de forma distribuída prejudica performace; Exemplo: Chave Valor Chave Valor Alunos/nome/1 Igor Alunos/1/nome Igor Alunos/nome/2 Rute Alunos/1/idade 21 Alunos/idade/1 21 Alunos/2/nome Rute Alunos/idade/2 19 Alunos/2/idade 19 Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 69

70 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Clássica com Particionamento com Replicação com Controle Distribuído com Caching Particionamento e Agrupamento Experimento 2: Representação de documentos XML no Scalaris; Fragmentação baseada em workload; 16 nodos; Transação Order-Status do TPC-C; 18% melhor com fragmentação; 10% melhor com agrupamento; Em alguns casos a melhora chegou a 68%. Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 70

71 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Clássica com Particionamento com Replicação com Controle Distribuído com Caching Arquitetura com Replicação Cada servidor de BD controla uma cópia do BD inteiro ou de parte dele; Pode melhorar escalabilidade e confiabilidade para workloads de leitura; Fonte: [Kossmann et al 2010] Limitações de escalabilidade: workloads com atualizações freqüentes; Master se torna o gargalo. Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 71

72 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Clássica com Particionamento com Replicação com Controle Distribuído com Caching Arquitetura com Replicação Principal protocolo: ROWA (Read once, write all); O principal aspecto inerente a replicação é o mecanismo para manter as réplicas consistentes; Pode ser transparente ou não: Não transparente: atualizações são direcionadas para o servidor Master; Transparente: atualizações são automaticamente roteadas para o servidor Master. Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 72

73 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Clássica com Particionamento com Replicação com Controle Distribuído com Caching Arquitetura com Controle Distribuído Fonte: [Kossmann et al 2010] Sistema de armazenamento é desacoplado do servidor de BD; Servidor de BD acessa os dados de forma concorrente e autônoma; Potencialmente a melhor arquitetura (escalabilidade em todos os níveis). Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 73

74 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Clássica com Particionamento com Replicação com Controle Distribuído com Caching Arquitetura com Controle Distribuído Não é possível assegurar o teorema CAP (Consistency, Availability, Partition Tolerance): Não é possível garantir as três propriedades ao mesmo tempo; Em geral, a consistência é sacrificada (consistência eventual); Situação adequada para OLAP mas não para OLTP. Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 74

75 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Clássica com Particionamento com Replicação com Controle Distribuído com Caching Arquitetura com Controle Distribuído Alguns tipos de consistência: Eventual (Fraca): Operações de escrita podem não refletir em leituras subseqüentes; Maioria dos repositórios p2p; Snapshot Isolation: Consistência forte sobre uma única visão instantânea e consistente dos dados; Forte: Provida por Scalaris e G-Store; No Scalaris a disponibilidade pode ser parcialmente sacrificada. Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 75

76 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Clássica com Particionamento com Replicação com Controle Distribuído com Caching Arquitetura com Caching Resultados de consultas são armazenados em servidores dedicados (MemCache); Diversos meios para manter a cache consistente; Fonte: [Kossmann et al 2010] Fonte: [Kossmann et al 2010] Arquitetura deve ser combinada com outras; Arquitetura aplicada pelo Google AppEng. Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 76

77 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Amazon Web Services Google AppEngine MS Azure Tipos de Serviços Disponíveis Infrastructure as a service (IaaS): Infra-estrutura computacional; Ciclos de CPU, armazenamento e rede; Platform as a service (PaaS): Plataforma para o desenvolvimento de aplicações; Software as a service (SaaS): Software oferecido como um serviço; Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 77

78 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Amazon Web Services Google AppEngine MS Azure Amazon AWS Serviços básicos: EC2 (Elastic Compute Cloud) : ciclos de CPU; Máquinas virtuais hospedadas em um dos servidores Amazon; EBS (Elastic Block Store): Blocos de armazenamento persistentes para aplicações rodando no EC2; Serviço de armazenamento que pode ser montado como um disco. Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 78

79 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Amazon Web Services Google AppEngine MS Azure AWS RDS (Relational Database Service) Número de máquinas EC2 pode variar conforme o workload para suportar servidor web e de aplicação; Uma máquina EC2 com o SGBD MySQL; EBS: armazenamento do BD e logs: EBS replica dados para garantir disponibilidade; Cinco tamanhos para servidores de BD: Custos variam conforme o tamanho escolhido. Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 79

80 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Amazon Web Services Google AppEngine MS Azure Comparativo Aspectos AWS RDS AWS SimpleDB AWS S3 Arquitetura Clássica Part + Repl. C. Distribuído Google App Eng. Part.+Repl+ Cache Modelo PaaS PaaS IaaS PaaS PaaS MS Azure Replicação Provedor Amazon Amazon Flexível Google Microsoft SGBD MySQL SimpleDB - DataStore SQL Azure Storage EC2 & EBS - S3 GFS Windows Azure Linguagem SQL SimpleDB Baixo nível GQL SQL Consistência Eventual Eventual Eventual Snapshot Isolation Fonte: [Kossmann et al 2010] Snapshot Isolation Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 80

81 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Amazon Web Services Google AppEngine MS Azure AWS SimpleDB SimpleDB - Serviço de BD próprio da Amazon: Permite operações de inserção, atualização e remoção de registros; Permite busca por valores de chaves, ou intervalos de valores sobre as chaves primárias ou secundárias; Consistência eventual; Embora não-relacional, apresenta correspondências: Domínios (tabelas): máximo 100; Itens (tuplas): coleção de pares atributo-valor; no máximo 256 atributos por item; Atributos (colunas): Podem conter valores múltiplos. Linguagem de consulta própria Similar a SQL; Só pode ser feita sobre um domínio (sem joins) Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 81

82 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Amazon Web Services Google AppEngine MS Azure Comparativo Aspectos AWS RDS AWS SimpleDB AWS S3 Arquitetura Clássica Part + Repl. C. Distribuído Google App Eng. Part.+Repl+ Cache Modelo PaaS PaaS IaaS PaaS PaaS MS Azure Replicação Provedor Amazon Amazon Flexível Google Microsoft SGBD MySQL SimpleDB - DataStore SQL Azure Storage EC2 & EBS SimpleDB S3 GFS Windows Azure Linguagem SQL SimpleDB Baixo nível GQL SQL Consistência Eventual Eventual Eventual Snapshot Isolation Fonte: [Kossmann et al 2010] Snapshot Isolation Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 82

83 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Amazon Web Services Google AppEngine MS Azure AWS S3 S3: Provê uma interface de baixo nível (put/get); Serviços de mais alto-nível como interfaces de consultas e indexação devem ser implementadas a parte; Pode utilizar o SQS (Simple Queueing System): Fila persistente provida pela Amazon; Implementa os protocolos básicos que garantem durabilidade e consistência eventual. Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 83

84 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Amazon Web Services Google AppEngine MS Azure AWS S3 Uso gratuito*: Armazenamento: 5 GB; Requisições get: ; Requisições put: 2.000; Transferência (entrada): 15 GB; Transferência (saída): 15 GB; * Para usuários novos durante 1 ano. Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 84

85 Classificação de BDs P2P Arquiteturas para o Gerenciamento de Dados Serviços para o Gerenciamento de Dados Considerações Finais Amazon Web Services Google AppEngine MS Azure Comparativo Aspectos AWS RDS AWS SimpleDB AWS S3 Arquitetura Clássica Part + Repl. C. Distribuído Google App Eng. Part.+Repl+ Cache Modelo PaaS PaaS IaaS PaaS PaaS MS Azure Replicação Provedor Amazon Amazon Flexível Google Microsoft SGBD MySQL SimpleDB - DataStore SQL Azure Storage EC2 & EBS - S3 GFS Windows Azure Linguagem SQL SimpleDB Baixo nível GQL SQL Consistência Eventual Eventual Eventual Snapshot Isolation Fonte: [Kossmann et al 2010] Snapshot Isolation Vidal Martins Rebeca Schroeder Freitas Gerenciamento de Dados em Sistemas P2P 85