Re: [phpms] Sistema de busca para aplicações php

ótima explicação begnini.

Em 10 de maio de 2011 16:21, Humberto Pereira <[EMAIL PROTECTED]> escreveu:

> Opa,
>
>     e-mail longuinho.
>
> O Lucene em si é a biblioteca de indexação, enquanto o Solr é um tipo de
> cliente do Lucene. Os projetos começaram separados, mas agora andam juntos
> (dividem o mesmo trunk), e cada vez mais se confudem.
>
> A ideia central do Lucene é ser um "banco de dados" orientado a documentos.
> O Lucene tem o conceito de indice, que é uma coleção de documentos que tem
> os mesmos campos, algo parecido com uma tabela do banco de dados. E assim
> como uma tabela do banco de dados, cada campo desses é de um tipo.
>
> Esses tipos são mais crus no Lucene (integer ou text), e o Solr extende
> acrescentando outros (campo único, date, float, decimal, etc.). O tipo mais
> interessante eh o Text, que pode ser tokenizado (não consigo pensar numa
> tradução) e indexado.
>
> Os campos indexados criam um indice remissivo palavra (ou melhor token) ->
> documento. Quando alguem procura por uma palavra, o Lucene vai direto nesse
> indice e pega a lista de documentos que contêm a palavra buscada. Mas antes
> de inserir essas palavras no indice, ou de fazer a busca delas, o Lucene faz
> um tratamento no texto.
>
> O Lucene não sabe o que é uma palavra, você tem que dizer isso para ele.
> Para isso, ele usa um cara chamado Tokenizer. O Tokenizer pega uma string e
> quebra em varias partes, chamadas tokens, inserindo esses tokens no indice
> (o Lucene tambêm grava o texto original, para visualização). Por ex. imagine
> a frase:
>
> João foi a escola, Maria não.
>
> Se você quebrar a string em espaço o Lucene ira gravar os seguintes tokens:
>
> João | foi | a | escola, | Maria | não.
>
> Quando alguêm for na sua busca e procurar apenas por "escola", o Lucene não
> vai achar essa ocorrência, por causa da virgula. Seu tokenizer tem que
> cuidar disso, quebrando a frase onde tem pontuação. Agora imagine que você
> tenha um CPF no meio da sua frase no formato "000.000.000-00", se voce
> tokenizar ele usando apenas pontuação, o resultado vai ser:
>
> 000 | 000 | 000-00
>
> Se o seu usuário precisa encontrar o CPF dele (por ex., uma publicação do
> tribunal de justica) ele está ferrado :). O Tokenizer tem que ser esperto
> para cuidar desses casos.
>
> Depois da tokenização, tem a parte da normalização do texto. O Lucene
> distingue entre maiuscula e minuscula, e entre acentuação. Para não ter
> problemas na busca você usa um Analizador, que normaliza tanto o texto do
> indice quanto o texto da busca, removendo acentuação e colocando todos os
> caracteres em minusculo (ou maiusculo, você escolhe). O texto do exemplo
> depois de normalizado e tokenizado ficaria:
>
> joao | foi | a | escola | maria | nao
>
> Se o usuario digitar Joao, JOAO, JoÃO, ou jOAO, ele vai transformar em
> "joao" e casar com o da frase, pq o analizador vai deixar o texto em
> minusculo e vai remover qualquer acento que tiver na busca.
>
> Alem disso, o Analizador pode fazer o stemming, que eh achar o radical do
> verbo e remover a conjugacao dele. Por ex.,
>
> jogar, jogador, jogo,
>
> podem todos virar
>
> jog
>
> Buscando por "jogador" no seu indice, a pessoa vai encontrar jogo e jogar
> também, e vice-versa. Em inglês isso é mais facil, em pt_BR é magia negra.
>
> E por último o Analizador faz a remoção de stop words, palavras que não
> adicionam significado ao documento. Artigos, adverbios, preposições, etc.
> são todas excluidas. No caso do exemplo, o Lucene ficaria com os seguintes
> tokens:
>
> joao | foi | escola | maria
>
> Se o usuario procurar por "Joao e Maria", ele vai achar o documento acima,
> já que ele vai remover a palavra "e" e vai procurar apenas "joao maria".
>
> Uma vantagem do Lucene são os tipos de queries, que aceitam booleanos (AND,
> OR, NOT), busca por prefixo, sufixo e expressões regulares. Aqui na empresa
> a gente desenvolveu também busca por similaridade, (buscar Cesar e achar
> Cezar, por ex.). É razoaelmente simples extender ele.
>
>  O Solr também te permite fazer busca por range com datas e números.
>
> Nas minhas aplicações, como mexo com documentos, o Lucene caiu como uma
> luva. No seu caso, teria que adaptar pelo menos o paradigma, chamando cada
> tupla na tabela de documento. Nada que não de para ser feito, mas talvez o
> Sphinx se encaixe melhor. Outro problema é a atualização, não sei como
> funciona o Sphinx, mas com o Lucene/Solr, voce teria que fazer um POST p/ o
> servidor a cada vez que quissesse salvar algo. Ou então fazer um batch que
> rodasse de tempos em tempos atualizando o indice.
>
> Se você quiser mais pitacos,  tem que passar mais detalhes do problema. Não
> sei qual o seu volume de atualização, qual é o tempo aceitavel até a
> informação estar disponivel no indice, se precisa de informações de outras
> fontes(outras tabelas, por ex.), se precisa controlar permissão nos dados.
> Tudo isso pesa na hora de escolher qual o melhor.
>
> Mas acho que deu pra ter um idéia do Lucene. Infelizmente eu não conheço o
> Sphinx o suficiente para fazer um comparativo, mas posso te garantir que o
> Lucene é o estado da arte para busca textual.
>
> []s
> Begnini
>
>
>
> 2011/5/10 Cauan Cabral <[EMAIL PROTECTED]>
>
>> Opa Begnini,
>>
>> Antes de fechar o assunto na lista, já que talvez interesse a mais
>> alguém...
>>
>> Achava que o Lucene seria o próprio Solr, agora que você comentou e fui
>> atrás do projeto que vi que ele é uma aplicação em si, enquanto o Lucene é
>> uma lib.
>>
>> Você acha que essa abordagem (trabalhar com um sistema isolado para
>> pesquisa) é mais interessante então? No caso que comentei a busca deverá
>> trazer informação
>> sobre qual registro da tabela contém aquela informação (considerando que
>> os dados utilizados para busca estão em um DB e os dados da aplicação estão
>> em outro),
>> isso é possível com o Solr?
>>
>> De resto ele me parece muito interessante =]
>>
>> Aproveitando, você chegou a comparar o Solr com o Sphinx quando adotou
>> ele? Olhando os cases do Sphinx parece que é bem popular. (o Solr e o Lucene
>> também são, e muito, hehehe).
>>
>> Abraço,
>>
>>
>> 2011/5/10 Humberto Pereira <[EMAIL PROTECTED]>
>>
>>> Opa Cauan,
>>>
>>>    eu trabalho com Lucene e Solr jah uns 2 anos e posso te garantir q o
>>> desempenho deles eh extraordinario (10 mil consultas diarias em 30 GB de
>>> texto, com cada consulta demorando em media 200 ms), e trabalhar com eles
>>> via REST / JSON eh bem simples com PHP.
>>>
>>> O problema eh aprender a configurar eles, eles tem alguns conceitos nao
>>> muito conhecidos (stemming, stop words, etc.) e o fato deles rodarem em java
>>> (precisa de um servlet container p/ rodar - tomcat ou jetty).
>>>
>>> Se quiser alguma ajuda, jah q acho q foge do escopo da lista, podemos
>>> conversar em pvt.
>>>
>>> []s
>>> Humberto Pereira
>>>
>>>
>>> 2011/5/10 Renan A. Marks <[EMAIL PROTECTED]>
>>>
>>>> Fala Cauan,
>>>>
>>>>
>>>> Cara, já ouviu falar do Sphinx[1]? É um engine de busca full-text, que
>>>> roda sobre mysql/postgresql/odbc. Nunca usei, mas ele parece cumprir o que
>>>> promete. Restaria vc integrá-lo no seu sistema da melhor forma possível e
>>>> fazer uns testes pra ver se vale a pena.
>>>>
>>>> Tae minha pequena contribuição. :)
>>>>
>>>> []s!
>>>>
>>>> [1] - http://sphinxsearch.com/about/sphinx/
>>>>
>>>>
>>>> 2011/5/10 Cauan Cabral <[EMAIL PROTECTED]>
>>>>
>>>>> Dae pessoal, tudo bem?
>>>>>
>>>>> Trabalho com alguns sistemas que gerenciam diversas informações (acho
>>>>> que como a grande maioria de vocês), e na maioria das vezes é preciso
>>>>> oferecer algum sistema de busca no sistema.
>>>>>
>>>>> Normalmente uma simples "like" em um campo do banco de dados é
>>>>> suficiente (temos até um plugin para ajudar nisso junto ao CakePHP[1]), 
>>>>> mas
>>>>> aí tenho dois problemas:
>>>>>
>>>>> 1) Performance - o like não é rápido já que faz uma busca simples por
>>>>> padrão. quando você tem uma tabela com milhares/milhões de registro
>>>>> o custo é altíssimo.
>>>>> 2) Necessidade de múltiplas comparações - se na tabela tenho por
>>>>> exemplo o nome do usuário, email e documento dele e quero buscar por
>>>>> qualquer
>>>>> um destes critérios, tenho que repetir o like para todos estes campos.
>>>>> O problema de performance é multiplicado pelo número de campos.
>>>>>
>>>>> Tendo em vista o problema, queria a ajuda de vocês para pensar em uma
>>>>> solução interessante, já que é um problema bem corriqueiro.
>>>>>
>>>>> Vou lista algumas soluções que imaginei:
>>>>>
>>>>> *1 - *Montar um campo ou uma tabela própria contendo um campo TEXT
>>>>> indexado como FULLTEXT e neste campo eu coloco a concatenação
>>>>> de todos os campos que podem ter seus dados pesquisados. A dificuldade
>>>>> seria manter atualizar este campo sempre que
>>>>> os campos de interesse fossem atualizados.
>>>>>
>>>>> *2 - *Trabalhar com um sistema separado, especializado em buscas (por
>>>>> exemplo o Lucene[2]), utilizando-o como uma api
>>>>> de busca. Neste caso imagino ser necessário a criação de um esquema de
>>>>> dados que fornece as informações que serão
>>>>> buscadas e uma referência para onde essa informação está no banco de
>>>>> dados da aplicação (tabela + id, por exemplo).
>>>>> A dificuldade, para  mim, seria a implementação dessa api e a
>>>>> manutenção dos dados atualizados, de modo a não sobrecarregar
>>>>> o servidor.
>>>>>
>>>>>
>>>>> Alguém já desenvolveu um sistema dessa natureza? Recomenda alguma
>>>>> abordagem?
>>>>>
>>>>>
>>>>> [1] - https://github.com/radig/r_search
>>>>> [2] - http://lucene.apache.org/java/docs/index.html
>>>>>
>>>>>
>>>>> Abraço
>>>>> --
>>>>> Cauan Cabral
>>>>> ----------------
>>>>> Como falar comigo: Google Talk: [EMAIL PROTECTED] Skype: CauanCabral MSN:
>>>>> [EMAIL PROTECTED]
>>>>> Onde me encontrar: [image: 
>>>>> Linkedin]<http://www.linkedin.com/in/cauancabral>[image:
>>>>> Facebook] <http://www.facebook.com/cauancabral>[image: 
>>>>> Wordpress]<http://cauancabral.net>[image:
>>>>> Twitter] <http://twitter.com/cauancabral>[image: 
>>>>> Orkut]<http://www.orkut.com.br/Main#Profile?uid=7512190439488689375>
>>>>>
>>>>>
>>>>>  --
>>>>> Você recebeu esta mensagem porque está inscrito no Grupo "phpms" em
>>>>> Grupos do Google.
>>>>> Para postar neste grupo, envie um e-mail para [EMAIL PROTECTED]
>>>>> Para cancelar a sua inscrição neste grupo, envie um e-mail para
>>>>> [EMAIL PROTECTED]
>>>>> Para ver mais opções, visite este grupo em
>>>>> http://groups.google.com/group/phpms?hl=pt-PT
>>>>> Para acessar o site do grupo, visite: http://www.phpms.org/
>>>>> As regras de utilização deste grupo encontram-se em:
>>>>> http://www.phpms.org/regras-da-lista
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Atenciosamente,
>>>>
>>>> Renan A. Marks
>>>>
>>>>
>>>>  --
>>>> Você recebeu esta mensagem porque está inscrito no Grupo "phpms" em
>>>> Grupos do Google.
>>>> Para postar neste grupo, envie um e-mail para [EMAIL PROTECTED]
>>>> Para cancelar a sua inscrição neste grupo, envie um e-mail para
>>>> [EMAIL PROTECTED]
>>>> Para ver mais opções, visite este grupo em
>>>> http://groups.google.com/group/phpms?hl=pt-PT
>>>> Para acessar o site do grupo, visite: http://www.phpms.org/
>>>> As regras de utilização deste grupo encontram-se em:
>>>> http://www.phpms.org/regras-da-lista
>>>>
>>>
>>>  --
>>> Você recebeu esta mensagem porque está inscrito no Grupo "phpms" em
>>> Grupos do Google.
>>> Para postar neste grupo, envie um e-mail para [EMAIL PROTECTED]
>>> Para cancelar a sua inscrição neste grupo, envie um e-mail para
>>> [EMAIL PROTECTED]
>>> Para ver mais opções, visite este grupo em
>>> http://groups.google.com/group/phpms?hl=pt-PT
>>> Para acessar o site do grupo, visite: http://www.phpms.org/
>>> As regras de utilização deste grupo encontram-se em:
>>> http://www.phpms.org/regras-da-lista
>>>
>>
>>
>>
>> --
>> Cauan Cabral
>> ----------------
>> Como falar comigo: Google Talk: [EMAIL PROTECTED] Skype: CauanCabral MSN:
>> [EMAIL PROTECTED]
>> Onde me encontrar: [image: 
>> Linkedin]<http://www.linkedin.com/in/cauancabral>[image:
>> Facebook] <http://www.facebook.com/cauancabral>[image: 
>> Wordpress]<http://cauancabral.net>[image:
>> Twitter] <http://twitter.com/cauancabral>[image: 
>> Orkut]<http://www.orkut.com.br/Main#Profile?uid=7512190439488689375>
>>
>>
>>  --
>> Você recebeu esta mensagem porque está inscrito no Grupo "phpms" em Grupos
>> do Google.
>> Para postar neste grupo, envie um e-mail para [EMAIL PROTECTED]
>> Para cancelar a sua inscrição neste grupo, envie um e-mail para
>> [EMAIL PROTECTED]
>> Para ver mais opções, visite este grupo em
>> http://groups.google.com/group/phpms?hl=pt-PT
>> Para acessar o site do grupo, visite: http://www.phpms.org/
>> As regras de utilização deste grupo encontram-se em:
>> http://www.phpms.org/regras-da-lista
>>
>
>  --
> Você recebeu esta mensagem porque está inscrito no Grupo "phpms" em Grupos
> do Google.
> Para postar neste grupo, envie um e-mail para [EMAIL PROTECTED]
> Para cancelar a sua inscrição neste grupo, envie um e-mail para
> [EMAIL PROTECTED]
> Para ver mais opções, visite este grupo em
> http://groups.google.com/group/phpms?hl=pt-PT
> Para acessar o site do grupo, visite: http://www.phpms.org/
> As regras de utilização deste grupo encontram-se em:
> http://www.phpms.org/regras-da-lista
>

-- 
Você recebeu esta mensagem porque está inscrito no Grupo "phpms" em Grupos do 
Google.
 Para postar neste grupo, envie um e-mail para [EMAIL PROTECTED]
 Para cancelar a sua inscrição neste grupo, envie um e-mail para [EMAIL 
PROTECTED]
 Para ver mais opções, visite este grupo em 
http://groups.google.com/group/phpms?hl=pt-PT
Para acessar o site do grupo, visite: http://www.phpms.org/
As regras de utilização deste grupo encontram-se em: 
http://www.phpms.org/regras-da-lista