Solr vs. ElasticSearch

¿Cuáles son las principales diferencias arquitectónicas entre estas tecnologías?

Además, ¿qué casos de uso son generalmente más apropiados para cada uno?

Actualizar

Ahora que se ha corregido el scope de la pregunta, también podría agregar algo al respecto:

Hay muchas comparaciones entre Apache Solr y ElasticSearch disponibles, por lo que haré referencia a las que me resultaron más útiles, es decir, cubriendo los aspectos más importantes:

  • Bob Yoplait ya vinculó la respuesta de kimchy a ElasticSearch, Sphinx, Lucene, Solr, Xapian. ¿Cuál se ajusta a qué uso? , que resume las razones por las que siguió adelante y creó ElasticSearch , que en su opinión proporciona un modelo distribuido muy superior y facilidad de uso en comparación con Solr.

  • Búsqueda en tiempo real de Ryan Sonnek : Solr vs Elasticsearch proporciona un análisis / comparación perspicaz y explica por qué cambió de Solr a ElasticSeach, a pesar de ser un usuario feliz de Solr, lo resume de la siguiente manera:

    Solr puede ser el arma de elección al construir aplicaciones de búsqueda estándar , pero Elasticsearch lo lleva al siguiente nivel con una architecture para crear aplicaciones modernas de búsqueda en tiempo real . La percolación es una característica emocionante e innovadora que sopla Soller directamente del agua. Elasticsearch es escalable, rápido y un sueño para integrarse . Adios Solr, fue lindo conocerte. [énfasis mío]

  • El artículo de Wikipedia sobre ElasticSearch cita una comparación de la reputada revista alemana iX, que enumera las ventajas y desventajas, que prácticamente resume lo que se ha dicho anteriormente:

    Ventajas :

    • ElasticSearch se distribuye. No se requiere un proyecto separado. Las réplicas también son casi en tiempo real, lo que se llama “replicación de inserción”.
    • ElasticSearch es totalmente compatible con la búsqueda casi en tiempo real de Apache Lucene.
    • El manejo de multiempresas no es una configuración especial, donde con Solr es necesaria una configuración más avanzada.
    • ElasticSearch presenta el concepto de Gateway, que facilita las copias de seguridad completas.

    Desventajas :

    • Solo un desarrollador principal [ya no se aplica según la organización actual de elasticitarch GitHub , además de tener una base de committer bastante activa en primer lugar]
    • Sin función de auto calentamiento [no aplicable más de acuerdo con la nueva API de Index Warmup ]

Respuesta inicial

Son tecnologías completamente diferentes que abordan casos de uso completamente diferentes, por lo que no se pueden comparar en absoluto de ninguna manera significativa:

  • Apache Solr – Apache Solr ofrece las capacidades de Lucene en un servidor de búsqueda rápido y fácil de usar con características adicionales como faceting, escalabilidad y mucho más.

  • Amazon ElastiCache : Amazon ElastiCache es un servicio web que facilita la implementación, el funcionamiento y la escala de una memoria caché en la memoria en la nube.

    • Tenga en cuenta que Amazon ElastiCache cumple con el protocolo Memcached, un sistema de caché de objetos de memoria ampliamente adoptado, por lo que el código, las aplicaciones y las herramientas populares que utiliza hoy en día con los entornos Memcached existentes funcionarán perfectamente con el servicio (consulte Memcached para obtener más detalles).

[énfasis mío]

Quizás esto se ha confundido con las siguientes dos tecnologías relacionadas de una forma u otra:

  • ElasticSearch – Es un motor de búsqueda de fuente abierta (Apache 2), distribuido, RESTful, construido sobre Apache Lucene.

  • Amazon CloudSearch – Amazon CloudSearch es un servicio de búsqueda completamente administrado en la nube que permite a los clientes integrar fácilmente la funcionalidad de búsqueda rápida y altamente escalable en sus aplicaciones.

Las ofertas de Solr y ElasticSearch suenan sorprendentemente similares a primera vista, y ambas utilizan el mismo motor de búsqueda de back-end, a saber, Apache Lucene .

Si bien Solr es más antiguo, bastante versátil y maduro, y se usa mucho en consecuencia, ElasticSearch se ha desarrollado específicamente para abordar las deficiencias de Solr con los requisitos de escalabilidad en entornos de nube modernos, que son difíciles de abordar con Solr .

Como tal, probablemente sería más útil comparar ElasticSearch con el recientemente presentado Amazon CloudSearch (vea la publicación introductoria Comenzar a buscar en una hora por menos de $ 100 / mes ), porque ambos afirman cubrir los mismos casos de uso en principio.

Veo que algunas de las respuestas anteriores están un poco desactualizadas. Desde mi punto de vista, y trabajo tanto con Solr (nube y sin nube) como con ElasticSearch diariamente, aquí hay algunas diferencias interesantes:

  • Comunidad: Solr tiene una comunidad de usuarios, desarrolladores y contribuyentes más grande y más madura. ES tiene una comunidad de usuarios más pequeña pero activa y una creciente comunidad de contribuyentes
  • Madurez: Solr es más maduro, pero ES ha crecido rápidamente y lo considero estable
  • Rendimiento: difícil de juzgar. Yo / nosotros no hemos hecho pruebas de rendimiento directo. Una persona en LinkedIn sí comparó Solr vs. ES vs. Sensei una vez, pero los resultados iniciales deberían ignorarse porque usaron una configuración no experta tanto para Solr como para ES.
  • Diseño: a la gente le encanta Solr. La API de Java es algo prolija, pero a la gente le gusta cómo se arma. El código de Solr lamentablemente no siempre es muy bonito. Además, ES tiene sharding, replicación en tiempo real, documento y enrutamiento integrados. Mientras que algo de esto existe en Solr, también, se siente un poco como una idea tardía.
  • Soporte: hay compañías que brindan soporte tecnológico y de consultoría tanto para Solr como para ElasticSearch. Creo que la única compañía que brinda soporte para ambos es Sematext (revelación: soy el fundador de Sematext)
  • Escalabilidad: ambos pueden escalarse a clústeres muy grandes. ES es más fácil de escalar que la versión anterior a Solr 4.0 de Solr, pero con Solr 4.0 ya no es el caso.

Para obtener una cobertura más completa del tema Solr vs. ElasticSearch, consulte http://blog.sematext.com/2012/08/23/solr-vs-elasticsearch-part-1-overview/ . Esta es la primera publicación de la serie de publicaciones de Sematext que hace una comparación directa y neutral de Solr vs. ElasticSearch. Divulgación: trabajo en Sematext.

Veo que mucha gente aquí ha respondido a esta pregunta de ElasticSearch vs Solr en términos de características y funcionalidad, pero no veo mucha discusión aquí (ni en ningún otro lado) con respecto a cómo se comparan en términos de rendimiento.

Es por eso que decidí llevar a cabo mi propia investigación . Tomé un micro-servicio de fuente de datos heterogéneo ya codificado que ya usaba Solr para búsqueda de términos. Cambié Solr por ElasticSearch, luego ejecuté ambas versiones en AWS con una aplicación de prueba de carga ya codificada y capturé las métricas de rendimiento para el análisis posterior.

Esto es lo que encontré. ElasticSearch tuvo un rendimiento 13% más alto cuando se trataba de documentos de indexación, pero Solr era diez veces más rápido. Cuando se trataba de consultar documentos, Solr tenía cinco veces más rendimiento y era cinco veces más rápido que ElasticSearch.

He estado trabajando en la búsqueda solr y elástica para aplicaciones .Net. La principal diferencia con la que me he enfrentado es

Búsqueda elástica

  • Más código y menos configuración, sin embargo hay APIs para cambiar, pero aún así es un cambio de código
  • para tipos complejos, escriba dentro de tipos, es decir, tipos nesteds (no fue posible lograrlo en solr)

Solr:

  • menos código y más configuración y, por lo tanto, menos mantenimiento
  • para agrupar los resultados durante la consulta (mucho trabajo para lograr en la búsqueda elástica en resumen, no de manera directa)

Desde la larga historia de Apache Solr, creo que una fortaleza del Solr es su ecosistema . Hay muchos complementos de Solr para diferentes tipos de datos y propósitos.

pila de solr

Plataforma de búsqueda en las siguientes capas de abajo hacia arriba:

  • Datos
    • Propósito: Representar varios tipos de datos y fonts
  • Construcción de documentos
    • Propósito: generar información del documento para indexar
  • Indexación y búsqueda
    • Propósito: crear y consultar un índice de documento
  • Mejora de lógica
    • Propósito: lógica adicional para procesar consultas de búsqueda y resultados
  • Servicio de plataforma de búsqueda
    • Propósito: Agregar funcionalidades adicionales del núcleo del motor de búsqueda para proporcionar una plataforma de servicio.
  • Aplicación de interfaz de usuario
    • Propósito: interfaz de búsqueda de usuario final o aplicaciones

Artículo de referencia: búsqueda empresarial

Si bien todos los enlaces anteriores tienen mérito, y me han beneficiado mucho en el pasado, como lingüista “expuesto” a varios motores de búsqueda Lucene durante los últimos 15 años, debo decir que el desarrollo de búsqueda elástica es muy rápido en Python. Dicho esto, parte del código me pareció no intuitivo. Entonces, me acerqué a un componente de la stack ELK, Kibana, desde una perspectiva de código abierto, y descubrí que podía generar el código algo críptico de búsqueda elástica con mucha facilidad en Kibana. Además, también pude consultar las consultas sobre el sentido de Chrome en Kibana. Si usa Kibana para evaluar es, acelerará aún más su evaluación. Lo que demoró horas en ejecutarse en otras plataformas estaba funcionando en JSON en Sense en la parte superior de elasticsearch (interfaz RESTful) en unos pocos minutos en el peor (conjuntos de datos más grandes); en segundos en el mejor de los casos La documentación de elasticsearch, aunque tenía más de 700 páginas, no respondía las preguntas que tenía que normalmente se resolverían en SOLR u otra documentación de Lucene, lo que evidentemente tomó más tiempo para analizar. Además, es posible que desee echar un vistazo a Agregados en elástico de búsqueda, que han llevado a Faceting a un nuevo nivel.

Una imagen más grande: si está haciendo ciencia de datos, análisis de texto o lingüística computacional, elasticsearch tiene algunos algoritmos de clasificación que parecen innovar bien en el área de recuperación de información. Si está utilizando algoritmos TF / IDF, Frecuencia de texto / Frecuencia inversa del documento, elasticsearch amplía el algoritmo de los años 60 a un nuevo nivel, incluso utilizando BM25, Mejor coincidencia 25 y otros algoritmos de Clasificación de relevancia. Por lo tanto, si está anotando o clasificando palabras, frases u oraciones, elasticsearch hace esta calificación sobre la marcha, sin la gran sobrecarga de otros enfoques de análisis de datos que toman horas, otro ahorro de tiempo de búsqueda elástica. Con es, combinando algunas de las fortalezas de la agrupación de agregaciones con la puntuación y clasificación de relevancia de datos JSON en tiempo real, puede encontrar una combinación ganadora, dependiendo de su enfoque ágil (historias) o arquitectónico (casos de uso).

Nota: vi una discusión similar sobre las agregaciones anteriores, pero no sobre las agregaciones y la calificación de relevancia, mi disculpa por cualquier superposición. Divulgación: no trabajo para elástico y no podré beneficiarme en un futuro cercano de su excelente trabajo debido a un camino arquitectónico diferente, a menos que haga algún trabajo de caridad con elasticsearch, lo cual no sería una mala idea.

He creado una tabla de grandes diferencias entre elasticsearch y Solr y splunk, puedes usarla como actualización de 2016: enter image description here

He usado Elasticsearch durante 3 años y Solr durante aproximadamente un mes, siento que el cluster elástico es bastante fácil de instalar en comparación con la instalación de Solr. Elasticsearch tiene un conjunto de documentos de ayuda con una gran explicación. En uno de los casos de uso me quedé atrapado con la Agregación de Histogtwigs que estaba disponible en ES pero que no se encontró en Solr.

Si ya está usando SOLR, permanezca apegado a él. Si está comenzando, vaya a Búsqueda elástica.

Los problemas principales máximos se han solucionado en SOLR y es bastante maduro.

Solo uso Elastic-search. Desde que encontré solr es muy difícil comenzar. Funciones de búsqueda elástica:

  1. Fácil de comenzar, muy pocas configuraciones. Incluso un novato puede configurar un clúster paso a paso.
  2. API relajante simple que utiliza la consulta NoSQL. Y muchas bibliotecas de idiomas para un fácil acceso.
  3. Buen documento, puedes leer el libro:. Hay una versión web en el sitio web oficial.

Agregar un documento nested en solr muy compleja y la búsqueda de datos nesteds también es muy compleja. pero Elastic Search es fácil de agregar documento nested y búsqueda

Imagine el caso de uso:

  1. Mucho (más de 100) de índices de búsqueda pequeños (10Mb-100Mb, 1000-100000 documentos).
  2. Están usando muchas aplicaciones (microservicios)
  3. Cada aplicación puede usar más de un índice
  4. Pequeño por índice de índice, sí. Pero la gran carga (cientos de búsquedas-solicitudes por segundo) y las solicitudes son complejas (agregaciones múltiples, condiciones, etc.)
  5. Los tiempos de inactividad no están permitidos
  6. Todo eso está funcionando durante años y en constante crecimiento.

La idea de tener instancias individuales de ES por cada índice es una gran sobrecarga en este caso.

Según mi experiencia, este tipo de caso de uso es muy complejo para ser compatible con Elasticsearch.

¿Por qué?

PRIMERO.

El principal problema es la despreocupación fundamental de la compatibilidad de respaldo.

¡Los cambios de última hora son geniales! (Nota: imagínese SQL-server que requiere que haga pequeños cambios en todas sus declaraciones de SQL, cuando se actualiza … no lo puedo imaginar, pero para ES es normal)

¡Las depredaciones que caerán en la próxima gran versión son tan sexy! (Nota: ya sabes, Java contiene algunas objeciones, que tienen más de 20 años, pero aún funcionan en la versión de Java real …)

Y no solo eso, a veces incluso tienes algo que no está documentado en ninguna parte (personalmente me encontré solo una vez, pero …)

Asi que. Si desea actualizar ES (porque necesita nuevas características para alguna aplicación o quiere obtener una solución de errores), está en el infierno. Especialmente si se trata de la actualización de la versión principal.

Client API no respaldará compatible. La configuración del índice no será compatible. Y actualizar todas las aplicaciones / servicios en el mismo momento con la actualización de ES no es realista.

Pero debes hacerlo de vez en cuando. Ninguna otra manera.

Los índices existentes se actualizan automáticamente? – Sí. Pero no lo ayudará cuando deba cambiar algunas configuraciones de índice anterior.

Para vivir con eso, necesita invertir constantemente mucho poder en … avanzar la compatibilidad de sus aplicaciones / servicios con lanzamientos futuros de ES. O necesita construir (y de todos modos apoyar constantemente) algún tipo de middleware entre su aplicación / servicios y ES, que le proporcione una API de cliente compatible. (Y no puede usar Transport Client (porque requiere la actualización de jar para cada actualización de ES de versión secundaria), y este hecho no le hace la vida más fácil)

¿Es simple y barato? No, no es. Lejos de ahi. El mantenimiento continuo de una infraestructura compleja basada en ES es costosa en todos los sentidos posibles.

SEGUNDO. API simple? Bueno … en realidad no. Cuando realmente está usando condiciones complejas y agregaciones … La solicitud JSON con 5 niveles nesteds es lo que sea, pero no es simple.


Lamentablemente, no tengo experiencia con SOLR, no puedo decir nada al respecto.

Pero Sphinxsearch es mucho mejor en este escenario, ya que es totalmente compatible con SphinxQL.

Nota: Sphinxsearch / Manticore son realmente interesantes. No es basado en Lucine, y como resultado seriamente diferente. Contiene varias características únicas de la caja que ES no tiene y muy rápido con índices de tamaño pequeño / mediano.