API de pesquisa vs. Apache Solr Search

Estou usando o módulo Apache Solr Search no Drupal 6 e estou procurando na API de pesquisa uma instalação do Drupal 7. Eu já vi algumas discussões aqui, mas estou procurando por quaisquer razões para escolher uma ou outra.

Existe um motivo para escolher um sobre o outro? Se sim, por que ou por que não? Ouvi dizer que pode haver problemas de complexidade e / ou de desempenho com a API de pesquisa. Isso é verdade?

A partir de 2015, podemos comparar os módulos Search API vs Apache Solr Search com os números:

                   | Apache Solr Search  | Search API
Posted in:         | 2007                | 2010
Downloads:         | >2k                 | >20k
Reported installs: | >21k                | >64k
Total bugs:        | >1200               | >600
Active bugs:       | >200                | >170
Commits:           | >1.3k               | >1.5k

o que indica a escolha clara. A API de pesquisa foi desenvolvida três anos depois e conseguiu tirar proveito de seu concorrente.

Além disso, a API de pesquisa fornece uma arquitetura muito diferente e mais flexível, sendo mantida de forma mais ativa. O que é mais importante, já é compatível com o Drupal 8 e o Solr 5.x mais recentes, que o Apachesolr ainda não possui.

A API de pesquisa começou de novo e é mais flexível em sua configuração, incluindo o suporte a Views (para o Apachesolr, você precisa do módulo extra). Também existem muitos módulos que ampliam sua funcionalidade.

Em segundo lugar, para evitar que alguns problemas sejam resolvidos duas vezes pela comunidade devido a diferenças na arquitetura desses módulos, atualmente há alguns esforços combinados entre esses dois projetos, como:

• criando a maneira comum de mostrar blocos de facetas por meio da API da faceta (também conhecida como filtros),
• um esquema comum e arquivos de configuração solrconfig.xml,
• os dois mantenedores trabalharam juntos e migraram as classes de conexão do módulo Apache Solr Search para a API de pesquisa.

^{Fonte: Battleplan for Search & Solr em Drupal 8 em Acquia}

Observe que não é recomendável usar os dois módulos no mesmo ambiente.

Para análises técnicas adicionais das diferenças, verifique os detalhes abaixo.

API de pesquisa

Visão geral da API:

• Estrutura para criar pesquisas com facilidade
• Resumos de fontes de dados e implementações de back-end
• Grande ecossistema com extensões, por exemplo, back-end
• Integração de API de faceta

• Fortemente baseado na API da entidade

  • Fornece metadados
  • Usado para configurações de índice e servidor

Recursos de extensão:

• Preenchimento automático da API de pesquisa
• Anexos
• Pesquisas salvas
• Localização
• Caminhos de facetas bonitas
• Controle deslizante (intervalos da API de pesquisa)
• e muitos mais.

Estrutura básica:

Recursos do índice:

• Diferentes fontes de dados
• Uma fonte de dados: entidades

• Com base na API da entidade:

  • Cada propriedade pode ser indexada
  • Propriedades de entidades relacionadas podem ser indexadas

Como configurar seu índice - campos:

Exibições da API de pesquisa:

• Suporte total de visualizações
• Exibir qualquer propriedade de uma entidade
• Use qualquer campo indexado como filtro, argumento ou classificação
• A maioria dos códigos baseados na integração de visualizações da API da entidade

• Por padrão: dados recuperados via carregamento da entidade

  • Pode ser ignorado (configuração "Recuperar dados do Solr" no servidor)
• Alternativa: páginas da API de pesquisa

Receitas da API de pesquisa:

• Ganchos CRUD para índices e servidores

• Ganchos para adicionar

  • fontes de dados
  • back-end
  • alterações de dados
  • processadores

• Gancho disparado ao indexar itens

• Gancho disparado ao executar uma pesquisa

Apachesolr

Recursos de extensão:

• Anexos (sem suporte de mídia, codificação personalizada para anexos a outras entidades)
• Localização (localização geográfica Apachesolr, localização Apachesolr)

Receitas Apachesolr:

• Plataforma de pesquisa corporativa de código aberto
• Fundação Apache
• Pesquisa de texto completo, destaque, pesquisa facetada, clustering, manipulação de documentos avançados
• Distribuído
• Replicação / escalável
• Java
• HTTP REST e respostas em XML / JSON e alguns outros
• Não relacional

Fonte: API de pesquisa vs apresentação de slides do Apachesolr

Veja também:

• Quando vale a pena usar o módulo de pesquisa principal do Drupal?
• Quais são as vantagens de usar o Apache Solr sobre o módulo de pesquisa principal?

Eu tentei usar os dois e posso dizer o seguinte: depende da sua situação.

Atualmente, a versão 7 estável do módulo ApacheSolr Integration pode indexar apenas nós. Portanto, se você possui entidades que não são do nó que precisa indexar, deve usar a multividade ainda em andamento patch de . A integração do ApacheSolr pode armazenar muitos dados diferentes de conteúdo quando configurados corretamente.

A API de pesquisa indexa e tem um monte de coisas maravilhosas escritas para ele. No entanto, a API de pesquisa busca apenas o ID dos dados que você está procurando. Isso significa que carregar mais dados além do ID exigirá uma carga de entidade, atingindo seu banco de dados ou qualquer camada de armazenamento em cache que você colocar. Para sites com muita pesquisa, essa pode não ser a solução mais otimizada.

Aqui está uma ótima apresentação feita na drupalcon chicago sobre o módulo de integração ApacheSolr, minuto 16 para menções à API de pesquisa.

Eu acho que você realmente tem que tentar os dois e tomar uma decisão informada. Mas considere fortemente que o apachesolr ainda não possui uma versão beta do Drupal 8.

Na API de pesquisa, você não pode combinar entidades no mesmo índice SearchAPI. Portanto, Perfis, Usuários, Nós estão em diferentes índices. Existe um módulo para permitir pesquisas multi-índice, ele não atendeu às minhas necessidades, mas o YMMV. Se você tiver muitos tipos de conteúdo e muitos campos no mesmo índice, a definição do índice poderá se tornar bastante difícil. (NB SearchAPI D8 reporta para suportar a pesquisa de vários índices)

O Apachesolr permite a edição de campos em uma base por conteúdo, o que pode ser mais fácil, mas não tem a capacidade de adicionar conteúdo relacionado a um documento; na verdade, espera-se que seja necessário escrever algum código personalizado para incluir informações de coleções de campos, referências e outras Campos. O Apachesolr D7 não suporta ajax, a menos que você use vistas, mas usando vistas que você perde facetas. Dito isto ... modificar as informações armazenadas no índice é bastante fácil se você estiver feliz codificando em ganchos.

A ideia de procurar por IDs de entidade e renderizar cada um individualmente (pode ser usado pelos dois módulos) parece um pesadelo de desempenho, mas, se você armazenar em cache as exibições de sua entidade, poderá ser mais eficiente do que renderizar a partir da resposta solr.