Solr vs. ElasticSearch [fechado]

Quais são as principais diferenças arquitetônicas entre essas tecnologias?

Além disso, quais casos de uso geralmente são mais apropriados para cada um?

Atualizar

Agora que o escopo da pergunta foi corrigido, devo acrescentar algo a esse respeito:

Existem muitas comparações disponíveis entre o Apache Solr e o ElasticSearch , por isso vou fazer referência às que achei mais úteis, ou seja, cobrindo os aspectos mais importantes:

• Bob Yoplait já vinculou a resposta de kimchy ao ElasticSearch, Sphinx, Lucene, Solr, Xapian. Qual se encaixa para qual uso? , que resume as razões pelas quais ele criou o ElasticSearch , que, em sua opinião, fornece um modelo distribuído muito superior e facilidade de uso em comparação com o Solr.

• A pesquisa em tempo real de Ryan Sonnek : Solr vs Elasticsearch fornece uma análise / comparação perspicaz e explica por que ele mudou do Solr para o ElasticSeach, apesar de já ser um usuário feliz do Solr - ele resume o seguinte:

  O Solr pode ser a arma de escolha na criação de aplicativos de pesquisa padrão , mas o Elasticsearch leva para o próximo nível com uma arquitetura para criar aplicativos de pesquisa em tempo real modernos . A percolação é um recurso empolgante e inovador que, sozinho, tira o Solr da água. O Elasticsearch é escalável, rápido e um sonho de integração . Adios Solr, foi um prazer conhecê-lo. [ênfase minha]

• O artigo da Wikipedia sobre ElasticSearch cita uma comparação da reputada revista alemã iX, listando vantagens e desvantagens, que resumem o que já foi dito acima:

  Vantagens :

  • O ElasticSearch é distribuído. Nenhum projeto separado é necessário. As réplicas também são quase em tempo real, chamadas "Replicação por push".
  • O ElasticSearch suporta totalmente a pesquisa quase em tempo real do Apache Lucene.
  • O tratamento da multilocação não é uma configuração especial, onde, com o Solr, é necessária uma configuração mais avançada.
  • O ElasticSearch apresenta o conceito do Gateway, que facilita os backups completos.

  Desvantagens :

  • Apenas um desenvolvedor principal [não é mais aplicável de acordo com a organização atual do elasticsearch do GitHub , além de ter uma base de commits bastante ativa em primeiro lugar]
  • Nenhum recurso de aquecimento automático [não é mais aplicável de acordo com a nova API de aquecimento de índice ]

Resposta inicial

São tecnologias completamente diferentes, abordando casos de uso completamente diferentes, portanto, não podem ser comparadas de nenhuma maneira significativa:

• Apache Solr - O Apache Solr oferece os recursos do Lucene em um servidor de pesquisa rápida e fácil de usar, com recursos adicionais como lapidação, escalabilidade e muito mais

• Amazon ElastiCache - O Amazon ElastiCache é um serviço da Web que facilita a implantação, a operação e a escalabilidade de um cache na memória na nuvem.

  • Observe que o Amazon ElastiCache é compatível com o protocolo Memcached, um sistema de cache de objetos de memória amplamente adotado, para que códigos, aplicativos e ferramentas populares que você usa hoje em ambientes Memcached existentes funcionem perfeitamente com o serviço (consulte o Memcached para obter detalhes).

[ênfase minha]

Talvez isso tenha sido confundido com as duas tecnologias relacionadas a seguir, de uma maneira ou de outra:

• ElasticSearch - É um mecanismo de pesquisa de código aberto (Apache 2), distribuído, RESTful, construído sobre o Apache Lucene.

• Amazon CloudSearch - O Amazon CloudSearch é um serviço de pesquisa totalmente gerenciado na nuvem que permite aos clientes integrar facilmente a funcionalidade de pesquisa rápida e altamente escalável em seus aplicativos.

As ofertas Solr e ElasticSearch são surpreendentemente semelhantes à primeira vista e ambas usam o mesmo mecanismo de pesquisa de back-end, chamado Apache Lucene .

Embora o Solr seja mais antigo, bastante versátil, maduro e amplamente utilizado em conformidade, o ElasticSearch foi desenvolvido especificamente para solucionar deficiências do Solr com requisitos de escalabilidade em ambientes de nuvem modernos, difíceis de resolver com o Solr .

Como tal, provavelmente seria mais útil comparar o ElasticSearch com o recém-lançado Amazon CloudSearch (consulte a postagem introdutória Iniciar pesquisa em uma hora por menos de US $ 100 / mês ), porque ambos pretendem cobrir os mesmos casos de uso em princípio.

Vejo que algumas das respostas acima estão um pouco desatualizadas. Da minha perspectiva, e eu trabalho com o Solr (Cloud e não Cloud) e o ElasticSearch diariamente, aqui estão algumas diferenças interessantes:

• Comunidade: O Solr tem uma comunidade de usuários, desenvolvedores e contribuidores maior e mais madura. O ES possui uma comunidade menor, mas ativa de usuários e uma comunidade crescente de colaboradores
• Maturidade: Solr é mais maduro, mas o ES cresceu rapidamente e considero estável
• Desempenho: difícil de julgar. Não fizemos benchmarks diretos de desempenho. Uma pessoa no LinkedIn comparou Solr vs. ES vs. Sensei uma vez, mas os resultados iniciais devem ser ignorados porque eles usaram configurações não especializadas para Solr e ES.
• Design: As pessoas adoram Solr. A API Java é um tanto detalhada, mas as pessoas gostam de como é montada. Infelizmente, o código Solr nem sempre é muito bonito. Além disso, o ES possui sharding, replicação em tempo real, documento e roteamento embutidos. Embora parte disso também exista no Solr, parece um pensamento posterior.
• Suporte: existem empresas que fornecem suporte técnico e de consultoria para o Solr e o ElasticSearch. Acho que a única empresa que fornece suporte para ambos é o Sematext (divulgação: sou o fundador do Sematext)
• Escalabilidade: ambos podem ser dimensionados para clusters muito grandes. O ES é mais fácil de escalar do que a versão anterior ao Solr 4.0, mas com o Solr 4.0 não é mais esse o caso.

Para uma cobertura mais completa do tópico Solr vs. ElasticSearch, consulte https://sematext.com/blog/solr-vs-elasticsearch-part-1-overview/ . Este é o primeiro post da série de posts do Sematext que faz comparação direta e neutra entre Solr e ElasticSearch. Divulgação: Eu trabalho na Sematext.

Vejo que muitas pessoas aqui responderam a essa pergunta do ElasticSearch vs Solr em termos de recursos e funcionalidades, mas não vejo muita discussão aqui (ou em outro lugar) sobre como elas se comparam em termos de desempenho.

Foi por isso que decidi conduzir minha própria investigação . Tomei um microsserviço de fonte de dados heterogêneos já codificado que já usava o Solr para pesquisa de termos. Troquei o Solr for ElasticSearch, depois executei as duas versões na AWS com um aplicativo de teste de carga já codificado e capturei as métricas de desempenho para análises subseqüentes.

Aqui está o que eu encontrei. O ElasticSearch teve uma taxa de transferência 13% maior quando se tratava de indexação de documentos, mas o Solr era dez vezes mais rápido. Quando se tratava de consultar documentos, o Solr tinha cinco vezes mais taxa de transferência e era cinco vezes mais rápido que o ElasticSearch.

Desde a longa história do Apache Solr, acho que uma das forças do Solr é seu ecossistema . Existem muitos plugins Solr para diferentes tipos de dados e finalidades.

Pesquise a plataforma nas seguintes camadas, de baixo para cima:

• Dados
  • Objetivo: representar vários tipos e fontes de dados
• Construção de documentos
  • Objetivo: criar informações do documento para indexação
• Indexação e pesquisa
  • Objetivo: criar e consultar um índice de documento
• Aprimoramento da lógica
  • Objetivo: Lógica adicional para processar consultas e resultados de pesquisa
• Serviço de plataforma de pesquisa
  • Objetivo: adicionar funcionalidades adicionais do núcleo do mecanismo de pesquisa para fornecer uma plataforma de serviço.
• Aplicativo de interface do usuário
  • Objetivo: Interface ou aplicativos de pesquisa do usuário final

Artigo de referência: Pesquisa corporativa

Eu criei uma tabela de grandes diferenças entre elasticsearch e Solr e splunk, você pode usá-lo como atualização de 2016:

Eu tenho trabalhado na pesquisa solr e elástica para aplicativos .Net. A principal diferença que enfrentei é

Pesquisa elástica:

• Mais código e menos configuração, no entanto, há APIs para alterar, mas ainda é uma alteração de código
• para tipos complexos, digite dentro de tipos, ou seja, tipos aninhados (não foi possível obter em solr)

Solr:

• menos código e mais configuração e, portanto, menos manutenção
• para agrupar os resultados durante a consulta (muito trabalho a ser alcançado na pesquisa elástica de maneira curta e direta)

Embora todos os links acima tenham mérito e tenham me beneficiado bastante no passado, como linguista "exposto" a vários mecanismos de pesquisa Lucene nos últimos 15 anos, devo dizer que o desenvolvimento de pesquisas elásticas é muito rápido em Python. Dito isto, parte do código não me pareceu intuitiva. Então, estendi a mão para um componente da pilha ELK, Kibana, de uma perspectiva de código aberto, e descobri que era possível gerar o código um tanto enigmático da pesquisa elástica com muita facilidade no Kibana. Além disso, eu também poderia puxar as consultas do Chrome Sense es para o Kibana. Se você usar o Kibana para avaliar es, isso acelerará ainda mais sua avaliação. O que levou horas para ser executado em outras plataformas foi instalado no JSON no Sense, em cima da elasticsearch (interface RESTful) em alguns minutos, na pior das hipóteses (maiores conjuntos de dados); em segundos na melhor das hipóteses. A documentação para elasticsearch, com mais de 700 páginas, não respondeu às perguntas que eu tinha que normalmente seriam resolvidas no SOLR ou em outra documentação do Lucene, que obviamente levou mais tempo para analisar. Além disso, você pode dar uma olhada nos Agregados na pesquisa elástica, que levaram o Faceting a um novo nível.

Visão geral: se você está fazendo ciência de dados, análise de texto ou linguística computacional, a elasticsearch possui alguns algoritmos de classificação que parecem inovar bem na área de recuperação de informações. Se você estiver usando algum algoritmo TF / IDF, Frequência de texto / Frequência inversa de documento, a elasticsearch estende o algoritmo da década de 1960 para um novo nível, mesmo usando BM25, Best Match 25 e outros algoritmos de classificação de relevância. Portanto, se você estiver pontuando ou classificando palavras, frases ou sentenças, a elasticsearch faz essa pontuação rapidamente, sem a grande sobrecarga de outras abordagens de análise de dados que levam horas - outra economia de tempo na pesquisa elástica. Com es, combinando alguns dos pontos fortes do bucketing de agregações com a pontuação e classificação de relevância de dados JSON em tempo real, você pode encontrar uma combinação vencedora,

Nota: houve uma discussão semelhante sobre agregações acima, mas não sobre agregações e pontuação de relevância - meu pedido de desculpas por qualquer sobreposição. Divulgação: eu não trabalho para elástico e não poderei me beneficiar no futuro próximo de seu excelente trabalho devido a um caminho arquitetural diferente, a menos que eu faça algum trabalho de caridade com elasticsearch, o que não seria uma má ideia

Imagine o caso de uso:

1. Muitos (100+) pequenos índices de pesquisa (10Mb-100Mb, 1000-100000 documentos).
2. Eles estão usando muitos aplicativos (microsserviços)
3. Cada aplicativo pode usar mais de um índice
4. Pequeno por índice de tamanho, sim. Mas uma carga enorme (centenas de solicitações de pesquisa por segundo) e solicitações são complexas (várias agregações, condições e assim por diante)
5. Não são permitidos períodos de inatividade
6. Tudo isso dura anos e cresce constantemente.

A ideia de ter uma instância individual do ES para cada índice - é uma enorme sobrecarga nesse caso.

Com base na minha experiência, esse tipo de caso de uso é muito complexo para oferecer suporte no Elasticsearch.

Por quê?

PRIMEIRO.

O principal problema é o desconhecimento fundamental da compatibilidade com as costas.

Quebrar mudanças são tão legais! (Nota: imagine o servidor SQL, que exige que você faça pequenas alterações em todas as suas instruções SQL, quando atualizadas ... não pode imaginar. Mas para o ES é normal)

As preterições que serão lançadas no próximo grande lançamento são muito sexy! (Nota: você sabe, Java contém algumas preterições, com mais de 20 anos, mas ainda trabalhando na versão Java real ...)

E não é só isso, às vezes você ainda tem algo que não foi documentado em nenhum lugar (pessoalmente só me deparei uma vez, mas ...)

Assim. Se você deseja atualizar o ES (porque precisa de novos recursos para algum aplicativo ou deseja obter correções de bugs) - você está no inferno. Especialmente se for sobre atualização de versão principal.

A API do cliente não será compatível. As configurações do índice não serão compatíveis. E atualizar todos os aplicativos / serviços no mesmo momento com a atualização do ES não é realista.

Mas você deve fazê-lo de tempos em tempos. Não há outro jeito.

Os índices existentes são atualizados automaticamente? - Sim. Mas isso não ajuda quando é necessário alterar algumas configurações do índice antigo.

Para viver com isso, você precisa investir constantemente muito poder em ... compatibilidade futura de seus aplicativos / serviços com versões futuras do ES. Ou você precisa criar (e de qualquer maneira suportar constantemente) algum tipo de middleware entre seu aplicativo / serviços e o ES, que fornece uma API de cliente compatível. (E você não pode usar o Transport Client (porque exigia a atualização do jar para todas as atualizações secundárias do ES), e esse fato não facilita a sua vida)

Parece simples e barato? Não, não é. Longe disso. A manutenção contínua de infraestrutura complexa, baseada no ES, é muito cara em todos os sentidos possíveis.

SEGUNDO. API simples? Bem ... não mesmo. Quando você realmente está usando condições e agregações complexas ... A solicitação JSON com 5 níveis aninhados é o que for, mas não é simples.

Infelizmente, não tenho experiência com SOLR, não posso dizer nada sobre isso.

Mas o Sphinxsearch é muito melhor nesse cenário, devido ao SphinxQL totalmente compatível com as versões anteriores.

Nota: Sphinxsearch / Manticore são realmente interessantes. Não é baseado em Lucine e, como resultado, seriamente diferente. Contém vários recursos exclusivos da caixa que o ES não possui e malucos rapidamente com índices de tamanho pequeno / médio.

Se você já estiver usando o SOLR, mantenha-o. Se você estiver iniciando, vá para a pesquisa Elastic.

Os problemas principais máximos foram corrigidos no SOLR e ele é bastante maduro.

Uso o Elasticsearch há 3 anos e o Solr por cerca de um mês. Considero que o cluster do elasticsearch é bastante fácil de instalar em comparação com a instalação do Solr. O Elasticsearch possui um conjunto de documentos de ajuda com ótimas explicações. Um dos casos de uso em que eu estava preso à agregação de histograma, disponível no ES, porém não encontrado no Solr.

Eu só uso a pesquisa elástica. Desde que eu encontrei solr é muito difícil de começar. Recursos da Elastic-search:

1. Fácil de começar, muito poucas configurações. Até um novato pode configurar um cluster passo a passo.
2. API Restful simples que usa consulta NoSQL. E muitas bibliotecas de idiomas para facilitar o acesso.
3. Bom documento, você pode ler o livro:. Existe uma versão web no site oficial.

Adicione um documento aninhado na pesquisa de dados muito complexa e muito complexa também. mas a Pesquisa Elástica é fácil de adicionar documentos e pesquisas aninhados