gestão de dados partilhados em ambientes de computação móvel
gestão de dados partilhados em ambientes de computação móvel gestão de dados partilhados em ambientes de computação móvel
176 CAPÍTULO 11. TRABALHO RELACIONADO Os sistemas apresentados nesta dissertação são baseados na arquitectura cliente estendido/servidor. Esta aproximação permite suportar um elevado número de clientes capazes de modificar os objectos, cada um mantendo réplicas de apenas um subconjunto de objectos. No entanto, o algoritmo de replicação principal, responsável por controlar a evolução dos objectos, é executado apenas entre os servidores. O reduzido número de servidores e a sua boa conectividade permite que as operações sejam reflectidas em todas as réplicas principais rapidamente. A existência de múltiplos servidores (DOORS) permite fornecer uma maior disponibilidade das réplicas principais à custa do aumento de complexidade na reconciliação. A criação de uma nova réplica num servidor (DOORS) deve ser efectuada pelo administrador do sistema. A possibilidade de os clientes comunicarem entre si para actualizar as suas cópias dos objectos permite que quaisquer dois elementos do sistema cooperem sem necessidade de contactar um servidor, ultrapas- sando uma das limitações geralmente apontadas aos sistemas cliente/servidor [139]. Relativamente a um sistema participante-a-participante, esta aproximação tem a desvantagem de a sincronização entre os clientes ser, em geral, mais primitiva. No entanto, o menor número de réplicas principais existentes simplifica a gestão da consistência das réplicas. 11.1.3 Unidade de replicação A unidade de replicação é o menor elemento que pode ser replicado independentemente, a que se chama genericamente objecto. A utilização de unidades de replicação de grandes dimensões tem vantagens, de entre as quais se destacam as seguintes: simplifica a gestão da replicação, devido ao menor número de objectos existentes; e diminui a probabilidade da ocorrência de erros devido à não replicação de algum objecto. No entanto, a grande dimensão dos objectos impõe elevadas exigências de recursos para armazenar e obter uma nova réplica de um objecto. Estas exigências podem estender-se à propagação de modificações, no caso de ser necessário propagar o novo estado de todo o objecto. Assim, enquanto computadores bem conectados com grande capacidade de armazenamento podem satisfazer as necessidades relativas à utilização de unidades de replicação de grandes dimensões, os computadores móveis fracamente conectados e com limitada capacidade de armazenamento necessitam de utilizar unidades de replicação de pequenas dimensões. Nos sistemas cliente/servidor (Coda [87], Oracle Lite [115], Objectivity [109]), em que se pressupõe a diferença de qualidade entre os clientes e os servidores, é comum existirem duas unidades de replicação. Por exemplo, no sistema Coda, a unidade de replicação entre os servidores é o volume (conjunto de ficheiros), enquanto os clientes podem obter cópias de ficheiros individuais. A aproximação utilizada no sistema DOORS é semelhante: os servidores replicam conjuntos de coobjectos, enquanto os clientes podem obter cópias parciais de coobjectos individuais. Nos sistema participante-a-participante, em geral, apenas existe uma unidade de replicação. Quando
11.1. REPLICAÇÃO 177 a unidade de replicação é de grandes dimensões (conjunto de ficheiros no sistema Ficus [66] e base de dados no sistema Bayou [161]), o sistema tem dificuldade em suportar computadores com pequena capa- cidade de armazenamento, como é comum nos computadores portáteis. Quando a unidade de replicação é menor (um ficheiro no sistema Roam [140]), o sistema tem de gerir um elevado número de objectos. Dimensão da menor unidade de replicação A dimensão da menor unidade de replicação deve ser suficientemente pequena para que não se repliquem dados desnecessários e suficientemente grande para que a gestão do processo não se torne demasiado complexa. Como se discutiu na secção 2.3.5, a unidade de manipulação de um sistema de gestão de dados é, por vezes, inadequada como unidade de replicação. Assim, no sistema DOORS, a unidade de replicação é definida pelos programadores de acordo com o modo como os objectos estão internamente organizados. Esta aproximação permite adequar a unidade de replicação às características dos dados manipulados por cada aplicação. Uma aproximação seme- lhante foi usada nos sistemas Javanaise [68] e Perdis [51] para melhorar o desempenho num ambiente de computação distribuída. O agrupamento automático de objectos, como executado nos sistemas de bases de dados orientadas para os objectos [165], não soluciona o problema de gestão, porque o sistema continua a ter de lidar com todos os objectos no momento de determinar quais devem ser replicados. Pelo contrário, no sistema DOORS, a unidade de replicação define uma caixa negra, o que minimiza o número de objectos com que o sistema necessita de lidar. Num sistema de ficheiro é possível dividir um documento longo em vários ficheiros, obtendo um resultado semelhante ao proposto no sistema DOORS. No entanto, esta aproximação não é natural. Adicionalmente, a unidade de replicação definida no sistema DOORS, o subobjecto, define um ele- mento no qual é possível executar operações de forma independente. Ao contrário do que acontece nos sistemas desenvolvidos para ambientes distribuídos, nos quais é possível replicar incrementalmente [166] os objectos necessários ao funcionamento da aplicação, num ambiente de computação móvel esta propri- edade é importante por permitir o funcionamento (ainda que parcial) durante os períodos de desconexão. No sistema Mobisnap, a unidade de replicação é o subconjunto de um registo. No entanto, a espe- cificação dos dados a replicar é efectuada usando instruções de interrogação, o que permite lidar com os objectos a nível semântico. Esta aproximação é semelhante à adoptada nos sistemas de bases de dados relacionais que suportam computação móvel [115] e nas soluções de replicação secundária se- mântica [35, 142].
- Page 143 and 144: 8.4. PROCESSAMENTO DAS TRANSACÇÕE
- Page 145 and 146: 8.5. EXEMPLOS 127 id tipo tabela co
- Page 147 and 148: 8.5. EXEMPLOS 129 1 ------ COMPRA 1
- Page 149 and 150: Capítulo 9 Avaliação do modelo b
- Page 151 and 152: 9.1. APLICAÇÕES 133 1 ------ REMO
- Page 153 and 154: 9.2. RESERVAS 135 dentemente em dif
- Page 155 and 156: 9.2. RESERVAS 137 seguinte forma. P
- Page 157 and 158: 9.2. RESERVAS 139 Commit (% total)
- Page 159 and 160: 9.2. RESERVAS 141 Commit (% total)
- Page 161 and 162: 9.2. RESERVAS 143 Commit (% total)
- Page 163 and 164: 9.2. RESERVAS 145 Commit (% total)
- Page 165 and 166: 9.2. RESERVAS 147 Por exemplo, no c
- Page 167 and 168: Capítulo 10 Sistema de reconcilia
- Page 169 and 170: 10.2. RELAÇÕES ESTÁTICAS 151 10.
- Page 171 and 172: 10.3. ALGORITMO DE RECONCILIAÇÃO
- Page 173 and 174: 10.3. ALGORITMO DE RECONCILIAÇÃO
- Page 175 and 176: 10.3. ALGORITMO DE RECONCILIAÇÃO
- Page 177 and 178: 10.4. OPTIMIZAÇÃO DA RECONCILIAÇ
- Page 179 and 180: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 181 and 182: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 183 and 184: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 185 and 186: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 187 and 188: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 189 and 190: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 191 and 192: Capítulo 11 Trabalho relacionado A
- Page 193: 11.1. REPLICAÇÃO 175 11.1.2 Arqui
- Page 197 and 198: 11.1. REPLICAÇÃO 179 O mecanismo
- Page 199 and 200: 11.1. REPLICAÇÃO 181 dade 3 . Est
- Page 201 and 202: 11.1. REPLICAÇÃO 183 e ser propag
- Page 203 and 204: 11.1. REPLICAÇÃO 185 ordem de exe
- Page 205 and 206: 11.1. REPLICAÇÃO 187 execução d
- Page 207 and 208: 11.2. INFORMAÇÃO SOBRE A EVOLUÇ
- Page 209 and 210: 11.3. INTEGRAÇÃO DE SESSÕES SÍN
- Page 211 and 212: Capítulo 12 Conclusões A generali
- Page 213 and 214: 12.1. SUMÁRIO 195 é executado no
- Page 215 and 216: Apêndice A DOORS Este apêndice ap
- Page 217 and 218: A.1. FILIAÇÃO 199 A operação de
- Page 219 and 220: A.1. FILIAÇÃO 201 anterior à de
- Page 221 and 222: A.1. FILIAÇÃO 203 associados e o
- Page 223 and 224: A.1. FILIAÇÃO 205 Actualização
- Page 225 and 226: A.1. FILIAÇÃO 207 • Periodicame
- Page 227 and 228: A.1. FILIAÇÃO 209 estas situaçõ
- Page 229 and 230: A.1. FILIAÇÃO 211 2. Um servidor
- Page 231 and 232: A.2. SINCRONIZAÇÃO EPIDÉMICA 213
- Page 233 and 234: A.2. SINCRONIZAÇÃO EPIDÉMICA 215
- Page 235 and 236: A.2. SINCRONIZAÇÃO EPIDÉMICA 217
- Page 237 and 238: A.2. SINCRONIZAÇÃO EPIDÉMICA 219
- Page 239 and 240: Apêndice B Mobisnap B.1 Transacç
- Page 241 and 242: Bibliografia [1] S. Agarwal, D. Sta
- Page 243 and 244: BIBLIOGRAFIA 225 [22] Michael J. Ca
11.1. REPLICAÇÃO 177<br />
a unida<strong>de</strong> <strong>de</strong> replicação é <strong>de</strong> gran<strong>de</strong>s dimensões (conjunto <strong>de</strong> ficheiros no sist<strong>em</strong>a Ficus [66] e base <strong>de</strong><br />
<strong>dados</strong> no sist<strong>em</strong>a Bayou [161]), o sist<strong>em</strong>a t<strong>em</strong> dificulda<strong>de</strong> <strong>em</strong> suportar computadores com pequena capa-<br />
cida<strong>de</strong> <strong>de</strong> armazenamento, como é comum nos computadores portáteis. Quando a unida<strong>de</strong> <strong>de</strong> replicação<br />
é menor (um ficheiro no sist<strong>em</strong>a Roam [140]), o sist<strong>em</strong>a t<strong>em</strong> <strong>de</strong> gerir um elevado número <strong>de</strong> objectos.<br />
Dimensão da menor unida<strong>de</strong> <strong>de</strong> replicação A dimensão da menor unida<strong>de</strong> <strong>de</strong> replicação <strong>de</strong>ve ser<br />
suficient<strong>em</strong>ente pequena para que não se repliqu<strong>em</strong> <strong>dados</strong> <strong>de</strong>snecessários e suficient<strong>em</strong>ente gran<strong>de</strong> para<br />
que a <strong>gestão</strong> do processo não se torne <strong>de</strong>masiado complexa. Como se discutiu na secção 2.3.5, a unida<strong>de</strong><br />
<strong>de</strong> manipulação <strong>de</strong> um sist<strong>em</strong>a <strong>de</strong> <strong>gestão</strong> <strong>de</strong> <strong>dados</strong> é, por vezes, ina<strong>de</strong>quada como unida<strong>de</strong> <strong>de</strong> replicação.<br />
Assim, no sist<strong>em</strong>a DOORS, a unida<strong>de</strong> <strong>de</strong> replicação é <strong>de</strong>finida pelos programadores <strong>de</strong> acordo com o<br />
modo como os objectos estão internamente organizados. Esta aproximação permite a<strong>de</strong>quar a unida<strong>de</strong><br />
<strong>de</strong> replicação às características dos <strong>dados</strong> manipulados por cada aplicação. Uma aproximação s<strong>em</strong>e-<br />
lhante foi usada nos sist<strong>em</strong>as Javanaise [68] e Perdis [51] para melhorar o <strong>de</strong>s<strong>em</strong>penho num ambiente <strong>de</strong><br />
<strong>computação</strong> distribuída.<br />
O agrupamento automático <strong>de</strong> objectos, como executado nos sist<strong>em</strong>as <strong>de</strong> bases <strong>de</strong> <strong>dados</strong> orientadas<br />
para os objectos [165], não soluciona o probl<strong>em</strong>a <strong>de</strong> <strong>gestão</strong>, porque o sist<strong>em</strong>a continua a ter <strong>de</strong> lidar<br />
com todos os objectos no momento <strong>de</strong> <strong>de</strong>terminar quais <strong>de</strong>v<strong>em</strong> ser replicados. Pelo contrário, no sist<strong>em</strong>a<br />
DOORS, a unida<strong>de</strong> <strong>de</strong> replicação <strong>de</strong>fine uma caixa negra, o que minimiza o número <strong>de</strong> objectos com<br />
que o sist<strong>em</strong>a necessita <strong>de</strong> lidar. Num sist<strong>em</strong>a <strong>de</strong> ficheiro é possível dividir um documento longo <strong>em</strong><br />
vários ficheiros, obtendo um resultado s<strong>em</strong>elhante ao proposto no sist<strong>em</strong>a DOORS. No entanto, esta<br />
aproximação não é natural.<br />
Adicionalmente, a unida<strong>de</strong> <strong>de</strong> replicação <strong>de</strong>finida no sist<strong>em</strong>a DOORS, o subobjecto, <strong>de</strong>fine um ele-<br />
mento no qual é possível executar operações <strong>de</strong> forma in<strong>de</strong>pen<strong>de</strong>nte. Ao contrário do que acontece nos<br />
sist<strong>em</strong>as <strong>de</strong>senvolvidos para <strong>ambientes</strong> distribuídos, nos quais é possível replicar incr<strong>em</strong>entalmente [166]<br />
os objectos necessários ao funcionamento da aplicação, num ambiente <strong>de</strong> <strong>computação</strong> <strong>móvel</strong> esta propri-<br />
eda<strong>de</strong> é importante por permitir o funcionamento (ainda que parcial) durante os períodos <strong>de</strong> <strong>de</strong>sconexão.<br />
No sist<strong>em</strong>a Mobisnap, a unida<strong>de</strong> <strong>de</strong> replicação é o subconjunto <strong>de</strong> um registo. No entanto, a espe-<br />
cificação dos <strong>dados</strong> a replicar é efectuada usando instruções <strong>de</strong> interrogação, o que permite lidar com<br />
os objectos a nível s<strong>em</strong>ântico. Esta aproximação é s<strong>em</strong>elhante à adoptada nos sist<strong>em</strong>as <strong>de</strong> bases <strong>de</strong><br />
<strong>dados</strong> relacionais que suportam <strong>computação</strong> <strong>móvel</strong> [115] e nas soluções <strong>de</strong> replicação secundária se-<br />
mântica [35, 142].