sistemas de busca para texto (full text search)

Há algum tempo criei e venho mantendo uma aplicação web que faz busca em um grande volume de informações. Hoje, a base de dados possui cerca de 120 milhões de registros, e preciso importar mais 90 milhões.

No início, procurei me informar sobre sistemas de busca, e descobri que há diversas alternativas de ótima qualidade. O problema da minha base é que os dados não são relacionados a data, os registros não são relacionados a um período (estilo log). Porém, são imutáveis, nunca sofrem update – só select.

Comecei pelo full text search do MySQL 5.1, que era o banco onde os dados estavam armazenados – em uma única tabela, de uns 40GB. Os resultados não foram muito bons – no próprio manual há comentários de outros usuários relatando fatos de lentidão com grandes volumes.

Pelos testes que fiz, o mysql se comportou muito bem com pequeno volume de dados, entre 1 e 2 milhões de registros. A máquina é um quad-core 3.2 com 4GB de RAM e dois discos SATA de 160GB em Raid1.

Procurando mais, encontrei o Lucene, da Jakarta. Como o backend do site é inteiro escrito em python, optei por não usar o lucene em java e acabei encontrando o PyLucene – binding do lucene pra python, usando jcc. Na época, havia ainda uma versão que podia ser compilada com gcj, que era o padrão.

Depois de uma batalha pra comparar os dois, e escolher a melhor opção, acabei ficando com a versão do jcc – ainda, publiquei um artigo no Ubuntu Forums sobre a instalação e uso dos dois, pouco antes de entrar na lista de discussão e me tornar ativo no pylucene.

Consegui diversos benefícios usando o lucene:

• Armazenar ou apenas indexar documentos (linhas), compostos por campos (estilo csv)
• Realizar a busca em um ou mais campos, considerando relevância
• Linguagem de busca com muitos recursos específicos pra texto

Em determinado período, eu excluí completamente o mysql do sistema. Coloquei todos os dados em um index do lucene e quando executava uma busca, ele já me fornecia os campos dos documentos retornados. Com cerca de 80 buscas simultâneas, na base com uns 80 milhões de registros, os resultados surgiam em menos de 0.5 segundos.

Quando dobrei a quantidade de clientes usando o sistema, começaram os problemas de memória do java.lang.OutOfMemoryError: Java heap space. Aí, descobri um problema no design do sistema.

Pra cada nova busca eu abria o index, executava a query, pegava os documentos do resultado e fechava o index – o index do lucene é um diretório no disco, e as funções da API gerenciam o conteúdo dele. Encontrei em algum documento do manual que isso não era apropriado, e poderia causar lentidão – mas meu problema não era lentidão, e sim falta de memória. Se eu aumentasse o heap de 512 pra 1024, a máquina engolia o swap com essa quantidade de clientes simulâneos.

Então, decidi mudar o design e acabei criando um daemon que sozinho abria o index, com um heap de 4096, atendendo requisições por um unix socket. Resolveu parcialmente, pois aquelas buscas de 0.5 passaram pra 0.8, 0.9 segundos. As vezes, chegava a 1.5 segundos. Depois de uma semana, voltavam os problemas de memória do java, e não havia mais como aumentar o heap.

Outro problema do lucene, nesse caso, era gerenciar o conteúdo da base: ele não possui nenhum mecanismo de update. Há apenas insert, search e delete. Pra atualizar um documento é necessário removê-lo e depois criá-lo novamente, e após criar novos documentos é recomendado otimizar a base toda – processo que demorava mais de 8 horas.

Numa tentativa de melhorar o desempenho, fiz o seguinte: voltei os dados pro mysql, extraí apenas os campos texto que precisavam de busca, e criei o index do lucene sem armazenar os dados. Em cada documento, havia um único campo que era armazenado, que era o ID daquele registro no mysql. Todos os outros eram apenas tokenized.

Com isso, o sistema melhorou muito. As buscas pelo daemon voltaram a ser extremamente rápidas, mas depois de cada uma ainda era necessário fazer um select no mysql pra extrair os dados, pois a busca no lucene retornava apenas um monte de IDs dos registros do mysql.

Então, voltei a procurar outras alternativas. O Gleicon já fez um ou mais sistemas com o Ferret, mas sou alérgico a Ruby e por isso já descartei. Pouco depois encontrei o Sphinx, que parece muito interessante pelo fato de já extrair e indexar automaticamente os dados de RDBMs como MySQL e PostgreSQL. Ele possui um daemon próprio e permite queries via socket, mas depois que vi um dos clientes em python, achei que poderia ser lento só pelo processo de conexão e manuseio do protocolo, e decidi nem tentar.

Por fim, o que estava evidente e nunca cheguei nem a cogitar, foi o que mais me impressionou. Durante muitos anos fui à favor do PostgreSQL. Vale lembrar que o MySQL até as versões 4.x era pelado. Mas quando saiu a versão 5, fui migrando gradativamente e passei a usar MySQL em tudo.

O full text search do PostgreSQL 8.3 é beeeeeem interessante. Como sempre, o PG é muito mais lento pra criar os índices e importar os dados, mas no meu caso, se comportou muito melhor que todas outras alternativas com grande volume de dados e diversas conexões simultâneas. Um pouco disso é empolgação, pois essa versão do meu sistema ainda não está em produção – mas pelos testes que fiz, já houve resultado muito satisfatório.

Uma das coisas necessárias foi particionar a tabela, pra gerar índices menores e mais rápidos. Porém, ele tem um esquema que permite gerar o vetor da busca e armazenar em um campo da tabela junto com os dados, e então gerar o índice à partir daquele campo. A configuração inicial de tudo isso tem quase a mesma complexidade de escrever os programas que gerenciam o index do lucene, mas por se tratar de SQL acaba sendo mais prático pra dar manutenção, importar e principalmente atualizar os dados quando necessário.

Usando esse esquema, ele permite um fast full text search, que apresenta um desempenho tão bom quanto do lucene, sem que haja o maldito problema de falta de memória do java.

Se um dia tiver saco de fazer um benchmark de tudo isso, publico aqui pra todos verem.

---