O experimento

Para a prova de conceito, foi necessário implementar um protótipo que validasse a proposta desta dissertação de mestrado. Para a modelagem, foi utilizado UML, através das ferramentas Gentleware Poseidon for UML 3.1, e o Borland Together Developer 2005.

Para o desenvolvimento, foi utilizada a IDE Borland JBuilder 2005, com a máquina virtual Java 1.4.2 da IBM para Linux. O ambiente de testes adotado foi uma máquina Intel Pentium IV de 2.0 GHz, 512 MB de RAM, disco rígido de 80GB com 4200 rpm, rodando o sistema operacional Linux Fedora Core 4, com kernell 2.6.11- 1.1369_FC4. Como dispositivo móvel, foi utilizado um Compaq iPaq 3790, com sistema operacional Microsoft Pocket Windows 2002, com 64MB de memória.

Base de dados

Para os testes da arquitetura de pré-seleção e pré-carga de dados para bancos de dados móveis proposta nesta dissertação, é necessário o uso de uma base de dados complexa e de tamanho significativo. É interessante para este trabalho validar se o agente interceptador consegue capturar regras interessantes a partir de consultas feitas no cliente móvel em uma base de dados utilizada por múltiplos usuários.

A organização Open Source Development Labs (OSDL)11 mantém um conjunto de testes de desempenho para avaliar o comportamento de soluções de software livre, em especial o sistema operacional Linux. Existem testes voltados especialmente para sistemas de bancos de dados e inspirados nos benchmarks do Transaction Processing Performance Council (TPC)12.

Foi utilizado nos testes, o toolkit Database Test 1 (DBT-1)13, versão 2.1, provido pelo OSDL para o SGBD PostgreSQL. Este toolkit simula uma base de dados que representa atividades realizadas por uma loja de livros online em um ambiente de Internet controlado. A origem da base de dados utilizada e das transações executadas é baseada na especificação do TPC-W [TPCW02]. 11 http://www.osdl.org 12 http://www.tpc.org

Apesar de utilizar o mesmo esquema, forma de geração de dados e transações do

benchmark TPC-W, os resultados obtidos com o DBT-1 não devem ser comparados

com resultados oficiais publicados pelo TPC. Os resultados oficiais do TPC aderem a um conjunto de práticas de auditoria que requerem, entre outras informações, a publicação de dados sobre preços e configuração de todos os produtos utilizados para obtenção do resultado. O objetivo do DBT-1 é oferecer para seus usuários a capacidade de gerar uma carga de trabalho comparável às encontradas em aplicações reais.

Figura 4.10- Entidades e relacionamentos da base de dados TPC-W [TPCW02]

A Figura 4.10 mostra o modelo de entidade e relacionamento especificado pelo TPC-W. As linhas tracejadas representam relacionamentos um-para-um entre atributos não-chaves relacionados por uma regra de negócio. Estes atributos são indicados em

itálico.

Para popular as tabelas do banco, o toolkit DBT-1 gera dados aleatórios, ou seja, dados com valores selecionados de forma independente e distribuídos uniformemente. A carga de trabalho para o banco de dados do experimento foi de 10000 itens, 2500

autores, 2880000 clientes, 2592000 transações de compras. Um exemplo do tipo de dado gerado pelo DBT-1 pode ser visto no Quadro 4.1.

Quadro 4.1 - Exemplo de dados gerados pelo DBT-1

Tabela ITEM Tabela AUTHOR

Atributo I_TITLE Atributo A_LNAME

Children with BABABABABABAAL the other, general

BABABABABABAOGl7xF

Years shall fall BABABABABABARI firm, black patients--

BABABABABABAALwH

Right, short schools would look BABABABABABARE more?

BABABABABABARI

Papers could love. Political, BABABABABABASEeconomic

BABABABABABARE

Soviet, BABABABABABAATindustrial duties must know in

BABABABABABASE

Como critério para a escolha das consultas realizadas pelo cliente foram escolhidas transações que envolvessem uma compra, consultando dados de suas compras, como mostrado no Quadro 4.2. O objetivo é encontrar relações entre essas compras e compras que outros usuários fizeram.

Quadro 4.2 - Exemplos de consultas feitas no cliente móvel

Tipo de consulta Consulta SQL

1. Consulta por dados de uma determinada compra.

select co_name, addr_city, addr_state,

c_fname, i_title, i_publisher

from customer, item, orders, order_line,

address, country

where i_id=ol_i_id and ol_o_id=o_id and

c_id=o_c_id and c_addr_id=addr_id and addr_co_id=co_id and o_id = 20934;

2. Consulta por dados de uma compra de um determinado usuário

select co_name, addr_city, addr_state,

c_fname, i_title, i_publisher

from customer, item, orders, order_line,

address, country

where i_id=ol_i_id and ol_o_id=o_id and

c_id=o_c_id and c_addr_id=addr_id and addr_co_id=co_id and c_id = 1500;

Execução dos testes

Na Figura 4.11, o diagrama de colaboração que ilustra, em linhas gerais, as trocas de mensagens entre o cliente móvel e o servidor fixo, já detalhados nas seções 4.1 e 4.2 é mostrado. Em um primeiro momento, o cliente móvel envia a pilha de consultas realizadas, a fim de que o servidor fixo execute o algoritmo Apriori (ver seção 4.3.2). Após análise das consultas enviadas pelo QueriesStack, o QueriesHoard executa o algoritmo Apriori sobre os dados no SGBD fixo.

QueriesStack QueriesHoard 1: Apriori 1.1: AprioriItemSet 1.1.1: «actor» HSQLDB 1.3.1: 1.3.1.1: 1.3: «actor» PostgreSQL 1.2:

Figura 4.11 - Diagrama de colaboração. Troca de mensagens entre cliente móvel e servidor fixo

Por restrição de memória no servidor (512MB de RAM), o teste foi restringido a um subconjunto dos mais de dois milhões de compras simuladas pelo DBT-1 e registradas no SGBD.

Por exemplo, para consultas do tipo consulta 1 do Quadro 4.2, foram encontradas as regras que estão no Quadro 4.3:

Quadro 4.3 - Exemplos de regras de associação

1 co_name=United States 25 ==> o_ship_type=UPS 18 conf:(0.72) 2 co_name=Slovakia 43 ==> o_ship_type=MAIL 16 conf:(0.37) 3 I_subject=CHILDREN 71 ==> o_ship_type=UPS 23 conf:(0.32) 4 I_subject=MYSTERY 55 ==> o_ship_type=SHIP 15 conf:(0.27) 5 I_subject=YOUTH 65 ==> o_ship_type=COURIER 17 conf:(0.26) 6 I_subject=ROMANCE 69 ==> o_ship_type=COURIER 18 conf:(0.26) 7 I_subject=REGLIGION 79 ==> o_ship_type=COURIER 19 conf:(0.24) 8 I_subject=TRAVEL 67 ==> o_ship_type=AIR 16 conf:(0.24)

9 I_subject=SELF-HELP 73 ==> o_ship_type=UPS 17 conf:(0.23) 10 I_subject=COMPUTERS 68 ==> o_ship_type=MAIL 15 conf:(0.22)

Tomando por exemplo a regra 1 descrita no Quadro 4.3, que indica que as compras realizadas nos Estados Unidos estão associadas com o tipo de serviço de

entrega da empresa UPS, com confiança de 72%, ou seja, 72% das compras realizadas nos EUA escolheram os serviços de entrega da UPS.

A confiança das regras achadas é relativamente baixa visto que a base de dados, apesar de representar um banco transacional real, tem seus dados gerados aleatoriamente, seguindo uma distribuição uniforme [TPCW02]. Isso implica em baixa relação entre os dados, uma vez que há pouca repetição de itens nas transações. Apesar desta característica, a base de dados cumpre seu propósito de ilustrar a prova de conceito.

É papel, então, do QueriesHoard enviar para o dispositivo móvel dados que respeitem a regra 1 listada no Quadro 4.3, como descreve a consulta:

select *

from customer, item, orders, order_line, address, country

where i_id=ol_i_id and ol_o_id=o_id and c_id=o_c_id and c_addr_id=addr_id and

addr_co_id=co_id and co_name=’United States’ and o_ship_type=’UPS’;

Comparação pré-seleção x política LRU

Como planejado para esse trabalho, a pré-seleção de dados com uso de descoberta de regras de associação é comparado com a seleção de dados para o banco de dados no dispositivo móvel utilizando a política LRU, na qual os dados menos utilizados recentemente são descartados para dar lugar a novos dados.

A comparação entre os dois esquemas de seleção de dados para bancos de dados móveis é feita de forma simulada14, uma vez que este trabalho não teve acesso a uma rede de usuários de cliente móveis como também não teve acesso a uma base de dados reais.

14

0 2 4 6 8 10 12 14 16 18 20 0 10 20 30 Tamanho da cache (x10) C o n su lt as co m su cesso Apriori LRU

Figura 4.12 - Cache Hit x Tamanho da cache

O gráfico ilustrado na Figura 4.12 mostra uma comparação entre número de consultas x tamanho da cache. Utilizando a política LRU, ao longo do tempo a disponibilidade dos dados torna-se tecnicamente igual à disponibilidade quando se utiliza a pré-seleção de dados com o Apriori.

Analisando-se a Figura 4.12 verifica-se que o desempenho da política LRU, por não fazer nenhuma pré-carga de dados, só se iguala ao desempenho do Apriori após algumas consultas terem sido realizadas. Isso implica em mais conexões entre o dispositivo móvel e o servidor fixo. O Apriori utiliza menos vezes a conexão, enquanto envia a pilha de consultas realizadas e recebe em troca uma massa de dados referentes a uma regra descoberta. Em contra-partida, o Apriori consome mais banda por conexão utilizada, uma vez que é devolvida uma massa de dados que abrange, normalmente, mais dados que a consulta original requisitou.

0 5 10 15 20 25 30 35 0 5 10 15 20 25 30 Tamanho da cache Qua n ti d a de de b a nd a u ti li z a d a Apriori LRU

Figura 4.13 - Banda x tamanho da cache

A Figura 4.13 mostra a quantidade de banda utilizada, isto é, o número de tuplas transferidas do servidor fixo para o dispositivo móvel. Utilizando-se o Apriori, este número é maior que se utilizando a política LRU. Também se pode observar na Figura 4.13 que há menos requisições feitas ao servidor fixo quando utilizado o Apriori, tornando as consultas no cliente móvel menos dependentes da conexão com o servidor fixo.

4.5 Considerações Finais

Neste capítulo, foi apresentada a proposta de gerenciamento de cache em bancos de dados móveis a partir de pré-seleção e pré-carga em um banco de dados móvel. Também foi apresentada a infra-estrutura do SGBD no lado do cliente necessária para a implementação do sistema assim como foi discutida a arquitetura de agentes necessária para a comunicação entre o SGBD no cliente móvel e o SGBD na estação fixa.

Também foi apresentada neste capítulo, na seção 4.1, a arquitetura geral do sistema. Na seção 4.2, foi apresentado a infra-estrutura no dispositivo móvel, utilizando como base o SGBD HSQLDB, assim como a arquitetura no lado do agente

interceptador no servidor fixo, baseada no Weka e no PostgreSQL, na seção 4.3. A técnica de aprendizagem de máquina para descoberta de regras de associação, o algoritmo Apriori, foi apresentado em detalhes na seção 4.3.2 deste capítulo.

Nos testes executados, foi observado que a utilização do Apriori como política para pré-selecionar os dados tornou o dispositivo móvel menos dependente do servidor fixo, uma vez que ele precisa se conectar menos vezes para atualizar sua base de dados local.

Por outro lado, também foi observado que o Apriori, na implementação desta dissertação, consome muita memória no servidor fixo para encontrar os itemsets candidatos, além de consumir bastante tempo de processamento para fazer a contagem do suporte dos itemsets candidatos encontrados (ver seção 4.3.2 para detalhes). O tempo de processamento é diretamente proporcional ao tamanho da base varrida.

Na seção 4.4 deste capítulo, foi apresentado o experimento realizado como prova de conceito. Nesta seção, a base de dados, que está associada a especificação do TPC- W, detalhando-se a natureza dos dados, e também foram apresentados os tipos de consultas realizadas nos testes.

Por fim, foi analisado o resultado das simulações do experimento, que mostra o comportamento da disponibilidade dos dados no cliente móvel quando utilizado o Apriori como política de seleção de dados e o comportamento quando utilizado a política de seleção baseado em LRU:

Resumidamente podemos constatar as seguintes vantagens e desvantagens do uso do Apriori no Quadro 4.4:

Quadro 4.4 - Vantagens e desvantagens

Vantagens Desvantagens

Maior disponibilidade dos dados Consumo de banda

Menor número de requisições ao servidor Necessidade de poder de processamento no servidor

Menor dependência da rede Necessidade de memória diretamente proporcional ao tamanho da base de dados