Por que eu devo ler este artigo:A busca da informação em ambientes web tem se tornado um serviço cada vez mais essencial nos diferentes contextos. Logo, conhecer soluções livres que facilitem a viabilização deste tipo de demanda constitui um diferencial especialmente em ambientes onde a informação agrega valor estratégico.

A web vem se consolidando como a principal fonte de informações para um público cada vez maior e mais heterogêneo. Fatores como o volume de informações disponível e a facilidade de acesso a elas têm se mostrado preponderantes na escolha desse mecanismo de divulgação e recuperação da informação. Nesse contexto, serão apresentadas duas ferramentas para construção de uma infraestrutura de busca na web: Nutch e Solr. A integração de ambos possibilita que uma máquina de busca possa ser implementada de maneira simples em ambientes de Intranet ou mesmo sobre a própria Internet.

Com o advento da Internet, a busca pela informação na web tem se tornado cada vez mais ampla e popular. Uma evidência disso é apontada por Manning et al [14] ao descrever uma mudança de cultura no âmbito da busca pela informação. Segundo Manning, estudos realizados na década de 90 indicavam que a maior parte das pessoas preferia buscar informações por meio de outras pessoas em lugar de recorrer a sistemas de recuperação da informação. Em 2004, porém, outro estudo (Pew Internet Survey) mostrou que 92% dos usuários de Internet encaravam a própria Internet como um bom lugar para se buscar diariamente informação.


Guia do artigo:


Apesar dessa significativa ascensão no uso da Internet, a busca da informação nesse espaço tende a constituir uma atividade ineficiente e/ou ineficaz. Essa tendência deve-se a fatores que se consolidaram como inerentes ao contexto web [1]:

  • Volume e diversidade de informações disponíveis;
  • Espontaneidade e velocidade com que os conteúdos se constroem na Rede sem uma instância reguladora para dirigi-la ou ordená-la;
  • “Descentralidade” na publicação, variedade de autores, idiomas, interesses e usos da informação;
  • Grau de volatilidade das informações disponibilizadas.

A título de exemplo das dimensões envolvidas nesse universo de informação digital, Jian et al [11] faz referência a The Internet Archive [2] – uma coleção de páginas web existente desde 1996. Até Outubro de 2003, esse sítio abarcava aproximadamente 300 terabytes de dados, e vinha apresentando uma taxa de crescimento de 12 terabytes/mês.

Nesse cenário, portanto, passa a residir um dos grandes desafios da área de recuperação da informação (RI): prover tecnologias de RI que sejam eficientes, escaláveis e confiáveis. De fato, conectar os usuários com o conteúdo de que precisam e quando precisam não é mais opcional. É uma necessidade que deve ser atendida através de interfaces e dos motores de busca que operam em sites e portais da internet. E essa necessidade se mostra ainda mais essencial diante da expectativa criada pelos próprios usuários, os quais esperam, cada vez mais, resultados de alta qualidade para uma busca, e interfaces que os ajudem a encontrar a informação que estão procurando de maneira precisa, rápida, fácil e organizada [13].

Assim, conforme Abdala et al [13], de posse dessa perspectiva de que não basta a informação estar disponível na Internet, mas que ela precisa ser identificada e buscada por diferentes interfaces e motores de busca, torna-se fundamental garantir que os conteúdos armazenados em sites web sejam indexados por portais buscadores e por serviços de informação.

Motores de Busca

As primeiras gerações de ferramentas de busca web tentaram simplesmente transferir as técnicas clássicas de recuperação de documentos para esse novo contexto, mudando apenas a escala de abrangência, a qualidade e a relevância dos resultados. No entanto, apresentaram significativas limitações quanto à categorização e classificação dos resultados das pesquisas. Embora essas técnicas de RI ainda continuem sendo necessárias no âmbito da web, elas já não são suficientes nessa rede de informações sem precedentes em escala, sem uma coordenação centralizada na sua criação, e com uma enorme diversidade de cenários e objetivos de seus usuários [14].

Nota: Os modelos clássicos (booleano, vetorial e probabilístico) utilizados no processo de recuperação da informação apresentam estratégias de busca baseadas na relevância de documentos para uma dada consulta (query) [15]. Estes modelos consideram que cada documento é representado por um conjunto de palavras-chave representativas, ou termos de indexação, que são consideradas como mutuamente independentes. Como um mesmo termo pode aparecer em diferentes documentos, é necessário distinguir a ocorrência de um termo Ki em um documento Dj da ocorrência deste mesmo termo em outro documento Dl. Para isso, a cada par termo-documento [Ki, Dj] associa-se um peso Wij. Este peso deve ser utilizado para refletir a importância do termo Ki no documento Dj.

De acordo com Branski et al [12], buscadores, ferramentas de busca ou mecanismos de busca são sistemas especializados utilizados na recuperação de informação na Internet e caracterizam-se, essencialmente, pelo funcionamento de seu motor de busca. De maneira geral, os componentes básicos de um sistema de busca web apresentam o seguinte fluxo de funcionamento:

  1. O motor de busca (Web crawler) rastreia a informação disponível na web, periodicamente, navegando de página em página, ou de site em site, extraindo os documentos, as palavras, os termos que melhor representam a informação capturada – Crawling;
  2. Todo o conteúdo extraído é indexado e armazenado em bases de dados – Indexing;
  3. Usuários utilizam a interface de busca para entrar com consultas;
  4. O sistema recupera os documentos que são relevantes e os disponibiliza para o usuário.

A Figura 1 dá uma visão geral dos diversos componentes que integram uma ferramenta busca (web search engine).

Componentes de uma web search engine
Figura 1. Componentes de uma web search engine

Fica evidente, portanto, que os buscadores funcionam na dependência de fontes de informação disponíveis na Internet, ou seja, informações não produzidas, geridas ou organizadas por eles. Nesse sentido, essas engines de busca passaram a assumir um papel imprescindível para o fluxo de acesso à informação e para a conquista de novos usuários e visitantes para os sites na Internet [13].

Diante disso, o exposto a seguir terá um viés de “guia passo-a-passo” para a instalação e configuração de duas soluções open source voltadas para buscas na web. Além disso, será descrito como a integração de ambas as soluções pode ser feita, a fim de fornecer dois dos componentes essenciais para qualquer motor de busca:

  • Web Crawler – será apresentado e configurado o Apache Nutch;
  • Plataforma de consultas – será utilizada outra solução Apache, o Solr.

Apache Nutch

Nutch é uma completa engine open source de busca web cujo objetivo é ser capaz de indexar a World Wide Web da mesma forma que serviços comerciais de busca, como Google, Yahoo, etc. Como plataforma de pesquisa, pode ser aplicado em escalas menores, e sua arquitetura flexível possibilita que seja adaptado até mesmo para uso sobre um único computador pessoal [16].

Nutch é dotado de uma arquitetura extremamente modular que usa APIs como plug-ins para executar tarefas como: parser de diferentes tipos de arquivos, análise de código HTML e recuperação de dados. De acordo com Khare et al [16], o core do Nutch é composto de quatro componentes principais: searcher, indexer, database e fetcher. Esses componentes são apresentados na Figura 2, a qual detalha a arquitetura geral do Nutch em conjunto com os componentes responsáveis pelo fluxo de execução do processo de crawler. Segue uma descrição sucinta dos elementos mais relevantes:

  1. Searcher: dada uma query, é capaz, de modo eficiente, de localizar subconjuntos de menor relevância dentro de uma inteira coleção de documentos e recuperá-los. Encontrar um subconjunto de maior relevância é uma tarefa normalmente executada por meio de inverted indexes do completo conjunto de documentos. Para isso, os documentos localizados são ordenados pelo critério de relevância e podem ser agrupados para fins de disponibilização ao usuário;
  2. Indexer: Cria inverted indexes a fim de otimizar a extração de informações via Searcher. O Nutch utiliza o mecanismo de armazenamento do Apache Lucene;
  3. Injector: Identifica a lista inicial de URLs (seed) a serem inspecionadas pelo crawler e a aloca no CrawlDB;
  4. Generator: Determina o conjunto de URLs a serem buscadas;
  5. Fetcher: Efetua o request e a extração de links das páginas web;
  6. Parser: Efetua o parser de cada página buscada para a identificação de outlinks;
  7. Database: Armazena os conteúdos dos documentos para fins de indexação e posterior sumarização por parte do Searcher. É subdividido em três partes:
  8. CrawlDB: Mantém informações de todas as URLs inspecionadas pelo crawler, por exemplo, metadados, assinaturas, status das páginas, horário/data de busca de cada página;
  9. LinkDB: Para cada URL, mantém informações referentes aos seus respectivos links de entrada (inlinks) e âncoras associadas (selflinks);
  10. Segments: Armazena o conteúdo original de cada página, juntamente com novos conteúdos e metadados que são descobertos pós-parser. Nessa mesma base são mantidos ainda os links de saída (outlinks) e o conteúdo textual (sem código HTML) extraído de cada página (para fins de indexação e extração de fragmentos).
Nota: Inverted Index: É um mecanismo usado para indexar coleções textuais ao nível de palavras. É a estrutura mais utilizada em sistemas de RI por ser a forma mais intuitiva de modelar e estruturar o acesso aos dados. Sua função principal é retornar a lista de documentos onde ocorre um termo, tendo como ideia básica o armazenamento do mapeamento inverso de termos para documentos. A estrutura de inverted index é composta por dois elementos: o vocabulário e a lista invertida, como ilustrado na Figura 3. O vocabulário contém o conjunto de todas as palavras distintas que aparecem no conjunto de documentos. A lista invertida contém a relação de documentos onde cada palavra aparece. A informação presente em cada lista invertida são apontadores para os documentos nos quais a palavra-chave ocorre e, geralmente, são adicionadas outras informações que podem ser úteis durante o processamento de uma consulta. Um exemplo de informação que poderia ser adicionada é a lista de posições de cada palavra. Esta lista seria utilizada, por exemplo, para tornar possível o processamento de consultas por frases exatas ou consultas por proximidade [3].

Apache Lucene: É uma biblioteca de alto desempenho, escrita inteiramente em Java, que disponibiliza todos os recursos necessários para a implementação de buscas textuais [4]. O Apache Nutch tem suas origens no projeto Lucene.

Nota: Os links funcionam como conectores entre os diferentes nós na Web, entendendo por nó qualquer unidade de informação como as páginas web, os diretórios, os sítios e os domínios. É possível classificar os links em diferentes tipos, de acordo com a direção que eles assumem e com a função que exercem na Web. A classificação adotada neste artigo é a descrita em [18]. Inlinks são aqueles links recebidos por um nó dentro da Web, enquanto os outlinks são aqueles que apontam para outras páginas. Já os selflinks correspondem aos links que apontam para o próprio nó de origem.
Arquitetura de Funcionamento do Nutch
Figura 2. Arquitetura de Funcionamento do Nutch
Exemplo de Inverted Index
Figura 3. Exemplo de Inverted Index

Diante do exposto, pode-se explicitar o fluxo básico de execução do Nutch conforme o pseudocódigo da Listagem 1. Observe que é preciso definir o número de repetições (variável LOOP) do processo.

1.    Injetar URLs iniciais.
2.    Executar os próximos passos LOOP vezes
2.1. Gerar lista de URLs.
2.2. Buscar conteúdo das páginas.
2.3. Efetuar o parser do conteúdo de cada página.
2.4. Atualizar CrawlDB.
2.5. Atualizar LinkDB.
2.6. Indexar segmentos.
   
Listagem 1. Algoritmo do fluxo básico de execução do Nutch

Instalação e Configuração

Nesse artigo será utilizada a versão 1.4 do Apache Nutch, a qual pode ser baixada através de qualquer mirror dentre os listados no link [5]. Após a descompactação do arquivo, todo o trabalho a ser desenvolvido se dará sobre o subdiretório /runtime/local, o qual será referenciado, neste artigo, simplesmente por NUTCH_HOME. Essencialmente, todas as configurações do Nutch são efetuadas através dos arquivos presentes no diretório NUTCH_HOME/conf. Além das configurações, será necessário a execução de comandos a fim de acionar cada etapa do processo de crawler. Esses comandos estão disponíveis no script nutch do diretório NUTCH_HOME/bin.

Para exemplificar a configuração e utilização do Apache Nutch, será adotado o web site http://www.ascii-code.com/ [6] como alvo do processo de crawler. Ao término desse processo, o conteúdo disponibilizado no site poderá ser consultado através da interface de consulta da aplicação Localiza. Seguindo o algoritmo descrito na Listagem 1, para que o processo tenha início é necessário a definição das URLs que indicarão o alvo de ação do crawler.

Para fins de organização da estrutura de diretórios do Nutch, será criado o diretório NUTCH_HOME/urls. A este diretório será adicionado um arquivo – seed.txt – no qual as URLs iniciais serão indicadas. A estrutura de subdiretórios do NUTCH_HOME após a criação do diretório urls e inclusão do arquivo seed.txt é apresentada na Listagem 2. A Listagem 3 exibe o conteúdo do arquivo seed.txt.

É importante ressaltar que o conteúdo deste arquivo contém apenas uma URL, já que será utilizada apenas esta única no processo de crawler descrito neste artigo. Porém, podem ser adicionadas quantas URLs forem de interesse. Neste caso, cada URL será informada em uma linha do arquivo seed.txt, e estas indicarão o respectivo web site a ter suas informações disponibilizadas para consultas via interface de busca.

/home/dem/apache-nutch-1.4-bin/runtime/local
 |- bin
 |--- nutch
 |- conf
 |--- regex-urlfilter.txt
 |--- nutch-site.xml
 |--- nutch-default.xml
 |- lib
 |- plugins
 |- test
 |- urls
 |--- seed.txt
Listagem 2. Estrutura inicial de diretórios do NUTCH_HOME com alguns dos principais arquivos
http://www.ascii-code.com/
Listagem 3. Conteúdo do arquivo seed.txt de URLs inicias

Na sequência do algoritmo da Listagem 1, ao executar o processo de crawler o Nutch gerará a lista de URLs a ter o seu conteúdo indexado. Esta lista é gerada a partir das URLs iniciais informadas no arquivo seed.txt. Assim, para cada URL inicial, o Nutch fará uma varredura em busca de links para outras páginas e, para cada link encontrado, ele recuperará o conteúdo da página correspondente e executará recursivamente a mesma varredura em busca de novos links para outras páginas. Se não controlado, esse processo iterativo e incremental tende a se estender por toda a web. A Figura 4 retrata o estado do processo de crawler após sua primeira iteração. Observe que, se limites não forem impostos ao processo, por meio dos links encontrados no conteúdo das URLs iniciais o processo tende a se dispersar para qualquer web site além do domínio de busca.

Fica evidente, dessa forma, a necessidade de se indicar fronteiras as quais o crawler deve obedecer. Portanto, é preciso estabelecer um critério de decisão por meio do qual o crawler tenha condições de decidir se, dada uma URL encontrada, ele deve ou não inspecionar seu conteúdo, tanto para fins de indexação quanto para localização de novos links. O estabelecimento desse critério, ou fronteiras para o processo de crawler, é representado na Figura 5, que apresenta o estado do processo após três iterações.

A implementação dessas fronteiras é efetuada por meio do arquivo regex-urlfilter.txt, presente no diretório NUTCH_HOME/conf. Este arquivo utiliza o mecanismo de expressões regulares para definir quais URLs serão ou não inspecionadas pelo crawler.

Primeira iteração do processo de crawler
Figura 4. Primeira iteração do processo de crawler
Processo de crawler após três iterações
Figura 5. Processo de crawler após três iterações

A Listagem 4 apresenta o conteúdo do arquivo regex-urlfilter.txt (editado em relação ao original) estabelecendo os critérios que devem ser seguidos. Cada critério, informado em uma única linha, define que tipo de URL o crawler deve ou não considerar durante o processo de inspeção. Cada linha deve iniciar com um símbolo de inclusão (+) ou exclusão (-) determinando se a expressão regular indica um tipo de URL que deve ser inspecionada (inclusão) ou desconsiderada (exclusão) durante a varredura.

No caso da Listagem 4, a primeira linha expressa um critério de exclusão e a expressão regular define um padrão de URL que se inicie com algum dos seguintes termos: file, ftp, mailto. Em outras palavras, esse primeiro critério determina que o crawler, durante o processo de varredura, deve ignorar qualquer URL que faça referência a algum dos protocolos expressos pelos termos acima citados. De forma análoga, a segunda linha do arquivo – segundo critério – define que devem ser desconsideradas quaisquer URLs que terminem com um “.” (ponto) seguido de alguma das extensões indicadas entre parênteses. Neste caso, imagens, arquivos de CSS e JavaScript, por exemplo, serão todos ignorados pelo processo de crawler. A última linha do arquivo, por outro lado, estabelece um critério de inclusão, ou seja, todas as URLs cujos primeiros caracteres corresponderem ao padrão http://www.ascii-code.com/ devem ser incluídas no processo de varredura. Assim, todos os links que forem compostos por este prefixo terão o seu conteúdo inspecionado e indexado pelo crawler; logo estes conteúdos poderão ser recuperados pela ferramenta de busca.

  -^(file|ftp|mailto):
   
  -\.(gif|GIF|jpg|JPG|png|PNG|ico|ICO|css|CSS|sit|SIT|eps|EPS|wmf|WMF|zip|ZIP
  |ppt|PPT|mpg|MPG  |xls|XLS|gz|GZ|rpm|RPM|tgz|TGZ|mov|MOV|exe|EXE|jpeg|JPEG
  |bmp|BMP|js|JS)$
   
  +^http://www.ascii-code.com/
Listagem 4. Conteúdo do arquivo regex-urlfilter.txt com fronteiras apenas para

Com as configurações apresentadas na Listagem 4 e tendo como ponto de partida a URL do arquivo seed.txt, descrito na Listagem 3, o processo de crawler executará a inspeção do conteúdo das seguintes URLs:

  1. http://www.ascii-code.com/;
  2. http://www.ascii-code.com/html-symbol.php;
  3. http://www.ascii-code.com/html-color-names.php;
  4. http://www.ascii-code.com/http-status-codes.php.

Pode-se perceber, dessa forma, que todos os demais links presentes no corpo dessas páginas serão desconsiderados pelo Nutch. Este é o caso, por exemplo, dos links presentes na seção “HTML color links” da página referenciada pela quarta URL acima listada. A Figura 6 exibe o conteúdo dessa seção que terá as seguintes URLs excluídas do processo de crawler:

  1. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html;
  2. http://en.wikipedia.org/wiki/List_of_HTTP_status_codes;
  3. http://en.wikipedia.org/wiki/WebDAV.

Para fins de melhor detalhar o funcionamento da varredura do crawler, serão efetuadas algumas alterações no arquivo regex-urlfitler.txt. Primeiramente, será permitido ao Nutch efetuar a inspeção do conteúdo da URL que aponta para a página que contém as definições dos códigos de estado do protocolo HTTP/1.1 – link 3 listado acima. Em seguida, para demonstrar a execução do processo de crawler sobre arquivos recuperados a partir de requisições HTTP, as fronteiras de execução do Nutch receberão duas novas modificações a fim de que passem a abarcar também o arquivo texto que descreve o protocolo HTTP 1.1. A Figura 7 exibe o fluxo de inspeção do Nutch sobre este conjunto de páginas. A Listagem 5 apresenta o arquivo regex-urlfilter.txt com as modificações para possibilitar o novo fluxo do crawler.

  -^(file|ftp|mailto):
   
  -\.(gif|GIF|jpg|JPG|png|PNG|ico|ICO|css|CSS|sit|SIT|eps|EPS|wmf|WMF|zip|ZIP|ppt|PPT|mpg|MPG|
  xls|XLS|gz|GZ|rpm|RPM|tgz|TGZ|mov|MOV|exe|EXE|jpeg|JPEG|bmp|BMP|js|JS)$
   
  +^http://www.ascii-code.com/
  +^http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
  +^http://www.w3.org/Protocols/rfc2616/rfc2616.html
  +^http://www.ietf.org/rfc/
Listagem 5. Conteúdo do arquivo regex-urlfilter.txt com fronteiras estendidas

Seção de links externos da página

Figura 6. Seção de links externos da página

Fluxo de inspeção do Nutch
Figura 7. Fluxo de inspeção do Nutch

As demais configurações básicas do Nutch são efetuadas no arquivo nutch-site.xml. Originalmente este arquivo não contém qualquer informação. Porém, uma descrição de tudo o que pode ser configurado através dele pode ser encontrada em outro arquivo: o nutch-default.xml. Este último, como o próprio nome expressa, contém as configurações-padrão do Nutch e jamais deve ser alterado, conforme alertado pelo cabeçalho do arquivo. Na realidade, esses dois arquivos são utilizados de forma concomitante pelo Nutch. Ambos funcionam como um grande conjunto de pares Chave-Valor que vão personalizar a execução do processo de crawler. Tudo o que é configurado no arquivo nutch-site.xml, o Nutch assume como prioritário em relação ao que já está previamente configurado no nutch-default.xml. De fato, o Nutch efetua um merge dos dois arquivos e faz prevalecer os parâmetros informados no nutch-site.xml. A Listagem 6 apresenta as configurações utilizadas para o processo descrito neste artigo.


  <?xml version="1.0"?>
  <?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
   
  <configuration>
   
    <property>
      <name>http.agent.name</name>
      <value>my-nutch-agent</value>
    </property>
   
    <!-- Proxy Configurations -->
    <property>
     <name>http.proxy.host</name>
     <value>proxy.mycompany.com.br</value>
    </property>
   
    <property>
     <name>http.proxy.port</name>
     <value>my_proxy_port</value>
    </property>
   
    <property>
     <name>http.proxy.username</name>
     <value>my_proxy_user</value>
    </property>
   
    <property>
     <name>http.proxy.password</name>
     <value>my_proxy_password</value>
    </property>
   
  </configuration>
Listagem 6. Conteúdo do arquivo nutch-site.xml

A única configuração obrigatória exigida pelo Nutch é o nome (apelido) do agente HTTP responsável pela varredura das páginas na web. No caso da Listagem 6 este foi definido como my-nutch-agent no primeiro par Chave-Valor do arquivo nutch-site.xml. Foram incluídas outras configurações apenas para tornar mais clara a utilização do arquivo.

Como é uma prática comum em empresas a utilização de um proxy a fim de se ter certa medida de controle sobre o acesso à Internet, a Listagem 6 apresenta como um servidor de proxy pode ser configurado para que as requisições HTTP do Nutch não sejam “barradas” durante o processo de crawler. Cabe ressaltar que essas configurações foram copiadas do arquivo nutch-default.xml e foram alteradas apenas as informações delimitadas pela tag . Obviamente as informações vinculadas à tag de cada devem ser mantidas tal qual foram copiadas.

Apache Solr

De forma direta, Solr é um servidor open source de pesquisa baseado no projeto Lucene. Segundo Smiley et al [17], é um produto maduro que viabiliza pesquisas para web sites tais como CNET, Zappos, AOL, Netflix, além de inúmeras Intranets corporativas e governamentais. Apesar de ser escrito em Java, a camada servidor do Solr faz uso de padrões como HTTP, XML e JSON para efetuar transações com quaisquer outras aplicações. Além da funcionalidade primária de retornar a lista de resultados encontrados para um dado conjunto de termos consultados, o Solr apresenta outros aspectos principais como:

  • Highlight de termos pesquisados;
  • Navegação baseada em facets;
  • Correção e auto-complete de queries.
Nota: O termo Solr não é um acrônimo. Sua pronúncia é a mesma do termo “Solar” (em inglês). Na realidade, o projeto Solar foi originalmente desenvolvido pela CNET Networks para ser uma plataforma de consultas. Posteriormente a CNET fez a concessão do código-fonte à Apache Software Foundation, a qual renomeou o projeto para Solr, conforme seção FAQ de [7].
Nota: O faceting (amplamente utilizado em sites de e-commerce) é uma técnica de melhoria dos resultados pesquisados por meio da agregação de informações sobre o inteiro conjunto de documentos encontrados. O faceting de informação é um termo tipicamente utilizado em filtros de navegação dinâmica tais como categorização de produtos e agrupamentos por datas e preços [17].

A Figura 8 dá uma visão geral das relações entre os componentes principais do Apache Solr, bem como do fluxo de dados e queries. Embora o detalhamento de cada item da arquitetura fuja do escopo deste artigo, algumas observações merecem ressalva, a saber:

  • Request Handlers: responsáveis pelo controle da lógica de processamento de requisições, como por exemplo, para manipulação dos dados indexados pelo Solr. No caso dos handlers envolvidos com buscas de dados para o atendimento de consultas efetuadas por usuários, eles são denominados Search Handlers;
  • Response Writers: controlam a formatação das respostas geradas pelos Request Handlers;
  • Query Parser: responsável pela “tradução” da query do usuário para uma linguagem que seja compreendida pelo Lucene;
  • Solr config: contém diversos parâmetros que configuram o funcionamento do Solr. Na prática, é um arquivo – solrconfig.xml – que tem, dentre outras, informações referentes a:
    • Configurações dos Request Handlers;
    • Request Dispatcher – para o gerenciamento de comunicações HTTP;
    • Interface web de administração.
  • Schema: contém a descrição dos documentos indexados pelo Solr. Corresponde ao arquivo schema.xml.
Arquitetura geral do Apache Solr
Figura 8. Arquitetura geral do Apache Solr

De posse dessa visão geral da arquitetura do Solr, pode-se identificar três passos principais até que a informação seja passível de consulta pelo usuário. Essas etapas consideram que o Solr esteja em funcionamento integrado com o Nutch [9]:

  1. O Nutch repassa os dados oriundos do processo de crawler para o Solr;
  2. O Solr utiliza o Lucene para construir os índices referentes aos dados;
  3. O Solr carrega os índices gerados pelo Lucene para a aplicação de consulta.

Com respeito às respostas fornecidas pelo Solr, vale ressaltar ainda que a unidade básica de informação do Solr é o documento, o qual corresponde a um conjunto de dados que descrevem alguma coisa. Um documento sobre uma pessoa, por exemplo, pode conter informações como nome, biografia, cor favorita, número de calçado, etc. Nesse universo, documentos são compostos por campos (fields) os quais são peças mais específicas de informação. Número de calçado, primeiro nome e sobrenome podem ser enxergados como fields, por exemplo. Além disso, fields podem conter diferentes tipos de dados. Este é o caso, por exemplo, de um field “nome” que poderia conter dados do tipo texto (caracteres), e um field “número de calçado” que poderia abrigar dados numéricos num intervalo específico. Naturalmente, a definição de fields é flexível, ou seja, pode-se determinar que o field “número de calçado” contenha dados do tipo texto ao invés de dados numéricos. Contudo, é importante destacar que uma configuração correta dos fields possibilita que o Solr interprete corretamente os dados. Consequentemente, melhores resultados podem ser obtidos para as consultas realizadas pelos usuários. Nesse sentido, a especificação do tipo de dado armazenado por um field é passada ao Solr através do elemento field type. Esse elemento informa ao Solr como interpretar o field e como ele pode ser consultado [8].

Instalação e Configuração

O Apache Solr pode ser baixado através do link [10]. A versão utilizada neste artigo é a 3.5. Após a descompactação do arquivo, alguns dos principais diretórios encontrados são:

  • client: Contém APIs de aplicações-cliente, escritas em linguagens específicas, para possibilitar interações com o Solr. Um exemplo é a aplicação Ruby que acompanha a versão 3.5. Para possibilitar essa interação solr-ruby, o Solr contém um formato de resposta particular para o Ruby, baseado no formato JSON, o qual permite que uma resposta retornada por ele possa ser corretamente avaliada pelo interpretador Ruby;
  • contrib: Diretório contendo módulos ou extensões do Solr. A título de exemplo, há um módulo para clustering dos componentes de pesquisa e um módulo de integração com o Apache Tika – um framework para extração de textos e metadados a partir de arquivos de diferentes formatos;
  • dist: Neste diretório são encontrados, basicamente, três tipos de arquivos: (1) Um arquivo .war do Solr que possibilita sua instalação num servidor web; (2) Um arquivo .jar contendo o core do Solr, o qual pode ser utilizado para executá-lo embarcado em outra aplicação; (3) Os módulos e extensões do Solr (disponíveis no diretório contrib) empacotados em arquivos .jar;
  • docs: Contém a documentação em arquivos HTML;
  • example: Traz um completo servidor Solr que pode ser utilizado como exemplo. Ele inclui a engine de Servlets do Jetty, uma instância do Apache Solr, além de alguns dados e configurações de exemplo. Alguns dos subdiretórios mais relevantes são:
    • example/etc - Contém as configurações do Jetty. Entre outros itens, neste diretório é possível alterar-se a porta web utilizada – a porta default é a 8983;
    • example/docs - Contém exemplos de documentos para serem indexados pela instância de exemplo do Solr. Além disso, há o post.jar – um programa para envio de documentos ao Solr. Nesse artigo não faremos uso desse programa, uma vez que a carga de dados no Solr será uma tarefa delegada ao Nutch;
    • example/solr - Contém as configurações default da instância de exemplo do Solr. Pode ser usado como um bom ponto de partida para novas aplicações Solr;
    • example/webapps - diretório no qual o Jetty de exemplo aguarda deploys de aplicações web. Logo, o arquivo .war referente à instância de exemplo do Solr está instalada neste diretório.

Neste artigo será utilizada a instância de exemplo contida no arquivo descompactado. Logo, o diretório /example/solr será tratado, neste contexto, como SOLR_HOME. Alguns dos principais arquivos e diretórios do SOLR_HOME são:

  • solr.xml: arquivo que lista o core utilizado pelo Solr;
  • conf/schema.xml: arquivo que contém informações utilizadas pelos índices, além das definições de field types;
  • conf/solrconfig.xml: arquivo que contém a maior parte dos parâmetros que podem ser configurados para o Solr;
  • data: local onde os índices (dados binários) gerados pelo Lucene residem;

Como já mencionado, será utilizado os dados providos pelo Nutch para construção da base de consultas do Solr. Nesse sentido, é preciso definir que tipo de documentos, fields e field types o Solr irá reconhecer, ou seja, é preciso determinar o conteúdo do arquivo schema.xml. Para manter a integração com o conjunto de dados capturados pelo Nutch, será assumido para o Solr o mesmo esquema de documentos que o Nutch. Em outras palavras, Solr e Nutch compartilharão o mesmo schema.xml. Para isso, basta copiar o arquivo schema.xml do diretório NUTCH_HOME/conf para o diretório SOLR_HOME/conf.

Uma última verificação que precisa ser feita é com relação aos campos (fields) que serão armazenados e/ou indexados pelo Solr. Serão objetos de interesse para este artigo, ou seja, para a aplicação Localiza, os seguintes campos de informações das páginas: title, url e content. Assim, é preciso verificar se estes fields encontram-se definidos tanto para armazenamento como para indexação pelo Solr. A Listagem 7 exibe a configuração destes campos num trecho do arquivo schema.xml. Feito isso, a instância do Solr está pronta para executar consultas sobre os dados fornecidos pelo Nutch.

<field
name="url" type="url" stored="true"
indexed="true" required="true"/>

<field
name="content" type="text" stored="true"
indexed="true"/>
<field
name="title" type="text" stored="true"
indexed="true"/>
Listagem 7. Configuração dos Fields que serão utilizados pela aplicação de busca

Integração Nutch-Solr

Com as configurações que foram realizadas, dois dos principais componentes de uma máquina de busca encontram-se aptos para entrar em operação. Este é o caso do crawler Nutch, o qual está configurado para efetuar o processo de varredura e inspeção dos links e páginas dentro da fronteira estabelecida (regex-urlfilter.txt). Da mesma, a plataforma de consultas disponibilizada pelo Solr também está adequadamente instalada e pronta para efetuar buscas sobre qualquer conjunto de dados carregado.

Além disso, como a abordagem desse artigo é voltada para o funcionamento integrado das soluções, então é preciso estabelecer uma estrutura de dados que seja entendida por ambas. Nesse sentido, a utilização das mesmas configurações definidas no arquivo schema.xml, tanto no Nutch como no Solr, possibilita que os dados “gerados” pela primeira possam ser corretamente indexados e consultados pela segunda. Observa-se, portanto, que a integração Nutch-Solr é constituída, essencialmente, pelo compartilhamento do mesmo esquema ou definições de dados, isto é, fields e field types.

Conclusão

A utilização de máquinas de busca para recuperação de informações no ambiente web é um mecanismo cada vez mais adotado. Assim, ter à disposição soluções livres e de simples configuração, como o Nutch e o Solr, para o atendimento de demandas nesse contexto, constitui uma alternativa a ser explorada especialmente em cenários onde a informação agrega valor estratégico à organização.

Assim, na parte final desse artigo, será detalhado o funcionamento das duas aplicações e os mecanismos de comunicação entre elas. Além disso, será apresentado um meio de se abstrair toda a integração Nutch-Solr por meio de uma interface de consultas amigável.

Nota:
  1. Portal sem fins lucrativos cujo propósito é ser uma biblioteca digital de sites da Internet e de outros artefatos culturais em formato digital.
  2. Dissertação de Mestrado em Ciência da Computação que apresenta um levantamento de técnicas no estado-da-arte sobre estruturas de índices para sistemas de Recuperação de Informação.
  3. Página oficial do projeto Apache Lucene
  4. Página contendo os mirrors para download do Apache Nutch.
  5. Web site que contém informações referentes à tabela ASCII e outros padrões de símbolos utilizados na Web.
  6. Wiki do projeto Apache Solr.
  7. Página do projeto Apache Solr.
  8. An Enhanced Semantic Indexing Implementation for Conceptual Information Retrieval, Eric Jiang, Springer, 2004 -Artigo que descreve uma implementação mais eficiente de uma técnica de recuperação da informação conhecida como LSI (Latent Semantic Indexing).
  9. Recuperação de informação baseada em clusters, Carmen Verônica Mendes Abdala e Vinícius Antônio de Andrade, USP, 2009 -Artigo que trata da recuperação da informação no âmbito da clusterização e apresenta um sistema de pesquisa integrada que utiliza essa abordagem.
  10. Recuperação de informações na Web, Regina Meyer Branski, 2003 -Artigo que descreve as diferenças nas formas de operação de diversas ferramentas de busca existentes na Web e como as peculiaridades de cada uma delas podem afetar os resultados de uma pesquisa.
  11. An Introduction to Information Retrieval, Christopher D. Manning e Prabhakar Raghavan e Hinrich Schütze, Cambrige UP, 2009 -Livro produzido como uma compilação dos diversos cursos que os autores ministraram nas universidades de Stanford e Stuttgart.
  12. Recuperação de Informação, Olinda Nogueira Paes Cardoso, UFLA -Artigo que apresenta uma visão geral dos modelos, componentes e um método de avaliação dos sistemas de recuperação da informação.
  13. Nutch: A Flexible and Scalable Open-Source Web Search Engine, Rohit Khare e Doug Cutting e Kragen Sitaker eAdam Rifkin, CommerceNet, 2004 -Artigo que descreve a flexibilidade e escalabilidade da arquitetura do Nutch comparando-a com demais sistemas conhecidos.
  14. Apache Solr 3 Enterprise Search Server, David Smiley e Eric Pugh, PACKT Publishing, 2011 -Guia de referência para todas as funcionalidades oferecidas pelo Solr.
  15. Links Hipertextuais na Comunicação Científica, Nadia Aurora Vanti Vitullo, 2007 -Tese apresentada ao Programa de Pós-graduação em Comunicação e Informação da UFRGS. Aborda uma análise webométrica dos sítios acadêmicos latino-americanos em Ciências Sociais.