Sistemas de Busca na Web com Apache Solr e Nutch

Fique por dentro

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:

Motores de Busca
Apache Nutch
Instalaç�o e Configuraç�o
Apache Solr
Instalaç�o e Configuraç�o
Integraç�o Nutch-Solr
Conclus�o

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:

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;
Todo o conte�do extra�do � indexado e armazenado em bases de dados � Indexing;
Usu�rios utilizam a interface de busca para entrar com consultas;
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).

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:

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;
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;
Injector: Identifica a lista inicial de URLs (seed) a serem inspecionadas pelo crawler e a aloca no CrawlDB;
Generator: Determina o conjunto de URLs a serem buscadas;
Fetcher: Efetua o request e a extraç�o de links das p�ginas web;
Parser: Efetua o parser de cada p�gina buscada para a identificaç�o de outlinks;
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:
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;
LinkDB: Para cada URL, mant�m informaç�es referentes aos seus respectivos links de entrada (inlinks) e �ncoras associadas (selflinks);
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.

Figura 2. Arquitetura de Funcionamento do Nutch

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.

Figura 4. Primeira iteraç�o do processo de crawler

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:

http://www.ascii-code.com/;
http://www.ascii-code.com/html-symbol.php;
http://www.ascii-code.com/html-color-names.php;
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:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html;
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes;
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

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

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.

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]:

O Nutch repassa os dados oriundos do processo de crawler para o Solr;
O Solr utiliza o Lucene para construir os �ndices referentes aos dados;
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:

Portal sem fins lucrativos cujo prop�sito � ser uma biblioteca digital de sites da Internet e de outros artefatos culturais em formato digital.
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.
P�gina oficial do projeto Apache Lucene
P�gina contendo os mirrors para download do Apache Nutch.
Web site que cont�m informaç�es referentes � tabela ASCII e outros padr�es de s�mbolos utilizados na Web.
Wiki do projeto Apache Solr.
P�gina do projeto Apache Solr.
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).
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.
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.
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.
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.
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.
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.
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.

Buscas na web com Apache Solr e Nutch - Revista Java Magazine 106

Nesse artigo serão apresentadas duas soluções livres que podem ser usadas na construção de máquinas de busca para ambientes web: o Apache Nutch e o Solr. Será descrito ainda como essas duas aplicações podem operar de forma integrada.

Motores de Busca

Apache Nutch

Instalaç�o e Configuraç�o

Apache Solr

Instalaç�o e Configuraç�o

Integraç�o Nutch-Solr

Conclus�o

Artigos relacionados