Gerência de Transações em MDS Consistência de dados em conectividade intermitente Francisco de Assis UFCG/COPIN Pós-graduação - Banco de Dados

Gerência de Transações em MDS o Como manter a consistência de dados se a conectividade é intermitente? o Como fazer o controle de concorrência em MDS?

CONSISTÊNCIA DE DADOS EM CONECTIVIDADE INTERMITENTE Tópico1 13/04/20073

Agenda – Consistência de dados Motivação O modelo de consistência Operando em conectividade fraca Restaurando a consistência 13/04/20074

Motivação – Consistência de dados Variação na conectividade De alta velocidade até alta latência Clientes móveis devem operar desconectados Clientes móveis podem operar em conectividade fraca A conexão será, eventualmente, restaurada 13/04/20075

Conceitos - Cluster Dados nos sítios fortemente conectados possuem alta consistência – formam um cluster. 13/04/20076 Cluster Site Um certo grau de inconsistência é admitido para cópias dos dados em clusters diferentes. BD Distribuído Fraca conectividade

Conceitos - Leitura Leitura fraca Weak Read (WR) Lê cópias (possivelmente) inconsistentes Leitura estrita (explícita, rígida,...) Strict Read (SR) Lê cópias consistentes 13/04/20077

Conceitos - Escrita Escrita fraca Weak Write (WW) Faz atualização condicional Escrita estrita (explícita) Strict Write (SW) Grava dados de forma permanente 13/04/20078

Conceitos - Vantagens O grau de inconsistência pode ser adaptado as condições de uso. Usando Weak e Strict de forma balanceada Provê adaptabilidade variável: A aplicação sempre decide o grau de inconsistência; ou O BD sempre decide o grau de inconsistência. 13/04/20079

O modelo de consistência 13/04/ p-cluster p-cluster = physical cluster Definido se: Há baixa latência; A banda é muito larga; - Objetivo: reduzir comunicação inter-cluster (entre p-clusters). - Usar WR e WW para acesso direto aos dados do mesmo p- cluster (maximizar processamento local). - Temos dois tipos de cópia: core: valor permanente. quasi: valor sob validação condicional. (são reconciliados no restabelecimento da comunicação)

Modelo extendido Weak Read (WR) Lê cópias locais e retorna o valor mais atual Melhor esforço Lê cópia local mais atual (core ou quasi) Conservadora Lê cópia local mais atual (apenas quasi) Strict Read (SR)Lê apenas cópias core e retorna o valor mais atual Weak Write (WW)Escreve em cópias quasi Strict Write (SW) Eventual Escreve apenas em cópias core Imediata Escreve em cópias core e quasi, num mesmo p-cluster 13/04/ Extensões

Exemplo prático Ambiente cooperativo 13/04/ p-cluster Grupo B p-cluster Grupo B Notebook PDA Servidor p-cluster Grupo A p-cluster Grupo A Cópia core para Grupo A Cópia quasi para Grupo B

O modelo de consistência Para realizar uma transação, o DMS (Database Management System) consulta várias cópias do dado Traduz o resultado num único valor 13/04/200713

O modelo de consistência 13/04/ A transação pode ser: Strict (não inclui operações Weak) São ACID! Weak (não inclui operações Strict) São executadas em cópias locais de um p-cluster São visíveis apenas em operações weak Weak + Strict Difíceis de definir! São separadas em sub-transações sub-weak + sub-strict

Exatidão dos dados 13/04/ Restrições de integridade são relaxadas Não há como garantir corretude total em conexão intermitente

Exatidão dos dados 13/04/ O problema! Restrição IF X > 0 THEN Y > 0 CoreQuasi X = -1 Y = 2 X = -1 Y = -4 Transação X = 10; IF Y < 0 Y = 10; Realização da transação (Strict-Imediata) SW (x) SR (y) Inconsistência CoreQuasi X = 10 Y = 2 X = 10 Y = -4 A cópia quasi de X foi alterada sem se preocupar com a restrição!

Exatidão dos dados A solução! 1. Ao fazer SW imediata, as cópias quasi devem verificar a consistência 2. Ao fazer SW imediata, as operações de leitura devem ser feitas nas cópias quasi 3. Adiar a atualização das cópias quasi 13/04/200717

Exatidão dos dados 13/04/ Conceito de l-cluster (logical cluster) É o conjunto de cópias quasi de um p-cluster As restrições são aplicadas nesses l-clusters Restrições intra-cluster definem se o estado do banco é ou não consistente Deve haver uma medida de divergências (d) entre restrições inter-cluster

Operando em conectividade fraca 13/04/ Como fazer o agendamento correto da transação (scheduling)? Como garantir a corretude da transação? Como serializar a transação?

Agendamento completo intra-cluster 13/04/ Intra-cluster é: Num mesmo p-cluster Entre as cópias quasi

Agendamento completo intra- cluster 13/04/ IAS = IntrA-cluster Schedule Operações sobre um dado são traduzidas em operações nas cópias; A ordem das transações é respeitada; Operações conflitantes são gravadas; A transação deve operar sempre na mesma cópia de um dado; Transações weak não podem ver resultados parciais de transações strict;

Critério de corretude 13/04/ Corretude fraca de um IAS A execução concorrente pode manter inconsistência Limiarizada! As transações weak devem ler dados consistentes As transações strict devem ser equivalentes a transações em cópia única Não garante corretude em clusters diferentes

Critério de corretude 13/04/ Corretude forte de um IAS Há divergências entre l-clusters diferentes Tenta fazer a correspondência entre: IAS de transações strict E agendamento serial. Ainda pode existir inconsistência

Serializando 13/04/ Atestar a corretude de um IAS Usando um grafo de serialização modificado Incluir no grafo: Todas as transações strict Adicionar arestas que representem operações em cópias Incluir transações weak Incluir arestas: dependência, precedência Se uma IAS têm um grafo acíclico, então a corretude é forte

Serializando 13/04/ Controle de coerência Todas as cópias têm o mesmo valor Vale globalmente para cópias core Vale localmente para cópias quasi Controle de concorrência Mantém as outras restrições de integridade

Limitando a divergência 13/04/ Em cada p-cluster, d é o grau de divergência entre cópias quasi e core, podendo ser: Número máximo de cópias divergentes; Faixa de valores aceitável para o dado; Número máximo de transações que podem agir numa cópia quasi;...

Outras vantagens do modelo 13/04/ Leituras weak = dados imprecisos Mais flexibilidade para o usuário Oferece bons resultados se a aplicação tratar com dados estatísticos

MECANISMO DE CONTROLE DE CONCORRÊNCIA Tópico1I 13/04/200728

Agenda – Controle de concorrência Motivação Modelos disponíveis Adaptando modelos 13/04/200729

Motivação – Controle de concorrência Adaptar mecanismos existentes Ou não! Analisar o overhead Deve ser mínimo para MDS! 13/04/200730

Modelos disponíveis Baseado em travamento 2 fases, centralizado Um nó é responsável pelo travamento 2 fases, com cópia primária Vários nós são responsáveis pelo travamento 2 fases, distribuída Qualquer nó é responsável pelo travamento Nenhum resolve o problema da comunicação intermitente! 13/04/200731

Adaptando modelos Poucas alternativas foram pensadas! Distributed HP-PPL CCM Resolve conflitos usando: Prioridade Status (bloqueado, gravando) Acrescenta timeout para MDS 13/04/200732

Adaptando modelos Epsilon Serializability Coloca limites para inconsistência Uma transação importa inconsistência Lendo dados não validados Uma transação exporta inconsistência Permitindo a leitura de dados não validados Melhor alternativa, segundo Kumar 13/04/200733

Então... o Como manter a consistência de dados se a conectividade é intermitente? R: Relaxando... o Como fazer o controle de concorrência em MDS? R: Usando Epsilon Serializability

Bibliografia formal.html /Mobile/icdcs95-slides.ps pdf?arnumber= / /04/200735