Você está na página 1de 7

1

Indexação Distribuída de Colecções


Web de Larga Escala
Miguel Costa e Mário. J. Silva

O Sidra é um novo sistema de indexação para grandes


Resumo − O Sidra é um novo sistema de indexação e pesquisa colecções de dados extraídos da Web que suporta mais que as
para colecções de documentos Web de larga escala. Cria pesquisas por termos [2]. Mantém várias estruturas de índices
múltiplos índices distribuídos, organizados e particionados por distribuídas, organizadas segundo diferentes critérios de
diferentes critérios de ordenação, destinados a suportar
ordenação, que podem ser seleccionadas para achar
pesquisas contextualizadas sobre dados e metadados
hypertextuais. Este artigo apresenta a arquitectura do Sidra e documentos em função do contexto associado a cada pesquisa.
descreve os algoritmos usados para criar os seus índices. Os Esta abordagem aumenta significativamente os requisitos de
resultados da indexação da Web portuguesa com o Sidra armazenamento para os índices, mas preserva os tempos de
mostram que, em termos de desempenho e escalabilidade, este resposta inferiores a um segundo, actualmente exigidos pelos
apresenta características comparáveis aos motores de pesquisa utilizadores da Web.
da Web global.
Os motores de pesquisa da Web são compostos por
sistemas de recolha, armazenamento, indexação e pesquisa de
Palavras-chave−Indexação, motores de pesquisa, Web.
informação. Cada um apresenta desafios difíceis de superar. O
I. INTRODUÇÃO Sidra foi construído para o tumba! (ver http://www.tumba.pt),
um motor de pesquisa para a Web portuguesa, que está
O s sistemas de recuperação de informação usam índices de
termos para acelerar a pesquisa de documentos relevantes
numa colecção. Construir esses índices para pequenas
disponível como serviço público desde 2002 [3].
Este artigo centra-se no sistema de indexação,
apresentando a arquitectura e os algoritmos implementados
colecções de documentos é um processo bem estudado e para a geração em paralelo de índices de larga escala sobre
relativamente simples. Contudo, a construção de um índice dados provenientes da Web. Na Secção II, referimos como são
distribuído para colecções Web de larga escala é uma tarefa implementados os algoritmos de indexação em arquitecturas
muito mais complexa. A Web continua a crescer e os motores centralizadas. Na Secção III, descrevemos a arquitectura e os
de pesquisa actuais apenas indexam uma pequena parte da algoritmos implementados no Sidra. Na Secção IV,
mesma. A Web profunda, ou seja, a parte da Web armazenada apresentamos os resultados dos ensaios realizados com a
em bases de dados disponíveis online, tem um tamanho indexação de uma colecção de documentos que representam a
estimado em 500 vezes superior à Web conhecida e continua Web portuguesa. A Secção V discute as razões para termos
por indexar [1]. optado por uma reconstrução total do índice em vez de
Existem três factores que tornam o desenvolvimento de suportar actualizações parciais, e a Secção VI apresenta as
técnicas para construir índices sobre colecções de larga escala conclusões.
um desafio. A rapidez da indexação é uma característica
desejada, porque os motores de pesquisa da Web costumam II. ALGORITMO DE INDEXAÇÃO CENTRALIZADO
ter prazos restritos para actualizar os seus índices depois de
Os índices de grandes colecções de documentos não podem
terminada uma recolha. O sistema tem de estar preparado para
crescer rápida e facilmente em resposta a variações bruscas no ser construídos em memória num único passo, devido ao seu
tamanho. Por isso, os dados para construção dos índices têm
crescimento de colecções Web com a adição de PCs baratos.
primeiro de ser partidos em partes menores que o tamanho da
Exigem-se técnicas especializadas para indexação eficiente,
memória disponível. Depois, cada parte é processada
ultrapassando as limitações resultantes da falta de memória e
independentemente. Uma análise extensiva efectuada por
armazenamento em disco para colecções desta magnitude.
Moffat, compara 10 algoritmos para construir ficheiros
invertidos [4]. Alguns são impraticáveis devido à enorme
Este trabalho foi parcialmente suportado pela FCT, projecto quantidade de memória de que necessitam, outros devido ao
POSI/SRI/4019/2001 e pela FCCN, Fundação para a Computação Científica tempo dispendido no processamento. Como muito do tempo é
Nacional de Portugal.
Miguel Costa é aluno de Mestrado do Departamento de Informática da
Faculdade de Ciências da Universidade de Lisboa, 1749-016 Lisboa, Portugal
(correio: mcosta@xldb.fc.ul.pt).
Mário J. Silva é professor do Departamento de Informática da Faculdade
de Ciências da Universidade de Lisboa, 1749-016 Lisboa, Portugal (correio:
mjs@di.fc.ul.pt).
2

Partição Local Partição Global

termos listas de postings termos listas de postings

computador
blue 2 5 11 blue 2 5 11 12 22

computador
dog 1 3 4 14 dog 1 3 4 14 27 32 40 41

sea 1

xldb 7 9

computador
blue 12 22 sea 1 10

computador
dog 27 32 40 41 xldb 7 9 25 45

sea 10

xldb 25 45

Fig. 1. Alternativas para particionamento de ficheiros invertidos.

gasto no acesso a sectores no disco, os algoritmos com acesso ficheiro invertido é comprimido para reduzir o
sequencial são os mais eficientes. Os índices são tipicamente tamanho de armazenamento e tempos de
construídos em 4 fases: transferência para disco.

1. Leitura e análise dos documentos. Cada termo III. ALGORITMO DE INDEXAÇÃO DISTRIBUÍDO DO SIDRA
(identificado como uma sequência de caracteres sem O Sidra suporta a geração de vários índices, organizados e
nenhum espaço em branco) é extraído e armazenado particionados por diferentes critérios, onde cada índice é
num ficheiro temporário com informação associada. usado para pesquisar sobre uma dimensão de dados. Cada
Cada termo é associado num triplo partição indexa um subconjunto de dados de uma dimensão.
<termo,docId,pos>, sendo docId o identificador do As partições podem ser locais (também conhecidas como
documento e pos a posição do termo no documento. verticais) ou globais (também conhecidas como horizontais).
Outra informação pode ser adicionada a cada triplo, A Figura 1 representa ambas as alternativas. Na partição local,
tal como as características da formatação visual do cada computador tem um índice invertido de um conjunto
termo no ficheiro. Cada um dos triplos no ficheiro disjunto de documentos da colecção. Cada partição do índice é
resultante é designado por hit. gerida por um QueryServer, responsável por achar nesta os
2. Geração de runs. Como os hits de uma colecção de identificadores dos documentos indexados que satisfazem as
larga escala não cabem todos em memória, recorre-se pesquisas. Um Broker faz uma fusão dos identificadores dos
a um algoritmo de ordenação externa para os ordenar documentos recebidos de cada QueryServer e os primeiros k
em blocos, procurando minimizar o custo de acessos são retornados ao utilizador. Na partição global, cada
a disco. Os hits são divididos em blocos de computador tem um ficheiro invertido com um conjunto
aproximadamente o tamanho da memória disponível. disjunto dos termos da colecção. Os Brokers pedem
Estes blocos são depois ordenados por termo, docId e repetidamente conjuntos de identificadores de documentos aos
pos, nesta ordem, usando um algoritmo de ordenação QueryServers que indexam os termos das pesquisas, e os
interna. Cada um dos blocos ordenados e fundem até os primeiros k identificadores serem obtidos.
armazenados em disco é chamado de run. O Os índices do Sidra estão fisicamente divididos com
resultado é um conjunto de runs. partição global por múltiplos QueryServers, permitindo
3. Junção de todos os runs. Esta é a fase da ordenação pesquisas rápidas sobre diferentes dimensões em paralelo
externa dos runs. Executa-se iterativamente a junção (paralelismo de partição). A escolha do esquema da partição
de pares de runs até restar apenas um único run com global em vez da local é fundamentada em estudos prévios
todos os hits ordenados. Isto pode ser conseguido que demonstraram que esta atinge melhores desempenhos para
com um programa de ordenação externo, tal como o larguras de banda acima dos 100 Mbps [5-7]. A explicação é
utilitário sort do sistema unix. que na partição local todos os computadores têm de responder
4. Construção de um ficheiro invertido. Corresponde ao a cada pesquisa, enquanto que na partição global apenas os
ficheiro indexado final. Os termos são as chaves e o computadores com os termos da pesquisa
valor de cada chave é uma lista de hits contendo o
termo. Para o criar, os hits são lidos sequencialmente
do run produzido na fase prévia. Normalmente, o
3

Repositório de Dados + Metadados

Shredder Shredder Shredder

network

RunsGenerator RunsGenerator

runs runs

RunsMerger RunsMerger

run run
global global

IBuild
IBuild IBuild
IBuild IBuild
IBuild IBuild
IBuild
IBuild IBuild IBuild IBuild

A-M A-M N-Z N-Z


localizações termos termos localizações

partição do índice organizada partição do índice organizada


por termos de localizações por termos
Fig. 2. Arquitectura distribuída do Sidra para criar índices.

indexados respondem. (Portable Document Format), XML e outros [8].


Para melhorar a escalabilidade da criação dos índices de No Sidra, os hits extraídos não são armazenados
grandes colecções da Web, desenvolvemos uma variante localmente em disco. Em vez disso, os hits são enviados
distribuída e paralela do algoritmo típico de indexação directamente para processos remotos chamados
centralizado apresentado na secção anterior. O algoritmo foi RunsGenerators, que os acumulam para posteriormente se
desenhado para funcionar em clusters de computadores criarem partições do índice. Desta forma, eliminamos as
partilhando entre si apenas a rede de comunicação. A Figura 2 operações de escrita e leitura de hits nos discos onde se
representa a arquitectura do sistema de geração de índices do executam os Shredders. Cada RunsGenerator recebe os hits
Sidra. Os documentos indexados têm de ser previamente atribuidos à sua partição de todos os Shredders. De sequida,
recolhidos da Web e armazenados num repositório Web. A ordena estes hits com o algoritmo de ordenação interna
indexação inicia-se quando a recolha está totalmente quicksort, e armazena-os num run. Para evitar o
arquivada. O resto desta secção descreve cada uma das fases congestionamento da rede, os Shredders enviam pequenas
do algoritmo de indexação distribuído. mensagens contendo hits, em vez de grandes mensagens de
cada vez que um tampão com hits se enche. Contudo, estas
A. Geração de Runs
mensagens têm de ser suficientemente grandes para evitar
Um programa multi-threaded, o Shredder (triturador), faz a sobrecarga de mensagens na rede. Esta técnica, proposta por
análise dos documentos e metadados associados que são Ribeiro-Neto et al., foi aplicada no algoritmo RR [9].
extraídos do repositório Web e extraem destes os hits. Em No Sidra, combinámos a técnica RR com a técnica
cada computador podem em geral correr vários Shredders. O apresentada por Melnik et al., baseada em pipelines de
número e capacidade dos computadores são definidos com software [10]. A criação do run é particionada em três fases
base no tempo que pode ser gasto no processamento dos distintas: leitura, processamento e escrita. Durante a fase de
dados a indexar. A análise de documentos Web é uma tarefa leitura, um número de documentos é transferido pela rede para
complexa. O programa analisador tem de ser robusto e memória. Na fase de processamento, os hits são extraídos e
tolerante a todos os tipos de erros em vários tipos de ordenados, usando principalmente CPU. Na fase de escrita, os
documentos da Web. O Sidra incorpora um analisador de runs são armazenados em disco. Estas três fases
dados Web, WebCAT, também desenvolvido para o tumba!,
que processa uma larga variedade de formatos de documentos
Web, tais como HTML, formatos do MS Office, PDF
4

são executadas em pipeline e iterativamente até não armazenar ficheiros invertidos [14-16]. Isto permite um
restarem mais documentos para processar. Como cada uma desenvolvimento mais rápido, já que estes oferecem
destas três fases usa recursos diferentes, é conseguida uma suporte de transacções e existem ferramentas para
boa concorrência através da sua paralelização. Existe uma visualizar e actualizar os dados facilmente. Contudo, os
concorrência óptima quando todos os recursos são usados SGBDs não permitem grande controlo sobre as estruturas
simultaneamente. de dados e partes centrais do processamento das consultas,
fundamentais num sistema de alto desempenho. Por isso,
B. Junção de Runs
para gerir e armazenar índices, o Sidra usa as tabelas de
No fim da primeira fase, cada RunsGenerator recebeu os dispersão do BerkeleyDB, uma biblioteca de programas
hits necessários para criar uma partição do índice. Os hits para gestão de dados que oferece serviços escaláveis de
estão organizados e ordenados num conjunto de ficheiros, acesso concorrente e um elevado desempenho no acesso a
os runs. Na segunda fase, o programa RunsMerger faz a dados através de uma API [17]. O BerkeleyDB oferece
junção de conjuntos de runs iterativamente, até restar um uma panóplia de funcionalidades que reduzem o tempo e a
único ficheiro com a lista de hits ordenados. complexidade de um sistema como este, mas que ao mesmo
Implementámos vários algoritmos de junção para tempo, permitem optimizar as partes centrais do
identificar quais ofereciam os melhores tempos de resposta. processamento e armazenamento. O Sidra usa tabelas de
Escolhemos o algoritmo multiway merge sort com uma dispersão porque este é o método mais rápido de aceder às
técnica de replacement selection usando uma heap [11]. O listas de postings. Existe uma pequena probabilidade de
algoritmo faz também uso da técnica de double buffering, colisão com a função de dispersão FNV implementada (ver
usada em sistemas de gestão de bases de dados (SGBDs) http://www.isthe.com/chongo/tech/comp/fnv/), mas que é
para manter o CPU activo durante pedidos de transferência tolerável para um sistema desta natureza.
de dados [12]. A técnica de double buffering requer, para
cada run, dois tampões do mesmo tamanho. Enquanto que IV. RESULTADOS
uma thread processa os hits de um tampão, uma outra
Nesta secção, apresentamos o desempenho e a
enche o outro tampão em paralelo com hits lidos do run.
escalabilidade obtida com o Sidra na indexação de uma
Quando termina o processamento dos hits de um tampão, a
colecção de documentos da Web portuguesa. Este artigo
thread inicia o processamento sobre o outro. Desta forma,
incide na análise na criação das partições do índice de
os tempos inactivos de CPU originados por operações de
termos. Devido à grande quantidade de dados que é
escrita e leitura são eliminados. A mesma técnica é
necessário processar, esta é a tarefa de computação mais
aplicada para a saída dos dados.
intensiva na fase de criação das estruturas de dados.
C. Construção de Ficheiros Invertidos
A. Ambiente de Ensaio
No começo desta fase, todos os hits de cada partição
Os ensaios foram executados num cluster de 4
estão ordenados num único run. A criação de um ficheiro
computadores com o sistema operativo Linux RedHat 9
invertido é agora um processo simples. Um programa de
com o kernel 2.4.20, interligados por uma rede ethernet de
construção de índices (IBuild) lê os hits sequencialmente e
100 Mbps. Cada computador tem um processador Intel a
cria uma lista de postings (localizações) para cada termo.
2.4 GHz, 1 GB de RAM e dois discos com dados
O Sidra usa diferentes tipos de índices para pesquisar
replicados em espelho. Cada disco tem uma velocidade de
documentos por diferentes dimensões. Outras aplicações
rotação de 7200rpm, um tempo de acesso médio de 8,5
Ibuild lêem em paralelo os metadados associados aos
milisegundos, e uma média de transferência de 699
documentos do repositório Web, e criam partições de
Mbits/sec.
ficheiros invertidos sobre outras dimensões de indexação.
A colecção usada é composta por 3.235.140 documentos
Na Figura 2, mostramos dois índices particionados. Um é o
Web de diferentes tipos MIME, com 78,4 Gigabytes de
usual índice de termos. O outro é um índice geográfico
dados (ver [18], para uma caracterização detalhada desta
indicando os documentos associados a termos,
colecção).
representando localizações compostas por metadados do
Durante a primeira fase da criação do índice, a
repositório Web.
configuração usada nos ensaios tinha um Shredder e um
No Sidra, as listas de postings são comprimidas com o
RunsGenerator por computador. As fases seguintes
algoritmo Binary Interpolative Coding, um algoritmo de
executam-se de forma independente em cada um dos
compressão de listas de postings optimizado para
computadores utilizados.
minimizar requisitos de armazenamento e latência de
operações de entrada/saída de dados [13]. Escolhemos este
algoritmo porque oferece a melhor compressão e é um dos
mais rápidos. Depois de comprimidas, as listas de postings
são armazenadas em disco e ficam disponíveis para
suportar consultas (ver [2]).
Alguns sistemas de indexação usam SGBDs para
5

60 60
55 55
50 50
45 45
To tal 40 To tal
40

tempo (horas)
tempo (horas)

35 Geração de Runs 35 Geração de Runs

30 30
Co nstrução de Co nstrução de
25 Ficheiro s Invertido s 25 Ficheiro s Invertido s
Junção de Runs Junção de Runs
20 20
15 15

10 10

5 5

0 0
1 2 4 1 2 4

computadores computadores

(a) speedup (b) scaleup


Fig. 3. Tempos para indexar a Web portuguesa variando (a) o número de computadores, e (b) o número de computadores
e o tamanho da colecção a mesma ordem de vezes.

Ribeiro-Neto et al. desenvolveram três algoritmos


B. Testes e Análise
distribuídos para construir ficheiros invertidos
O Sidra indexou a nossa colecção da Web portuguesa particionados [19]. O que apresenta os melhores resultados
em 55,41 horas com apenas um computador. Deste tempo, é o algoritmo RR, parcialmente descrito na Secção III.
20,2 horas foram gastas na transferência e descompressão Depois de os computadores receberem os hits, executam
(com o software zlib) dos documentos do repositório Web. várias vezes o algoritmo multiway merge para produzir o
Também indexámos a mesma colecção com 2 e 4 run global, e depois constroem um ficheiro invertido a
computadores. O tempo decresceu para 30,19 e 15,19 partir deste. Usando 8 computadores ligados por uma rede
horas, respectivamente (ver Figura 3(a)). Estes tempos a 80 Mbps, o algortimo RR construiu um ficheiro invertido
mostram que o aumento da velocidade de processamento sobre 100 Gigabytes da colecção de texto do TREC-7 em
(speedup) acompanha o do número de computadores, em 12 horas. Com o dobro dos computadores, construiu o
todas as fases de processamento. Isto significa que com p índice em metade do tempo, demonstrando um speedup
vezes mais computadores, o tempo de indexação desce para linear perfeito.
1/p do total, o que é essencial para produzir rapidamente Apenas alguns artigos descrevem a indexação de
índices com informação mais actualizada. colecções Web de larga escala, e todos o fazem usando
Também indexámos a mesma colecção replicada nos esquemas de partição local. Esta alternativa é mais simples
computadores, simulando colecções 2 e 4 vezes maiores. do que criar índices com partição global, porque depois de
Os tempos foram quase constantes, variando entre 55,41 distribuir os documentos pelos computadores, não é
horas, quando a colecção foi indexada com um necessário trocar mais dados, excepto se forem necessárias
computador, e 56,38 horas para indexar uma colecção 4 estatísticas globais para a ordenação dos resultados (como
vezes maior usando 4 vezes mais computadores (ver Figura por exemplo, a frequência inversa dos documentos). O
3(b)). O Sidra não mostra degradação do desempenho com sistema inicial do Google construía um índice sobre 147,8
o aumento da escala do sistema (scaleup). Isto significa GB de dados de uma recolha de 24 milhões de documentos
que, com p vezes mais computadores, o Sidra consegue Web, a uma velocidade de 54 páginas por segundo [20].
indexar uma colecção p vezes maior no mesmo espaço de Isto totaliza 123,4 horas. A transformação deste índice num
tempo. ficheiro invertido demora 24 horas adicionais utilizando 4
C. Comparação de Resultados computadores. Assumimos que o mesmo número de
A Tabela 1 apresenta valores de desempenho computadores foi usado para todo o processo.
comparativos entre o Sidra e outros sistemas com O CobWeb é o sistema de indexação e processamento de
funcionalidades similares e resultados publicados. Todos consultas do Internet Archive [21]. A sua arquitectura não
estes sistemas têm diferentes objectivos e funcionalidades. está publicada, mas são publicados alguns resultados sobre
Alguns indexam apenas texto, enquanto outros fazem o seu desempenho numa apresentação no seu Web site. O
análise de documentos da Web. Alguns descomprimem os CobWeb indexa mais de 11 mil milhões de páginas (0,5 PB
documentos antes de os indexar, outros não. Os resultados de dados) do Internet Archive, a maior colecção de páginas
foram obtidos com configurações de hardware distintas. Web conhecida. Num cluster de 312 computadores com
Contudo, apesar das diferenças, estes dados de desempenho 512 MB de memória e 500 GB de disco cada, este sistema
podem ser usados como um ponto de partida para uma tem uma velocidade de indexação de 75 páginas
comparação.
TABELA I
6

SISTEMAS DISTRIBUÍDOS PARA CONSTRUÇÃO DE FICHEIROS INVERTIDOS


CPU Colecção Índice Tempo Velocidade
Sistema
# tamanho(GB) tipo descomprimir partição comprimido (horas) 1 2
Sidra 4 313,6 web sim global sim 56,38 1.39 16.2
RR 16 100 textual ? global sim 6 1.04 ?
Google 4 147,8 web sim local sim 147,4 0.25 13.5
CobWeb 312 500 000 web ? ? ? 130,6 12.27 75
COLECÇÃO DESCOMPRIMIR INDICA SE A COLECÇÃO DEVE SER DESCOMPRIMIDA ANTES DE SER INDEXADA. ÍNDICE COMPRIMIDO INDICA SE O FICHEIRO
INVERTIDO É COMPRIMIDO. VELOCIDADE 1 É A MEDIDA DO NÚMERO DE GIGABYTES INDEXADOS POR CPU EM UMA HORA. VELOCIDADE 2 É A MEDIDA DO
NÚMERO DE DOCUMENTOS INDEXADOS POR CPU EM UM SEGUNDO.

por computador por segundo, totalizando um tempo de adicionar novos postings no futuro [24,25]. Isto
indexação de 130,6 horas. O índice tem 2 terabytes e cresce causa também a degradação do desempenho das
sub-linearmente. A Tabela 1 mostra que o Sidra tem pesquisas, porque actualizações parciais dos
resultados de desempenho comparáveis a outros sistemas, índices ligam listas de postings existentes com
quando o tamanho da colecção indexada é na ordem dos novas listas em diferentes blocos do disco. Como
100-300 GB e o número de processadores é até 16. O as listas de postings não são contínuas no disco, as
CobWeb opera numa dimensão completamente diferente: operações de leitura/escrita e, consequentemente,
uma ordem de grandeza acima no número de o tempo total de criação dos índices aumentam.
processadores, uma colecção de três ordens de grandeza 3. Para uma actualização eficiente, é necessário um
superior em tamanho, e uma velocidade de indexação mais índice forward da colecção. Este tem
rápida numa ordem de grandeza. Contudo, os algoritmos e sensivelmente o mesmo tamanho que o ficheiro
a arquitectura de software deste sistema de indexação não invertido.
estão publicamente documentados. 4. Além de tudo isto e ao contrário do esperado, Cho
O Sidra apresenta características de speedup e scaleup e Garcia-Molina demonstraram que, para recolhas
que permitem construir índices para colecções Web de de documentos feitas periodicamente em cada
larga escala tão depressa quanto necessário, apenas sendo mês, as actualizações parciais oferecem índices
necessário adicionar mais computadores ao seu com informação igualmente recente, em relação à
processamento. Isto motiva a discussão seguinte sobre a média dos índices completamente reconstruídos
necessidade de suporte de actualizações aos índices de [22].
motores de pesquisa da Web. A partir dos resultados dos estudos apresentados e do
desempenho observado pelo Sidra, não parece vantajoso
V. ACTUALIZAÇÕES DOS ÍNDICES suportar actualizações parciais de índices. O Sidra permite
Como os conteúdos da Web mudam continuamente, a rápida criação de índices para colecções específicas que
existe a necessidade de actualizar os índices dos motores de possuam documentos alterados com uma maior frequência.
pesquisa da Web frequentemente. Cho e Garcia-Molina O Sidra consegue suportar pesquisas para múltiplas
analisaram a evolução da Web durante 4 meses e colecções nos mesmos computadores. Esta funcionalidade
descobriram que 23% dos documentos mudam todos os permite ao tumba! oferecer índices especializados. Este é
dias, 15% mudam entre um dia e uma semana, e 16% entre também o caminho seguido por alguns motores de pesquisa
uma semana e um mês [22]. Fetterly et al. aprofundaram da Web. O Google, por exemplo, recolhe e indexa de novo
este trabalho e apresentaram resultados obtidos a partir da cerca de 8 mil milhões de páginas em cerca de um mês (ver
análise de um período de onze semanas [23]. Durante este http://www.google.com/webmasters/2.html), e oferece um
tempo, 34,8% dos documentos sofreram alguma alteração, índice especializado para notícias, actualizado diariamente
mas o texto apenas mudou em 10% dos documentos. Dadas (ver http://news.google.com). No Sidra, planeamos também
estas condições, parecem existir vantagens em um sistema implementar em trabalho futuro um mecanismo para
de indexação suportar actualizações parciais aos índices, pesquisar em paralelo índices criados com periodicidades
em vez de apenas a sua reconstrução total. diferentes. No processamento das consultas, apenas se
Contudo, o suporte de actualizações parciais não está ordenarão na geração de resultados das pesquisas as
isento de problemas: versões mais recentes dos documentos.
1. A complexidade de um sistema de indexação
cresce, já que os índices têm de responder a VI. CONCLUSÃO
pesquisas, enquanto são actualizados com novas As colecções de documentos Web estão a crescer a um
versões de documentos simultaneamente. ritmo rápido. Os sistemas de indexação, que são parte
2. O tamanho dos índices cresce devido à fulcral dos sistemas de pesquisa da Web, necessitam de
fragmentação interna nas listas de postings. A uma arquitectura e algoritmos eficientes com características
maior parte das técnicas para actualizar índices de escalabilidade para continuar a suportar este
reserva espaço apriori nas listas de postings para crescimento. O Sidra é um novo sistema de indexação e
7

ranking para colecções Web de larga escala, permitindo a in Proc of the 18th International conf. of the Chilean Computer
Science Society, 1998.
criação de vários índices usados para contextualizar [20] S. Brin, L. Page, “The anatomy of a large-scale hypertextual Web
pesquisas em diferentes dimensões de dados. search engine”, Computer Networks and ISDN Systems, vol 30, pp.
O Sidra distribui os índices recorrendo a um esquema 107-117, 1998.
[21] A. Patterson, “Cobweb search”, Available from
de particionamento global, o que apresenta os melhores
http://ia00406.archive.org/cobwebsearch.ppt.
resultados de desempenho para processamento de [22] J. Cho, H. Garcia-Molina, “The evolution of the Web and
pesquisas. O Sidra combina vários algoritmos e técnicas implications for an incremental crawler”, in Proc. of the 26th
aplicadas em sistemas tradicionais de recuperação de International Conf. on Very Large Databases, pp. 200-209, 2000.
[23] D. Fetterly, M. Manasse, M. Najork, J. L. Wiener, “ A large-scale
informação, bases de dados e motores de pesquisa da Web, study of the evolution of Web pages”, in Proc. of the 12th
para produzir um sistema de alto desempenho, capaz de International World Wide Web Conf., WWW2003, pp. 669-678,
escalar a criação de índices para colecções de documentos 2003.
[24] E. W. Brown, J. P. Callan, W. B. Croft, “Fast incremental indexing
Web de larga escala. Estas propriedades foram validadas for full-text information retrieval”, in Proc. of the 20th International
com a indexação da Web portuguesa pelo Sidra enquanto Conference on Very Large Databases, pp. 192-202, 1994.
componente do motor de pesquisa tumba!. [25] A. Tomasic, H. Garcia-Molina, K. A. Shoens, “Incremental updates
of inverted lists for text document retrieval”, in Proc. of the 1994
ACM SIGMOD International Conf. On Management of Data, pp.
VII. REFERÊNCIAS 289-300, 1994.
[1] M. K. Bergman, "The deep Web: surfacing hidden value”, The
Journal of Electronic Publishing from the University of Michigan,
vol. 7, 2001.
[2] M. Costa, M. J. Silva, "Sidra: a flexible distributed indexing and
ranking architecture for Web search”, in Proc. of the Jornadas de
Ingeniería del Software y Bases de Datos JISBD, 2003.
[3] M. J. Silva, “The case for a Portuguese Web search engine”, in Proc.
of the IADIS WWW/Internet 2003 Conf., 2003.
[4] A. Moffat, “Resource-limited index construction for large texts”, in
Proc. of the 17th Australian Computer Science Conf., pp. 169-178,
1994.
[5] A. Tomasic, H. Garcia-Molina, “Performance of inverted indexes in
distributed text document retrieval systems”, in Proc. of the 2nd
International Conf. on Parallel and Distributed Information Systems,
pp. 8-17, 1993.
[6] B. S. Jeong e E. Omiecinski, “Inverted file partitioning schemes in
multiple disk systems”, IEEE Transactions on Parallel and
Distributed Systems, vol 6, pp. 142-153, 1995.
[7] B. Ribeiro-Neto e R. A. Barbosa, “Query performance for tightly
coupled distributed digital libraries”, in Proc. of the 3rd ACM Conf.
on Digital Libraries, pp. 182-190, 1998.
[8] B. Martins, M. J. Silva, “WebCAT: A Web contents analysis tool for
IR applications”, 2004.
[9] B. Ribeiro-Neto, E. S. Moura, M. S. Neubert, N. Ziviani, “Efficient
distributed algorithms to build inverted files”, in Proc. of the 22th
International ACM SIGIR Conf. on Research and Development in
Information Retrieval, pp. 105-112, 1999.
[10] S. Melnik, S. Raghavan, B. Yang, H. Garcia-Molina, “Building a
distributed full-text index for the Web”, in Proc. of the 10th
International World Wide Web Conf., pp 396-406, 2001.
[11] R. Sedgewick, Algorithms in C, Addison Wesley, 1990.
[12] R. Ramakrishnan, Database Management Systems, McGraw-Hill
Computer Science Series, 1998.
[13] A. Moffat, L. Stuiver, “Binary interpolative coding for effective
index compression”, Information Retrieval, vol. 3, pp. 25-47, 2000.
[14] E. W. Brown, J. P. Callan, W. B. Croft, J. E. B. Moss, “Supporting
full-text information retrieval with a persistent object store”, in Proc.
of the 4th International Conf. on Extending Database Technology,
pp. 365-378, 1994.
[15] O. Frieder, A. Chowdhury, D. Grossman, M. C. McCabe, “On the
integration of structured data and text: a review of the SIRE
architecture”, in DELOS Workshop on Information Seeking,
Searching and Querying in Digital Libraries, 2000.
[16] T. Grabs, K. Böhm, H.J. Schek, “PowerDB-IR: information retrieval
on top of a cluster of databases”, in Proc. of the 10th International
Conf. on Information and Knowledge Management, 2001.
[17] M. Olson, K. Bostic, M. Seltzer, “Berkeley DB”, in Proc. of
USENIX Technical Conf., FREENIX Track, 1999.
[18] D. Gomes, M. J. Silva, “A characterization of the Portuguese Web”,
in Proc. of the 3rd ECDL Workshop on Web Archives, 2003.
[19] B. Ribeiro-Neto, J.P. Kitajima, G. Navarro, C. Sant’Ana, N. Ziviani,
“Parallel generation of inverted files for distributed text collections”,