[SP-pm] [OT] Possível Oportunidade

[Lindolfo Rodrigues Oliveira Neto]

Staninslaw, Fulltext é horrivel ! o melhor jeito de se fazer busca é usando uma estrutura de dados baseada em 'Indice Invertido'

http://en.wikipedia.org/wiki/Inverted_index

No CPAN tem o Kinosearch http://search.cpan.org/search?query=kinosearch&mode=all que usa isso, mas eu recomendo fortemente o Solr

O marcioferreira fez alguns benchmark a pouco tempo sobre isso, caso esteja vivo e queira contribuir para a thread :)

On Jan 11, 2011, at 6:32 PM, Stanislaw Pusep wrote:

> 
>    Stanislaw> Agora, falando sério: eu quero que o meu blog tenha um
>    Stanislaw> sisteminha básico de busca de conteúdo.
> 
> Que bom que você falou disso, nesse caso você deveria ficar longe de
> bancos de dados relacionais porque a forma padrão de se implementar uma
> busca por texto é indexar documentos desnormalizados. Assim um /john/
> vai encontrar ocorrências no documento inteiro (seja no título, autor,
> corpo, etc.). Num banco de dados relacional você gasta processamento
> a mais porque precisa fazer where title like '%john%' or author like
> '%john%' e esse tipo de busca nunca vai sempre ser um table scan, que é,
> como diria um amigo meu, "lento pacas", além de ser mais complicado de
> implementar.
> 
> FULLTEXT?
>  
> 
>    Stanislaw> Também acho legal que os posts novos contenham
>    Stanislaw> referências para posts antigos; e, como a minha memória é
>    Stanislaw> ruim, prefiro que o CMS faça isso automaticamente.
> 
> O que impede o CMS de te apontar pruma url que coincide com o documento
> que você quer referenciar?
> 
> Supondo: estou escrevendo resenha sobre iPad. O sistema deve "automagicamente" (categorias, tags, indexação do conteúdo, whatever) associar esse artigo com resenhas de iPhone, iPod, iMac. Em blog pequeno até pode ser viável scanear tudo sempre que artigo novo é criado...
>  
>    Stanislaw> Um esqueminha de comentários c/threads é bacaninha
>    Stanislaw> também;
> 
> Escreve pra mim o SQL que recupera todos os nós dentro de uma thread com
> profundidade arbitrária. Difícil né? Agora põe esse SQL pra rodar num
> benchmark contra um filesystem: "lento pacas".
> 
> use Data::NestedSet;
>  
> 
>    Stanislaw> sem falar de um filtro anti-spam bayesiano...
> 
> Por definição, um filtro remove elementos do stream *antes* deles
> chegarem no storage, então esse requisito é completamente ortogonal à
> escolha do storage. E mesmo assim, a natureza sequencial dos filtros
> também seriam lentos e complicados de implementar num banco de dados
> relacional pelos mesmos motivos da busca.
> 
> Filtro que se preza é treinável. Vou manter (black|white)list como? tie %hash, 'DB_File'?
> 
>    Stanislaw> Faltou algum argumento para empregar RDBMS?
> 
> Tire suas próprias conclusões.
> 
> Provando por absurdo e desprezando o atrito: OK, um blog pode ser um emaranhado de arquivos organizados em diretórios. Porém vai ter que ter um (ou mais) índice. Talvez em CSV. E por que não dbmopen? Ou, quem sabe, Berkeley DB. Mas melhor mesmo seria SQLite. Opa!!!
> =begin disclaimer
>   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
> SaoPaulo-pm mailing list: SaoPaulo-pm em pm.org
> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer

-------------- Pr?xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20110111/118486de/attachment-0003.html>