Uma Abordagem para Indexação e Buscas Full-Text Baseadas em Conteúdo em Sistemas de Armazenamento em Nuvem

Uma Abordagem para Indexao e Buscas Full-Text
Baseadas em Contedo em Sistemas de Armazenamento em

Nuvem
Por
Marco Andr Santos Machado

Dissertao de Mestrado
Universidade Federal de Pernambuco

posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao
Recife, Agosto/2013
Universidade Federal de Pernambuco

Centro de Informtica
Ps-graduao em Cincia da Computao
Marco Andr Santos Machado
Uma Abordagem para Indexao e Buscas Full-Text

Baseadas em Contedo em Sistemas de Armazenamento
em Nuvem
Trabalho apresentado ao Programa de Ps-graduao em

Cincia da Computao do Centro de Informtica da Universidade Federal de Pernambuco como requisito parcial para
obteno do grau de Mestre em Cincia da Computao.
Orientador: Vinicius Cardoso Garcia

Co-Orientador: Frederico Arajo Duro
Recife, Agosto/2013
Eu dedico esta dissertao meus pais por todo o incentivo

e apoio que sempre me deram em minha vida.
Agradecimentos
Primeiramente gostaria de agradecer a toda minha famlia, em especial meus pais,

Andr e Eliete, e irmos, Mateus e Jssica, por todo o amor, carinho e incentivo dado
durante toda minha vida.
Agradeo a Felcia, minha namorada, por seu amor, amizade e apoio incondicional
durante todos esses anos e por sempre me incentivar a seguir adiante.
Agradeo a Vinicius Garcia e Frederico Duro, respectivamente, meu orientador e
co-orientador, por dedicarem tempo para me orientar durante o desenvolvimento deste
trabalho e pelos seus conselhos, ensinamentos e cobranas.
Aos meus amigos da Ustore, em especial Rodrigo Assad, Anderson Fonseca,
Francisco Soares, Paulo Fernando, por toda a estrutura tcnica disponibilizada e pelas
inmeras discusses relacionadas a este trabalho.
Aos amigos que fiz dentro do CIn, especialmente Paulo Fernando, Thiago Vieira,
Lenin Abadie, Francisco Airton, Dhiego Abrantes, Adriano Tito, Rodolfo Arruda, Jamilson Batista, Joo Emanoel, Bruno Felipe, Hlio Rodrigues, Kellyton Brito, Leandro
Marques.
Agradeo a Bernadette Lscio e Rodrigo Assad por aceitarem fazer parte da banca
da minha defesa e pelas crticas e conselhos dados, que possibilitaram melhorar este
trabalho.
Aos meus velhos amigos Jonatas Bastos e Leandro Oliveira por me incentivarem a
fazer um mestrado e por todo o apoio dado para que eu conseguisse uma vaga na UFPE.
Agradeo Fundao de Amparo Cincia e Tecnologia do Estado de Pernambuco
(FACEPE) pelo suporte financeiro dados minha pesquisa, o qual possibilitou a realizao
deste trabalho.
Finalmente, gostaria de agradecer a todos aqueles que colaboraram direta ou indiretamente na realizao deste trabalho
...
iv
Resumo
O universo digital cresce de forma exponencial e a previso que em 2015 chegue

a quase 8 zettabytes. cada vez mais complexo processar, armazenar, gerenciar, garantir
a segurana e disponibilizar estas informaes. O armazenamento em nuvem apontado como melhor soluo para lidar com estes problemas e muitos sistemas tm sido
desenvolvidos com este fim. Grande parte destes sistemas tiram proveito da arquitetura
peer-to-peer (p2p) para evitar gargalos, pontos nicos de falha e conseguir escalar de
forma fcil. A maioria dos sistemas de armazenamento em nuvem existentes no permite
que o usurio faa buscas mais complexas, por exemplo, levando em considerao o
contedo dos arquivos ou informaes presente nos metadados. Com isso essa pesquisa
tem como objetivo propor uma abordagem para extrao e indexao de contedo dos
arquivos, de forma que o sistema permita que sejam realizadas buscas full-text baseadas
no contedo dos arquivos em sistemas de armazenamento em nuvem com arquitetura
peer-to-peer. Alm disso, essa pesquisa tambm tem como objetivo investigar uma
maneira eficiente para armazenar o ndice de busca dentro da arquitetura P2P, de forma
que seja possvel replicar as informaes com facilidade, permita elasticidade, garanta
disponibilidade e, com isso, permitir que as buscas encontrem a maior quantidade de
resultados relevantes possvel.
Palavras-chave: Recuperao de Informao, Computao em Nuvem, Armazenamento em Nuvem
Abstract
The "digital universe"grows exponentially and is expected in 2015 will reach almost
8 zettabytes. It is becoming more complex to process, store, manage, ensure safety and
provide this information. The cloud storage is pointed as the best solution to deal with
these problems and many systems have been developed for this purpose. Most of these
systems take advantage of the peer-to-peer (p2p) architecture to avoid bottlenecks, single
points of failure and and to scale easily. Most cloud storage systems existing does not
allow the user to make more complex searches, eg, taking into account the contents of
the files or information on metadata. Hence this research aims to propose an approach to
extract and index the contents of files, such the system allows full-text searches based
on the content of files in cloud storage systems based on peer-to-peer architecture. In
addition, this research also aims to investigate an efficient way to store the search index
within the P2P architecture, so that it is possible to replicate the information with ease,
allowing elasticity, ensures availability and thereby allow the searches bring as many
relevant results possible. In addition, this research also aims to investigate an efficient
way to store search index within the P2P architecture, such it is possible to replicate the
information with ease, allowing elasticity, ensures availability and, thus, allow searches
to find as many relevant results possible.
Keywords: Information Retrieval, Cloud Computing, Cloud Storage
vi
Sumrio
Lista de Figuras
ix
Lista de Tabelas
xi
1
2
3
3
4
5
Introduo
1.1 Motivao . . . . . . . .
1.2 Definio do Problema .
1.3 Soluo Proposta . . . .
1.4 Fora do Escopo . . . . .
1.5 Estrutura da Dissertao
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Contextualizao e Trabalhos Relacionados

2.1 Recuperao de Informao . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Modelos de Recuperao de Informao . . . . . . . . . . . . .
2.1.1.1 Modelo Booleano . . . . . . . . . . . . . . . . . . .
2.1.1.2 Modelo Espao Vetorial . . . . . . . . . . . . . . . .
2.1.1.3 Modelo Probabilstico . . . . . . . . . . . . . . . . .
2.1.2 Recuperao de Informao versus Recuperao de Dados . . .
2.2 Computao em Nuvem . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Armazenamento de Dados em Nuvem . . . . . . . . . . . . . .
2.3 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Recuperao de Informao em Sistemas de Armazenamento em
Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Sumrio do Captulo . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
6
7
7
7
8
8
9
11
13
14
16
Uma Abordagem para Indexao e Buscas Full-Text Baseadas em Contedo

em Sistemas de Armazenamento em Nuvem
3.1 Ustore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Arquitetura do Ustore . . . . . . . . . . . . . . . . . . . . . .
3.1.1.1 Cliente Ustore . . . . . . . . . . . . . . . . . . . . .
3.1.1.2 Servidor Ustore . . . . . . . . . . . . . . . . . . . .
3.1.1.3 Super peer . . . . . . . . . . . . . . . . . . . . . . .
3.2 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . . .
3.2.2 Requisitos No-Funcionais . . . . . . . . . . . . . . . . . . . .
3.3 Indexao e Consultas Full-Text Baseadas em Contedo . . . . . . . . .
3.3.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1.1 Viso de Componentes . . . . . . . . . . . . . . . .
3.3.2 Indexao Full-Text . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2.1 Metadados . . . . . . . . . . . . . . . . . . . . . . .
3.3.2.2 Indexao Local . . . . . . . . . . . . . . . . . . . .
3.3.2.3 Indexao no Servidor de Buscas . . . . . . . . . . .
17
17
17
19
20
20
20
21
21
23
23
23
23
24
26
26
vii
3.3.2.4
3.4
3.5
4
Elasticidade e Replicao do ndice entre Servidores

de Busca . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3 Estratgias para Consultas Full-Text . . . . . . . . . . . . . . .
3.3.3.1 Consulta Local . . . . . . . . . . . . . . . . . . . . .
3.3.3.2 Consultas em outros clientes Ustore pela rede . . . .
3.3.3.3 Consultas no Servidor de Buscas . . . . . . . . . . .
Detalhes da Implementao . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1 Apache Lucene . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.2 Apache Tika . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sumrio do Captulo . . . . . . . . . . . . . . . . . . . . . . . . . . .
Experimento
4.1 Coleo de Dados . . . . . . . . . . . .
4.2 Consultas . . . . . . . . . . . . . . . .
4.3 Conjunto de Julgamentos de Relevncia
4.4 Ambiente de Teste . . . . . . . . . . .
4.5 Metodologia de Avaliao . . . . . . .
4.5.1 Cenrios para Avaliao . . . .
4.6 Resultados . . . . . . . . . . . . . . . .
4.6.1 Resultados no Cenrio I . . . .
4.6.2 Resultados no Cenrio II . . . .
4.6.3 Resultados no Cenrio III . . .
4.6.4 Resultados no Cenrio IV . . .
4.7 Discusso e Consideraes Finais . . .
4.7.1 Discusso dos Resultados . . .
4.7.2 Problemas Encontrados . . . . .
4.7.3 Possveis Ameaas Validade .
4.8 Sumrio do Captulo . . . . . . . . . .
27
28
30
31
31
32
32
35
35
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
37
38
38
38
39
41
41
42
45
47
50
51
51
52
53
53
Concluso e Trabalhos Futuros

5.1 Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
54
55
Referncias Bibliogrficas
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
56
viii
Lista de Figuras
1.1
2.1
2.2
2.3
2.4
Expectativa de crescimento da quantidade de dados gerados [Gantz and

Reinsel, 2011]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arquitetura em camadas para computaao nas nuvens . . . . . . . . . .

9
Arquitetura de um sistema de armazenamento em nuvem. Adaptado de
[Peddemors and Spoor, 2010]. . . . . . . . . . . . . . . . . . . . . . . 12
Arquitetura de um sistema de armazenamento em nuvem utilizando
arquitetura P2P. Adaptado de [Peddemors and Spoor, 2010]. . . . . . . 12
Representao do processo de para armazenamento e recuperao de
dados utilizando erasure code. Adaptado de [Peddemors and Spoor, 2010]. 13
3.1
3.2
3.3
Representao da arquitetura do JXTA [Heiss, 2005] . . . . . . . . . .

Representao da arquitetura do Ustore. . . . . . . . . . . . . . . . . .
Diagrama de componentes do Ustore mostrando os componentes para
indexao e busca. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Diagrama de sequncia mostrando o processo de indexao. . . . . . .
3.5 Diagrama de atividades representando o processo de indexao e replicao do ndice de busca implementado no Ustore. . . . . . . . . . . . . .
3.6 Diagrama de sequncia mostrando o processo de busca. . . . . . . . . .
3.7 Tela do Ustore exibindo resultado da busca. . . . . . . . . . . . . . . .
3.8 Representao da consulta atravs da rede P2P . . . . . . . . . . . . . .
3.9 Representao da consulta utilizando o Servidor de Buscas . . . . . . .
3.10 ndice Invertido no Apache Lucene [Hatcher and Gospodnetic, 2004]. .
3.11 Arquitetura do Apache Lucene. [Hatcher and Gospodnetic, 2004] . . .
3.12 Arquitetura do Apache Tika. [Mattmann and Zitting, 2011] . . . . . . .
4.1
4.2
4.3
4.4
4.5
4.6
4.7
Representao do cenrio de testes utilizado no experimento. . . . . . .

Grfico comparando a preciso entre quatro clientes do Ustore variando
a quantidade de retornos e o tipo de indexao. . . . . . . . . . . . . .
Grfico comparando o recall entre quatro clientes do Ustore variando a
quantidade de retornos e o tipo de indexao. . . . . . . . . . . . . . .
Grfico comparando o tempo de consulta local do Ustore variando a
Grfico comparando a preciso entre quatro clientes do Ustore variando
a quantidade de retornos e o tipo de indexao e fazendo consulta aos
outros clientes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Grfico comparando o recall de quatro clientes do Ustore variando a
quantidade de retornos e o tipo de indexao e fazendo consulta aos
outros clientes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Grfico comparando o tempo de consulta aos outros clientes do Ustore
variando a quantidade de retornos e o tipo de indexao. . . . . . . . .
18
19
24
25
27
29
30
31
32
33
35
36
38
42
43
44
45
46
47
ix
4.8
Grfico comparando a preciso do Ustore variando a quantidade de

retornos e o tipo de indexao. . . . . . . . . . . . . . . . . . . . . . .
4.9 Grfico comparando o recall do Ustore variando a quantidade de retornos
e o tipo de indexao. . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.10 Grfico comparando as taxas de preciso e recall do Ustore variando a
4.11 Grfico comparando o tempo gasto para realizar consultas no Ustore
utilizando indexao baseada em ttulo e contedo. . . . . . . . . . . .
4.12 Grfico comparando o tempo gasto realizar backup com e sem a indexao baseada em contedo gerando um ndice local e outro no servidor. .
48
48
49
50
51
Lista de Tabelas
2.1
Tabela com diferenas entre recuperao de dados e recuperao de

informao. Adaptada de [Rijsbergen, 1979] . . . . . . . . . . . . . .
3.1
3.2
Tabela com a situao dos requisitos propostos. . . . . . . . . . . . . .

Tabela de metadados indexados no Ustore. . . . . . . . . . . . . . . .
22
26
4.1
4.2
4.3
4.4
4.5
4.6
Mtricas utilizadas na avaliao. . . . . . . . . . . . . . . . . .

Fatores e nveis utilizados para avaliar as mtricas definidas. . .
Tabela com tamanho dos ndices gerados em cada cliente Ustore.
Tabela com os valores da F-Measure. . . . . . . . . . . . . . .
39
40
42
44
46
49
. . .
. . .
. .
. . .
. . .
. . .
.
.
.
.
.
.
xi
Introduo
A cada dia se produz mais informao e, geralmente, estas informaes so armazenadas em meios digitais. O tamanho desse universo digital cresce de forma exponencial.
Segundo relatrio publicado pela EMC Corporation1 [Gantz and Reinsel, 2011], em 2005,
o volume de dados chegou a 130 exabytes2 ; em 2010, superou 1 zettabyte e a previso
que em 2015 chegue a quase 8 zettabytes3 , conforme mostrado na Figura 1.1.
Figura 1.1 Expectativa de crescimento da quantidade de dados gerados [Gantz and Reinsel,
2011].
Este universo digital citado em [Gantz and Reinsel, 2011] expande e se torna
cada vez mais complexo para processar, armazenar, gerenciar, garantir a segurana e
disponibilizar estas informaes. Somente a demanda por armazenamento cresceu mais
1 http://www.emc.com
Acessado em: 07/08/2013

1.000.000.000 GB
3 aproximadamente, 1.000.000.000.000 GB
2 aproximadamente,
1.1. MOTIVAO
de 50% nos ltimos anos [Kaplan et al., 2008]. Para lidar com essas demandas, segundo
[Gantz and Reinsel, 2011], sero necessrias habilidades, experincia e recursos, como
capacidade de armazenamento, processamento, que rapidamente se tornaro escassos,
alm de uma nova infraestrutura de Tecnologia da Informao escalvel e flexvel. Uma
opo que atende a estes requisitos a computao em nuvens.
A utilizao da computao em nuvens permite que os usurio possam alocar recursos dinamicamente, de acordo com sua necessidade. Entre esses recursos est o
de armazenamento, o qual prov recursos e servios de armazenamento baseados em
servidores remotos que utilizam os princpios da computao em nuvem. A utilizao da
computao em nuvens para armazenamento permite que servios de armazenamento
sejam disponibilizados a um baixo custo [Zeng et al., 2009].
Diversos sistemas de armazenamento em nuvem dividem os arquivos em pedaos
menores, chamados chunks, antes de armazen-los. Esta estratgia permite que seja
efetuada uma replicao de dados mais eficiente e menos custosa, pois somente sero
enviados pequenas partes do arquivo e no o arquivo completo. Alm disto, como
os arquivos so armazenados apenas de forma particionada, isto garante uma maior
segurana dos dados [Rabin, 1989].
Quando preciso lidar com um grande conjunto de dados, podemos utilizar tcnicas de
recuperao de informao para facilitar o processo de localizao de algum documento.
Para isto, necessrio que os documentos sejam indexados e um ndice de busca seja
gerado. A partir da, um sistema de recuperao de informao (RI) poder localizar os
arquivos que so mais relevantes para a necessidade do usurio [Manning et al., 2008].
A necessidade de informao do usurio representada atravs de sua expresso de
busca, que pode ser especificada em linguagem natural (mesmos termos usados pelo
autor do documento) ou atravs de uma linguagem artificial (termos determinados pelos
desenvolvedores do sistema de RI), e deve resultar na recuperao de um nmero de
documentos que possibilite a verificao de cada um deles a fim de selecionar os que so
teis. A principal dificuldade do usurio est em predizer, por meio de uma expresso
de busca, as palavras ou expresses que foram usadas para representar os documentos
e que satisfaro sua necessidade. Com o aumento da capacidade de armazenamento
dos computadores, muitos sistemas de RI conseguem disponibilizar o texto integral dos
documentos. Esta abordagem muito utilizada em grandes engenhos de busca, como:
Google4 , Yahoo5 , Microsoft Bing6 , entre outros, e tem como objetivo permitir que o
usurio possa localizar informaes existentes no contedo dos documentos, alm de
permitir a utilizao de linguagem natural na expresso de busca.
1.1
Motivao
Os sistemas de armazenamento em nuvem mais populares, como: Amazon S3,

Dropbox, SugarSync, Wuala, entre outros, somente permitem que o usurio localize
4 http://www.google.com
Acessado em 21/08/2013
6 http://www.bing.com Acessado em 21/08/2013
5 http://www.yahoo.com
1.2. DEFINIO DO PROBLEMA
algum arquivo pelo ttulo do arquivo armazenado. Conforme discutido em [Kostoff, 2010]
e [Berrios, 2000] a utilizao de consultas full-text baseadas no contedo do arquivo
podem aumentar a quantidade de resultados relevantes retornados em relao consultas
baseadas no ttulo e palavras-chave. Alm disso, pelo fato de ser possvel consultar o
contedo integral do arquivo, as consultas podem ser realizadas utilizando linguagem
natural. Por exemplo, caso o usurio esteja escrevendo um artigo sobre o banco de dados
Cassandra7 e no consiga se lembrar do nome que usou para salvar o arquivo, mas sabe
que o texto escrito possui a frase O Cassandra um banco de dados NoSQL. Utilizando
consultas full-text baseadas no contedo, ser possvel utilizar esta frase para localizar o
arquivo salvo, e no somente o nome do arquivo.
Para que seja possvel realizar consultas full-text baseada em contedo necessrio
que o contedo do arquivo seja extrado e, juntamente com os metadados, indexado para
formar o ndice de busca. Esta operao de indexao pode ser muito custosa caso seja
realizada aps a concluso do armazenamento, j que muitos sistemas de armazenamento
em nuvem armazenam somente os chunks dos arquivos, sendo necessrio, assim, uma
abordagem que possibilite que o contedo dos arquivos seja extrado e indexado no
momento do backup.
Tomando isto como base, este trabalho prope uma abordagem para permitir indexao e consultas full-text baseadas no contedo dos arquivos indexados. A abordagem
ser desenvolvida de forma que seja possvel ser implantada em um sistema de armazenamento, no qual os arquivos sejam armazenados em chunks. Esta abordagem ser
implantada em um sistema real de armazenamento de dados em nuvem, o qual funciona
sobre uma arquitetura peer-to-peer.
1.2
Definio do Problema
A maioria dos sistemas de armazenamento em nuvem somente permitem que consultas

sejam feitas pelo ttulo do arquivo. Visto que a utilizao de consultas full-text permite
que o usurio utilize uma linguagem natural nos termos de busca e isto pode aumentar a
qualidade dos resultados retornados, o problema que esta dissertao se prope a resolver
pode ser definido como:
Os resultados retornados em uma busca em um sistema de armazenamento
em nuvem podem ser melhorados utilizando indexao e busca full-text baseadas em contedo?
1.3
Soluo Proposta
Esta dissertao tem como objetivo geral propor uma abordagem para realizar indexao e consultas full-text baseadas no contedo dos arquivos para sistemas de armazena7 http://cassandra.apache.org/
1.4. FORA DO ESCOPO
mento em nuvem.
Para o desenvolvimento desta pesquisa, os seguintes itens so considerados como
objetivos especficos:
Identificar as propostas adotadas hoje pelo sistemas de armazenamento em
nuvem para analisar quais informaes so armazenadas em forma de metadados
e quais as opes de consultas disponibilizadas.
Realizar um levantamento de requisitos para as funcionalidades da abordagem proposta de forma a tornar a abordagem vivel para ser utilizada em um
sistema real de armazenamento em nuvem.
Definir a estrutura dos metadados que sero utilizados na abordagem proposta.
Definir e implementar como os arquivos armazenados sero indexados, de
forma que seja possvel implementar a abordagem em um sistema real de armazenamento em nuvem, onde este armazena somente os chunks dos arquivos.
Definir e implementar como sero realizadas as consultas, levando em considerao a arquitetura na qual o sistema de armazenamento em nuvem foi implementado.
Realizar um estudo experimental para avaliar a abordagem desenvolvida e o
impacto de sua implementao e utilizao.
1.4
Fora do Escopo
Alguns assuntos foram excludos do escopo de pesquisa desta dissertao. So eles:

Atributos relacionados com a segurana do ndice gerado na indexao ou
dos arquivos armazenados: O ndice gerado na indexao contm todas as informaes importantes dos arquivos indexados. Entretanto, no faz parte do escopo
deste trabalho analisar qual a forma mais segura de armazenar o ndice gerado e
nem os arquivos armazenados.
Tcnicas para evitar flooding em uma rede peer-to-peer: A abordagem proposta
utiliza, como uma das estratgias possveis de busca, a consulta ao ndice de outros
peers atravs da rede peer-to-peer formada. Se a quantidade de mensagens trocadas
na rede for muito grande, isto pode gerar um problema conhecido com flooding.
Esta pesquisa no aborda as diversas tcnicas disponveis para evitar este tipo de
problema.
Modelo probabilstico para recuperao de informao: Este modelo possibilita recuperar informao atravs de clculos probabilsticos, usando para tal a
teoria da probabilidade. Este modelo no analisado nesta dissertao.
1.5. ESTRUTURA DA DISSERTAO
Indexao do contedo de arquivos de udio e video: H diversas propostas na

literatura propondo abordagens para indexao do contedo de arquivos de udio,
vdeo e imagens. Entretanto estas abordagens no sero analisadas no escopo deste
trabalho.
1.5
Estrutura da Dissertao
O restante desta dissertao est organizada da seguinte forma:

Captulo 2 apresenta uma contextualizao e os trabalhos relacionados com recuperao de informao em sistemas de armazenamento em nuvem.
Captulo 3 descreve a abordagem proposta, includos os requisitos, arquitetura e
detalhes das implementaes realizadas.
Captulo 4 apresenta um experimento realizado no Ustore com a abordagem proposta implementada.
Captulo 5 apresenta a concluso do trabalho e aponta alguns possveis trabalhos
futuros.
Contextualizao e Trabalhos
Relacionados
Neste captulo sero apresentados os conceitos de recuperao de informao e
computao em nuvens, conceitos-chave desta dissertao, bem como alguns trabalhos
relacionados com recuperao de informao em sistemas de armazenamento em nuvem.
2.1
Recuperao de Informao
Um sistema de recuperao de informao (RI) tem o objetivo de localizar a informao que relevante para a consulta do usurio. Um sistema de RI tipicamente realiza
consultas em colees de dados no estruturados ou semi-estruturados (por exemplo,
pginas web, documentos, imagens, vdeos, etc.). A necessidade de um sistema de RI
ocorre quando um conjunto de dados atinge um tamanho que as tcnicas tradicionais de
catalogao j no permitem que os documentos sejam encontrados facilmente. Para que
isto seja possvel, necessrio que os documentos sejam indexados e um ndice de busca
seja gerado [Manning et al., 2008].
Os sistemas de RI devem representar o contedo dos documentos e apresent-los ao
usurio de uma maneira que lhe permita uma rpida seleo dos itens que satisfazem total
ou parcialmente sua necessidade de informao, formalizada atravs da uma expresso
de busca. O processo de representao busca descrever ou identificar cada documento
atravs de seu contedo. Tal representao geralmente realizada atravs do processo de
indexao. Durante a indexao so extrados conceitos do documento atravs da anlise
de seu contedo e traduzidos em termos de uma linguagem de indexao, gerando um
ndice onde sero realizadas as consultas [Hiemstra, 2009; Lu, 2007].
Um sistema de RI geralmente desenvolvido com o objetivo de melhorar a eficincia
e eficcia da tarefa de recuperao. A eficincia normalmente calculada em termos
computacionais (desempenho, tempo de CPU, etc) e a eficcia dada, principalmente,
pela taxa de preciso e recall [Baeza-Yates and Ribeiro-Neto, 1999]. Essas medidas so
usadas para avaliar o desempenho de um modelo de RI e para fazer a comparao de
performance entre diferentes modelos, os quais sero descritos na prxima Seo.
2.1. RECUPERAO DE INFORMAO
2.1.1
Modelos de Recuperao de Informao
De acordo com [Baeza-Yates and Ribeiro-Neto, 1999] um modelo de RI composto

por:
Um conjunto de vises lgicas, ou representaes, de documentos em uma coleo;
Um conjunto de vises lgicas, ou representaes, da informao requerida por
usurios;
Um framework para modelar documentos, consultas e suas relaes;
Uma funo de ordenao que associa um nmero com uma consulta e um documento.
Nas prximas sees sero descritos os principais modelos modelos utilizados para
recuperao de informao.
2.1.1.1
Modelo Booleano
O modelo Booleano um dos mais antigo e simples modelo para RI. Ele se baseia
na teoria dos conjuntos e na lgebra booleana [Baeza-Yates and Ribeiro-Neto, 1999].
As consultas so descritas por meio de expresses booleanas usando conectores lgicos:
AND, OR e NOT e cada documento representado por um conjunto de termos indexados, os quais simplesmente so palavras ou frases. Os documentos recuperados so
aqueles que satisfazem completamente a consulta do usurios. Aqueles que satisfazem
parcialmente a consulta no so retornados. Como o resultado da recuperao de um
documento um valor binrio, esse modelo no oferece um mecanismo de ordenao.
A principal vantagem do modelo booleano se refere ao formalismo e simplicidade. A
principal desvantagem a comparao exata entre consulta e documento, que pode levar
recuperao de poucos ou muitos documentos [Baeza-Yates and Ribeiro-Neto, 1999;
Hiemstra, 2009].
2.1.1.2
Modelo Espao Vetorial
O modelo Espao Vetorial tem o objetivo de resolver o principal problema do modelo

booleano, que a a incapacidade de retornar resultados que satisfaam parcialmente a
consulta e falta de ordenao dos documentos retornados. No modelo Espao Vetorial
cada documento representado por um vetor ou por uma lista de termos ordenados, por
exemplo, pela frequncia do termo no documento, em vez de apenas um conjunto de
termos, como utiliza o modelo booleano [Baeza-Yates and Ribeiro-Neto, 1999]. Com
isso, possvel, atravs deste modelo, associar um peso a cada termo de indexao ou da
da expresso de busca. Esses pesos so utilizados para calcular o grau de similaridade
entre a expresso de busca formulada pelo usurio e cada um dos documentos. Desta
forma, o modelo Espao Vetorial retorna os documentos ordenados de acordo com esta
similaridade, ao invs de analisar de um documento relevante ou no. As principais
2.1. RECUPERAO DE INFORMAO
vantagens deste modelo so a possibilidade de retornar documentos que satisfazem parcialmente consulta e a possibilidade de ordenar os resultados. A principal desvantagem
que os termos de indexao so mutualmente independentes; ento este modelo no
captura a semntica da consulta ou do documento [Manning et al., 2008].
2.1.1.3
Modelo Probabilstico
O modelo probabilstico tenta recuperar a informao atravs de clculos probabilsticos, usando para tal a teoria da probabilidade. A ideia bsica a de recuperar os
documentos de acordo com a probabilidade de o documento ser relevante [Baeza-Yates
and Ribeiro-Neto, 1999]. Existem diversas propostas baseadas no modelo probabilstica
como: [Rijsbergen, 1979], [Robertson, 1977], [Sparck Jones et al., 2000] e [Robertson
and Zaragoza, 2009]
O modelo probabilstico no faz parte da proposta apresentada nesta dissertao.
Portanto, as propostas relacionadas acima no sero detalhadas.
2.1.2
Recuperao de Informao versus Recuperao de Dados
Existe uma grande diferena entre os termos recuperao de informao e recuperao

de dados e, como discutido em [Duro et al., 2008] e [Rijsbergen, 1979], eles so muitas
vezes confundidos. Portanto, nesta Seo sero discutidas as caractersticas destas reas
a fim de entender as diferenas e situar a abordagem proposta em uma dessas.
De acordo com [Baeza-Yates and Ribeiro-Neto, 1999] e [Rijsbergen, 1979], a recuperao de dados tem como objetivo claro recuperar todos os objetos que satisfaam
condies definidas, por exemplo, em uma expresso regular ou em uma expresso de
lgebra relacional. Assim, para um sistema de recuperao de dados, um nico objeto
recuperado erroneamente entre mil objetos recuperados significa fracasso total. Para
um sistema de recuperao de informao, no entanto, os objetos recuperados podem
ser imprecisos e pequenos erros so aceitveis. A principal razo para essa diferena
que a recuperao da informao geralmente lida com texto de linguagem natural que
nem sempre bem estruturado e pode ser semanticamente ambguo. Por outro lado, um
sistema de recuperao de dados (como um banco de dados relacional) lida com dados
que tem uma estrutura e semntica bem definida.
A Tabela 2.1, adaptada de [Rijsbergen, 1979], sumariza esta e outras diferenas
existentes entre recuperao de dados e recuperao de informao.
2.2. COMPUTAO EM NUVEM
Tabela 2.1 Tabela com diferenas entre recuperao de dados e recuperao de informao.
Adaptada de [Rijsbergen, 1979]
Correspondncia
Inferncia
Modelo
Linguagem da Consulta
Especificao da Consulta
Itens Desejados
Sensibilidade a Erros
Recuperao de Dados
Exata
Deduo
Determinstico
Artificial
Completa
Correspondentes
Sensvel
Recuperao de Informao
Parcialmente, melhor possvel
Induo
Probabilstico
Natural
Incompleta
Relevantes
No-Sensvel
Portanto, a soluo proposta nesta dissertao integrar um sistema de recuperao de

informao, pois esta no requer nenhum controle de sintaxe nas consultas, os resultados
encontrados so baseados em relevncia e fazem uso de dois modelos de recuperao de
informao: modelo Espao Vetorial e modelo Booleano.
2.2
Computao em Nuvem
O National Institute of Standards and Technology (NIST) define computao em

nuvem como um modelo que permite que um conjunto de recursos computacionais
possam ser fornecidos sob demanda de forma a permitir que os mesmos sejam fornecidos
e liberados rapidamente com o mnimo de esforo de gesto ou interao do fornecedor
[Mell and Grance, 2009]. Vaquero et al. [2009] define computao em nuvem como um
grande conjunto de recursos virtualizados (como hardware, plataformas de desenvolvimento e/ou servios) facilmente usveis e acessveis. A arquitetura da computao nas
nuvens comumente representada em camadas: Software como servio, Plataforma como
Servio e Infraestrutura como servio. Nesse modelo cada camada est construda sobre
os servios oferecidos pela camada de baixo [Lenk et al., 2009], conforme apresentado
na Figura 2.1.
Figura 2.1 Arquitetura em camadas para computaao nas nuvens
Infraestrutura como um servio (Infrastructure-as-a-Service - IaaS) o fornecimento
de enormes recursos computacionais como: capacidade de processamento, armazenamento e conectividade. Tomando armazenamento como um exemplo, quando o usurio
usa um servio de armazenamento em computao em nuvem, ele somente paga a parte
que foi efetivamente consumida sem comprar nenhum disco rgido ou at mesmo sem
nem conhecer a localizao dos seus dados armazenados. O exemplo mais conhecido
de IaaS o Amazon Web Services (Amazon AWS)1 , principalemente, atravs do Amazon
Elastic Compute Cloud (Amazon EC2)2 .
Do ponto de vista do hardware, computao em nuvem trs trs novos aspectos
[Vogels, 2008]:
1. A iluso de recursos computacionais infinitos disponveis sob demanda, eliminando
assim a necessidade dos usurios planejarem muito frente para provisionamento
de recursos.
2. A eliminao de um compromisso antecipado por parte dos usurios da nuvem,
permitindo que as empresas comecem pequeno e aumente os recursos de hardware
apenas quando h um aumento de suas necessidades.
3. A capacidade de pagar somente pelo que foi usado dos recursos computacionais
(por exemplo, os processadores por hora e armazenamento por dia), e liberar
recursos contratados facilmente quando no so mais necessrios.
Plataforma como um servio (Platform-as-a-Service - PaaS) geralmente abstrai a
infraestrutura e d suporte a um conjunto de interfaces de programao para aplicaes em
nuvem. o meio entre o hardware e as aplicaes. Devido a importncia da plataforma,
muitas grandes empresas querem aproveitar a oportunidade para tentar dominar essa rea
como a Microsoft fez na poca do computador pessoal. Exemplo bem conhecidos so o
Google App Engine3 , a plataforma de servios do Microsoft Azure4 , o RackSpace5 .
Software como um servio (Software-as-a-Service - SaaS) tem como objetivo substituir as aplicaes que rodam nos computadores. No h a necessidade de instalar ou
rodar softwares especiais no computador para rodar um SaaS. Ao invs de comprar o
software por um preo relativamente alto, o usurio paga pelo que usado do SaaS, o que
pode reduzir o preo total. O conceito de SaaS atrativo e alguns softwares executam
bem na nuvem, mas o atraso na rede fatal para algumas aplicaes, como sistemas de
tempo real. Exemplos muito conhecidos de SaaS so o SalesForce 6 , o Google Docs 7 e o
Dropbox 8 .
Como discutido em Armbrust et al. [2009], computao em nuvem refere-se tanto aos
aplicativos entregues como servios atravs da internet como ao hardware e software nos
1 http://aws.amazon.com/

3 https://developers.google.com/appengine/ Acessado em: 28/07/2013
4 http://www.windowsazure.com/ Acessado em: 28/07/2013
5 http://www.rackspace.com/ Acessado em: 28/07/2013
6 http://www.salesforce.com/ Acessado em: 28/07/2013
7 http://docs.google.com Acessado em: 28/07/2013
8 http://www.dropbox.com Acessado em: 28/07/2013
2 http://aws.amazon.com/ec2/
10
datacenters que oferecem esses servios. Quando a nuvem disponibilizada no formato

pay-as-you-go, ou seja, pague pelo que voc usa, para o pblico em geral, chamamos
isso de uma nuvem pblica. O termo nuvem privada usado para se referir a datacenters
internos de uma empresa ou outra organizao, no disponibilizadas ao pblico em geral.
2.2.1
Armazenamento de Dados em Nuvem
Na Seo anterior mostramos que a utilizao da computao em nuvens permite que

os usurio possam alocar recursos dinamicamente, de acordo com sua necessidade. Entre
esses recursos est o de armazenamento, o qual prov recursos e servios de armazenamento baseados em servidores remotos que utilizam os princpios da computao em
nuvem [Zeng et al., 2009]. Armazenamento em nuvem tem duas caractersticas bsicas:
a primeira trata da infra-estrutura da nuvem, a qual baseia-se em clusters de servidores
baratos; a segunda tem o objetivo de, atravs dos clusters de servidores, armazenamento
distribudo e redundncia de dados, fazer mltiplas cpias dos dados armazenados para
alcanar dois requisitos: alta escalabilidade e alta usabilidade. A alta escalabilidade
significa que o armazenamento em nuvem pode ser dimensionado para um grande aglomerado com centenas de ns ou peers de processamento. Alta usabilidade significa que o
armazenamento em nuvem pode tolerar falhas de ns e que estas falhas no afetam todos
o sistema [Deng et al., 2010].
Com a popularizao da computao em nuvem, cresceu o nmero de sistemas
utilizados para armazenamento de dados em nuvem. O servio oferecido por estes
sistemas baseia-se no software que executado em um cluster de servidores, os quais
armazenam em seus discos rgidos os arquivos dos clientes, como mostrado na Figura 2.2.
Normalmente, cada cliente possui um processo que controla a transferncia de arquivos
entre a mquina do usurio e os servidores na nuvem. Este processo tambm tem a funo
de se certificar que os dados enviados sejam espalhados por outros servidores no cluster
e manter a sincronia dos dados na mquina do cliente e os dados armazenados, ou seja,
novos dados gerados na mquina do cliente devero ser salvos na nuvem e, caso os dados
locais sejam perdidos, recuper-los.
11
Figura 2.2 Arquitetura de um sistema de armazenamento em nuvem. Adaptado de [Peddemors

and Spoor, 2010].
Diversos sistemas uniram os conceitos peer-to-peer com os conceitos de armazenamento em nuvem e passaram a oferecer solues de armazenamento em nuvem baseadas
em uma arquitetura peer-to-peer, como Wuala, BitTorrent Sync, Symform, Freenet,
AeroFS.
Neste tipo de sistema, os ns que fazem parte da rede cooperam uns com os outros,
atravs do compartilhamento de uma quota de espao no disco rgido, e cada n , ao
mesmo tempo, um consumir e produtor de dados. Como mostrado na Figura 2.3, cada n
composto por um processo que responsvel pelo envio dos dados locais para outros
ns da rede e por receber os dados de outros peers.
Figura 2.3 Arquitetura de um sistema de armazenamento em nuvem utilizando arquitetura P2P.

Adaptado de [Peddemors and Spoor, 2010].
12
2.3. TRABALHOS RELACIONADOS
A arquitetura peer-to-peer permite que a rede formada tenha uma composio dinmica, ou seja, peer podem entrar e sair da rede com facilidade e, para evitar que os dados
armazenados em um peer sejam perdidos, comum utilizar tcnicas de armazenamento
redundante [Datta et al., 2010]. Um efeito comum do armazenamento redundante de
dados a disperso dos dados de forma geogrfica (assumindo que a prpria rede est
distribuda geograficamente).
A redundncia pode ser alcanada simplesmente atravs da replicao de arquivos
para um nmero de peers, mas esta tcnica muito custosa, devido necessidade da
cpia integral do arquivo em cada peers escolhido e ao aumento do trfego de rede para
efetuar as cpias. Outra tcnica muito utilizada a erasure code, a qual utilizada como
tcnica de correo de erros para compensar os erros ocorridos durante a transmisso
de dados. Como representado na Figura 2.4, os dados originais so quebrados em
pedaos menores e so criados fragmentos redundantes dos mesmos. Estes fragmentos
so enviados para serem armazenados nos outros peers. Caso algum dos fragmentos
armazenados seja perdido, o dados original ainda poder ser re-montado partir dos
fragmentos restantes [Peterson and Weldon, 1972].
Figura 2.4 Representao do processo de para armazenamento e recuperao de dados utilizando

erasure code. Adaptado de [Peddemors and Spoor, 2010].
2.3
Trabalhos Relacionados
Nas sees anteriores apresentamos os principais conceitos relacionados com as reas

de recuperao de informao e computao em nuvem. Nesta Seo iremos analisar os
13
trabalhos relacionados com recuperao de informao em sistemas de armazenamento

em nuvem e mostrar como os principais sistema de armazenamento fazem para prover ao
usurio uma maneira de efetuar consultas relacionadas com os arquivos armazenados.
2.3.1
Recuperao de Informao em Sistemas de Armazenamento

em Nuvem
O Amazon S39 (Simple Storage Systems) um sistema de armazenamento de objetos

em nuvem oferecido pela Amazon Web Service10 que funciona atravs de interfaces web
services baseadas em REST, SOAP e BitTorrent.
O Amazon S3 foi projetado para fornecer escalabilidade, alta disponibilidade e
baixa latncia. Ele formado por buckets, que so similares a diretrios ou containers.
Cada objeto armazenado composto pelo nome, um blob com o contedo (at 5 Gb)
e os metadados do mesmo, composto por atributos que representam o tipo de dado
armazenado, associao com usurios e permisses de acesso, datas de criao, acesso e
modificao, localizao de objetos relacionados, classificao e comentrios feitos pelo
usurio, rtulos de rea, assunto e geolocalizao11 .
O Amazon S3 s permite buscas limitadas a consultas simples baseadas no nome dos
objetos e dentro de um nico bucket, ou seja, ele no d suporte para buscas baseadas
nos metadados e nem no contedo dos objetos armazenados [Palankar et al., 2008]. O
Amazon S3 pode ser unido com o Amazon CloudSearch12 , que um servio da Amazon
para inicializar, gerenciar e escalar uma soluo de busca. O Amazon CloudSearch
permite que documentos j armazenados no S3 ou em algum banco de dados como
DinamoDB13 sejam indexados.
Entretanto, para utilizar o Amazon CloudSearch necessrio que o sistema esteja
sendo executado na infra-estrutura da Amazon, ou seja, no possvel acoplar este servio
a um sistema externo. Alm disso, para utilizar o Amazon CloudSearch seria necessrio
ter o arquivo completo armazenado para que o mesmo possa extrair os metadados
necessrios. Desta forma, no seria possvel utiliz-lo em um sistema que armazene os
arquivo particionados em chunks utilizando, por exemplo, o erasure code.
XtreemFS14 um sistema de arquivos globalmente distribudo e replicado. Ele
desenvolvido como parte do projeto XtreemOS EU, o qual tem o objetivo de criar
um sistema operacional open source tolerante a falhas para qualquer necessidade de
armazenamento em ambientes de grid ou computao em nuvem. XtreemFS baseado
em objetos, com metadados e dados armazenados em diferentes tipos de ns. Alm disso,
ele compatvel com o padro POSIX, e possui sistema de tratamento de falhas. Ele
replica os objetos para garantir tolerncia a falhas e faz cache dos dados e metadados
para melhorar o desempenho no caso de alta latncia [Hupfeld et al., 2008, 2007]. O
9 http://aws.amazon.com/s3/,
ltimo acesso em 01/08/2013

11 http://bit.ly/JeaAZg, ltimo acesso em 01/08/2013
12 http://aws.amazon.com/cloudsearch/ Acessado em: 02/08/2013
13 http://aws.amazon.com/dynamodb/ Acessado em 02/08/2013
14 http://www.xtreemfs.org
10 http://aws.amazon.com/,
14
XtreemFS faz a replicao a partir do arquivo completo, ao invs de utilizar as partes j

divididas do arquivo. Isso faz com que haja um aumento considervel na comunicao
interna para manter as rplicas sincronizadas. O XtreemFS utiliza o BabuDB [Stender
et al., 2010] como banco de dados para armazenar os metadados do sistema de arquivos.
Os atributos utilizados nos metadados incluem uma identificao nica para arquivos e
diretrios, nome, tipo, alm de atributos relacionados a data de criao e modificao,
tamanho do arquivo, localizao do contedos do arquivos, localizao das rplicas15 ,
dono, controle de acesso e atributos estendidos.
O XtreemFS no armazena nenhum atributo relacionado com o contedo dos arquivos
armazenados. Desta forma, o mesmo s permite que consultas sejam realizadas baseadas
nos nomes do arquivos, diretrios, tipo de arquivo, entre outros atributos dos metadados.
O BitTorrentSync16 permite que seja realizado o backup de arquivos e diretrios.
Este utiliza o BitTorrent17 , que j utilizado h muito tempo para compartilhamento de
arquivos atravs de torrent. O BitTorrent um protocolo de transferncia de arquivos
que, juntamente, com alguns websites como Piratebay.org e Mininova.org e servidores
trackers prov, atualmente, um dos maiores sistema de compartilhamento de arquivos.
No BitTorrent os arquivos so dividios em pedaos menores (chunks) e o peer passa a
disponibilizar cada arquivo para que outros usurios possam realizar o download dos
mesmos. Quando outros peers obtm os arquivos, esses passar a disponibiliz-los tambm.
Os servidores tracker tem a funo de manter uma lista atualizada de quais peers possuem
cada chunk.
Para encontrar algum arquivo, o usurio precisa utilizar algum dos websites, os quais
disponibilizam informaes como: nome do arquivo, tamanho, nmero atual de peers
realizando download e enviando chunks, nome do usurio que disponibilizou o arquivo e
palavras-chave adicionar pelo usurio [Pouwelse et al., 2005].
O Box18 um sistema online de armazenamento em nuvem e permite, na verso
paga, que buscas full-text baseadas em contedo possam ser realizadas nos arquivos com
extenso Microsoft Word, Excel, PowerPoint, PDFs, TXT e CSV. Entretanto, no h
disponvel nenhuma informao sobre como os arquivos so armazenados, nem como a
indexao e busca so realizadas
Outros sistemas de armazenamento em nuvem como Dropbox19 , SugarSync20 , Google
Drive21 , Wuala22 no disponibilizam informaes relacionadas com quais atributos so
utilizados nos metadados, o que dificulta uma anlise tcnica aprofundada sobre os
mesmos, mas possvel dizer que os mesmos no possuem uma indexao que permita
que consultas sejam realizadas baseadas no contedo dos arquivos armazenados e que
nestes sistemas s possvel realizar consultas baseadas no ttulo dos mesmos.
15 http://www.xtreemfs.org/arch.php,

17 http://www.bittorrent.com/ Acessado em 06/08/2013
18 http://box.net/ Acessado em 22/08/2013
19 http://www.dropbox.com, Acessado em 01/08/2013
20 http://www.sugarsync.com/, Acessado em 01/08/2013
21 https://drive.google.com, Acessado em 01/08/2013
22 http://www.wuala.com/, Acessado em 01/08/2013
16 http://labs.bittorrent.com/experiments/sync.html
15
2.4. SUMRIO DO CAPTULO
2.4
Sumrio do Captulo
Neste captulo foi apresentada uma reviso dos conceitos de recuperao de informao e computao em nuvem. Alm disso, foi detalhado o funcionamento de sistemas
de armazenamento em nuvem, os conceitos envolvidos no armazenamento e alguns
trabalhos relacionados baseados em sistemas de armazenamento em nuvem disponveis
no mercado.
Conforme apresentado na Tabela ??, a maioria os sistemas de armazenamento hoje
desenvolvidos oferecem opes simples para indexao e realizao de consultas, normalmente somente baseadas no ttulo dos arquivos armazenados. Alguns outros sistemas
(como o Amazon S3) permite que as buscas sejam realizadas baseadas nos metadados
armazenados, entretanto estes no armazenam nenhum atributo relacionado com o contedo armazenado. A Amazon props recentemente o Amazon Cloud Search (ainda em
beta), que permite que buscas mais avanadas sejam realizadas no Amazon S3, entre elas
a busca full-text. Entretanto, como discutido anteriormente, esta soluo exclusiva para
ser utilizada com os servios da Amazon (Amazon S3, DinamoDB, etc). Portanto, ela
no adequada para ser utilizada em sistemas de armazenamento em nuvem utilizando,
por exemplo, o erasure code, para particionar e replicar os arquivos antes de armazenar,
e o armazenamento distribudo, possibilitado pela utilizao de uma arquitetura P2P.
Ainda h o problema da falta de detalhamento de algumas propostas. Por exemplo, o Box
apresenta uma soluo para buscas full-text baseadas em contedo, entretanto, por ser um
sistema proprietrio, no h informaes detalhadas do seu funcionamento.
Desta forma, a quantidade de trabalhos relacionados com recuperao de informao
em sistemas de armazenamento em nuvem pequena. Mas possvel dizer que falta
uma proposta para indexao e consultas full-text baseadas no contedo dos arquivos
armazenados para este tipo de sistema e isto nos motivou a desenvolver este trabalho.
No prximo captulo ser apresentada a abordagem proposta por esta dissertao,
bem como os requisitos atendidos e a arquitetura da mesma.
16
Uma Abordagem para Indexao e

Buscas Full-Text Baseadas em Contedo
em Sistemas de Armazenamento em
Nuvem
Neste captulo ser apresentada a abordagem desenvolvida nesta dissertao. Alm
disso, apresentamos tambm o Ustore, um sistema de armazenamento em nuvem privadas,
no qual a abordagem foi implementada. Sero apresentados tambm os requisitos
elicitados que esta abordagem se prope a resolver, bem como detalhes de como foram
implementados.
3.1
Ustore
O Ustore uma ferramenta de armazenamento em nuvem baseada em uma arquitetura

P2P hbrida que tem como objetivo armazenar dados com baixo custo e de forma que
os mesmos no se tornem indisponveis com eventuais problemas na rede [Assad et al.,
2012]. Os dados a serem armazenados so quebrados em pedaos menores de tamanho
pr-definido, chamados de chunks. Os chunks so armazenados em outros peers da
rede, utilizando para isto os recursos ociosos disponveis na rede. Estes peers podem,
por exemplo, ser computadores da prpria empresa utilizados para outros fins, mas que
possuam espao livre em disco suficientes para serem compartilhados. A utilizao deste
modelo faz com que o Ustore garanta um baixo custo para o armazenamento.
3.1.1
Arquitetura do Ustore
A arquitetura do Ustore consiste de uma arquitetura P2P hibrida em trs camadas,

onde h peers representando papis distintos compondo a soluo final. Os peers so
agrupados em federaes de dados, o que traz diversas vantagens, como: minimizar a
sobrecarga na rede, em cada peer e reduzir a quantidade de mensagens trocadas. Este
agrupamento permite uma maior escalabilidade do sistema, j que no h limites para a
quantidade de federaes criadas [Duro et al., 2013; Silva et al., 2012a].
17
3.1. USTORE
A comunicao entre as entidade internas do sistema feita atravs da plataforma

JXTA. O JXTA1 um projeto de software livre de protocolos P2P baseados em mensagens XML para o desenvolvimento de aplicativos distribudos, permitindo que qualquer
dispositivo conectado em uma rede, independente de sua plataforma, natureza, ou protocolo de rede possa interagir, compartilhar recursos, e formar uma rede distribuda,
descentralizada e cooperativa [Heiss, 2005]. O JXTA tem como objetivo encapsular
funcionalidades e servios comuns, escondendo a complexidade das implementaes
para o desenvolvedor. Na Figura 3.1 est representada a arquitetura do JXTA, na qual os
peers, embora hierarquicamente semelhante, podem possuir capacidade computacional
distintas, j que uma das grandes vantagens de JXTA garantir o uso racional e adequado
dos recursos sem abrir mo da portabilidade.
Figura 3.1 Representao da arquitetura do JXTA [Heiss, 2005]
Cada peer JXTA cria uma rede sobreposta virtual, permitindo a interao com outros
pares normalmente inacessveis, como os protegidos por dispositivos reguladores de
trfego (como firewalls) ou que utilizem outro tipo de transporte de rede. Estes peers
tambm podem ser organizados em grupos de uma forma descentralizada [Barolli and
Xhafa, 2011]. Alm disso, os recursos de rede possuem uma identificao nica e
constante, de forma a poder mudar seu endereo de localizao livremente sem perder
a identificao e ele define um protocolo para as operaes principais de uma rede P2P,
como descobrimento de servios, mensagens e organizao de grupos. Alm disto,
o JXTA permite que cada peer, independente da plataforma de software e hardware
utilizada, possa se conectar em uma rede P2P [Gong and Others, 2001].
A Figura 3.2 mostra os tipos de peers do Ustore [Silva et al., 2012b]:
1 http://java.net/projects/jxta,
18
3.1. USTORE
Cliente Ustore: possui os dados a serem salvos e disponibilizam o espao livro

para armazenar chunks;
Servidor Ustore: disponibiliza os servios para serem utilizados pelos clientes e
compem as federaes.
Super peer: informa ao cliente, ao entrar na rede, onde esto os servidores. Tambm funciona como peer relay, ou seja, ele permite a troca de mensagens entre
clientes que estejam em redes diferentes.
Cada tipo de peer do Ustore ser descrito com mais detalhes nas prximas sees.
Figura 3.2 Representao da arquitetura do Ustore.
3.1.1.1
Cliente Ustore
Os clientes so aqueles que armazenam os chunks dos arquivos e, atravs deles, o

usurio pode solicitar operaes de backup e recuperao de arquivos. Cada cliente
possui um horrio de funcionamento estipulado inicialmente, que ser utilizado para
garantir a disponibilidade de dados no Ustore. Depois que um cliente se autentica na rede,
ele pode salvar os dados que desejar. Estes dados so quebrados em chunks de tamanho
pr-definido e enviados para que outros clientes que esto conectados os armazenem.
Estes so escolhidos atravs de um algoritmo estatstico que localiza quais so os clientes
que possuem o horrio de funcionamento similar ao cliente inicial, desta forma o Ustore
garante a disponibilidade dos dados no horrio estipulado [Duarte, 2010]. Os chunks
so espalhado na rede e somente o servidor possui as informaes necessrias para
remont-los e, como forma de garantir uma maior disponibilidade, so replicados dentro
da prpria rede.
19
3.2. REQUISITOS
3.1.1.2
Servidor Ustore
Os peers servidores so aqueles que oferecem um conjunto (ou subconjunto) de servios existentes. A definio de peers com funcionalidades especificas na rede opem-se a
algumas propostas para sistemas P2P, onde cada peer deveria ser capaz de desempenhar
todos os papis no sistema, promovendo a ideia de uma DHT (Distributed Hash Table)
completa [Oliveira, 2007; Loest et al., 2009]. No entanto, a implementao utilizando
uma DHT em sua essncia bastante custosa e de difcil escalabilidade. Sendo assim, a
proposta adotada no Ustore a criao de nveis hierrquicos que implementam servios
bem definidos e que podem crescer horizontalmente. Dentre os servios disponibilizados
pelos servidores, pode-se citar:
Autenticao: usado para que cada cliente se autentique;
Disponibilidade: permite checar a disponibilidade de cada peer;
Gerncia de Diretrios: utilizado para armazenamento e recuperao de diretrios
inteiros;
Gerencia de Arquivos: utilizado para armazenamento e recuperao de arquivos;
Busca por Dados: procura por um conjunto de peers que obedeam ao acordo de
nvel de servio;
3.1.1.3
Super peer
Os super peers funcionam como elementos de referncia para os demais componentes

da arquitetura, sendo a porta de entrada para a participao de servidores, e clientes no
sistema. O papel do super peer definir as federaes de dados quando cada cliente
solicita conexo rede. Para isto, os super peers devem ter sua localizao previamente
conhecida por todos os demais peers por meio de uma pr-configurao. Tambm
papel deste tipo de peer, escolher dinamicamente os clientes e servidores das federaes
baseando-se em um algoritmo de proximidade [Duarte, 2010]. O agrupamento em
federaes permite o crescimento elstico e garante a escalabilidade do sistema, pois no
existe um limite para a quantidade de federaes que podem ser criadas.
3.2
Requisitos
Os requisitos (funcionais e no-funcionais) propostos para o engenho de busca fulltext so baseadas nos problemas enfrentados por outros engenhos de busca analisados
no Captulo 2. Alm disto, os requisitos tambm so derivados da rea de computao
em nuvens e discusses no grupo ASSERT2 . Neste contexto, um conjunto de requisitos
funcionais e no-funcionais so apresentados nas sees seguintes.
2 http://www.assertlab.com
20
3.2. REQUISITOS
3.2.1
Requisitos Funcionais
Indexar no lado do cliente - Muitos sistemas de armazenamento adotam a estratgia de no armazenar o arquivo inteiro e, sim, dividido em pedaes menores,
chamados de chunks. Devido a isto, o processo de indexao deve acontecer no
cliente que est efetuando o backup, j que este ser o nico cliente com acesso ao
arquivo inteiro.
Indexar vrios formatos de arquivos - A indexao deve ser feita em diversos
tipos de arquivos, incluindo: arquivos de todos o pacote Office, arquivos de todo o
pacote OpenOffice, arquivos com extenso pdf, arquivos de imagem, arquivos de
vdeo.
Extrair e indexar contedo dos arquivos de texto - Para os arquivos de texto
(por exemplo, arquivos com extenso: pdf, doc, xls, txt), o sistema deve extrair e
indexar tambm o contedo dos mesmos.
Realizar consultas full-text - O sistema deve permitir que o usurio realize consultas do tipo full-text, ou seja, levando em considerao todo o contedo do arquivo.
O sistema deve retornar uma quantidade estipulada inicialmente de resultados,
organizando-os pelo nmero de ocorrncias dos termos escolhidos pelo usurio.
Realizar a indexao global-local - O sistema deve realizar a indexao dos
metadados em um ndice global e em um local. O ndice local permitir que o
cliente realize consultas somente entre seus prprios arquivos e tambm poder
responder a consultas de outros clientes. O ndice global dever ficar no Servidor
de Busca e agregar o ndice de todos os arquivos do sistema.
Realizar consultas locais e globais - O sistema deve permitir que consultas fulltext sejam realizadas no ndice local do cliente e de outros clientes e no ndice
global.
Apresentar resultados da consulta para o usurio - O resultado da consulta
deve ser apresentado para o usurio classificados de acordo com o nmero de
ocorrncias dos termos utilizados. Alm disso, o usurio dever ter a opo de
solicitar o download do arquivo a partir do resultado apresentado.
3.2.2
Requisitos No-Funcionais
Extensibilidade - Em geral, qualquer software deve levar em considerao o

crescimento futuro. As restries de arquitetura devem presumir a adio de novas
funcionalidades e o nvel de esforo necessrio para implement-las sem afetar
s funcionalidades j sistema existentes. Por esta razo, a soluo proposta deve
ser bem estruturada, com mdulos de baixo acoplamento para permitir uma fcil
manuteno e extenso;
21
3.2. REQUISITOS
Elasticidade - O sistema deve permitir que a soluo consiga expandir e diminuir

os recursos alocados de forma automtica.
Replicao - O sistema deve replicar os ndices gerados como forma de garantir
que no sejam perdidos em eventuais falhas.
Usabilidade - O sistema deve fornecer uma interface grfica com componentes
intuitivos para realizar as funcionalidades.
Desempenho - O desempenho normalmente envolve a anlise do tempo de resposta.
Em um sistema distribudo, alm do poder de processamento, trfico de rede,
distribuio geogrfica, entre outros atributos exercem influncia sobre o tempo de
resposta.
Alta preciso e recall - Este um requisito essencial que deve ser considerado em
qualquer mecanismo de busca. O desempenho de uma ferramenta de recuperao
de informao medido tendo em conta a preciso alcanada e as taxas de recall.
Alta preciso alcanada quando os elementos mais relevantes so retornados em
uma pesquisa e alto recall alcanado quando poucos elementos relevantes so
deixados de fora do resultado.
A Tabela 3.1 sumariza a situao dos requisitos apresentados. Os requisitos na situao Alcanado significa que foram completamente desenvolvido e avaliado. Aqueles na
situao Parcialmente Alcanado foram desenvolvido, entretanto no foram avaliados
ou precisam de melhorias.
Tabela 3.1 Tabela com a situao dos requisitos propostos.
Requisito
Indexar no lado do cliente
Indexar vrios formatos de arquivos
Extrair e indexar contedo dos arquivos de texto
Realizar consultas full-text
Realizar a indexao global-local
Realizar consultas locais e globais
Apresentar resultados da busca para o usurio
Extensibilidade
Elasticidade
Replicao
Usabilidade
Desempenho
Alta preciso e recall
Situao
Alcanado
Alcanado
Alcanado
Alcanado
Alcanado
Alcanado
Alcanado
Parcialmente Alcanado
Alcanado
Alcanado
22
3.3. INDEXAO E CONSULTAS FULL-TEXT BASEADAS EM CONTEDO
3.3
Indexao e Consultas Full-Text Baseadas em Contedo
Na Seo anterior foram apresentados os requisitos que sero desenvolvido por esta
abordagem, cujo objetivo permitir que consultas full-text baseadas em contedo sejam
realizadas no Ustore. Nesta Seo ser mostrado como a abordagem proposta extrai e
indexa o contedo de cada arquivo e, aps isso, ser mostrado as estratgias de busca
adotadas no Ustore. Cada estratgia se refere um tipo de busca diferente: local, atravs
da rede e no Servidor de Busca.
3.3.1
Arquitetura
Arquitetura de software lida com a concepo e implementao da estrutura de

alto nvel do software. o resultado da montagem de um certo nmero de elementos
arquiteturais em algumas formas bem-definidas. A segui apresentada a viso de
componentes do Ustore juntamente com os componentes da abordagem proposta.
3.3.1.1
Viso de Componentes
Os clientes do Ustore e o Servidor de Busca possuem componentes especficos para a

realizao de indexao e consultas full-text. Como mostrado na Figura 3.3 o componente
responsvel pela indexao se comunica diretamente com o componentes responsvel
pelo controle dos backups efetuados no sistema. Isto se justifica pelo fato de existir
um vnculo entre estes procedimentos com operaes que ocorrem paralelamente, como
ser mostrado mais adiante. J o componente de busca se comunica diretamente com a
interface grfica do Ustore, onde o usurio pode informar os termos que deseja pesquisar
e onde visualizar o resultado da consulta.
O Servidor de Busca possui somente os componentes de indexao e busca e disponibiliza duas interfaces para, respectivamente, receber informaes para serem indexadas e
receber os termos de busca.
3.3.2
Indexao Full-Text
Conforme mostrado na Figura 3.3 cada cliente e Servidor de Buscas do Ustore possui
um componente responsvel pela indexao. A Figura 3.4 mostra o diagrama de sequncia
do processo de indexao que se inicia quando o cliente informa ao servidor que um
backup ser iniciado.
A primeira mensagem enviada para o servidor faz com que algumas informaes
sobre o backup sejam registradas e, atravs do algoritmo de disponibilidade de peers,
descubra quais so os melhores clientes para os quais o cliente dever enviar os chunks
do arquivo. Aps isto, o cliente divide o arquivo em chunks com tamanho pr-definido, o
qual configurado em arquivo de propriedades. Paralelamente ao envio dos chunks para
os outros clientes, o componente de indexao acionado e, primeiramente, identifica
qual o tipo do arquivo que est sendo salvo. Isto permite que seja escolhido um parser
23
Figura 3.3 Diagrama de componentes do Ustore mostrando os componentes para indexao e

busca.
adequado para possibilitar a extrao dos metadados juntamente com o contedo do

mesmo. Estas informaes so armazenadas no objeto Index para posterior indexao.
3.3.2.1
Metadados
Visando atender aos requisitos descritos, tornou-se necessrio a implementao de

um modelo de metadados. Para isto, o primeiro passo, conforme definido por [Steinacker
et al., 2001], a definio da sintaxe do mesmo, ou seja, quais atributos devem fazer parte
da estrutura. Os atributos dos metadados foram definidos tendo como base os requisitos
definidos anteriormente na Seo 3.2, e os trabalhos relacionados com computao em
nuvens, recuperao de informao e metadados, discutidos no Captulo 2.
Os atributos dos metadados extrados durante a indexao esto descritos na Tabela
3.2.
Os metadados que sero indexados devem ser armazenados em dois locais, a saber:
Localmente: Os metadados so indexados e armazenado na mquina onde a aplicao cliente est instalada;
No Servidor de Buscas: O cliente que est realizando o backup envia os metadados
para serem indexados e armazenados no Servidor de Buscas;
Conforme descrito na Seo 3.1, o Ustore divide o arquivos em chunks ainda no
cliente que est efetuando o backup e estes chunks so enviados para outros clientes
para serem armazenados. Desta forma, nem os clientes que recebem os chunks e nem o
servidor do Ustore possuem o arquivo inteiro e, por isto, a extrao de metadados e do
contedo somente dever ser executada pelo prprio cliente que efetua o backup, pois
24
Figura 3.4 Diagrama de sequncia mostrando o processo de indexao.
25
Tabela 3.2 Tabela de metadados indexados no Ustore.
Atributo
FILE_NAME
FILE_NAME_LOWER
SIZE
PATH
PATH_LOWER
FILE_ID
CONTENT
LANGUANGE
CATEGORY
USER_INTEREST
AUTHENTICATION
DATE_CREATED
DATE_MODIFIED
DATE_INDEXED
Descrio
Nome do arquivo
Nome do arquivos (minsculas)
Tamanho do arquivo (Kbytes)
Caminho completo do arquivo
Caminho completo do arquivo (minsculas)
ID do arquivo no banco de dados
Contedo do arquivo
Linguagem do arquivo
Categoria do arquivo
reas de interesse do usurio
Nmero de autenticao do usurio
Data de criao do arquivo
Data de modificao do arquivo
Data de indexao do arquivo
somente este possui o arquivo inteiro. Alm disto, o componente de indexao tambm
tem a responsabilidade de criar um ndice local, como ser descrito adiante.
3.3.2.2
Indexao Local
A indexao dos metadados localmente acontece no prprio cliente que est efetuando
o backup e acontece paralelamente finalizao do mesmo, conforme apresentado na
Figura 3.4. Esta indexao tem a vantagem de funcionar independente de problemas na
rede, entretanto, permite que o cliente consulte unicamente o ndice existente no cliente.
Estas consultas acontecem atravs de mensagens sncronas, pois o cliente tem acesso
direto ao ndice gerado. Outra desvantagem que o ndice existe unicamente neste cliente,
o que significa que caso o cliente apresente algum problema que ocasione a perde deste
ndice, no ser possvel recuper-lo, ser necessrio executar uma rotina para realizar o
download de todos os arquivos e index-los novamente.
3.3.2.3
Indexao no Servidor de Buscas
O envio dos metadados para serem indexados no Servidor de Busca ocorre de forma
paralela finalizao do backup, da mesma forma que a indexao local. Uma mensagem
JXTA assncrona enviada atravs da rede para o Servidor de Busca. Quando esta chega
ao servidor, os metadados que ela contm so indexados no ndice global. A utilizao de
um ndice global permite que o usurio faa uma consulta levando em considerao todos
os arquivos pblicos indexados pelo Ustore, mas o servidor pode se tornar um gargalo
no sistema e se transformar em um ponto de falha. Por isto, foi adotada uma soluo
para garantir a escalabilidade dos servidores e a replicao de dados entre eles, que ser
descrita na prxima Seo.
26
3.3.2.4
Elasticidade e Replicao do ndice entre Servidores de Busca
Como o JXTA possui o recurso de auto-descobrimento de peers na rede, possvel

criar um novo Servidor de Busca facilmente e integr-lo rede existente. Caso existam
dois ou mais servidores de busca ativos, o cliente escolher aleatoriamente um e enviar
a mensagem para este. Aps a indexao neste, o mesmo encaminhar a mensagem
para outro servidor, tambm escolhido de forma aleatria, para que o contedo tambm
seja indexado. Com este procedimento o Ustore garante a replicao do ndice de busca
global, descrito com mais detalhes na prxima Seo. O ndice de busca gerado a
parte mais importante do sistema de busca. Ele o nico que possui os metadados dos
arquivos indexados e por isto a replicao do mesmo muito importante para garantir a
disponibilidade de informaes. No diagrama de atividade na Figura 3.5 est representado
o processo de indexao e replicao do ndice de busca implementado no Ustore, onde
nota-se que para cada backup so realizadas trs indexaes em locais diferentes. A
primeira ocorre no cliente que est efetuando o backup; a segunda, em um Servidor de
Buscas escolhido aleatoriamente pelo cliente; e a terceira, em outro Servidor de Busca
escolhido aleatoriamente pelo primeiro Servidor de Buscas escolhido; de forma que seja
possvel reduzir as chances de que o ndice de busca seja perdido, juntamente com todos
os metadados indexados, devido a alguma falha em uma das instncias.
Existe ainda a possibilidade de diminuir na quantidade de servidores de busca existentes ou que algum servidor apresente falha. Nestes casos, o ndice seria perdido e a
informao no estaria mais adequadamente replicada. Para solucionar isto, possvel
executar um algoritmo que faz a juno de dois ou mais ndices de busca.
Figura 3.5 Diagrama de atividades representando o processo de indexao e replicao do ndice

de busca implementado no Ustore.
27
3.3.3
Estratgias para Consultas Full-Text
Na Figura 3.3 o componente responsvel pela consulta interage diretamente com a

GUI (graphical user interface). A Figura 3.6 mostra como se d o processo de consulta
envolvendo outros clientes do Ustore e o Servidor de Buscas.
Na GUI o usurio informa quais os termos que deseja procurar nos arquivos armazenados no Ustore. Estes termos formam o objeto SearchQuery, juntamente com informaes
relativas ao cliente que o usurio est usando. No Ustore h trs formas de se realizar
uma consulta por informaes, a saber:
Busca local: esta consulta leva em considerao somente o ndice armazenado no
cliente em que o usurio est;
Busca na rede: esta consulta leva em considerao os ndices armazenados nos
outros clientes e realizada atravs de troca de mensagens JXTA pela rede P2P;
Busca no Servidor de Busca: esta consulta leva em considerao o ndice global
armazenado no Servidor de Busca;
Em todos os casos de busca, o cliente ou servidor que recebe a requisio de busca
deve realizar uma consulta em seu ndice local e localizar entre os arquivos indexados
quais possuem a maior quantidade de ocorrncias do termo de busca passado. Aps isto,
os resultados encontrados so retornados para o cliente inicial e exibidos para o usurio,
conforme apresentado na Figura 3.7.
28
Figura 3.6 Diagrama de sequncia mostrando o processo de busca.
29
Figura 3.7 Tela do Ustore exibindo resultado da busca.
Caso o usurio opte por realizar a consulta utilizando os servidores e os mesmos

estiverem inativos, o Ustore pode detectar este problema e passar a realizar a consulta
atravs da rede. Caso nenhum outro cliente esteja conectado no momento da consulta (impossibilitando este tipo de busca), ser possvel fazer uma consulta utilizando unicamente
o ndice armazenado localmente. A existncia de formas alternativas para realizao de
consultas, juntamente com a capacidade do Ustore de detectar estas falhas, faz com que o
mesmo possua um mecanismo que garanta que uma busca sempre ser realizada.
3.3.3.1
Consulta Local
A consulta local permite que o cliente do Ustore faa uma consulta de forma sncrona
ao seu prprio ndice. Esta consulta sempre ir funcionar, independente da existncia
algum problema de conexo na rede. Porm, como no h consulta aos ndices em
outros clientes ou servidores, os resultados ficam restritos apenas aos arquivos indexados
naquele cliente e que sejam pblicos (em caso de arquivos pertencentes a outros usurios
do sistema, mas indexados no mesmo cliente).
30
3.3.3.2
Consultas em outros clientes Ustore pela rede
O Ustore tambm permite que o usurio opte pela consulta atravs da rede; caso
isto ocorra, o Ustore utilizar o recurso de auto-descobrimento do JXTA para descobrir
quais clientes conectados na rede possuem o servio de busca associado e encaminhar
a consulta para eles. Para isto o Ustore utiliza mensagens JXTA assncronas e, uma
vez que a consulta chegue at um cliente, este realizar a consulta no seu ndice local
e retornar os resultados para o cliente que lhe encaminhou a consulta. Utilizando esta
estratgia possvel analisar mais ndices procura de arquivos pblicos que satisfaam
aos termos informados pelo usurios. Apesar disto, uma consulta implicar em enviar
uma mensagem assncrona para todos os clientes conectados naquele momento. Quanto
maior a quantidade clientes conectados, maior ser a quantidade de mensagens enviada, o
que poder ocasionar uma degradao do desempenho da rede, este problema conhecido
como query flooding. H diversas propostas para evitar que este problema acontea,
entretanto no faz parte do escopo deste trabalho analis-las.
Figura 3.8 Representao da consulta atravs da rede P2P
3.3.3.3
Consultas no Servidor de Buscas
A ltima estratgia para consultas no Ustore realizar a consulta em um ou mais

servidores exclusivos para indexao e consultas. Nesta abordagem o Ustore utiliza o
auto-descobrimento do JXTA para localizar um servio especfico que roda nos servidores
e, caso exista mais de um, escolhe um aleatoriamente, e envia para o mesmo a consulta
desejada. O servidor que recebe a consulta, faz uma consulta no seu ndice local e, caso a
quantidade de resultados no alcance um mnimo estipulado, este servidor encaminhar
a consulta para um outro servidor que tenha o servio disponvel, recomeando o ciclo.
Este ciclo durar at que a quantidade mnima de resultados seja alcanada ou at que
no exista mais servidores disponveis no consultados. Aps a finalizao os resultados
so retornados para o cliente inicial.
31
3.4. DETALHES DA IMPLEMENTAO
Figura 3.9 Representao da consulta utilizando o Servidor de Buscas
Com esta estratgia, as consultas so realizadas sobre um ndice global, pois os

servidores indexam os arquivos de todos os usurios. Como descrito anteriormente na
Seo 3.3.2, os servidores so sempre escolhidos aleatoriamente, tanto para indexao
quando para replicao do ndice. Sendo assim, os servidores no possuem exatamente o
mesmo contedo nos seus ndices.
3.4
Detalhes da Implementao
Para implementao da abordagem proposta no Ustore foi utilizado o Apache Lucene

verso 3.6 e Apache Tika verso 1.2
3.4.1
Apache Lucene
O Apache Lucene3 uma biblioteca de cdigo aberto para contulas full-text feita em
Java e tem como objetivo adicionar a funcionalidade de busca de forma fcil para uma
aplicao ou site. A biblioteca composta por 2 mdulos principais: indexao e busca.
A indexao processa os dados originais gerando uma estrutura de dados inter-relacionada
eficiente para a pesquisa baseada em palavras-chave. A busca, por sua vez, consulta o
ndice pelas palavras digitadas em uma consulta e organiza os resultados pela similaridade
do texto com a consulta.
O Lucene oferece um bom nvel de abstrao para um conjunto poderoso de tcnicas
baseadas no modelo Vetorial e Booleano. Isto permite que o desenvolvedor crie um
engenho de busca sem necessariamente conhecer as rotinas e algoritmos de indexao,
nem de busca, sendo necessrio apenas utilizar a API disponibilizada.
3 http://lucene.apache.org/
32
O Lucene utiliza em seu ndice a estrutura de dados chamada de ndice invertido, onde
cada termo adicionado possui uma referncia para o documento que o contm, como
mostrado na Figura 3.10. Os ndices invertidos so estruturas compostas por duas partes:
o vocabulrio e as ocorrncias. O vocabulrio incorpora o conjunto de todas as palavras
distintas existentes no documento. Para cada palavra do vocabulrio so construdas listas
que contm as exatas posies nas quais aparecem dentro do texto. O conjunto de todas
as listas denominado de ocorrncias. Em uma coleo de documentos, para cada palavra
existente armazenado tambm o nmero do documento no qual ocorre. A busca num
arquivo invertido se d atravs da verificao das entradas do arquivo e a recuperao de
todos os documentos que citam o termo usado [Baeza-Yates and Ribeiro-Neto, 1999].
Figura 3.10 ndice Invertido no Apache Lucene [Hatcher and Gospodnetic, 2004].
Para cada documento presente no resultado de uma busca atribudo uma pontuao
que representa a similaridade de tal documento com a consulta. O clculo dessa pontuao
feito baseando-se no modelo de recuperao de informao escolhido. No caso do
Lucene, ele suporta h alguns modelos plugveis, incluindo:
Modelo Espao Vetorial;
Modelo Probabilstico, como Okapi BM25 e DFR;
Modelo baseado em Linguagem Natural;
A busca padro no Lucene ocorre atravs da combinao de duas tcnicas de Recuperao de Informao: Modelo Espao Vetorial e modelo Booleano. Em geral, o modelo
Booleano utilizado primeiro para encontrar os documentos para os quais ser calculado
a pontuao de similaridade.
Este valor calculado por meio da frmula:
33
onde,
Fator
coord(q,d)
queryNorm(q)
tf(t in d)
idf(t)
t.getBoost()
norm(t,d)
Significado
Quantos termos da consulta q aparecem no documento d
Utilizado para fazer comparaes entre consultas. No afeta o
ranqueamento
Frequncia do termo t no documento d
Nmero de documentos que contm o termo t.
Peso atribudo ao termo t no momento da consulta
Encapsula alguns outros pesos no momento da indexao, como
fatores ligados ao documento, atributos de indexao e fatores
ligados a similaridade
Em resumo, segundo o clculo apresentado:

Documentos contendo todos os termos so melhores;
Correspondncia entre os termos de busca e palavras raras nos metadados melhor
do que com palavras comuns;
Documentos curtos so melhores que documentos longos
Documentos com muitas menes aos termos de buscas so bons;
Como o objetivo do Ustore localizar e ordenar os resultados somente atravs da
quantidade de termos encontrados em todo o texto, este algoritmo de pontuao foi
simplificado para levar em considerao apenas a quantidade de combinaes entre os
metadados indexados e os termos de busca.
Apesar da facilidade de uso, o Lucene contm apenas o ncleo do "motor"de busca.
Por isto, ele no inclui um Web crawler ou um parser para diferentes formatos de
documentos. Este processamento, se necessrio, deve ser feito pela aplicao ou por
outra biblioteca e repassado ao Lucene por meio de instncias da classe Document.
Como o Lucene no possui um parser prprio, foi necessrio utilizar uma outra
biblioteca que tivesse essa capacidade. E para isto foi utilizado o Apache Tika4 , que um
detector e extrator de contedo de metadados e texto estruturado, podendo ser utilizado
com arquivos de diversos formatos.
4 http://tika.apache.org/,
34
Figura 3.11 Arquitetura do Apache Lucene. [Hatcher and Gospodnetic, 2004]
3.4.2
Apache Tika
O Apache Tika um subprojeto do Apache Lucene e um kit de ferramentas para

extrair metadados e contedo de diversos tipos de arquivos. A extrao do contedo
feita por parsers especficos para cada tipo de arquivo. O Tika fornece uma API padro
e faz uso de bibliotecas de terceiros para fazer a extrao do contedo, como a POI5 ,
usada para extrair o contedo de arquivos do Word, Excel, PowerPoint, e a PDFBox6 ,
usada para extrao do contedo de arquivos PDF. O Apache Tika nativamente j vem
com acesso aos parsers para trabalhar com arquivos com os formatos: HTML, XML,
OLE2 e OOXML do Microsoft Office, OpenDocument Format, PDF, ePub, RTF, arquivos
compactados e empacotados.
A arquitetura em alto nvel do Apache Tika pode ser vista na Figura 3.12, onde
possvel identificar uma camada chamada Tika Facade. Esta camada responsvel
por receber o arquivo que ser processado, identificar o tipo do mesmo, seu idioma e
selecionar um parser adequado para extrair seus metadados e contedo.
3.5
Sumrio do Captulo
Este captulo apresentou uma abordagem para indexao e consultas full-text baseada
em contedo para sistemas de armazenamento em nuvem. Alm disso, foram apresentados os requisitos que foram desenvolvidos nesta abordagem, sua arquitetura e detalhes
da implementao realizada. A abordagem proposta foi implementada no Ustore, um
sistema real de armazenamento em nuvem, no qual a indexao dos arquivos acontece
somente no clientes. Esta indexao extrai os metadados correspondentes e o contedo
5 http://poi.apache.org/
6 http://pdfbox.apache.org/
35
Figura 3.12 Arquitetura do Apache Tika. [Mattmann and Zitting, 2011]
dos arquivos. Estes metadados so indexao no prprio cliente e enviados para serem
indexados nos Servidores de Busca. Com isso, o Ustore permite que as consultas full-text
sejam realizadas nos Servidores, atravs da rede P2P ou apenas localmente
No prximo captulo ser apresentado um experimento e seus resultados, o qual foi
realizado no Ustore com o objetivo de medir o desempenho da abordagem proposta.
36
Experimento
Este capitulo descreve o experimento e seus resultados realizado com o objetivo de

avaliar o desempenho do engenho de busca em um sistema de armazenamento em nuvem,
levando em considerao uma indexao baseada no nome do arquivo e a indexao
baseada em contedo para fins de comparao. Tambm avaliamos o o impacto da
incluso da funcionalidade de indexao nos clientes do Ustore.
Como mostrado em [Manning et al., 2008], para realizar a avaliao de uma sistema
desta natureza precisamos definir:
Uma coleo de dados;
As informaes que sero solicitadas expressas em forma de consultas;
Um conjunto de julgamentos de relevncia;
Nas prximas sees estes itens sero detalhados.
4.1
Coleo de Dados
Ns decidimos utilizar para validao um conjunto de documentos pessoais e/ou

profissionais. Por isso, tomamos a deciso de utilizar artigos acadmicos indexados no
engenho de busca Scopus1 . Escolhemos como termo de busca a palavra-chave cloud
computing, por ser uma das palavras-chave deste trabalho, e realizamos o download
dos 100 primeiros artigos ordenados pela quantidade de vezes que foram citados em
outros artigos acadmicos indexados. Geralmente, as avaliaes de engenhos de busca
utilizam mais arquivos, mas, devido restrio de tempo, decidimos utilizar um conjunto
de dados pequeno, pois, como ser mostrado adiante, foi necessrio realizar o backup de
todo o conjunto de arquivos diversas vezes no Ustore para que fosse possvel extrair os
resultados para as mtricas planejadas. Entretanto, mesmo com um conjunto de dados
reduzido, possvel obter resultados satisfatrios.
1 www.scopus.com
37
4.2. CONSULTAS
4.2
Consultas
Como descrito na Seo anterior, o termo de busca escolhido para realizar as consultas
foi a palavra-chave cloud computing, por ser uma das palavras-chave deste trabalho.
4.3
Conjunto de Julgamentos de Relevncia
Para a realizao dos testes necessrio que os arquivos tenham uma classificao
que indique quais so os mais relevantes para cada consulta que ser realizada. Para
fazer essa classificao no nosso conjunto de dados utilizamos a quantidade de citaes
aos artigos como critrio de qualidade, ou seja, quanto mais citaes o artigo teve, mais
relevante ele para nossa consulta.
4.4
Ambiente de Teste
Os testes foram realizados utilizando 4 mquinas virtuais interligadas por uma rede
Ethernet de 10/100 MBit/s, 2 delas (Win7.1 e Win7.2) executando Windows 7 com 1Gb
de memria RAM e processador de 2.4 Ghz e 1 executando Linux Debian 5.0 com 1Gb
de memria RAM e processador de 2.4 Ghz e 1 executando Linux CentOS com 1Gb
de memria RAM e processador de 2.4 Ghz. O Servidor Ustore e o Super Peer foram
hospedados na mquina CentOS. A mquina Debian hospedou 1 Servidor de Busca.
Tanto a mquina Win7.1 quanto a Win7.2 receberam dois Clientes Ustore cada, conforme
representado na Figura 4.1.
Figura 4.1 Representao do cenrio de testes utilizado no experimento.
38
4.5. METODOLOGIA DE AVALIAO
4.5
Metodologia de Avaliao
A metodologia de avaliao utilizada se baseia no mtodo sistemtico para avaliao

de desempenho proposto em [Jain, 1991], na qual precisamos definir objetivos, mtricas
e fatores e nveis. O objetivo desta avaliao avaliar o desempenho do engenho de
busca em um sistema de armazenamento em nuvem levando em considerao a indexao
baseada no nome do arquivo e a indexao baseada em contedo para fins de comparao.
E tambm avaliar qual o impacto da incluso da funcionalidade de indexao nos clientes
do Ustore.
As mtricas so os critrios para comparar o desempenho e esto sumarizadas na
Tabela 4.1. As mtricas escolhidas foram:
Tabela 4.1 Mtricas utilizadas na avaliao.
Mtricas
M1 : Preciso
M2 : Recall
M3 : F-Measure
M4 : Tempo para realizao de
consultas
M5 : Tempo para indexao
Descrio
Proporo entre o nmero de documentos relevantes retornados e o nmero total de documentos recuperados
Proporo entre o nmero de documentos relevantes recuperados e o nmero total de documentos relevantes na base
Mdia harmnica ponderada da preciso e recall.
Tempo gasto para realizar uma consulta
Tempo gasto para realizar a indexao de um arquivo
1. Preciso: A preciso representa a frao dos resultados retornados que so relevantes para a consulta. dada atravs da proporo entre o nmero de documentos
relevantes retornados e o nmero total de documentos recuperados e representada
pela frmula [Baeza-Yates and Ribeiro-Neto, 1999]:
precisao =
|{documentos relevantes} {documentos recuperados}|

|{documentos recuperados}|

4.1
representada por valores entre 0 (zero) e 1 (um) ou em termos de porcentagem.

Quando mais prximo de 1 (um) ou 100% mais preciso o sistema.
2. Recall: A taxa de recall representa a frao de documentos relevantes que foram
retornados pela consulta. Ou seja, dado-se o conjunto de documentos recuperados,
o recall a proporo entre o nmero de documentos relevantes recuperados e o
nmero total de documentos relevantes na base e dado pela frmula [Baeza-Yates
and Ribeiro-Neto, 1999]:
recall =
|{documentos relevantes} {documentos recuperados}|

|{documentos relevantes}|

4.2
39
4.5. METODOLOGIA DE AVALIAO
representada por valores entre 0 (zero) e 1 (um) ou em termos de porcentagem,

onde 0 (zero) representa que nenhum documento satisfaz a consulta e 1 (um) ou
100% representa todos os documentos indexados.
3. F-Measure: a mdia harmnica ponderada da preciso e recall. Pode ser representada pela frmula abaixo [Baeza-Yates and Ribeiro-Neto, 1999] :
F Measure =
(1 + ) precisao recall
(( precisao) + recall

4.3
Neste experimento as taxas de preciso e recall tem o mesmo fator de importncia,

portanto o valor de igual a 1 (um). Logo, esta funo s retornar um valor no
intervalo entre zero e um. Quanto mais prximo de zero, menos relevantes so os
documentos e quanto mais prximo de um, mais relevantes. A F-Measure s ter
valores prximo de 1 (um) quando ambas as taxas de preciso e recall forem altas
[Garcia et al., 2006; Duro et al., 2008].
4. Tempo para realizao de consultas: Foram efetuadas 30 consultas e medido o
tempo gasto para realiz-las. Com os resultados obtidos ser calculado um intervalo
com 95% de confiana para representar estatisticamente o tempo necessrio para
realizar uma consulta. Um intervalo de confiana tem como objetivo mostrar o
quanto determinada medida precisa.
5. Tempo para indexao: Foram efetuadas 30 consultas e medido o tempo gasto para
realiz-las. Com os resultados obtidos ser calculado um intervalo com 95% de
confiana para representar estatisticamente o tempo necessrio para realizar uma
indexao.
Para efeito de comparao, esta avaliao considera como satisfatria taxas de preciso de 0.40 e recall de 0.45, resultados semelhantes encontrados em [Tang and Dwarkadas,
2004] e [Lu and Callan, 2003]. Utilizando estas taxas de preciso e recall, podemos
calcular a taxa de F-Measure esperada. Esta ficou com o valor de 0.42. Para o tempo gasto
para realizar as consultas, consideramos como satisfatrio o tempo de 1000 milissegundos
(ms), pois este foi o tempo alcanado em uma arquitetura peer-to-peer semelhante
utilizada pelo Ustore [Yang et al., 2006].
Tabela 4.2 Fatores e nveis utilizados para avaliar as mtricas definidas.
Fatores
Estratgia de indexao
Nveis
Baseada no ttulo dos arquivos e baseada no contedo arquivos
Estratgia de busca
Local, distribuda e Servidor de Buscas
Quantidade de resultados re- 5, 10 e 15
tornados
40
4.6. RESULTADOS
O desempenho de um sistema afetado por vrios parmetros, que podem ser divididos em variveis ou no-variveis. Os parmetros que podem ser variados so chamados
de fatores e os seus valores so chamados de nveis. Os fatores e nveis deste estudo
esto listados na Tabela 4.2.
4.5.1
Cenrios para Avaliao
A avaliao de desempenho foi dividida em quatro cenrio. A diviso em cenrios

visa facilitar o entendimento do que est sendo avaliado e tambm torna mais fcil variar
os fatores. Os cenrio foram montados da seguinte forma:
Cenrio 1: No primeiro cenrio o objetivo foi avaliar a busca local. Para isso,
a indexao de ttulos e contedo foi feita localmente, ou seja, todo o ndice foi
gerado em cada cliente que efetuou backup. Neste cenrio foram avaliadas as
mtricas M1 (preciso), M2 (recall), M3 (F-Measure) e M4 (tempo de consulta)
variando a estratgia de indexao utilizada e a quantidade de retornos.
Cenrio 2: No segundo cenrio o objetivo foi avaliar a busca distribuda. Para
isso, a indexao de ttulos e contedo foi feita localmente, ou seja, todo o ndice
foi gerado em cada cliente que efetuou backup. Com isso possvel enviar uma
requisio para que os outros clientes faam uma consulta aos seus respectivos
ndices. Neste cenrio foram avaliadas as mtricas M1 (preciso), M2 (recall), M3
(F-Measure) e M4 (tempo de consulta) variando a estratgia de indexao utilizada
e a quantidade de retornos.
Cenrio 3: No terceiro cenrio o objetivo foi avaliar a busca no Servidor de
Buscas. Para que isso fosse possvel, cada cliente, ao finalizar um backup, enviou
os metadados de cada arquivos para o Servidor de Buscas, que os indexou em um
nico ndice. Neste cenrio foram avaliadas as mtricas M1 (preciso), M2 (recall),
M3 (F-Measure) e M4 (tempo de consulta) variando a estratgia de indexao
utilizada e a quantidade de retornos.
Cenrio 4: O ltimo cenrio tem como objetivo analisar o impacto da incluso
da funcionalidade de indexao e buscas no Ustore. Neste cenrio foi analisada
a mtrica M5 (tempo de backup). Para isto, foi realizado o clculo estatstico do
intervalo de confiana com 95% de confiana e taxa de erro de 5% para o tempo de
backup no Ustore em trs situaes: sem indexao, com indexao local e com
indexao local e no servidor.
4.6
Resultados
O experimento foi executados nos quatro cenrio de avaliao e a seguir so apresentados os resultados obtidos.
41
4.6. RESULTADOS
4.6.1
Resultados no Cenrio I
No primeiro cenrio utilizamos os quatro clientes Ustore (U1, U2, U3 e U4) para
fazer backup de todos os arquivos, os quais foram distribudos aleatoriamente entre os
clientes de forma que todos ficassem com o mesmo nmero de arquivos (25 arquivos
para cada um). Neste cenrio realizamos a indexao e busca locais, ou seja, foi gerado
apenas ndices em cada cliente que efetuou backup e utilizamos somente estes ndices
para responder s consultas.
Tabela 4.3 Tabela com tamanho dos ndices gerados em cada cliente Ustore.
Estratgia de Indexao
Ttulo
Contedo
U1
20.5 Kb
2 Mb
U2
20.7 Kb
2 Mb
U3
21.5 Kb
2.6 Mb
U4
21.8 Kb
2 Mb
A Tabela 4.3 mostra o tamanho dos ndices gerados em cada cliente Ustore. Nota-se
que o ndice gerado com a indexao baseada em contedo maior do que o ndice gerado
com a indexao baseada em ttulo. Isso se deve pela grande quantidade de informao
armazenada no atributo CONTENT dos metadados de cada arquivos, descrito na Seo
3.3.2 do Captulo 3.
Figura 4.2 Grfico comparando a preciso entre quatro clientes do Ustore variando a quantidade
de retornos e o tipo de indexao.
A Figura 4.2 mostra a preciso alcanada utilizando os quatro clientes Ustore utilizando indexao por contedo e por ttulo dos arquivos e variando a quantidade de
retornos (5, 10 e 15) e utilizando para consultas apenas o ndice local em cada cliente.
Pelo grfico percebemos que a maior parte dos arquivos relevantes ficaram nos clientes U2
42
4.6. RESULTADOS
e U3, pois estes foram os que obtiveram as maiores taxa de preciso. Como percebemos
pelo grfico, na maior parte dos testes realizados, as taxas de preciso quando utilizamos
a indexao baseada em contedo so mais altas do que quando utilizamos a indexao
baseada em ttulo, por exemplo, quando consideramos apenas o cliente U2 temos taxas
de preciso de 0.8, 0.5 e 0.45 para buscas baseadas em contedo e 0.6, 0.4 e 0.53 para
buscas baseadas em ttulo, com nmero de retornos de 5, 10 e 15, respectivamente. Com
isso, temos que, para 2 das 3 buscas realizadas, as taxas de preciso so superiores para o
primeiro caso. Devido distribuio aleatria dos arquivos, alguns clientes indexaram
poucos arquivos relevantes e, por isso, possuem taxas de preciso baixas. Se considerarmos a mdia aritmtica das taxas de preciso alcanadas para um retorno de 5 resultados,
conseguimos alcanar uma taxa satisfatria de 0.45. J, ao considerarmos as outras
taxas de retornos, as mdias obtidas mostram que precisamos melhorar a qualidade dos
resultados, j que essas no alcanaram o valor de referncia obtidos por outros autores.
Figura 4.3 Grfico comparando o recall entre quatro clientes do Ustore variando a quantidade de
retornos e o tipo de indexao.
A Figura 4.3 mostra as taxas de recall alcanadas com os quatro clientes do Ustore
utilizando indexao por contedo e por ttulo dos arquivos e variando a quantidade de
retornos (5, 10 e 15). Assim como na preciso, as taxas obtidas com o recall quando
utilizamos a indexao por contedo so superiores s taxas obtidas quando utilizamos
a indexao por ttulo. A anlise do grfico gerado permite observar que quando consideramos apenas os 5 (cinco) primeiros resultados, o cliente U1 possui uma taxa de
recall significante (0.5) para a busca baseada no contedo. Considerando os 15 (quinze)
primeiros resultados, o cliente U2 possui as taxas mais altas de recall: 0.35 e 0.34,
respectivamente para buscas baseada em contedo e ttulo. Analisando o grfico de forma
geral, percebe-se que as taxas de recall no so significativamente altas, ou seja, muitos
resultados relevantes no foram recuperados na consulta As mdias aritmticas relativas
43
4.6. RESULTADOS
s taxas de retorno mostram que melhorias urgentes so necessrias para melhorar a

qualidade do recall do Ustore.
Com as taxas de preciso e recall definidas podemos calcular a F-Measure para cada
cliente Ustore apresentado. Os resultados esto na Tabela 4.4.
Tabela 4.4 Tabela com os valores da F-Measure.
Retornos
5
10
15
U1
Contedo
0.29
0.10
0.17
Ttulo
0.00
0.13
0.17
U2
Contedo
0.32
0.29
0.39
Ttulo
0.24
0.31
0.41
U3
Contedo
0.24
0.20
0.17
Ttulo
0.24
0.20
0.18
U4
Contedo
0.20
0.13
0.17
Analisando os dados apresentados na Tabela 4.4 percebemos que no alcanamos

valores muitos altos (prximos a 1), pois a F-Measure derivida das taxas de preciso e
recall e, como apresentado anteriormente, as taxas de recall alcanadas no foram altas.
Figura 4.4 Grfico comparando o tempo de consulta local do Ustore variando a quantidade de
retornos e o tipo de indexao.
A Figura 4.4 mostra a medio de tempo para realizar 30 consultas locais no Ustore
utilizando indexao baseada em ttulo e em contedo. Nela podemos perceber que,
devido maior quantidade de informao gerada pela indexao baseada em contedo,
as consultas realizadas neste ndice so mais demoradas do que aquelas realizadas no
ndice com indexao baseada apenas no ttulo. Foi realizada uma anlise estatstica dos
resultados obtidos e ela mostra que em 95% dos casos uma consulta no ndice gerado
com o contedo dos arquivos demora entre 60ms e 180ms; j uma consulta no ndice
gerado apenas com o ttulo dos arquivos demora entre 25ms e 42ms. Como descrito
44
Ttulo
0.08
0.10
0.12
4.6. RESULTADOS
anteriormente, consideramos o tempo de 1000ms como satisfatrio para a realizao

de uma consulta, logo os tempos obtido para a consulta baseada em contedo so
satisfatrios.
4.6.2
Resultados no Cenrio II
No segundo cenrio foram utilizados os mesmo clientes Ustore anteriores com os

mesmo arquivos indexados. A nica diferena significativa entre o primeiro e segundo
cenrio, foi a estratgia de busca adotada. Enquanto no primeiro cenrio a busca foi
realizada localmente, neste a busca foi realizada utilizando os outros clientes ativos, ou
seja, a busca foi realizada atravs da rede JXTA formada entre os clientes.
Figura 4.5 Grfico comparando a preciso entre quatro clientes do Ustore variando a quantidade
de retornos e o tipo de indexao e fazendo consulta aos outros clientes.
A Figura 4.5 mostra a preciso alcanada utilizando os quatro clientes Ustore utilizando indexao por contedo e por ttulo dos arquivos e variando a quantidade de
retornos (5, 10 e 15). A anlise do grfico gerado permite dizer que os clientes U1, U2
e U4 conseguem taxas satisfatrias de preciso, 0.5 e 0.4 e 0.4, respectivamente, com
taxas de retornos variveis. Considerando todo os clientes, temos que as taxas de preciso
so semelhantes quando comparamos as buscas realizadas baseadas no contedo e ttulo.
A anlise das mdias aritmticas para cada variao da quantidade de retornos mostra
que melhorias precisam ser aplicadas para aumentar a preciso do Ustore nas consultas
atravs da rede, pois a mdia mais alta que obtemos foi de 0.37, enquanto a mdia de
referncia de 0.45.
A Figura 4.6 mostra a taxa de recall dos clientes Ustore. O grfico mostra que
os clientes Ustore conseguem taxas de recall semelhantes, independente da estratgia
de indexao utilizada (contedo ou ttulo). Para este cenrio, foram alcanadas taxas
45
4.6. RESULTADOS
Figura 4.6 Grfico comparando o recall de quatro clientes do Ustore variando a quantidade de
retornos e o tipo de indexao e fazendo consulta aos outros clientes.
de recall muito baixas, assim como no Cenrio I. Em alguns casos, como no cliente
U2, as taxas alcanam uma mdia de apenas 0.1. As mdias aritmticas obtidas para
cada variao da quantidade de retornos mostram que melhoria urgentes precisam ser
realizadas para aumentar a qualidade do recall das consultas atravs da rede. A mdia
mais alta alcanada neste cenrio foi de 0.22.
Com as taxas de preciso e recall definidas podemos calcular a mdia F para cada
cliente Ustore. Os resultados esto na Tabela 4.5.
Retornos
5
10
15
U1
Contedo
0.16
0.33
0.29
Ttulo
0.24
0.27
0.34
U2
Contedo
0.08
0.13
0.17
Ttulo
0.08
0.13
0.17
U3
Contedo
0.16
0.20
0.29
Ttulo
0.08
0.27
0.29
U4
Contedo
0.16
0.27
0.29
Analisando os dados apresentados na Tabela 4.5 percebemos que no alcanamos

valores muitos altos (prximos a 1), pois a F-Measure derivida das taxas de preciso e
recall e, como apresentado anteriormente, as taxas de recall alcanadas no foram altas.
A Figura 4.7 mostra o tempo gasto para a execuo de 30 consultas no Ustore
utilizando os outros clientes ativos para respond-las. A anlise do grfico gerado
permite observar que, na maioria dos casos, a busca baseada em contedo demora mais
para executar do que a busca por ttulo. Isso se justifica pelo fato da indexao do
contedo gerar um ndice de busca maior, como mostrado anteriormente. H consultas
que demoraram muito mais que outras, por exemplo, a primeira e quarta consulta por
46
Ttulo
0.16
0.20
0.29
4.6. RESULTADOS
Figura 4.7 Grfico comparando o tempo de consulta aos outros clientes do Ustore variando a
quantidade de retornos e o tipo de indexao.
contedo. Os testes foram executados durante a execuo normal do Ustore e o mesmo

continua enviando outros tipos de mensagens, como: disponibilidade, replicao de
chunks e isto pode ter causado esta elevao no tempo necessrio para concluir uma
consulta. A anlise estatstica nos permite calcular, com 95% de confiana, que as
consultas atravs da rede baseadas em contedo sero realizadas no intervalo de 101ms
e 393ms. J as consultas baseadas em ttulo sero realizadas no intervalo de 53ms e
66ms. Os resultados obtidos no intervalo de confiana para realizao de uma consulta se
mostraram satisfatrios, pois, como descrito anteriormente, consideramos o tempo de
1000ms como satisfatrio para a realizao de uma consulta.
4.6.3
Resultados no Cenrio III
O terceiro cenrio leva em considerao somente a indexao e consultas realizadas

no Servidor de Buscas. Neste cenrio o Servidor de Busca contm um ndice de busca
gerado pela indexao de todo o conjunto de dados de 100 arquivos com extenso PDF,
com o tamanho total de 4.6 MB para o ndice com o contedo dos arquivos e 76,7 KB
para o ndice gerado pela indexao baseada apenas no ttulo dos arquivos.
A Figura 4.8 mostra o resultado da consulta pela palavra-chave cloud computing
variando a quantidade de retornos e o tipo de indexao usada no Ustore. Nela podemos
ver que a indexao por contedo possui uma preciso melhor do que a indexao
por ttulo. Por exemplo, quando analisamos o grfico com uma taxa de retorno de 10
resultados, obtemos 0.40 de preciso com a indexao baseada em contedo, enquanto
obtemos somente 10% de preciso com a indexao por ttulo. J com um retorno de 15
resultados, temos 0.5 e 0.15, respectivamente.
47
4.6. RESULTADOS
Figura 4.8 Grfico comparando a preciso do Ustore variando a quantidade de retornos e o tipo
de indexao.
Figura 4.9 Grfico comparando o recall do Ustore variando a quantidade de retornos e o tipo de
indexao.
48
4.6. RESULTADOS
A Figura 4.9 mostra a taxa de recall alcanada. Nele notamos que a taxa de recall
cresce quando aumentamos a quantidade de retornos para uma busca baseada em contedo.
J para uma busca baseada no ttulo, esta taxa se manteve constante para 10 e 15 resultados.
Neste cenrio tambm obtivemos taxa consideravelmente baixas, o que indica que muito
arquivos relevantes no foram retornados nas consultas.
Figura 4.10 Grfico comparando as taxas de preciso e recall do Ustore variando a quantidade
de retornos e o tipo de indexao.
Unificamos os dois resultados, de forma que possamos comparar as taxas obtidas

levando em considerao as duas mtricas, simultaneamente. Na Figura 4.10 temos o
grfico gerado e nele podemos notar que com uma taxa de retorno de 15 resultados
possvel obter uma taxa satisfatria de preciso (0.50) juntamente com uma taxa razovel
de recall (0.35) para a busca baseada no contedo. J para as consultas baseadas no ttulo
dos arquivos, um retorno de 15 resultados alcana uma taxa de 0.15 de preciso e 0.2 de
recall, ambas inferiores s mesmas consultas baseada em contedo.
Com os valores de preciso e recall definidos, possvel calcular o valor da mdia F.
Os valores encontrados so mostrados na Tabela 4.6.
Qnt. Retornos
Ttulo
Contedo
5
10
15
0.08
0.13
0.17
0.16
0.27
0.41
Como mostrado anteriormente, a F-measure tem valores baixos para a razo entre
preciso e recall devido, principalmente, s baixas taxas de recall. Entretanto, se considerarmos somente a taxa de F-measure alcanada quando utilizamos a consulta baseada
49
4.6. RESULTADOS
em contedo e com uma taxa de retorno de 15 resultados temos um valor de 0.41, muito
prximo ao valor inicialmente estabelecido de 0.42.
Figura 4.11 Grfico comparando o tempo gasto para realizar consultas no Ustore utilizando
indexao baseada em ttulo e contedo.
Na Figura 4.11 temos o tempo gasto para realizar 30 consultas pela palavra-chave
cloud computing no Ustore utilizando indexao baseada em ttulo e em contedo. O
tempo gasto para efetuar as consultas no segundo caso superior ao primeiro devido ao
tamanho do ndice que foi gerado, pois, como mostrado anteriomente, este , aproximadamete, 60% maior. Utilizando o teste estatstico do intervalo de confiana, possvel
dizer que em 95% do casos a busca baseada no ttulo demorar entre 47ms e 58ms. J a
busca baseada no contedo demorar entre 461ms e 519ms. Como descrito anteriormente,
consideramos o tempo de 1000ms como satisfatrio para a realizao de uma consulta,
logo os tempos obtidos pelo intervalo de confiana para a consulta baseada em contedo
so satisfatrios.
4.6.4
Resultados no Cenrio IV
O quarto cenrio tem como objetivo avaliar o impacto da incluso da funcionalidade

de indexao no sistema Ustore. Para isso foram realizados 30 backups de um mesmo
arquivo com extenso pdf e com tamanho de 12 Mb para avaliar o aumento no tempo gasto
para a concluso da tarefa para as trs situaes possveis: sem indexao, indexao
por ttulo e indexao local e no servidor. A Figura 4.12 mostra o resultado dos backups
realizados.
A anlise atravs do clculo estatstico do intervalo de confiana nos mostra que em
95% dos casos o backup sem a realizao de nenhuma indexao gastar entre 2647ms e
50
4.7. DISCUSSO E CONSIDERAES FINAIS
Figura 4.12 Grfico comparando o tempo gasto realizar backup com e sem a indexao baseada
em contedo gerando um ndice local e outro no servidor.
3922ms. O backup somente com indexao local gastar entre 2989ms e 4087ms. J o
backup com indexao local e no servidor gastar entre 5714ms e 7441ms.
4.7
Discusso e Consideraes Finais
Nesta Seo ns discutimos os resultados obtidos e sua avaliao, restries e oportunidades. Ns tambm discutimos possvel ameaas validade de nosso experimento.
4.7.1
Discusso dos Resultados
Os experimentos mostram que a indexao baseada em contedo faz com que o

ndice tenha um crescimento significativo, como mostrado na Tabela 4.3. Este aumento
de cerca de 100% devido grande quantidade de informao adicionada no atributo
CONTENT dos metadados. Este aumento faz com que as consultas demorem mais tempo
para serem executadas, como mostrado nas Figuras 4.4, 4.7 e 4.11. A Figura 4.4 apresenta
uma diferena entre as consultas de 35ms para as consultas mais rpidas e 138ms para as
consultas mais demoradas. A Figura 4.7 apresenta uma diferena de 48ms para consultas
mais rpidas e 327ms para consultas as consultas mais demoradas. A Figura 4.11 mostra
uma diferena de 414ms para consultas mais rpidas e 461ms para consultas as consultas
mais demoradas. Mesmo com uma elevada diferena entre os tempos de consulta, estas
continuaram sendo respondidas em um intervalo de tempo abaixo de 500ms. Como o
51
4.7. DISCUSSO E CONSIDERAES FINAIS
tempo de referncia utilizado foi de 1000ms, temos que o Ustore continua respondendo
as consultas em um tempo consideravelmente baixo.
A anlise do impacto da implantao da funcionalidade de indexao baseada em
contedo no Ustore no Cenrio IV mostra que a utilizao somente da indexao local
tem um impacto pequeno de aproximadamente 300ms para a indexao mais rpida e
160ms para a indexao mais demorada. J com a utilizao da indexao local e no
servidor, o impacto maior: cerca de 2700ms para a indexao mais rpida e 3300ms
para a indexao mais demorada. Este aumento se d pela necessidade de enviar uma
mensagem assncrona para o servidor com os metadados para serem indexados.
Os experimentos tambm mostram que apesar do aumento significativo no tamanho
do ndice gerado, no tempo de resposta da consulta e no tempo de indexao, a preciso,
recall e F-measure do sistema melhoraram utilizando a abordagem proposta. Entretanto,
importante ressaltar que os valores obtidos nestas mtricas alcanaram os valores
de referncias inicialmente estabelecidos apenas em poucos casos, o que mostra que
melhorias so necessrias.
A utilizao de um ndice centralizado no Servidor de Buscas permite que o usurio
tenha acesso ao ndice completo gerado no Ustore e, com isso, permite que a consulta
leve em considerao todos os arquivos pblicos de todos os usurios. Entretanto, como
j discutido, este modelo tem diversas desvantagens como: ponto nico de falha na rede,
possibilidade de sobrecarga, entre outros. Com a utilizao da abordagem proposta para
armazenamento do ndice no Servidor de Buscas e tambm localmente juntamente com a
indexao baseada no contedo do arquivos, possvel minimizar estes problemas e, em
caso de falha do servidor, possvel obter resultados satisfatrios, como mostrado pelo
experimento executado, utilizando a busca atravs da rede ou at mesmo somente a busca
local. Isto permite que o usurio obtenha retorno para suas consultas independente de
problemas que possam acontecer com o Servidor.
4.7.2
Problemas Encontrados
Analisando os resultado finais possvel observar que a busca baseada em contedo

traz resultados satisfatrios. Entretanto, a avaliao tambm revela alguns problemas:
Taxas baixas de preciso e recall: Na maioria dos casos analisados as taxas
de preciso e recall foram superiores para a indexao baseada em contedo.
Entretanto, em alguns cenrio o inverso aconteceu. Isto pode ter acontecido devido
classificao de relevncia adotada: a quantidade de repeties dos termos
buscados no contedo dos arquivos. Apesar do requisito no-funcional Alta
preciso e recall ter sido Parcialmente Atendido (Seo 3.2.2), melhoria ainda
podem ser realizadas neste sentido.
Crescimento do ndice de busca: O ndice gerado para buscas baseadas no contedo dos arquivos tem um aumento de tamanho considervel em relao ao ndice
para buscas baseadas no ttulo dos arquivos. Este aumento aconteceu devido a
deciso de manter no ndice todo o contedo armazenado para ser utilizado futuramente, por exemplo, para calcular a similaridade entre arquivos e poder utilizar
52
uma abordagem para recomendao de informao. O contedo armazenado no

necessrio para a realizao das consultas, pois este j foi indexado pelo Lucene e
mantido em uma estrutura de ndice invertido, como descrito na Seo 3.4.1.
4.7.3
Possveis Ameaas Validade
O experimento executado tem algumas limitaes, as quais devem ser levadas em

considerao em uma possvel replicao do mesmo, como:
Conjunto de dados pequeno: Devido a restries de tempo, nosso experimento
foi realizado com um conjunto pequeno de dados. Deve-se considerar a utilizao
de uma quantidade maior de arquivos ou a utilizao de um conjunto de dados do
TREC2 .
Apenas uma consulta foi realizada: Com a massa de dados indexada, apenas
uma consulta foi realizada. Esta utilizou a palavra-chave cloud computing.
Deve-se considerar aumentar a quantidade de consultas realizadas e quantidade de
palavras-chave utilizadas.
Ambiente totalmente distribudo: No experimento realizado, os clientes, servidor e servidor de busca do Ustore foram executados em mquinas virtual em um
mesmo servidor fsico. Deve-se considerar a utilizao de um ambiente totalmente
distribudo, de forma a simular um ambiente real de computao em nuvem.
Mtricas de avaliao: Poucas mtricas foram utilizas na avaliao de desempenho. Pode-se utilizar outras mtricas relacionadas com recuperao de informao,
bem como, computao em nuvem.
4.8
Sumrio do Captulo
Neste captulo foi apresentado o experimento realizado no Ustore com o objetivo

de avaliar a abordagem proposta. A avaliao foi feita para analisar o impacto de sua
adoo no Ustore, bem como avaliar os nveis de preciso, recall e f-measure obtidos, os
quais utilizados para analisar se houve aumento na quantidade de resultados relevantes
retornados para o usurio. A abordagem de indexao e buscas baseadas em contedo foi
comparada com a abordagem de busca baseada em ttulo, utilizada pelo maior parte dos
sistemas de armazenados existentes. O resultados mostraram que a abordagem proposta
consegue aumentar a quantidade de resultados relevantes retornados e que se mostra
vivel para ser utilizada em sistemas reais de armazenamento em nuvem.
No prximo captulo sero apresentadas as concluses deste trabalho, as contribuies
alcanadas e alguns possveis trabalhos futuros.
2 http://trec.nist.gov/
53
Concluso e Trabalhos Futuros

A utilizao de sistemas para armazenamento de dados em nuvem se tornaro ainda
mais necessrios com o enorme volume de dados que ser gerado nos prximos anos. J
existem diversos sistemas com este propsito, conforme descrito em captulos anteriores.
Entretanto, os sistemas de armazenamento em nuvem disponveis no trazem recursos
avanados para recuperao de informaes, como buscas full-text e buscas baseadas no
contedo. Neste contexto, foi proposto e desenvolvido uma abordagem com este objetivo,
a qual se baseou nos requisitos definido na Seo 3.2 e ns a avaliamos em um sistema
de armazenamento em nuvem real no Captulo 4.
Com nossa abordagem possvel indexar e realizar consultas full-text baseadas em
contedo em sistemas de armazenamento em nuvem. A implementao da abordagem
proposta realizada no Ustore mostra que a abordagem proposta vivel e prtica para ser
utilizada em um ambiente real, como evidenciado pelo experimento realizado. O experimento mostrou que a utilizao da abordagem permitiu que o contedo fosse indexado
juntamente com os metadados do arquivos e que as mtricas analisadas (preciso, recall
e f-measure) indicam uma melhoria na qualidade dos resultados, em comparao com a
busca baseada em ttulo, a qual utilizada pela maioria dos sistemas de armazenamento
em nuvem. Os outros requisitos propostos no Captulo 3 tambm foram alcanados,
alguns de forma parcial e outros totalmente, como discuto anteriormente.
5.1
Contribuies
As principais contribuies deste trabalho foram: (a) uma abordagem para permitir
indexao e consultas full-text baseadas em contedo, (b) a implementao da abordagem
no Ustore e (c) um estudo experimental para medir o desempenho da abordagem. Estas
contribuies esto detalhadas abaixo.
Uma abordagem para permitir indexao e consultas full-text baseadas em
contedo para sistemas de armazenamento em nuvem foi desenvolvida. Seus
requisitos, arquitetura, implementao foram apresentados ao longo desta dissertao.
A implementao da abordagem no Ustore, o que permitiu avaliar e demonstrar
sua efetividade em um sistema real de armazenamento em nuvem.
54
5.2. TRABALHOS FUTUROS
Um estudo experimental foi realizado com o objetivo de medir o desempenho

da abordagem full-text em comparao com a abordagem baseada em ttulos
dos arquivos, a qual utilizada por muitos sistemas de armazenamento. Este
experimento foi baseado no processo para avaliao de desempenho proposto em
[Jain, 1991].
5.2
Trabalhos Futuros
Devido a restries de tempo, esta dissertao aborda alguns problemas, mas alguns
outros ainda esto abertos. Alm disso, ainda possvel melhorar alguns pontos nesta
dissertao e evoluir a proposta apresentada. Estes so alguns pontos que podem ser
investigados como trabalhos futuros:
Estender o experimento executado: O experimento pode ser estendido de forma
que seja validada toda a abordagem proposta. Esta extenso inclui:
Testar a eficincia da replicao do ndice.
Utilizar um conjunto maior de dados para indexar ou uma base da dados
conhecida como o TREC1 .
Realizar testes com uma base dados real do Ustore e com seus usurios.
Expanso do termos da consulta: A abordagem pode ser evoluda para permitir
a expanso dos termos da consulta. Esta expanso poder, por exemplo, melhorar
as taxas de preciso e recall obtidas.
Arquivos versionados: O Ustore tem a capacidade de manter todas as verses dos
arquivos modificados. Na abordagem proposta, n ao levamos isso em considerao.
Ento, necessrio estender a abordagem para que sejam mantidas todas as verses
do contedo dos arquivos modificados.
Evitar flooding na rede: Como discutido anteriormente, a busca na rede pode
causar flooding se a quantidade de mensagens necessria para consultar todos os
clientes Ustore for muito grande. H na literatura diversas propostas para evitar este
tipo de problema [Li and Wu, 2006], como: include iterative deepening [Yang and
Garcia-Molina, 2002], k-walker random walk [Lv et al., 2002], two-level k-walker
random walk [Jawhar and Wu, 2004], intelligent search [Kalogeraki et al., 2002].
Definir critrios para escolha dos clientes Servidores de Busca para serem
consultados: Todas as buscas foram realizadas tendo como base a escolha aleatria
de clientes e Servidores de Busca. Alguns critrios podem ser adotados para definir
quais seriam os melhores clientes e Servidores para responder a consulta, como:
quantidade de informao indexada, tempo de resposta, histrico de respostas
relevantes, etc.
1 http://trec.nist.gov/
55
5.2. TRABALHOS FUTUROS
Recomendao de arquivos baseado no contedo: Atravs dos metadados definidos possvel montar uma proposta para recomendao de informao baseada,
por exemplo, no contedo dos arquivos, a categoria dos mesmo, as reas de interesse do usurio.
Segurana dos arquivos indexados: A abordagem proposta no abrange atributos relacionados com a segurana das informaes armazenadas e como realizar
consultas seguras neste ambiente. H propostas relacionadas com esta rea que
podem ser adotadas como: [Wang et al., 2010; Cao et al., 2011; Wang et al., 2012].
56
Referncias Bibliogrficas
Armbrust, M., Fox, A., Griffith, R., Joseph, A. D., Katz, R., Konwinski, A., Lee, G.,
Patterson, D., Rabkin, A., Stoica, I., and Zaharia, M. (2009). Above the Clouds : A
Berkeley View of Cloud Computing Cloud Computing : An Old Idea Whose Time Has
( Finally ) Come. Computing, pages 713.
Assad, R. E., Machado, M. A. S., Soares, P. F. A., Silva, A. F., Silva, T. J. e., Garcia,
V. C., Trinta, F., and Meira, S. (2012). Desafios em cloud computing: Armazenamento,
banco de dados e big data. In Tpicos em Multimdia, Hipermdia e Web, pages 76111.
Sociedade Brasileira de Computao.
Baeza-Yates, R. A. and Ribeiro-Neto, B. (1999). Modern Information Retrieval. AddisonWesley Longman Publishing Co., Inc., Boston, MA, USA.
Barolli, L. and Xhafa, F. (2011). Jxta-overlay: A p2p platform for distributed, collaborative, and ubiquitous computing.
Berrios, D. C. (2000). Automated indexing for full text information retrieval. In Proceedings of the AMIA Symposium, page 71. American Medical Informatics Association.
Cao, N., Wang, C., Li, M., Ren, K., and Lou, W. (2011). Privacy-preserving multikeyword ranked search over encrypted cloud data. In INFOCOM, 2011 Proceedings
IEEE, pages 829837. IEEE.
Datta, A., Wu, D., Xin, L., and Wierzbicki, A. (2010). Handbook of Research on P2P
and Grid Systems for Service-Oriented Computing. IGI Global.
Deng, J., Hu, J., Liu, A. C. M., and Wu, J. (2010). Research and Application of Cloud
Storage. 2010 2nd International Workshop on Intelligent Systems and Applications,
pages 15.
Duarte, M. (2010). Um algoritmo de disponibilidade em sistemas de backup distribudo
seguro usando a plataforma peer-to-peer. Masters thesis, Centro de Informtica/UFPE.
Duro, F., Almeida, E., and Lemos Meira, S. (2008). Applying a semantic layer in a
source code retrieval tool. Masters thesis, Centro de Informtica/UFPE.
Duro, F., Assad, R., Fonseca, A., Fernando, J., Garcia, V., and Trinta, F. (2013). Usto.re:
A private cloud storage software system. In Daniel, F., Dolog, P., and Li, Q., editors,
Web Engineering, volume 7977 of Lecture Notes in Computer Science, pages 452466.
Springer Berlin Heidelberg.
Gantz, J. and Reinsel, D. (2011). Extracting Value from Chaos State of the Universe : An
Executive Summary. (June):112.
57
REFERNCIAS BIBLIOGRFICAS
Garcia, V., Lucrdio, D., Duro, F., Santos, E., Almeida, E., Mattos Fortes, R., and Lemos Meira, S. (2006). From specification to experimentation: A software component
search engine architecture. In Gorton, I., Heineman, G., Crnkovic, I., Schmidt, H.,
Stafford, J., Szyperski, C., and Wallnau, K., editors, Component-Based Software Engineering, volume 4063 of Lecture Notes in Computer Science, pages 8297. Springer
Berlin Heidelberg.
Gong, L. and Others (2001). Project JXTA: A technology overview. Technical report,
Technical report, SUN Microsystems, April 2001. http://www. jxta. org/project/www/docs/TechOverview. pdf.
Hatcher, E. and Gospodnetic, O. (2004). Lucene in Action (In Action series). Manning
Publications Co., Greenwich, CT, USA.
Heiss, J. J. (2005). Jxta technology brings the internet back to its origin. Technical report,
Oracle.
Hiemstra, D. (2009). Information Retrieval Models. John Wiley and Sons, Ltd.
Hupfeld, F., Cortes, T., Focht, E., Hess, M., Malo, J., Marti, J., Cesario, E., Kolbeck,
B., and Stender, J. (2008). The XtreemFS architecture a case for object-based file
systems. Concurrency and computation: Practice and experience, 20(17):20492060.
Hupfeld, F., Cortes, T., Kolbeck, B., Stender, J., Focht, E., Hess, M., Malo, J., Marti,
J., and Cesario, E. (2007). XtreemFS: a case for object-based storage in Grid data
management. In 3rd VLDB Workshop on Data Management in Grids, co-located with
VLDB, volume 2007, pages 110.
Jain, R. (1991). The Art of Computer Systems Performance Analysis: techniques for
experimental design, measurement, simulation, and modeling. Wiley.
Jawhar, I. and Wu, J. (2004). A two-level random walk search protocol for peer-to-peer
networks. In Proc. of the 8th World Multi-Conference on Systemics, Cybernetics and
Informatics, pages 15.
Kalogeraki, V., Gunopulos, D., and Zeinalipour-Yazti, D. (2002). A local search mechanism for peer-to-peer networks. Proceedings of the eleventh international conference
on Information and knowledge management - CIKM 02, page 300.
Kaplan, J., Roy, R., and Srinivasaraghavan, R. (2008). Meeting the demand for data
storage. Technical report, The McKinsey Quarterly.
Kostoff, R. N. (2010). Expanded information retrieval using full-text searching. Journal
of Information Science, 36(1):104113.
Lenk, A., Klems, M., Nimis, J., Tai, S., Sandholm, T., and Alto, P. (2009). What s
Inside the Cloud ? An Architectural Map of the Cloud Landscape. Management, pages
2331.
58
Li, X. and Wu, J. (2006). Searching techniques in peer-to-peer networks. . . . Aspects of

Ad Hoc, Sensor, and Peer-to-Peer Networks, pages 131.
Loest, S. R., Madruga, M. C., Maziero, C. A., and Lung, L. C. (2009). Backupit: An
intrusion-tolerant cooperative backup system. Computer and Information Science,
ACIS International Conference on, 0:724729.
Lu, J. (2007). Full-text federated search in peer-to-peer networks. PhD thesis, School of
Computer Science, Carnegie Mellon University.
Lu, J. and Callan, J. (2003). Content-based retrieval in hybrid peer-to-peer networks.
Proceedings of the twelfth international conference on Information and knowledge
management - CIKM 03, page 199.
Lv, Q., Cao, P., Cohen, E., Li, K., and Shenker, S. (2002). Search and replication in
unstructured peer-to-peer networks. In Proceedings of the 16th international conference
on Supercomputing, pages 8495. ACM.
Manning, C. D., Raghavan, P., and Schtze, H. (2008). Introduction to Information
Retrieval. Cambridge University Press, New York, NY, USA.
Mattmann, C. and Zitting, J. (2011). Tika in Action. Manning Publications Co., Greenwich, CT, USA.
Mell, P. and Grance, T. (2009). The NIST Definition of Cloud Computing. Technical
report.
Oliveira, M. (2007). Ourbackup: Uma soluo p2p de backup baseada em redes sociais.
Masters thesis, Universidade Federal de Campina Grande.
Palankar, M. R., Iamnitchi, A., Ripeanu, M., and Garfinkel, S. (2008). Amazon s3 for
science grids: a viable solution? In Proceedings of the 2008 international workshop
on Data-aware distributed computing, DADC 08, pages 5564, New York, NY, USA.
ACM.
Peddemors, R. and Spoor, R. (2010). Cloud Storage and Peer-to-Peer Storage: End-user
considerations and product overview.
Peterson, W. W. and Weldon, E. J. (1972). Error-correcting codes. The MIT Press.
Pouwelse, J., Garbacki, P., Epema, D., and Sips, H. (2005). The bittorrent p2p file-sharing
system: Measurements and analysis. In Peer-to-Peer Systems IV, pages 205216.
Springer.
Rabin, M. O. (1989). Efficient dispersal of information for security, load balancing, and
fault tolerance. J. ACM, 36(2):335348.
Rijsbergen, C. J. V. (1979). Information Retrieval. Butterworth-Heinemann, Newton,
MA, USA, 2nd edition.
59
Robertson, S. and Zaragoza, H. (2009). The probabilistic relevance framework: BM25

and beyond. Now Publishers Inc.
Robertson, S. E. (1977). The probability ranking principle in ir. Journal of documentation,
33(4):294304.
Silva, A., Machado, M., Soares, P., Jamir, T., Garcia, V., and Assad, R. (2012a). Desenvolvendo aplicativos peer-to-peer (p2p) no contexto de data storage para ambientes de
cloud computing. In de Computao, S. B., editor, Simpsio Brasileiro de Sistema de
Informao.
Silva, A., Machado, M., Soares, P., Jamir, T., Garcia, V., Assad, R., and Meira, S. (2012b).
Usto.re uma plataforma descentralizada para storage de contedo em nuvens privadas.
In CBSoft2012 - Industria.
Sparck Jones, K., Walker, S., and Robertson, S. E. (2000). A probabilistic model of
information retrieval: development and comparative experiments: Part 1. Information
Processing & Management, 36(6):779808.
Steinacker, A., Ghavam, A., and Steinmetz, R. (2001). Metadata standards for web-based
resources. IEEE Multimedia, 8:7076.
Stender, J., Kolbeck, B., Hgqvist, M., and Hupfeld, F. (2010). BabuDB: Fast and
Efficient File System Metadata Storage. 2010 International Workshop on Storage
Network Architecture and Parallel I/Os, pages 5158.
Tang, C. and Dwarkadas, S. (2004). Hybrid global-local indexing for effcient peer-topeer information retrieval. In Proceedings of the 1st conference on Symposium on
Networked Systems Design and Implementation - Volume 1, NSDI04, pages 1616,
Berkeley, CA, USA. USENIX Association.
Vaquero, L. M., Rodero-merino, L., Caceres, J., and Lindner, M. (2009). A Break in the
Clouds : Towards a Cloud Definition. Computer Communication Review, 39(1):5055.
Vogels, W. (2008). A head in the clouds - the power of infrastructure as a service. First
workshop on Cloud Computing and in Applications (CCA 08).
Wang, C., Cao, N., Li, J., Ren, K., and Lou, W. (2010). Secure ranked keyword search
over encrypted cloud data. In Distributed Computing Systems (ICDCS), 2010 IEEE
30th International Conference on, pages 253262. IEEE.
Wang, C., Cao, N., Ren, K., and Lou, W. (2012). Enabling secure and efficient ranked
keyword search over outsourced cloud data. Parallel and Distributed Systems, IEEE
Transactions on, 23(8):14671479.
Yang, B. and Garcia-Molina, H. (2002). Improving search in peer-to-peer networks. In
Distributed Computing Systems, 2002. Proceedings. 22nd International Conference on,
pages 514. IEEE.
60
Yang, Y., Dunlap, R., Rexroad, M., and Cooper, B. F. (2006). Performance of Full
Text Search in Structured and Unstructured Peer-to-Peer Systems. Proceedings IEEE
INFOCOM 2006. 25TH IEEE International Conference on Computer Communications,
pages 112.
Zeng, W., Zhao, Y., and Ou, K. (2009). Research on cloud storage architecture and key
technologies. Technology, Culture and Human, pages 48.
61

Uma Abordagem para Indexação e Buscas Full-Text Baseadas em Conteúdo em Sistemas de Armazenamento em Nuvem

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Uma Abordagem para Indexação e Buscas Full-Text Baseadas em Conteúdo em Sistemas de Armazenamento em Nuvem

Enviado por

Direitos autorais:

Formatos disponíveis

Uma Abordagem para Indexao e Buscas Full-Text

Baseadas em Contedo em Sistemas de Armazenamento em

Marco Andr Santos Machado

Universidade Federal de Pernambuco

Universidade Federal de Pernambuco

Marco Andr Santos Machado

Uma Abordagem para Indexao e Buscas Full-Text

Trabalho apresentado ao Programa de Ps-graduao em

Orientador: Vinicius Cardoso Garcia

Eu dedico esta dissertao meus pais por todo o incentivo

Primeiramente gostaria de agradecer a toda minha famlia, em especial meus pais,

O universo digital cresce de forma exponencial e a previso que em 2015 chegue

Contextualizao e Trabalhos Relacionados

Uma Abordagem para Indexao e Buscas Full-Text Baseadas em Contedo

Elasticidade e Replicao do ndice entre Servidores

Concluso e Trabalhos Futuros

Expectativa de crescimento da quantidade de dados gerados [Gantz and

Arquitetura em camadas para computaao nas nuvens . . . . . . . . . .

Representao da arquitetura do JXTA [Heiss, 2005] . . . . . . . . . .

Representao do cenrio de testes utilizado no experimento. . . . . . .

Grfico comparando a preciso do Ustore variando a quantidade de

Tabela com diferenas entre recuperao de dados e recuperao de

Tabela com a situao dos requisitos propostos. . . . . . . . . . . . . .

Mtricas utilizadas na avaliao. . . . . . . . . . . . . . . . . .

Acessado em: 07/08/2013

Os sistemas de armazenamento em nuvem mais populares, como: Amazon S3,

1.2. DEFINIO DO PROBLEMA

A maioria dos sistemas de armazenamento em nuvem somente permitem que consultas

1.4. FORA DO ESCOPO

Alguns assuntos foram excludos do escopo de pesquisa desta dissertao. So eles:

1.5. ESTRUTURA DA DISSERTAO

Indexao do contedo de arquivos de udio e video: H diversas propostas na

O restante desta dissertao est organizada da seguinte forma:

2.1. RECUPERAO DE INFORMAO

Modelos de Recuperao de Informao

De acordo com [Baeza-Yates and Ribeiro-Neto, 1999] um modelo de RI composto

Modelo Espao Vetorial

O modelo Espao Vetorial tem o objetivo de resolver o principal problema do modelo

2.1. RECUPERAO DE INFORMAO

Recuperao de Informao versus Recuperao de Dados

Existe uma grande diferena entre os termos recuperao de informao e recuperao

2.2. COMPUTAO EM NUVEM

Portanto, a soluo proposta nesta dissertao integrar um sistema de recuperao de

O National Institute of Standards and Technology (NIST) define computao em

Figura 2.1 Arquitetura em camadas para computaao nas nuvens

Infraestrutura como um servio (Infrastructure-as-a-Service - IaaS) o fornecimento

2.2. COMPUTAO EM NUVEM

Acessado em: 28/07/2013

2.2. COMPUTAO EM NUVEM

datacenters que oferecem esses servios. Quando a nuvem disponibilizada no formato

Armazenamento de Dados em Nuvem

Na Seo anterior mostramos que a utilizao da computao em nuvens permite que

2.2. COMPUTAO EM NUVEM

Figura 2.2 Arquitetura de um sistema de armazenamento em nuvem. Adaptado de [Peddemors

Figura 2.3 Arquitetura de um sistema de armazenamento em nuvem utilizando arquitetura P2P.

2.3. TRABALHOS RELACIONADOS

Figura 2.4 Representao do processo de para armazenamento e recuperao de dados utilizando

Nas sees anteriores apresentamos os principais conceitos relacionados com as reas

2.3. TRABALHOS RELACIONADOS

trabalhos relacionados com recuperao de informao em sistemas de armazenamento

Recuperao de Informao em Sistemas de Armazenamento

O Amazon S39 (Simple Storage Systems) um sistema de armazenamento de objetos

ltimo acesso em 01/08/2013

2.3. TRABALHOS RELACIONADOS