O Tiago postou no seu blog sua percepção sobre como o Hibernate Search é um tiro no pé. Ele afirma que justo agora que o problema do mapeamento objeto-relacional está ficando irrelevante estão criando outro problema, que ele chamou de object-indexed.
Eu concordo que existe um novo problema no horizonte e que a estrutura simplificada de metadados para persistência não está pronta para este tipo de coisa, mas não acho que seja perda de tempo esta engine, na verdade acho que pode ser muito útil. Em um projeto recente utilizei a tecnologia que meu cliente adquiriu para fazer buscas em conteúdo, uma plataforma cara e famosa de busca. Apesar de eventuais problemas com APIs, a coisa se mostrou bem interessante.
Neste sistema eu utilizo o banco de dados para fazer buscas por objetos quando os quero processar e em um caso específico (o “resultado de busca”) eu preciso destes mesmos objetos vindos da engine de busca. Não importa qual a origem, os dados representam o mesmo objeto. As Camadas de Apresentação e de Negócios estão prontas para lidar com este objeto, apenas a Camada de Persistência deve saber de onde vieram.
Eu fiz todo este trabalho na mão e isso é bem trabalhoso. No final das contas criei um código relativamente reutilizável, que pode ser empacotado numa rquivo JAR e está sendo utilizado em outros projetos com necessidades parecidas.
A grande vantagem em termos objetos que podem vir de fontes estruturadas como um SGBD ou flat como uma engine de busca é que num ambiente como o meu atual onde a base de dados é o centro do universo fazer consultas ao banco é muito caro. Muitas vezes faz mais sentido pesquisar na engine de busca, que apesar de não trazer informações e relacionamentos completos possui informação para leitura facilmente encontrável.
Independência de persistência é algo que sempre existiu. Neste caso ainda é mais simples porque os dados são de somente-leitura em uma base, ela age simplesmente como um cache. O memcached, aliás, está sendo utilizado no meu projeto atual e é tratado de maneira persistente pela aplicação através de filtros no Spring.
Os dados vêm de todo lugar, uma interface única e poderosa como do Hibernate/JPA são muito úteis no cenário moderno.
Hmmm, gostei muito da sua observação. Mas não ficou muito claro se você chegou a usar o Hibernate Search. Entendi que vc fez isso na mão, salvando o ID do objeto no índice, carregando o objeto separadamente.
O que é a forma mais elegante de fazer a coisa mesmo. Eu concordo contigo 100% quando você diz que evitar consultas ao banco é ótimo. Mas o Hibernate não carrega o objeto a partir do documento no índice, ele te dá um proxy comum e na hora da inicialização, ele faz um SELECT mesmo assim. Portanto, a menos que a busca full-text substitua uma query muito, muito complexa, não acredito que haja qualquer ganho de performance. Também não vejo ganho em termos de uso de memória, pelo contrário. Sobra o ganho no tempo de desenvolvimento, que também não me convenceu.
Enfim, assim que eu souber como fazer, eu posto de novo sobre o assunto.
A minha curiosidade maior no momento é: será que essa arquitetura cobre os 80% dos casos “fáceis”?
Então, Tiago, eu fiz na mão mesmo mas *realmente* gostaria de ter usado alguma ferramenta. O ganho de performande que me referi foi simplesmente não ir a um banco de dados onde tabelas são compartilhadas por zilhões de aplicações, cada uma com sua política e cache (quando o fazem). Realmente o problema maior aí é arquitetural mas é algo que tenho que conviver…ao menos por enquanto.
Com certeza todo esse hype web2.0 vai me dar diversas oportunidades para testar isso. Neste momentou estou justamente imaginando como fazer uma aplicação (um serviço REST, na verdade) consultar ou um ou outro para casos de ‘get by id’.