Gerência de Transações em MDS Consistência de dados em conectividade intermitente

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

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

3. Tópico1 Consistência de dados em conectividade intermitente

4. Motivação O modelo de consistência Operando em conectividade fraca Restaurando a consistência Agenda – Consistência de dados

5. 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 Motivação – Consistência de dados

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

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

8. Escrita fraca Weak Write (WW) Faz “atualização condicional” Escrita estrita (explícita) Strict Write (SW) Grava dados de forma permanente Conceitos - Escrita

9. 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. Conceitos - Vantagens

10. O modelo de consistência p-cluster - 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) • p-cluster = physicalcluster • Definido se: • Há baixa latência; • A banda é muito larga;

11. Modelo “extendido” Extensões

12. Exemplo práticoAmbiente cooperativo Cópia core para Grupo A Cópia quasi para Grupo B p-cluster Grupo A Servidor Notebook p-cluster Grupo B PDA

13. 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

14. O modelo de consistência • 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”

15. Exatidão dos dados • Restrições de integridade são “relaxadas” • Não há como garantir “corretude total” em conexão intermitente

16. Exatidão dos dados O problema! A cópia quasi de X foi alterada sem se preocupar com a restrição!

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

18. Exatidão dos dados • 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

19. Operando em conectividade fraca • Como fazer o agendamento correto da transação (scheduling)? • Como garantir a corretude da transação? • Como serializar a transação?

20. Agendamento completo intra-cluster • Intra-cluster é: • Num mesmo p-cluster • Entre as cópias quasi

21. Agendamento completo intra-cluster • 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;

22. Critério de corretude • 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

23. Critério de corretude • 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

24. Serializando • 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

25. Serializando • 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

26. Limitando a divergência • 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; • ...

27. Outras vantagens do modelo • Leituras weak = dados “imprecisos” • Mais flexibilidade para o usuário • Oferece bons resultados se a aplicação tratar com dados estatísticos

28. Tópico1I Mecanismo de controle de concorrÊncia

29. Motivação Modelos disponíveis Adaptando modelos Agenda – Controle de concorrência

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

31. 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! Modelos disponíveis

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

33. EpsilonSerializability 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 Adaptando modelos

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

35. http://citeseer.ist.psu.edu/ramamritham94formal.html http://www.cs.uoi.gr/~pitoura/distribution/Mobile/icdcs95-slides.ps http://ieeexplore.ieee.org/iel5/69/17849/00824602.pdf?arnumber=824602 http://doi.ieeecomputersociety.org/10.1109/69.824602 Bibliografia