universidade federal de santa catarina programa de pós-graduação em ciência da computação lazy...

Universidade Federal de Santa CatarinaPrograma de Pós-Graduação em Ciência da Computação

Lazy Database Replication with Ordering Guarantees

Khuzaima Daudjee and Kenneth SalemSchool of Computer Science

University of WaterlooICDE'04

Apresentação por Rodrigo Gonçalves


1. Introdução2. Strong Session Serializability3. Arquitetura4. Testes5. Conclusão


Introdução

Replicação Performance Disponibilidade

Formas de replicação Eager replication

Uma transação Lazy replication

Duas ou mais transações


Introdução Lazy Replication

Ordem das transações Dados inválidos

Serialização Não resolve completamente o problema T2 pode não ver os efeitos de T1, mesmo

sendo executada após T1


Introdução Serialização forte

Garante ordem Problemática para Lazy Replication

Atualização completa antes do uso Proposta

Strong Session Serializability Serialização forte parcial


Strong Session Serializability Serialização forte

Garante ordem a um alto custo Reduz disponibilidade das réplicas

Aguardam transações anteriores Cria dependências entre transações

Muitas vezes desnecessárias


Strong Session Serializability Strong session serializability

Dependências apenas onde for necessário Diminui dependências entre transações

Sessão Conjunto de transações Existe dependência

Garante-se serialização forte na Sessão


Arquitetura Sistema básico

Arquitetura “Lazy Master” Um nodo primário Vários nodos secundários

Independentes Transações de leitura executadas em

nodos secundários Transações de escrita somente no nodo

primário



Arquitetura “Lazy Master” Escalonável

Adição de nodos secundários Consultas

Nodo primário Serializa transações Número seqüencial Replicação seqüencial “Lazy propagation”


Arquitetura O sistema básico

Garante serialização global Não garante “strong session

serializability” Um gerenciador de sessões

Garante “strong session serializability”



Nodos secundários FIFO Refresh Transactions Seqüencial

Gerado na aplicaçaõ de uma “Refresh Transaction”

Necessário pelo Gerenciador de Sessão seq(DB)


Arquitetura Gerenciador de Sessão

Garante Strong Session Serializability Um por nodo secundário Transações de um cliente Supõe-se

Transações executadas em um único nodo Transações seqüenciais



Seqüencial por sessão - seq(s) Último estado do BD

Algorítimo BLOCK Algorítimo FORWARD



Algorítimo BLOCK Transações (T) de leitura executam somente

quando o estado do nodo secundário é compatível com a transação

seq(DB) >= seq(s)



Algorítimo BLOCK Para transações de escrita:

Inicie T no nodo primário

Execute as operações de T no nodo primário

Complete ou aborte T no nodo primário

Obtenha o seq(T) do nodo primário

Se T completada entãoseq(s) ← seq(T)

FimSe



Algorítimo BLOCK Para transações de leitura:

AGUARDE ATÉ seq(DB) ≥ seq(s) no nodo secundário

Inicie T no nodo secundário

Execute as leituras de T no nodo secundário

Aborte ou complete T no nodo secundário

Se T completada entãoseq(s) ← seq(DB)

FimSe



Algorítimo FORWARD Gerencia atualizações como BLOCK Transações de leitura

Redirecionadas para o nodo primário Evita espera pela atualização do nodo

secundário



Algorítimo FORWARDSe seq(DB) ≥ seq(s) no nodo secundário então

Inicie T no nodo secundárioExecute as operações de T no nodo secundárioComplete ou aborte T no nodo secundárioSe T completada então

seq(s) ← seq(DB)FimSe

SenãoInicie T no nodo primárioExecute as operações de T no nodo primárioComplete ou aborte T no nodo primárioObtenha seq(T) do nodo primárioSe T completada então

seq(s) ← seq(T)FimSe

FimSe



Algorítimo BLOCK Distribui carga das operações de leitura Pode retardar uma transação de leitura

Algorítimo FORWARD Pode sobrecarregar o nodo primário Mais eficiente para operações de leitura


Testes Modelo de simulação

Comparar métodos Forward e Block

Pacote de simulação CSIM

Simula um sistema distribuído completo


Testes Modelo de simulação

Parâmetro Descrição Padrão

num_clients Número de clientes Variadonum_sec Número de nodos secundários 5think_time Tempo médio de processamento do cliente 7s

session_time Duração média de uma sessão 15 min.update_tran_prob Probabilidade de uma transação de escrita 20,00%

conflict_prob Probabilidade de conflito na transação 20,00%tran_size Número médio de operações por transação 10

op_service_time Tempo de serviço por operação 0.02supdate_op_prob Probabilidade de operação de atualização 30,00%

propagation_dealy Tempo de propagação 10s


Testes Análise de performance

Objetivos Custo em termos de transação Comparar o modelo geral de serialização

com o strong session serializability Comparar os algorítimos Forward e Block


Testes Análise de performance

Dois algorítimos adicionais na comparação ALG-1SR

Serialização global simples Não bloqueia transações

ALG-STRONG-SITE-1SR Algorítimo Block com apenas uma sessão por

nodo secundário Mais restritivo que strong session serializability

porém menos que strong serializability Equivalente ao strong serializability em custo


Testes Metodologia

Simulações com 35 minutos de duração 5 minutos para warm up Resultados tomados da média de 5

simulações


Testes Testes com a configuração padrão


Testes Testes com a configuração padrão

Leituras Forward mais eficiente em baixa carga Block mais constante

Tempo de propagação Torna métodos equivalentes

ALG-Strong-Site-1SR pior que Block Demonstra necessidade de evitar

dependências desnecessárias


Testes Escalabilidade

Número de nodos secundários e clientes variando Mantendo-se em média 20 clientes por nodo



Forward tem baixo desempenho Block demonstrou-se equivalente ao Alg-

1SR em performance Reduzindo o percentual de transações de

escrita, a escalabilidade melhorou consideravelmente


Conclusão Adaptação de um sistema 1SR Garante serialização em sessões Dependências Tempos de propagação Método escalável e aplicável a

sistemas distribuídos

universidade federal de santa catarina programa de pós-graduação em ciência da computação lazy...

Documents