Bancos de Dados Móveis A maioria dos slides é traduzida / adaptada de: Vijay Kumar Computer Sc. Telecommunications University of Missouri-Kansas City 5100 Rockhill Road Kansas City, MO 64110, USA

Bancos de Dados Móveis Índice  Espaço de Informação Totalmente Conectado  “Personal Communication System”  Sistemas de Computação Móvel  Sistemas de Banco de Dados Móvel  Gerência de Dados  Gerência de Transações

Bancos de Dados Móveis Índice (2)  Sobre um Relatório sobre Problemas Abertos e Direções de Pesquisa em MDS  Sumário e Conclusões

Espaço de Informação Totalmente Conectado

Espaço de Informação Totalmente Conectado (2)  Cada nó do espaço de informação tem alguma capacidade de comunicação  Alguns nós podem processar informação  Alguns nós podem se comunicar através de sinal de voz  Alguns nós podem fazer ambas as coisas

Espaço de Informação Totalmente Conectado (3) O espaço pode ser mantido integrando sistemas de banco de dados, e sistemas com / sem fio (PCS - “Personal Communication Systems” -, Sistemas Celulares, e GSM - “Global System for Mobile Communications”)

“Personal Communication System” (PCS)

PCS (2) Dois conjuntos distintos de entidades “Mobile hosts” (MH) – também chamados de clientes móveis “Fixed hosts” (FH) Alguns FH são estações de base (“Mobile Support Stations”) Comunicação com MH via uma interface sem fio Cada MH se comunica com uma estação de base via um canal sem fio Célula – área coberta por uma estação de base Tipicamente, o servidor de banco de dados (BD) reside em um FH via uma interface com fio Confundiremos BD com FH

PCS (3) Especificidades dos ambientes de computação móvel Largura de banca de comunicação assimétrica FH tem mais capacidade de comunicação do que MH Freqüentes desconexões MHs não podem se manter conectados à rede todo o tempo Limitações de energia MHs usam baterias, basicamente Economia de energia é um imperativo

PCS (4) Os limitados canais dos MHs devem ser utilizados eficientemente. Isto é feito por Reuso de freqüência A mesma freqüência de rádio é usada para comunicação por mais de uma célula Células móveis A área coberta pela rede sem fio é dividida em células

PCS (5): Células Móveis

PCS (6): Células Móveis (2) O tamanho das células depende da capacidade das estações de base MSC: “Mobile Swiching Center” PTSN “Public Switched Network”

PCS (7): “Handoff” Um processo, que permite quebrar a conexão com um BS (“Base Station”) e estabelecer a conexão com outro BS.

PCS (8): “Handoff” (2) O procedimento é completado enquanto o MH (o ônibus) se encontra na “overlap region”

PCS (9): Gerência de Localização Esquema de Dois Passos HLR: “Home Location Register” Um HLR armazena o perfil do usuário e sua localização geográfica – célula corrente VLR: “Visitor Location Register” O VLR de uma célula armazena o perfil do usuário e a localização corrente do usuário que vai visitar a célula

PCS (10): Gerência de Localização (2) MU1 se desloca para MU2 MU (“Mobile Unit”) é sinônimo de MH

PCS (11) 1. O VLR da célula 2 é pesquisado para o perfil de MU2 2. Se não é encontrado, então o HLR é pesquisado 3. Uma vez MU2 localizado, então a informação é enviada à estação de base da célula 1 4. A célula 1 estabelece a comunicação Passo 1: Localização

PCS (12) Passo 2: Atualização da localização 1. MU2 se move da célula 1 para a célula 2 2. A localização de MU2 é mudada e então a nova localização deve ser registrada 3. O HLR é atualizado 4. A entrada para MU2 é removida do VLR da célula 1 e uma nova entrada é incluída VLR da célula 2

Sistemas de Computação Móvel Computação móvel é associada com mobilidade de usuários, hardware, dados e software em aplicações de computador Classe especializada de sistemas de computação distribuída em que alguns nós podem mover-se dentro de um espaço físico ou lógico, (des)conectando-se de maneira ad hoc

Sistemas de Banco de Dados Móvel Um sistema de computação móvel com as seguintes propriedades estruturais e funcionais  Sistema distribuído com conectividade intermitente  O MH é um SGBD “à part entière”  Completa mobilidade espacial  Construído sobre plataforma PCS/GSM  Capacidade de comunicação com / sem fio O que é um sistema de banco de dados móvel (MDS: “Mobile Database Systems”)?

MDS (2) O que é uma conectividade móvel? Um modo de conectividade em que um MH e um FH podem se comunicar um com o outro toda vez que isto se fizer necessário. Conectividade intermitente é um caso especial de conectividade móvel

MDS (3) Um modo de conectividade em que somente o MH pode estabelecer comunicação com o FH, sempre que isto for necessário O que é conectividade intermitente?

MDS (4) Objetivos Construir um sistema de processamento de informação verdadeiramente ubíquo, mesmo com as restrições inerentes às arquiteturas sem fio

MDS (5): Arquitetura Cliente- Servidor Application-awareness (collaboration) Laissez faire (No system support) Application-transparent (No changes to applications) Fonte: J. Jing, A. Helal e A. Elmagarmid

MDS (6): Arquitetura Cliente- Servidor (2) Adaptado de: J. Jing, A. Helal e A. Elmagarmid Application-transparent Adaptation Applications DBMS Proxy DBMS APIs Mobile SGBD APIs Mobile File Server Mobile HostFixed Network

MDS (7): Arquitetura Cliente- Servidor (3) Fonte: J. Jing, A. Helal e A. Elmagarmid Application-transparent Adaptation Web Browser Web Client Side Intercept (CSI) HTTP (TCP/IP) TCP/IP Connection Mobile HostFixed Network Web Client Side Intercept (CSI) Web Server (or Proxy Server)

MDS (8): SGBDs Oracle Lite IBM DB/2 Everyplace Sybase Anywhere Versões MS Access e MS SQL Server para plataformas móveis MS Windows CE

MDS (9) Aplicações  Companhias de seguro  Serviços emergenciais (Polícia, assistência médica, etc.)  Controle de tráfego  Serviço de taxi  E-commerce  Etc.

MDS (10): Desafios  Gerência de Dados  Gerência de Transações Controle de Concorrência Tolerância a Falha Recuperação

Gerência de Dados Distribuição de dados Disseminação de dados “Caching” de dados Processamento de consulta

Gerência de Dados: Disseminação Como um cliente acessa o BD fixo? A abordagem mais aceita é “broadcasting”, ou “push-based” Mas a abordagem sob demanda, “pull- based”, cresce de interesse Abordagem híbrida Conseqüência lógica

Disseminação: Push-based “Flat broadcasting” Dados do FH são repetidamente difundidos através de um canal de difusão (broadcast channel) O canal torna-se um ‘disco’ (“file on the air”) MHs podem recuperar seus dados do ‘disco’ O tempo de espera por um ítem é sempre o mesmo

Disseminação: Flat Broadcasting

Disseminação: ‘Discos’ Hierárquicos Difunde os dados em diferentes freqüências, segundo suas relevâncias Hierarquia de memória multi-nível Dados quentes são difundidos mais frequentemente que dados frios Dados com freqüência de acesso similar são agrupados dentro dos ‘discos’

Disseminação: “Pull-based” Somente dados solicitados aparecerão como ‘dados no ar’

Disseminação: Híbrida Mistura tanto “push” como “pull” Clientes enviam pedidos se os dados não se encontram nos ‘discos’

Disseminação: Economia de bateria Clientes podem economizar bateria se conectando somente quando dados que lhes interessam são difundidos Um catálogo de dados é difundido m vezes toda vez que há uma difusão de dados

Gerência de Dados: “Caching” Clientes móveis (MHs) têm acesso a um servidor de BD fixo (FH), via um canal sem fio “Caching” de dados são importantes para melhorar a disponibilidade dos dados e o desempenho das consultas Limitada largura de banda dos canais sem fio Instabilidade das redes sem fio “Caches” convencionais requerem estabilidade da rede e bandas largas

Gerência de Dados: “Caching” (2) Uma nova abordagem de “caching” A estratégia de substituição de dados é baseada em padrões de acesso, em vez dos esquemas o menos recentemente usado ou o mais recentemente usado

Gerência de Dados: Processamento de Consultas Classificação de dados  “Location Dependent Data” (LDD)  “Location Independent Data” (LID)

Processamento de Consultas (2): LDD A classe de dados cujo valor é funcionalmente dependente da localização. Assim, o valor da localização determina o valor correto dos dados Localização Valor do dado

Processamento de Consultas (3): LDD (2) Exemplo: Existem vários hotéis Taj na India. Entretanto, a reserva de apto no hotel dependerá do lugar onde ele está localizado. Uma atualização do status de um apto não deve afetar qualquer outro apto da rede Esquema: Permanece o mesmo; apenas, múltiplos valores corretos existem no BD

Processamento de Consultas (4): LDD (3) LDD deve ser processado levando em conta as restrições de localização. Assim, impostos em Pune (cidade da Índia) devem ser processados segundo as regras de impostos desta localidade O MDS deve oferecer a função location binding ou location mapping

Processamento de Consultas (5): LDD (4) Distribuição de dados LDD Uma abordagem é representar uma cidade em termos de um número de células móveis, “Data region”. Assim, Pune pode ser representada em termos de N células, e os LDD de Pune podem ser replicados nessas células

Processamento de Consultas (6): LDD (5) Em uma “data region”, os LDD podem ser representados de um modo hierárquico LDD: Hierarquia de Conceitos

Processamento de Consultas (7): LID Uma classe de dados cujos valores são funcionalmente independentes de localização. Assim, o valor da localização não determina o valor dos dados Exemplos: Nome de pessoa, número de conta, etc.

Processamento de Consultas (8): Tipos de consulta  Location dependent (LD) query  Location independent query

Processamento de Consultas (9): LD Uma consulta cujo resultado depende da localização geográfica da submissão da consulta Exemplo Qual é a distância da estação ferroviária de Pune para ‘aqui’? O resultado desta consulta é correto somente para ‘aqui’

Processamento de Consultas (10): LD (2) Situação: Uma pessoa viajando de carro deseja saber seu progresso e continuamente se faz a mesma pergunta. Cada vez, a resposta é diferente porém correta Requisitos: Contínua monitoração da latitude e da longitude do local de origem da consulta. GPS pode fazer isso

Gerência de Transações Transações Clássicas ACID Controle de Concorrência Tolerância a Falha Recuperação

Gerência de Transações (2): Transações Clássicas ACID Atomicidade Tudo ou nada Consistência Uma transação é uma transição entre dois estados consistentes do BD, por hipótese Isolação Toda transação vê os dados como se ela fosse processada sozinha Durabilidade Se uma transação é validada, seus efeitos devem ser refletidos no BD

Gerência de Transações (3) Transações clássicas ACID são muito rígidas para MDS. Flexibilidade pode ser introduzida usando o conceito de “workflow”. Assim, uma parte de uma transação pode ser executada e validada, independentemente de suas outras partes “Workflow” Reserva de Hotel Reserva de Restaurante Reserva de Teatro

Gerência de Transações (4) Fragmentos de uma transação para a sua distribuição

Gerência de Transações (5) Cenário de execução: Um usuário lança uma transação de seu MH e os resultados finais voltam para o MH. A transação do usuáro não precisa ser completamente executada no seu MH: em vez disso, ela é fragmentada e distribuída entre FHs e MHs para execução. Isto cria uma execução distribuída de uma transação móvel Exemplo: “supply chain workflow”

Gerência de Transações (6): Uma Definição de Transação Móvel Uma transação móvel pode ser definida como T é uma tripla, em que F = {e 1, e 2, …, e n } é um conjunto de fragmentos da transação, L = {l 1, l 2, …, l n } é um conjunto de localizações, and FLM = {flm 1, flm 2, …, flm n } é um conjunto de funções de mapeamento de fragmento para localização, isto é,  j, flm i (e i ) = l i

Gerência de Transações (7): Uma Definição de Transação Móvel (2) Uma execução do fragmento e i é uma ordem parcial e ij = {  j,  j } em que   j = OS j  {N j } em que OS j =  k O jk, O jk  {read, write}, e N j {Abort L, Commit L }.  Para quaisquer O jk e O jl com O jk = R(x) e O jl = W(x) para um objeto x, então ou O jk  j O jl ou O jl  j O jk

Gerência de Transações (8): Um Modelo de Transação Móvel Semantics Based: O modelo assume que uma transação móvel é uma tarefa de longa duração, e por causa disso objetos grandes e complexos são fragmentados em diferentes MHs. Os fragmentos (objetos modificados) são colocados juntos outra vez por uma operação “merge” em um FH. Se os fragmentos puderem ser recombinados em uma ordem qualquer, então os objetos são alcunhados de “reorderable objects”

Gerência de Transações (9): Uma Execução de Transação Móvel

Gerência de Transações (10): Uma Execução de Transação Móvel (2) Cópias primárias: FHs ou estações de base Cópias secundárias (“cached”) mantidas em MHs A tolerância a falhas incorpora o ‘desaparecimento’ de MHs MHs fazem “checkpoints” periódicos

Gerência de Transações (11): Consistência de Dados - Isolação Um cliente lê e atualiza dados de seu “cache” local, baixados de um FH, como se os outros fragmentos da transação global não existissem O que fazer para garantir a consistência do FH, se os dados locais são atualizados durante uma desconexão – problema de consistência de dados --? Vários critérios para consistência baseiam-se na seriação das atualizações do BD Controle de concorrência para assegurar a propriedade de isolação das (sub)transações dos clientes móveis

Gerência de Transações (12): Consistência de Dados - Isolação (2) Métodos convencionais de seriação de execuções concorrentes:  Bloqueio em duas fases (Two-phase locking)  Timestamping  Controle otimista Estes métodos são pessimistas, e podem não funcionar para ambientes móveis  Sobrecarga de mensagens (com / sem fio)  Lidar eficientemente com desconexões é muito difícil  Em caso de bloqueio, a gerência de bloqueios distribuídos é muito complexa

Gerência de Transações (13): Consistência de Dados - Isolação (3) Novos esquemas de seriação baseados em timeout, multiversão, etc., podem funcionar. Um requisito importante é um número mínimo de mensagens trocadas, especialmente mensagens sem fio Métodos otimistas Deixa a consistência para depois, na esperança de que tudo dê certo Se não der certo?! Transações de compensação

Gerência de Transações (14): Consistência de Dados - Isolação (4) Consistência global (FH) O problema de atualização de um BD se levanta quando MHs atualizam o BD. Para manter a consistência global (do BD) um eficiente esquema de atualização faz-se necessário

Gerência de Transações (15): Validação de Transações Móveis Como sabemos, uma transação móvel pode ser fragmentada e pode rodar em mais de um nó (MHs e FHs) Um eficiente protocolo de validação é necessário. Os clássicos “2-phase commit” (2PC) e “3- phase commit” (3PC) não são bons porque usam e abusam de mensagens trocadas entre os participantes do processo de validação Um esquema que use poucas mensagens, especialmente sem fio, é sumamente necessário

Gerência de Transações (16): Validação de Transações Móveis (2) Um possível protocolo, baseado em “timeout”: Conceito: MHs e FHs garantem completar a execução de seus fragmentos da transação móvel dentro de seus “timeouts” pré-definidos. Assim, durante o processamento nenhuma comunicação é requerida. No fim do “timeout”, cada nó independentemente valida seu fragmento

Gerência de Transações (17): Validação de Transações Móveis (3) Protocolo: TCOT-Transaction Commit On Timeout Requirements Coordinator: Coordinates transaction commit Home MH: Mobile Transaction (MT) originates here Commit set: Nodes that process MT (MUs + FHs) Timeout: Time period for executing a fragment

Gerência de Transações (18): Validação de Transações Móveis (4)  MT arrives at Home MH  MH extract its fragment, estimates timeout, and send rest of MT to the coordinator  Coordinator further fragments the MT and distributes them to members of commit set  MU processes and commits its fragment and sends the updates to the coordinator  Other MHs and FHs process their fragments and inform the coordinator  Coordinator commits or aborts MT

Gerência de Transações (19): Recuperação de Falhas É um processo complexo pelas razões seguintes:  Alguns nós são móveis  Os canais sem fio são muito limitados  O suprimento de energia é limitado  A capacidade de processamento em presença de desconexão é restrita

Gerência de Transações (20): Recuperação de Falhas (2) Qualidades desejáveis para um processo de recuperação  Recuperações independentes (MHs e FHs)  MHs podem se recuperar sem a ajuda de um FH  reduz o número de mensagens  Operações de “logging” e “checkpointing” eficientes  Poupar as baterias dos MHs  Facilidade de duplicação de “logs”  Confiabilidade do processo de recuperação

Gerência de Transações (21): Recuperação de Falhas (3) Possíveis abordagens  Recuperação parcial  Uso de tecnologia de agentes móveis

Gerência de Transações (22): Recuperação de Falhas (4) Tecnologia de Agentes Móveis Um agente móvel é um módulo independente de software capaz de  Migrar para qualquer nó da rede  Capaz de se reproduzir e se eliminar  Capaz of registrar sua própria história

Gerência de Transações (23): Agentes Móveis  “Logging” centralizado e distribuído  Um carregador de “logs”: um agente móvel pode ser necessário para carregar seu log com ele  Processamneto de “logs” para a recuperação do FH  Validação ou rejeição da transação móvel Um agente móvel pode ser usado para as seguintes atividades, que são essenciais para recuperação:

Gerência de Transações (24): Agentes Móveis (2)  Difusão de agentes em um canal sem fio dedicado  “Pool” de agentes em cada nó  Migração de agentes segundo o modo requisitado Possíveis abordagens

Um Relatório … Mobile Databases: a Report on Open Issues and Research Directions, por pesquisadores do CNRS, França Sincronização de cópias em computação desconectada  Transações móveis  SGBDs para “ultra-light devices”  Confiabilidade de dados Modelos de disseminação P2P Adaptabilidade de “middleware”

Um Relatório … (2): Sincronização Contexto: “Real-time groupware” n MHs (“sites”) Cada “site” trabalha com uma cópia local de um complexo objeto compartilhado Exemplo: edição simultânea de um documento  Cada “site” participante combina o que vai fazer, mas o critério não é rígido Toda operação é processada em 4 passos P1: gerada em um “site” P2: difundida para os outros “sites” P3: recebida por eles P4: re-executada remotamente neles

Um Relatório … (3): Sincronização (2) Um sincronizador é capaz de garantir que o efeito final das operações, ao mesmo tempo concorrentes e colaborativas, seja consistente Duas direções de pesquisa  Sincronizadores ‘convencionais’ são projetados para suportar curtos períodos de desconexão; eles devem então ser estendidos para tolerar longas desconexões  Para a sincronização, é comum mover um “log” de operações de / para um MH; é importante então minimizar o tamanho dos “logs” Pesquisas ∆X? Uma interessante discussão, regada a chopp!

Um Relatório … (4): Transações Móveis Características do modelo de transações móveis Transação de longa duração (“long-duration transactions” – LDT) Sub-transação em cada MH  Possivelmente desconectada  Validação local LTD globalmente validada  Cópias locais são reintegradas, se possível  Durante a validação global, cada MH deve manter uma conexão estável com o FH

Um Relatório … (5): Transações Móveis (2) Validação global Cada LDT é associada com um contrato  Um conjunto de regras  Intenções de acesso  Bloqueios  “Timeouts” para bloqueios  Limite de divergência para cópias compartilhadas  Etc.

Um Relatório … (6): Transações Móveis (3) Direções de pesquisa (relacionadas com a noção de contrato) Como especificar um contrato? Como derivar regras operacionais para mantê-lo em tempo de execução? Como usá-lo para facilitar a integração de cópias modificadas localmente com as cópias do FH

Um Relatório … (7): “Embedded Databases” Restrições de hardware do tipo “smart card platform”) CPU poderosa RAM muito pequena Memória estável  Rápida para leitura  Dramaticamente lenta para gravação

Um Relatório … (8): “Embedded Databases” Protótipo de pesquisa PicoDBMS Processa qualquer consulta SQL sem usar a RAM, não importando o volume de dados da consulta Direções de pesquisa Como usar RAM em consultas?  Existe um limite mínimo de RAM não importando o tamanho da consulta?  Como pode uma consulta ser otimizada dentro do limite mínimo de RAM?  Como um crescimento incremental de RAM impacta as técnicas que levam em conta o limite mínimo de RAM?

Sumário e Conclusões Redes sem fio estão se tornando uma plataforma de comunicação muito usada. Elas oferecem um modo mais barato de se conectar e, em alguns casos, elas são a única forma de tornar ubíqua a computação Entretanto, muitos problemas complexos devem ser resolvidos, para que os MDS possam ser efetivamente úteis Esta visão geral discutiu alguns desses problemas, e identificou algumas possíveis abordagens