Cap. 07 Consistência e Replicação

Cap. 07 Consistência e Replicação 7.1 Introdução 7.1.1 Razões para a Replicação 7.1.2 Replicação como Técnica de Escalabilidade 7.2 Modelos de Consistência Data-Centric 7.2.1 Consistência Contínua 7.2.2 Ordenação Consistente de Operações 7.3 Modelos de Consistência Client-Centric 7.3.1 Consistência Eventual 7.3.2 Leituras Monotônicas 7.3.3 Escritas Monotônicas Pg. 1/116

Cap. 07 Consistência e Replicação 7.3 Modelos de Consistência Client-Centric... 7.3.4 Leia suas Escritas 7.3.5 Escritas seguem Leituras 7.4 Gerenciamento de Replicação 7.4.1 Possicionamento do Servidor de Réplica 7.4.2 Localização e Replicação de Conteúdo 7.4.3 Distribuição de Conteúdo Pg. 2/116

Cap. 07 Consistência e Replicação 7.5 Protocolos de Consistência 7.5.1 Consistência Contínua 7.5.2 Protocolo Primary Based 7.5.3 Protocolo Replicated-Write 7.5.4 Protocolo Cache-Coherence 7.5.5 Implementação de Consistência Client-Centric Pg. 3/116

Referências Bibliográficas Andrew S. Tanenbaum; Maarten van Steen - Distributed Systems: Principles and Paradigms, Prentice-Hall, 2007, ISBN-10: 0132392275, ISBN-13: 9780132392273 Lectures dos autores Andrew S. Tanenbaum e Maarteen van Steen ( www.cs.vu.nl e www.distributed-systems.net/ ) George Coulouris; Jean Dollimore; Tim Kindberg Sistemas Distribuídos: Conceitos e Projeto, Bookman, 4th Edition, 2007, ISBN 9788560031498 Notas de Aula do Prof. Ricardo Anido do Instituto de Computação (IC) da UNICAMP - www.ic.unicamp.br/~ranido/ Pg. 4/116

7 Consistência e Replicação 7 Consistência e Replicação Replicação de Dados - consiste em manter múltiplas cópias de dados, chamadas de réplicas, em diferentes computadores. problema - manter a consistência entre as cópias, ou seja, quando um cópia é atualizada é necessário garantir que todas as outras cópias sejam também atualizadas. 1a Abordagem - Leslie Lamport (1978) - Times, Clocks, and the Ordering of Events in a Distributed System tema de interesse em sistemas distribuídos e em banco de dados, mas sob diferentes aspectos. Pg. 5/116

7 Consistência e Replicação 7 Consistência e Replicação contexto - modelos de consistência para dados compartilhados são difíceis de serem implementados eficientemente em sistemas distribuídos de larga escala; duas questões constituem os principais aspectos de projeto de implementação dos modelos de consistência: gerenciamento de réplicas e como réplicas são mantidas. Pg. 6/116

7 Consistência e Replicação 7.1 Introdução 7.1.1 Razões para a Replicação reliability - dependability, or reliability, describes the ability of a system or component to function under stated conditions for a specified period of time [Wikipedia 2014] availability - the ratio of (a) the total time a functional unit is capable of being used during a given interval to (b) the length of the interval [Wikipedia 2014] São várias as razões para replicação, das quais se destacam: confiabilidade - réplicas garantem que não haverá um único ponto de falha no sistema. disponibilidade - réplicas propiciam o aumento da disponibilidade do sistema como consequência da confiabilidade. Pg. 7/116

7 Consistência e Replicação 7.1 Introdução 7.1.1 Razões para a Replicação razões para replicação, das quais se destacam: transparência de falha - em caso de falha, o usuário pode ser movido para outra réplica sem notar que a falha ocorreu. desempenho - balanceamento de carga, uso de cache, escalabilidade geográfica, aumento do sistema. consistência de dados - processo para manter uma informação uniforme conforme ela se move em uma rede ou entre vários processos de um computador. Obs.: fato de existir múltiplas cópias de dados, objeto de leitura e escrita de vários processos, gera o problema de inconsistência. Pg. 8/116

7 Consistência e Replicação 7.1 Introdução 7.1.2 Replicação como Técnica de Escalabilidade Replicação e Caching são largamente utilizadas como técnicas de escalabilidade para efeito de desempenho; questões de escalabilidade normalmente aparecem na forma de problemas de desempenho, assim: disponibilizar cópias de dados próximas aos processos que as utilizam pode melhorar o desempenho pela redução do tempo de acesso e, assim, resolver problemas de escalabilidade. dilema - modificação desses dados em uma réplica exige que as outras cópias sejam atualizadas para manter a consistência. dilema - propagar a modificação para cada réplica é um processo caro e pode causar perda de desempenho no sistema. Pg. 9/116

7 Consistência e Replicação 7.1 Introdução 7.1.2 Replicação como Técnica de Escalabilidade em muitos casos, a única solução é diminuir as restrições de consistência, ou seja, não exigir que a atualização seja executada como uma operação atômica => ganho de desempenho. nesta abordagem, evita-se a sincronização global (instantânea) dos dados => ganho de desempenho. Pg. 10/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2 Modelos de Consistência Data-Centric contexto - modelos de consistência são analisados tradicionalmente por meio de operações de leitura/escrita sobre dados compartilhados (memória ou banco de dados compartilhado). data store - pode se encontrar fisicamente distribuído em diferentes máquinas e com as sequintes características: cada processo pode acessar dados do repositório através de um cópia local de todo o conteúdo do repositório; operações de escrita são propagadas para todas as cópias; operação de dados é classificada como escrita quando altera o dado, diferentemente da operação de leitura. Pg. 11/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2 Modelos de Consistência Data-Centric Fig. 7.1 Organização geral de um Data Store, fisicamente distribuído e replicado sobre múltiplos processos. Pg. 12/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2 Modelos de Consistência Data-Centric consistency model - é essencialmente o contraste entre os processos e o repositório de dados, no sentido das regras acordadas entre os mesmos para manter a consistência. processos que realizam a leitura de um dado esperam que o valor retornado seja o valor da última escrita nesse dado; na ausência de um relógio global, é difícil definir qual operação de escrita é a última no contexto de sistemas distribuídos; assim, modelos de consistência restringem os valores que uma operação de leitura pode retornar sobre um item de dados. Pg. 13/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.1 Consistência Contínua Yu e Vehdat (2002) propõem 03 classes de inconsistências: desvio de valores numéricos entre réplicas ; desvio de idade entre réplicas; desvio em relação à ordenação de operações de escrita. desvio de valor numérico - ocorre em aplicações onde os dados possuem semântica numérica. solução óbvia - definir um desvio numérico absoluto ou relativo entre os valores assumidos pelas cópias, assim:... enquanto os valores estiverem dentro do limite estabelecido de desvio, serão considerados como consistentes. Pg. 14/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.1 Consistência Contínua desvio de valor numérico - também pode ser entendido como o nro. de atualizações aplicadas a uma réplica, mas ainda não disponíveis para as demais réplicas. e.g., réplicas de registros de preços de ações desvio numérico absoluto - preço de uma ação entre as réplicas não deve variar mais que $ 0,02; desvio númerico relativo - diferença entre o valor de duas cópias não deve ser maior 5%. Pg. 15/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.1 Consistência Contínua desvio de idade - relacionado com a diferença de tempo da data da versão atual para a data da última atualização. e.g., réplica de uma previsão de tempo será considerada consistente por uma hora, independente do número de atualizações que ocorram nesse período. Pg. 16/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.1 Consistência Contínua desvio de ordenação - ordem das operações de atualização em cada réplica podem ser diferentes dentro de um certo limite. correções são feitas alterando a ordem dessas atualizações antes de persistí-las em definitivo. Obs.: dependência de um acordo global de atualização, pode reverter atualizações já completadas para na sequência aplicá-las em uma ordem diferente de modo que se tornem permanentes. Pg. 17/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.1 Consistência Contínua Yu e Vehdat (2002) introduziram o conceito de unidade de consistência ou Consistency Unit ou conit - especifica a unidade sobre a qual a consistência deve ser medida; ou seja, um conit pode ser definido como um registro representando 01 estoque único ou relatório individual de tempo. e.g., considere 02 réplicas A e B com um conit contendo os itens de dados x e y ; cada réplica contém um relógio vetorial bidimensional VC i (Cap. 06), com a notação t, i expressando que uma operação foi realizada pela réplica i no tempo lógico t (tempo local). Pg. 18/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.1 Consistência Contínua Fig. 7.2 Exemplo do rastreamento do desvio de consistência extraído do artigo Yu e Vehdat (2002). Pg. 19/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.1 Consistência Contínua Note que há a uma negociação entre conits com granularidade fina e conits com granularidade grossa; e.g. considere um conit como um banco de dados completo, assim a atualização de dados está condicionada a todo o conjunto de dados naquele unidade de consistência; como consequência, este cenário pode produzir réplicas rápidas não consistentes estado inconsistente. e.g., considere 02 réplicas que se diferem não mais do que por uma única atualização contexto de granularidade grossa, ou seja, um conit consiste de 02 itens de dados (Fig. 7.3) Pg. 20/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.1 Consistência Contínua Fig. 7.3 Escolha da granularidade correta de um conit. a. 02 atualizações disparam uma propagação de atualização. Pg. 21/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.1 Consistência Contínua Fig. 7.3 Escolha da granularidade correta de um conit. a. 02 atualizações disparam uma propagação de atualização. b. não há a necessidade de propagação de atualização. Pg. 22/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.1 Consistência Contínua conits grandes - levam a réplica ao estado de inconsistência mais rápido quando comparada com conits pequenos. conits pequenos - aumentam o número de conits que precisam ser gerenciadas e, por consequência, afetam o desempenho. Obs.: para implementação deste mecanismos, faz-se necessário criar protocolos de consistência, por outro lado, identificar os seus requisitos não é uma tarefa nada fácil. Pg. 23/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.2 Ordenação Consistente de Operações Nesta seção, discutiremos operações ordenadas de forma consistente sobre dados compartilhados e replicados. neste contexto, quando tentativas de atualização em réplicas necessitam ser concluídas, as réplicas terão que acordar quanto a ordenação global destas atualizações. é necessário que as réplicas concordem na ordenação consistente das atualizações para garantir a consistência. Pg. 24/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.2 Ordenação Consistente de Operações Para melhor entendimento dos modelos a serem discutidos, processos realizam operações de escrita Wi(x)a e leitura Ri(x)a sobre dados ao longo do tempo, para tanto, seja a notação: Wi(x)a Processo Pi escreve/atualiza o dado x com o valor a ; Ri(x)b Processo Pi lê o dado x retornando o valor b eixo x representa o tempo que cresce da esquerda para a direita. Fig. 7.4 Comportamento de 02 processos operando sobre o mesmo item de dado x com operações de escrita e leitura. Pg. 25/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.2 Ordenação Consistente de Operações Fig. 7.4 Comportamento de 02 processos operando sobre o mesmo item de dado x com operações de escrita e leitura. Wi(x)a é inicialmente realizada sobre uma cópia local do repositório de dados para P1 e, subsequentemente, é propagada para as outras cópias do repositório de dados; P2 lê mais tarde o valor NIL e algum tempo depois o valor a da sua cópia local do repositório de dados; leva-se um tempo para propagar a atualização de x para P2, o que é perfeitamente aceitável. Pg. 26/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.2 Ordenação Consistente de Operações consistência sequencial - importante no modelo de consistência centrado em dados, foi definida por Lamport em 1979 no contexto de memória compartilhada de sist. multiprocessados. definição - resultado de qualquer execução é o mesmo que seria se as operações de leitura e escrita fossem executadas em alguma ordem sequencial por todos os processos no repositório; onde, as operações de cada processo aparecem nesta sequência em uma ordem especificada pelo seu programa. Obs.: definição sugere que quando processos executam concorrentemente em diferentes máquinas, um entrelaçamento válido de operações de leitura e escrita é aceitável, desde que todos os processos enxerguem o mesmo entrelaçamento. Pg. 27/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.2 Ordenação Consistente de Operações neste contexto, um processo enxerga writes de todos os processos, mas somente seus próprios reads. Fig. 7.5 a. consistência sequencial do repositório de dados; b. repositório de dados sem consistência sequencial. Pg. 28/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.2 Ordenação Consistente de Operações a. mostra um depósito de dados sequencialmente consistente, apesar de P3 e P4 terem lido um valor antigo; b. mostra um depósito de dados não consistente porque P3 e P4 não enxergam a mesma intercalação de operações de escrita. Fig. 7.5 a. consistência sequencial do repositório de dados; b. repositório de dados sem consistência sequencial. Pg. 29/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.2 Ordenação Consistente de Operações e.g., considere 03 processos executando concorrentemente onde os itens de dados são formados por 03 variáveis x, y e z de um repositório de dados compartilhado. variáveis são inicializadas com o valor 0 ; operação de atribuição corresponde a operação de escrita; declaração de impressão corresponde a 02 operações de leitura. Fig. 7.6 03 processos executando concorrentemente. Pg. 30/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.2 Ordenação Consistente de Operações análise - 06 declarações, 720 (6*5*4*3*2*1 = 6!) sequências de execução são possíveis, ainda que algumas sejam inválidas; são 120 (5!) sequências que iniciam com x 1, ½ das quais tem print(x,z) antes de y 1 o que viola a sequência no prog.; ½ das sequências tem print(x,y) antes de z 1, o que também viola a ordem do programa; análise semelhante cabe para sequências iniciadas por y 1 e sequências iniciadas por z 1 ; deste total, 90 sequências são válidas, 30 iniciando com x 1, 30 iniciando com y 1 e 30 com z 1. Pg. 31/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.2 Ordenação Consistente de Operações Fig. 7.7 04 sequências válidas de execução para os processos P1, P2, e P3 como mostrados na Fig. 7.6. eixo imaginário na vertical representa a linha do tempo. Pg. 32/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.2 Ordenação Consistente de Operações signature - concatenação das saídas de P1, P2, e P3, nesta ordem, formando um string de 06 bits que caracteriza uma sequência particular de comandos / declarações. nem todas as 64 combinações de bits são válidas: p.ex., 000000 não é permitida pois implica que as declarações print(y,z), print(x,z) e print(x,y) são executadas antes de x 1, y 1, z 1 viola a ordem de execução definida pelos programas. p.ex., 001001 também não é permitida, pois se assumirmos que P1 inicia a execução, então os 02 primeiros bits representam print(y,z) ; os próximos 02 bits 10 significam que P2 deve executar depois de P1 e antes de P3 e os últimos 02 bits 01 significam que P3 deve executar antes de P1 executar, mas já vimos que P1 deve executar primeiro. Pg. 33/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.2 Ordenação Consistente de Operações consistência causal - proposto por Hutto e Ahamad (1990) representa uma consistência sequencial fraca para garantir concorrência em memória compartilhada distribuída. faz distinção entre eventos potencialmente relacionados por causalidade e os que não são relacionados por causalidade. e.g., se o evento b é causado ou influenciado por um evento anterior a, todos devem ver primeiro a e depois b. Obs.: operações não relacionadas por causalidade são comumente denominadas concorrentes. Pg. 34/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.2 Ordenação Consistente de Operações consistência por causalidade - data store é considerado consistente por causalidade se satisfaz a seguinte condição: escritas que são potencialmente relacionadas por causalidade devem ser vistas por todos os processos na mesma ordem; escritas concorrentes,ou seja, sem relação de causalidade, podem ser vistas em ordem diferente em máquinas diferentes. implementação - consistência causal exige que as dependências entre operações seja monitorada, o que pode ser feito com o uso de marcas de tempo vetoriais. e.g., como exemplo de consistência causal, considere 04 processos P1, P2, P3 e P4 e uma sequência de eventos. Pg. 35/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.2 Ordenação Consistente de Operações e.g., como exemplo de consistência causal, considere 04 processos P1, P2, P3 e P4 e uma sequência de eventos. W2(x)b e W1(x)c são concorrentes, assim não é exigido que todos os processos enxerguem estas operações na ordem. Fig. 7.8 Sequência de eventos com consistência de causalidade, mas não com consistência sequencial. Pg. 36/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.2 Ordenação Consistente de Operações a. W2(x)b potencialmente depende W1(x)a porque b pode ser um resultado envolvendo o resultado do cálculo de a - R 2(x)a ; 02 operações de write estão relacionadas pela relação de causalidade, assim todos os processos devem exergar todas estas operações na mesma ordem. Fig. 7.9 a. violação da consistência de causalidade; b. sequência correta de eventos com consistência de causalidade. Pg. 37/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.2 Ordenação Consistente de Operações b. W2(x)b potencialmente concorre com W1(x)a, pois a operação R2(x)a foi removida de P2; consistência de causalidade não requer que escritas concorrentes sejam globalmente ordenadas. Fig. 7.9 a. violação da consistência de causalidade; b. sequência correta de eventos com consistência de causalidade. Pg. 38/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.2 Ordenação Consistente de Operações consistência causal e sequencial - definidas no nível (granularidade) de operações de leitura e escrita por razões históricas; em muitos casos este nível de granularidade fino não atende a granularide suportada pela aplicações; Normalmente, compartilhamento de dados é mantido através de mecanismos de sincronização para sincronização, enquanto as transações mantém o controle de concorrência. ENTER_CS - significa que o dado no armazenamento local está atualizado, ou seja, leituras e escritas podem ser realizadas; ao terminar as operações o processo invoca LEAVE_CS, protegendo as operações do acesso concorrente. Obs.: operações são atomicamene executadas como unidades. Pg. 39/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.2 Ordenação Consistente de Operações Neste ponto, é necessário dar semântica às operações ENTER_CS e LEAVE_CS através de variáveis de sincronização; dentre as possíveis maneiras, em uma abordagem geral cada variável tem um dado associado que pode ser equivalente a um conjunto de dados compartilhados; processo deve ter a posse das variáveis de sincronização para executar ENTER_CS, assim como deve liberar as variáveis de sincronização quando for executar LEAVE_CS. Obs.: Processos podem simultaneamente compartilhar uma variável de sincronização em modo não exclusivo, ou seja, podem ler mas não escrever no dado associado. Pg. 40/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.2 Ordenação Consistente de Operações 03 critérios devem ser satisfeitos: 01 - aquisição de acesso para uma variável de sincronização não é concedida a um processo até que todas as atualizações referentes aos dados compartilhados seja realizada; ou seja, todas as mudanças para um dado compartilhado devem se tornar visíveis, ou seja, devem ser atualizados. 02 - nenhum outro processo pode manter a variável de sincronização, nem mesmo no modo não exclusivo, antes que o acesso no modo exclusivo para uma variável seja concedido; ou seja, antes de atualizar um dado compartilhado, um processo precisa entrar na região crítica em modo exclusivo. Pg. 41/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.2 Ordenação Consistente de Operações 03 critérios devem ser satisfeitos: 03 - após a concessão do acesso no modo exclusivo para uma variável de sincronização, o acesso ao modo não exclusivo por um outro processo para a variável de sincronização não pode ser realizado até que ele tenha consultado o dono da variável; ou seja, se um processo deseja entrar na região crítica no modo não exclusivo, é necessário primeiro verificar como o proprietário da variável de sincronizaçãoa a mais recente cópia do dado compartilhado. Pg. 42/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.2 Ordenação Consistente de Operações e.g., considere o exemplo de consistência de entrada, ou seja, em vez de operar o dado compartilhado por completo, locks são associados a cada item do dado compartilhado. Acq(Lx) Acquire for x Rel(Ly) Release for y Fig. 7.10 Sequência válida de eventos para a consistência de entrada itens x e y compondo o dado compartilhado. Pg. 43/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.2 Ordenação Consistente de Operações problema da consistência de entrada - associar adequadamente o dado com variáveis sincronização; abordagem simples - explicitar ao middleware quais dados serão acessados, semelhante quando é informado quais tabelas serão afetadas em uma transação. consistência versus coerência - importante entender a diferença entre 02 conceitos que estão relacionados. e.g., considere o cenário de um conjunto de processos que executam operações de leitura/escrita em um conj. de dados. Pg. 44/116

7 Consistência e Replicação 7.2 Modelos de Consistência Data-Centric 7.2.2 Ordenação Consistente de Operações e.g., considere o cenário de um conjunto de processos que executam operações de leitura/escrita em um conj. de dados. Modelo de Consistência - descreve o que se espera de um conjunto de itens de dados quando vários processos operam de forma concorrente. Modelo de Coerência - descreve o que se espera de um único item de dado replicado em vários lugares quando cada cópia é submetida a um conj. de regras do modelo de coerência. e.g., modelo de consistência sequencial aplicado a um único item de dado, na prática, ocorrendo operações de escritas concorrentes, todos os processos eventualmente verão a mesma ordem de updates. Pg. 45/116

7 Consistência e Replicação 7.3 Modelos de Consistência Client-Centric 7.3 Modelos de Consistência Client-Centric Os modelos de consistência descritos anteriormente tem por objetivo prover uma consistência global do repositório de dados; ou seja, a suposição é a de processos concorrentes podem simultaneamente atualizar o repositório e, assim, é necessário consistência face a concorrência entre os mesmos. e.g., em modelos baseados em objetos, o repositório garante que uma cópia atual do objeto será fornecida ao processo chamador; durante a chamada, nenhum outro processo pode interferir, ou seja, acesso exclusivo é concedido ao processo chamador. Pg. 46/116

7 Consistência e Replicação 7.3 Modelos de Consistência Client-Centric 7.3 Modelos de Consistência Client-Centric ou seja, manipular operações concorrentes em dados compartilhados enquanto se mantém a consistência sequencial é fundamental em sistemas distribuídos. Por razões de desempenho, consistência sequencial pode ser garantida somente com o uso de mecanismos de sincronização tais como transações e locks. Nesta seção discutiremos uma classe especial de data stores distribuídos caracterizados pela ausência de atualizações simultâneas ou quando acontecem podem ser resolvidas facilmente. tais modelos de consistência são denominados eventualmente consistentes e de modo geral escondem as inconsistências. Pg. 47/116

7 Consistência e Replicação 7.3 Modelos de Consistência Client-Centric 7.3.1 Consistência Eventual Processos podem operar de modo concorrente de diferentes maneiras, bem como pode variar o nível de consistência que deve ser garantido aos dados objetos do compartilhamento. e.g., em muitos sistemas de banco de dados os processos executam muito mais operações de leitura do que de atualização; neste contexto, como atualizações rápidas devem estar disponíveis para processos de leitura? e.g., no DNS só a autoridade nomeada responderá pelo nome; consequentemente, conflitos de atualização nunca existirão, porém, ainda assim existem conflitos de read-write. solução - processo leitor espera algum tempo após completar a atualização para então executar a operação de leitura. Pg. 48/116

7 Consistência e Replicação 7.3 Modelos de Consistência Client-Centric 7.3.1 Consistência Eventual e.g., atualização de páginas na Web se dá por uma única autoridade, tal como o webmaster ou proprietário das páginas; ou seja, não há conflitos write-write, mas por outro lado, para melhorar o desempenho, browsers e proxies são configurados para buscar e manter páginas na cache ; o que pode ocasionar o retorno de páginas não atualizadas, ou seja, a versão da página é uma versão mais antiga do que aquela mantida pelo servidor Web atual. Obs.: exemplos descritos podem ser vistos como casos de repositórios de dados distribuídos e replicados que toleram relativamente um alto grau de inconsistência. Pg. 49/116

7 Consistência e Replicação 7.3 Modelos de Consistência Client-Centric 7.3.1 Consistência Eventual Neles, se nenhuma atualização acontecer por um tempo longo, todas as réplicas estarão gradualmente inconsistentes, ou seja, eventualmente consistente - o que exige que atualizações sejam propagadas a todas as réplicas. conflitos de atualizações são geralmente mais fáceis e baratos de serem resolvidas, desde que um pequeno grupo de processos executem as operações de escrita. Normalmente consistência eventual funciona bem na medida que clientes acessam as mesmas réplicas; entretanto, surgem problemas quando diferentes réplicas são objeto de acesso em um curto período de tempo (Fig. 7.11). Pg. 50/116

7 Consistência e Replicação 7.3 Modelos de Consistência Client-Centric 7.3.1 Consistência Eventual Fig. 7.11 Princípio de um Usuário Móvel acessando diferentes réplicas de um Repositório de Dados Distribuído. Pg. 51/116

7 Consistência e Replicação 7.3 Modelos de Consistência Client-Centric 7.3.1 Consistência Eventual Terry et al. (1994) (1998) constituem a origem dos trabalhos de modelos de consistência centrados no cliente com o intuito de amenizar os efeitos discutidos no exemplo anterior; client-centric consistency - provê garantias para um único cliente em relação aos acessos consistentes ao data store ; no entanto, não dá garantias de consistências para acessos concorrentes de 02 ou mais clientes. Terry et al. propõem 4 diferentes modelos de consistência: ** Leituras Monotônicas ** Escritas Monotônicas ** Leia suas Escritas ** Escritas seguem Leituras Pg. 52/116

7 Consistência e Replicação 7.3 Modelos de Consistência Client-Centric 7.3.1 Consistência Eventual Terry et al. (1994) (1998) propuseram 04 diferentes modelos de consistência para um repositório de dados fisicamente distribuído em diferentes máquinas e com as seguintes características: quando um processo acessa do data store, ele o faz na cópia local ou na cópia mais próxima, embora em princípio, qualquer cópia estaria apta para ser operada/manuseada; operações de leitura e escrita são realizadas na cópia local e atualizações são eventualmente propagadas para todas as cópias cada item de dado tem proprietário associado, ou seja, um processo que tem permissão para modificar aquele item, assim, evita-se conflitos do tipo escrita-escrita. Pg. 53/116

7 Consistência e Replicação 7.3 Modelos de Consistência Client-Centric 7.3.1 Consistência Eventual Modelos de Consistência Client-Centric são descritos utilizando-se a notação a seguir: Seja xi[t1] a versão do dado x na cópia local Li no tempo t1 ; versão xi[t1] é o resultado de uma série de operações de escrita na cópia local Li que ocorreram desde a inicialização conjunto que é denotado por WS( xi[t1] ) ; se as operações em WS(xi[t1]) também forem executadas em uma cópia local Lj no tempo t2, escrevemos WS( xi[t1]; xj[t2] ) ; se a ordenação de operações ou a temporização estiver clara no contexto, o índice de tempo será omitido. Pg. 54/116

7 Consistência e Replicação 7.3 Modelos de Consistência Client-Centric 7.3.2 Leituras Monotônicas monotonic-read consistency - se um processo ler o valor de um item de dado x, novas operações de leitura de x executadas por este processo retornaram o mesmo valor ou um mais recente. ou seja, se um processo viu o valor de x no tempo t1, este processo não verá uma versão anterior de x em t2 - t2 > t1. e.g., considere 02 cópias locais diferentes - L1 e L2 do mesmo data store e o eixo x representando o tempo - tleft < tright. em ambos os casos estamos interessados nas operações executadas por um único processo P, aqui representadas em negrito enquanto a linha pontilhada representa a ordem em que as operações são executadas - R(x1) antes de R(x2). Pg. 55/116

7 Consistência e Replicação 7.3 Modelos de Consistência Client-Centric 7.3.2 Leituras Monotônicas P inicialmente executa uma leitura em x na cópia local L 1, retornando o valor x1 naquele momento, resultado da operação de escrita WS(x1) sobre L1 ; mais tarde, P executa uma leitura em x na cópia local L2, retornando o valor x2 naquele momento, no contexto onde WS(x1) foi propagada para L2 => WS(x1,x2) Fig. 7.12 Operações de leitura executadas por P em 02 cópias locais do mesmo data store. a) monotonic-read consistency Pg. 56/116

7 Consistência e Replicação 7.3 Modelos de Consistência Client-Centric 7.3.2 Leituras Monotônicas Em contraste, Fig. 7.12 b) mostra que a consistência de leituras monotônicas não é garantida pois WS(x1) não se propagou para L2, pois apenas WS(x2) foi realizada; não há garantias que este conjunto contenha todas as operações contidas em WS(x1). Fig. 7.12 Operações de leitura executadas por P em 02 cópias locais do mesmo data store. a) monotonic-read consistency b) data store não garante a leituras monotônicas. Pg. 57/116

7 Consistência e Replicação 7.3 Modelos de Consistência Client-Centric 7.3.3 Escritas Monotônicas monotonic-write consistency - uma operação de escrita em um dado x é completada antes de alguma operação de escrita subsequente do mesmo processo sobre o mesmo dado x. ou seja, uma operação de escrita executada significa que a cópia na qual operações sucessivas forem realizadas reflete operações de escrita anteriormente executadas pelo mesmo processo, independente do local onde foi iniciada. e.g., considere 02 cópias locais diferentes - L 1 e L2 do mesmo data store e o eixo x representando o tempo - t left < tright. em ambos os casos estamos interessados nas operações executadas por um único processo P, aqui representadas em negrito enquanto a linha pontilhada representa a ordem em que as operações são executadas - W(x1) antes de W(x2). Pg. 58/116

7 Consistência e Replicação 7.3 Modelos de Consistência Client-Centric 7.3.3 Escritas Monotônicas Fig. 7.13 a) para garantir a consistência monotônica de escritas, é necessário que as operações de escrita anteriores tenham sido propagadas para as demais cópias. Fig. 7.13 b) mostra cenário onde a consistência de escritas monotônicas não é garantida, pois WS(x1) não foi propagada para L2 Fig. 7.13 Operações de escritas executadas por P em 02 cópias locais do mesmo data store. a) data store com consistência de escritas monotônicas; b) data store que não garante a consistência de escritas monotônicas. Pg. 59/116

7 Consistência e Replicação 7.3 Modelos de Consistência Client-Centric 7.3.4 Leia suas Escritas read-your-wristes consistency - efeito de operações de escrita por um processo em um item de dado x será visto por uma leitura subsequente em x pelo mesmo processo. ou seja, operação de escrita é sempre completada antes de uma operação de leitura subsequente executada pelo mesmo processo, independente de onde a operação foi executada. e.g., considere 02 cópias locais diferentes - L1 e L2 do mesmo data store e o eixo x representando o tempo - tleft < tright. em ambos os casos estamos interessados nas operações executadas por um único processo P, aqui representadas em negrito enquanto a linha pontilhada representa a ordem em que as operações são executadas - W(x1) antes de R(x2). Pg. 60/116

7 Consistência e Replicação 7.3 Modelos de Consistência Client-Centric 7.3.4 Leia suas Escritas Fig. 7.14 a) - P executa uma operação de escrita W(x1) e mais tarde executa uma operação de leitura R(x2) em uma outra cópia com a garantia de W(x1) foi propagada para L2 => W(x1,x2) Fig. 7.14 b) - W(x1) foi mantida aparte da atualização W(x2), ou seja, o efeito da operação prévia de escrita não foi propagada. Fig. 7.14 a) data store que provê read-your-writes consistency. b) data store que não provê read-your-writes consistency. Pg. 61/116

7 Consistência e Replicação 7.3 Modelos de Consistência Client-Centric 7.3.5 Escritas seguem Leituras writes-follow-reads consistency - uma operação de escrita no item de dado x após uma operação de leitura em x pelo mesmo processo é realizada em uma cópia de x atualizada com o valor mais recentemente lido por aquele processo. e.g., considere 02 cópias locais diferentes - L1 e L2 do mesmo data store e o eixo x representando o tempo - tleft < tright. em ambos os casos estamos interessados nas operações executadas por um único processo P, aqui representadas em negrito enquanto a linha pontilhada representa a ordem em que as operações são executadas - R(x1) antes de W(x2). Pg. 62/116

7 Consistência e Replicação 7.3 Modelos de Consistência Client-Centric 7.3.5 Escritas seguem Leituras Fig. 7.15 a) P executa uma operação de leitura R(x1) e mais tarde executa uma operação de escrita W(x2) em uma outra cópia com a garantia de W(x1) é parte de W(x2) Fig. 7.15 b) não há garantia de que a operação em L2 se deu sobre uma cópia que é consistente com aquela lida em L1. Fig. 7.15 a) data store com consistência writes-follow-reads. b) data store sem consistência writes-follow-reads. Pg. 63/116

7 Consistência e Replicação 7.4 Gerenciamento de Réplica 7.4 Gerenciamento de Réplica questão fundamental - decidir onde, quando e por quem as réplicas devem ser posicionadas e quais mecanismos usar para manter as réplicas consistentes. problema de possicionamento pode ser subdividido em 02 subproblemas: possicionamento de servidores de réplicas e possicionamento de conteúdo; naturalmente que antes de definir o possicionamento do conteúdo, cabe o possicionamento dos servidores de réplicas. Pg. 64/116

7 Consistência e Replicação 7.4 Gerenciamento de Réplica 7.4.1 Possicionamento do Servidor de Réplica possicionamento - trata-se de um problema de cunho com viez gerencial e/ou comercial do que um problema de otimização; existem diversas maneiras de se calcular a melhor localização do servidor de réplicas, ou seja, como escolher as melhores k posições de n possíveis localizações. Qui et al (2001) assume a distância entre o cliente e a localização dos servidores de réplicas como ponto de partida; localizações medidas por latênca ou largura de banda. solução - escolher um servidor por vez de modo que a distância média entre eles e seus clientes seja a menor possível, dado que k servidores tenham sido possicionados de um total de n servidores => n k localizações não são contabilizadas. Pg. 65/116

7 Consistência e Replicação 7.4 Gerenciamento de Réplica 7.4.1 Possicionamento do Servidor de Réplica Radoslavov et al (2001) consideram a topologia dos servidores quanto aos Autonomous Systems - ASs desconsiderando a posição dos clientes; autonomous systems - rede na qual todos os nós executam o mesmo protocolo de roteamento e são mantidos e gerenciados pela mesma organização. proposta - considera o maior AS e possiciona o servidor no roteador com o maior número de interfaces de rede, na sequência, repete o algoritmo para o segundo maior AS....considerando que clientes estão distribuídos na rede, o resultado alcançado para clientes que conheçam a localização dos servidores em relação aqueles que não conhece é similar. Pg. 66/116

7 Consistência e Replicação 7.4 Gerenciamento de Réplica 7.4.1 Possicionamento do Servidor de Réplica desvantagens - ambos os algoritmos são computacionalmene caros e apresentam complexidade > O(N2), onde N representa o número de localizações possíveis de serem inspecionadas; mesmo com alguns milhares de localizações faz-se necessário alguns minutos para encontrar o servidor mais próximo; seu uso torna-se inaceitável, ainda mais na presença de flash crowd - rajada de requisições para um site específico. Pg. 67/116

7 Consistência e Replicação 7.4 Gerenciamento de Réplica 7.4.1 Possicionamento do Servidor de Réplica Szymaniak et al. (2006) - desenvolveram uma maneira de encontrar rapidamente o local onde posicionar as réplicas: região é identificada como um coleção de nós de mesmo conteúdo que apresentem baixa latência entre os nós; objetivo - selecionar a região com maior demanda, ou seja, aquela com o maior nro. de nós e na sequência permitir que um dos nós atue como o servidor de réplicas. idéia - identificar k maiores clusters e escolher um nó de cada cluster para receber o conteúdo replicado; inicialmente o espaço total é particionado em células e as k células mais densas são escolhidas para receber as réplicas. Pg. 68/116

7 Consistência e Replicação 7.4 Gerenciamento de Réplica 7.4.1 Possicionamento do Servidor de Réplica Fig. 7.16 Escolha do tamanho apropriado de uma célula para possicionamento do servidor de réplicas. células muito grandes - pode existir diversos clusters e, assim, um nro. pequeno de servidores de réplicas é selecionado; células muito pequenas - cluster espalhado por varias células e, assim, um nro. grande de servidores de réplicas é selecionado. Pg. 69/116

7 Consistência e Replicação 7.4 Gerenciamento de Réplica 7.4.1 Possicionamento do Servidor de Réplica tamanho apropriado por ser computado como um função simples da distância média entre 02 nós e o nro. de réplicas; pode ser mostrado que o algoritmo apresenta desempenho tão bom o algoritmo ótimo descrito por Qiu et al. (2001), mas com uma complexidade menor: O( N * max{ logn, K} ). e.g., experimentos monstram que encontrar os 20 melhores locais para uma coleção de 64.000 nós é aproximadamente 50.000 vezes mais rápido. Pg. 70/116

7 Consistência e Replicação 7.4 Gerenciamento de Réplica 7.4.2 Possicionamento de Conteúdo Quando se trata de possicionamento e replicação de conteúdo, 03 diferentes tipos de réplicas podem ser logicamente organizados. Fig. 7.17 Organização lógica de diferentes tipos de cópias de um data store em 03 aneis concêntricos. Pg. 71/116

7 Consistência e Replicação 7.4 Gerenciamento de Réplica 7.4.2 Possicionamento de Conteúdo permanent replicas - podem ser consideradas como o conjunto inicial de réplicas que constituem um data store ; e.g., sites Web estão geralmente distribuídos em 02 formas: arquivos que constituem o site são replicados em um nro. restrito de servidores de uma mesma célula, assim, uma requisição é encaminhada para um dos servidores segundo alg. round-robin. site web é copiado para um nro restrito de servidores espalhados geograficamente pela Internet, assim, clientes simplesmente escolhem um dos sites espelhados semelhança entre ambos é que há um nro. reduzido de réplicas em que a configuração é mais ou menos estática. Pg. 72/116

7 Consistência e Replicação 7.4 Gerenciamento de Réplica 7.4.2 Possicionamento de Conteúdo organização similar está presente nos bancos de dados distribuídos - OSZu & Valduriez (1999); bancos de dados são distribuídos e replicados em servidores que conjuntamente formam um cluster de servidores, comumente referenciados como arquitetura nada-compartilhada ; arquitetura nada-compartilhada - memória secundária e a memória principal não são compartilhados pelos processadores. ou seja, banco de dados é distribuído e possivelmente replicado em um nro. de sites dispersos geograficamente. Pg. 73/116

7 Consistência e Replicação 7.4 Gerenciamento de Réplica 7.4.2 Possicionamento de Conteúdo server-initiated replicas - são cópias do data store criados pelo proprietário do data store para aumentar o desempenho; e.g., servidor em Nova York que repentinamente começa a receber uma rajada de requisições de um local distante; talvez, seja necessário o uso de réplicas temporárias no local de origem das requisições ou ao menos próximo; serviços de hospedagem Web oferecem uma coleção relativamente estática de servidores espalhados na Internet que podem manter e prover o acesso aos arquivos Web; Sivasubramanian et al. (2004) discute a visão geral de replicação em serviços de hospedagem na Web. Pg. 74/116

7 Consistência e Replicação 7.4 Gerenciamento de Réplica 7.4.2 Possicionamento de Conteúdo Uma outra abordagem para Serviço de Hospedagem Web é descrita por Rabinovich et al. (1999): algoritmo é projetado para suportar páginas Web para as quais assume-se que operações de atualização são raras comparadas com as operações de leitura; e.g., servidores no serviço de hospedagem web podem decidir qual servidor está mais próximo de um cliente C, tendo por base as informações dos bancos de dados de roteamento; se C1 e C2 compartilham o mesmo servidor mais próximo P, todas as requisições de acesso para o arquivo F no servidor Q vindas de C1 e C2 são registradas em Q com uma única contagem de acesso cnt(p,f) - Fig. 7.18 Pg. 75/116

7 Consistência e Replicação 7.4 Gerenciamento de Réplica 7.4.2 Possicionamento de Conteúdo se C1 e C2 compartilham o mesmo servidor mais próximo P, todas as requisições de acesso para o arquivo F no servidor Q vindas de C1 e C2 são registradas em Q como uma única contagem de acesso cnt(p,f) - figura abaixo. Fig. 7.18 Contando requisições de acesso de diferentes clientes. Pg. 76/116

7 Consistência e Replicação 7.4 Gerenciamento de Réplica 7.4.2 Possicionamento de Conteúdo quando o nro. de requisições para um arquivo F no servidor S cai abaixo de um limite estabelecido - del(s,f), o arquivo pode ser removido do servidor; como consequência o nro. de réplicas do arquivo F cai, possivelmente acarretando um aumento de carga nos servidores; medidas são tomadas para garantir que ao menos um cópia de cada arquivo continue a existir. se o limite de replicação rep(s,f) é maior que del(s,f), indica que vale a pena replicá-lo em outros servidores; se o número de requisições estiver entre os limites de replicação e remoção, então para aquele arquivo é permitido somente a migração. Pg. 77/116

7 Consistência e Replicação 7.4 Gerenciamento de Réplica 7.4.2 Possicionamento de Conteúdo Quando um servidor Q decide reavaliar os arquivos no seu repositório, ele verifica o contagem de acessos para os arquivos; se o nro de acessos para F está abaixo de um limiar, remove-se F a menos que seja a última cópia; além disso, se para algum servidor P, cnt Q (P,F) excede em mais da metada do total de requisições para F em Q, o servidor P é solicitado a assumir a cópia de F, ou seja, migração. migração do arquivo F para o servidor P nem sempre ocorre, p.ex., por que P está ainda carregado e fora do disco; neste caso, Q irá tentar replicar F em outros servidores, desde que o nro total de acessos para F em Q exceda o limite de replicação rep(q,f). Pg. 78/116

7 Consistência e Replicação 7.4 Gerenciamento de Réplica 7.4.2 Possicionamento de Conteúdo client-initiated replica - comumente conhecidas como cache, são na essência um armazenamento local utilizado pelo cliente para armazenar temporariamente dados objeto da requisição; data store do qual os dados foram lidos não tem nada a ver com a manutenção da consistência dos dados salvaguardados; quando a maior parte das operação são leituras de dados, o cliente pode guardar os dados que são requisitados em uma cache local para melhorar o desempenho; essa cache está na máquina cliente ou em uma cache separada na rede local onde máquina cliente se encontra. Pg. 79/116

7 Consistência e Replicação 7.4 Gerenciamento de Réplica 7.4.2 Possicionamento de Conteúdo dados são mantidos na cache por um tempo limitado, p.ex., para prevenir dados obsoletos sendo usados ou simplesmente abrir espaço para outros dados; para melhorar a taxa de acerto na cache, caches podem ser compartilhadas entre os clientes, desde que dados requisitados pelo cliente C1 são também requisitados pelo cliente C2. possicionamento de cache de cliente é relativamente simples: cache é possicionada na mesma máquina que o cliente; cache na máquina compartilhada por clientes na rede local; em alguns casos, níveis extras de cache são introduzidos entre departamentos ou organizações. Pg. 80/116

7 Consistência e Replicação 7.4 Gerenciamento de Réplica 7.4.3 Distribuição de Conteúdo gerenciamento de réplicas - trata da propagação e/ou atualização de conteúdo para servidores relevantes de réplicas e envolve vários aspectos: state vs operations - um importante aspecto de projeto refere-se ao que deve ser propagado: propaga somente a notificação de atualização nada é propagado além de notificações, ou seja, dados não são propagados; transferir dados de uma cópia para outra quando a relação de leituras/ escritas é alta é interessante transferir dados; propagar a operação de atualização para as outras cópias cada réplica recebe apenas parâmetros da operação de atualização. Pg. 81/116

7 Consistência e Replicação 7.4 Gerenciamento de Réplica 7.4.3 Distribuição de Conteúdo propagação de notificação - nada é propagado além de notificações, ou seja, encaminha através do protocolo de invalidação notificação às outras cópias de que o dado não é mais válido; protocolo de invalidação pode especificar que parte do data store foi atualizada, assim, apenas uma parte da cópia está atualmente invalidada. principal vantagem dos protocolos de invalidação é que utilizam pouca banda da rede, pois a informação transferida é a especificação de quais dados não mais são válidos;... tais protocolos geralmente trabalham bem quando há muitas operações de atualização comparado com as operações de leitura, ou seja, relação leituras/escritas é relativamente pequena. Pg. 82/116

7 Consistência e Replicação 7.4 Gerenciamento de Réplica 7.4.3 Distribuição de Conteúdo transferir dados de uma cópia para outra utilizada quando a relação de leituras/escritas é relativamente alta; neste contexto, a probabilidade que uma atualização seja efetiva no sentido de que o dado modificado será lido antes da próxima atualização é alta justicando a transferência; ao invés de propagar os dados modificados é possível salvar log as mudanças e transfera somente aquelas alterações salvas para economizar banda de rede; transferência são sempre concatenadas no sentido de que múltiplas modificações são agrupadas em um única mensagem, economizando overhead de comunicação. Pg. 83/116

7 Consistência e Replicação 7.4 Gerenciamento de Réplica 7.4.3 Distribuição de Conteúdo propagar a operação de atualização para as outras cópias também chamada de replicação ativa, cada réplica recebe apenas parâmetros da operação de atualização; vantagem - pode frequentemente ser propagada com o mínimo gasto de banda de rede, uma vez que os parâmetros associados com uma operação são relativamente pequenos; desvantagem - maior processamento pode ser exigido em cada um dos servidores de réplica, especialmente onde as operações são relativamente complexas. Pg. 84/116

7 Consistência e Replicação 7.4 Gerenciamento de Réplica 7.4.3 Distribuição de Conteúdo protocolos pull vs push - podem ser subdivididos em push-based protocols e pull-based protocols. push-based protocols - servidor inicia a atualização sem que outro servidor ou cliente encaminhe solicitação. pull-based protocols - servidor ou cliente encaminha solicitação de atualização para um servidor de réplicas. Pg. 85/116

7 Consistência e Replicação 7.4 Gerenciamento de Réplica 7.4.3 Distribuição de Conteúdo push-based protocols ou server-based protocols - servidor propaga as atualizações para as réplicas, independente de solicitação por parte das réplicas. envio de atualizações é frequentemente usado entre réplicas permanentes iniciadas pelo servidor, mas pode ser usado para atualização de cache de clientes. são normalmente aplicadas quando as réplicas são mantidas sob um alto grau de consistência réplicas idênticas. Alto grau de consistência advém do fato de que réplicas permanentes iniciadas pelo servidor são caracterizadas por operações de leitura; nestes casos, push-based protocols são eficientes no sentido de que toda atualização será passível de leitura com alta probabilidade por 01 (um) ou mais leitores. Pg. 86/116