Yakın Çevreye Yapılan Müdahaleler

distribu´ıdo

A necessidade de se identificar unicamente cada registro ´e uma caracter´ıstica b´asica presente

em muitos sistemas de informa¸c˜ao (Blaha et al. (1988)). Um dos grandes desafios introdu-

zidos pelo car´ater distribu´ıdo das solu¸c˜oes de replica¸c˜ao e sincroniza¸c˜ao de dados est´a na gera¸c˜ao de identificadores ´unicos locais, criados de forma independente nos dispositivos, que n˜ao sejam coincidentes com identificadores ´unicos criados no servidor ou em outros dispositi-

vos, evitando um problema conhecido como colis˜ao de chave prim´aria (Oracle FAQ’s (2008)).

Considere o seguinte exemplo:

1. Dispositivo A, executando uma aplica¸c˜ao de automa¸c˜ao de for¸ca de vendas, cadastra um novo pedido cujo c´odigo de identifica¸c˜ao possui o valor 1004. Dispositivo A sincroniza e o pedido ´e aplicado no servidor com o identificador ´unico 1004.

2. Dispositivo B, executando a mesma aplica¸c˜ao de automa¸c˜ao de for¸ca de vendas, cadastra outro pedido cujo c´odigo de identifica¸c˜ao ´unico tamb´em ´e 1004. Como o dispositivo B n˜ao sincronizou com o servidor depois que o dispositivo A enviou o pedido, ele n˜ao sabe que o n´umero 1004 j´a foi utilizado.

3. Dispositivo B sincroniza com servidor. Neste momento ocorrer´a um conflito de colis˜ao de chave prim´aria, pois o dispositivo B tentar´a cadastrar no banco de dados central um

3. Replica¸c˜ao e Sincroniza¸c˜ao de Dados 28

pedido com o c´odigo 1004, sendo que j´a existe no banco de dados um outro pedido com

este mesmo c´odigo cadastrado pelo dispositivo A.

Algumas solu¸c˜oes de sincroniza¸c˜ao encontradas no mercado, como o SyncML (SyncML Protocol

(2001)), prop˜oem uma arquitetura onde o cliente e o servidor administram seus pr´oprios iden- tificadores ´unicos independentemente. O identificador do cliente ´e conhecido como LUID, do inglˆes Locally Unique ID, e o identificador do servidor ´e conhecido como GUID, do inglˆes Globally Unique ID. Como os identificadores podem ser diferentes, o servidor precisa manter um tabela de mapeamento de identificadores. Por exemplo, para um item chamado “Carro” o LUID do cliente pode ser 11, enquanto o GUID do servidor pode ser 1010101. A tabela de mapeamento do servidor deve mostrar que, para este cliente, o LUID 11 ´e mapeado para o GUID 1010101. Nessa arquitetura os LUIDs s˜ao sempre atribu´ıdos pelo cliente. Se o servidor enviar um novo item para o cliente, o cliente ir´a atribuir a este item um LUID e enviar o identificador local gerado de volta para o servidor para que o mapeamento seja registrado.

A figura 3.2 apresenta um exemplo do mapeamento de identificadores ´unicos proposto pelo

SyncML.

Figura 3.2: Exemplo de mapeamento de identificadores no SyncML

Este procedimento ´e interessante em situa¸c˜oes onde um mesmo dispositivo precisa sincro- nizar dados com mais de um servidor, pois, nestes casos, cada servidor poderia ter um GUID independente. Por´em, no cen´ario de aplica¸c˜ao do mSync, onde v´arios dispositivos sincroni- zam com um ´unico servidor, esta solu¸c˜ao n˜ao ´e indicada, pois a medida que o n´umero de dispositivos e o volume de dados aumenta, o tamanho da tabela de mapeamento de identifica- dores tamb´em aumenta, e, considerando-se que a tabela de mapeamento precisa ser acessada para realizar qualquer opera¸c˜ao de atualiza¸c˜ao, inser¸c˜ao ou exclus˜ao de registros durante a sincroniza¸c˜ao, esse processo pode gerar um aumento significativo de processamento.

3. Replica¸c˜ao e Sincroniza¸c˜ao de Dados 29

Outras solu¸c˜oes, como o Microsoft Synchronization (MicrosoftSyncServices (2008)), su-

gerem que a aplica¸c˜ao se encarregue de gerar identificadores ´unicos locais que tamb´em sejam ´

unicos globalmente. Uma das sugest˜oes ´e a utiliza¸c˜ao de um tipo de dado especial do Micro-

soft SQL Server, chamado GUID (Vieira (2007)), como identificador ´unico. Esse tipo de dado

garante que os valores gerados como identificadores ser˜ao ´unicos independente do n´umero de clientes. Essa abordagem apresenta os seguintes problemas:

ˆ O tipo de dado utilizado ´e muito grande (16 bytes), o que aumenta o tamanho dos

agrupamentos de ´ındices e afeta negativamente a performance de opera¸c˜oes comuns,

como joins.

ˆ A gera¸c˜ao dos GUID ´e feita de maneira desordenada, o que faz com que os registros sejam inseridos em posi¸c˜oes aleat´orias no agrupamento de ´ındices. Isso pode causar a

fragmenta¸c˜ao dos agrupamentos de ´ındices, o que aumenta a quantidade de opera¸c˜oes

de entrada e sa´ıda necess´arias para a realiza¸c˜ao de consultas nas tabelas.

O framework mSync prop˜oe uma nova solu¸c˜ao para o problema de gera¸c˜ao de identifica-

dores ´unicos em um ambiente distribu´ıdo. Quando um dispositivo insere um novo registro em

sua base de dados local, ´e utilizado um LUID (Locally Unique ID), ´unico localmente, como

identificador do registro. Durante a sincroniza¸c˜ao, quando o registro ´e inserido no banco de

dados central, o servidor gera um GUID (Globally Unique ID) para o registro, que ´e ´unico

globalmente. O GUID gerado ´e enviado de volta para o dispositivo para que o LUID tem- por´ario seja substitu´ıdo pelo GUID definitivo, fazendo com que os identificadores nas duas arquiteturas, m´ovel e fixa, fiquem com o mesmo valor.

Essa abordagem n˜ao apresenta os problemas discutidos nas outras solu¸c˜oes. Diferente

do que acontece no SyncML, a tabela de mapeamento de identificadores n˜ao possui uma

quantidade excessiva de registros, pois o mapeamento s´o ´e necess´ario no momento em que

os registros s˜ao inseridos no banco de dados central durante a sincroniza¸c˜ao, podendo depois serem descartados. Na solu¸c˜ao proposta os identificadores globais s˜ao gerados apenas pelo servidor, o que permite a utiliza¸c˜ao de identificadores de tipos menores, resultando em agru- pamentos de ´ındices mais compactos, joins mais eficientes e menos processamento de entrada e sa´ıda na consulta `as tabelas. A Se¸c˜ao 4.4 detalha o esquema de gera¸c˜ao de identificadores ´

unicos proposto nesta disserta¸c˜ao.

Gera¸c˜ao de identificadores ´unicos globais nos dispositivos

Algumas aplica¸c˜oes exigem que os identificadores globais sejam gerados no pr´oprio dispositivo ub´ıquo. Um exemplo s˜ao aplica¸c˜oes de fiscaliza¸c˜ao, onde o fiscal precisa imprimir, em campo, autos de infra¸c˜ao que contenham o n´umero de identifica¸c˜ao do auto gerado.

Nesses casos ´e preciso utilizar alguma t´ecnica de gera¸c˜ao de identificadores que garanta que o identificador gerado no banco de dados local seja ´unico globalmente, n˜ao coincidindo com nenhum identificador gerado pelo servidor ou outro dispositivo.

3. Replica¸c˜ao e Sincroniza¸c˜ao de Dados 30

Uma solu¸c˜ao ´e utilizar como identificador a combina¸c˜ao de um valor que seja ´unico lo- calmente, por exemplo, um campo auto-incremental, e um valor que identifique unicamente

o dispositivo. Outra solu¸c˜ao ´e utilizar como identificador uma chave natural, como, por

exemplo, um n´umero de CPF ou CNPJ como identificador de um cliente.

A desvantagem destas abordagens ´e que, conforme discutido nesta Se¸c˜ao, elas geram iden- tificadores pouco compactos, que influenciam negativamente no tamanho dos agrupamentos de ´ındices, eficiˆencia dos joins e requerimentos de entrada e sa´ıda.