search solr lucene elasticsearch

Solr vs. ElasticSearch



elasticsearch vs solr (12)

¿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 el alcance de la pregunta se ha corregido, también podría agregar algo al respecto:

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

  • Bob Yoplait ya vinculó la respuesta de Kimchy con ElasticSearch, Sphinx, Lucene, Solr, Xapian. ¿Qué encaja para 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 una facilidad de uso en comparación con Solr.

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

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

  • El artículo de Wikipedia sobre ElasticSearch cita una comparison de la reputada revista German iX, que enumera ventajas y desventajas, que resume bastante bien lo que ya se ha dicho anteriormente:

    Ventajas :

    • ElasticSearch se distribuye. No se requiere un proyecto separado. Las réplicas también están casi en tiempo real, lo que se denomina "replicación por inserción".
    • ElasticSearch es totalmente compatible con la búsqueda casi en tiempo real de Apache Lucene.
    • El manejo de multitenidad no es una configuración especial, donde con Solr es necesaria una configuración más avanzada.
    • ElasticSearch introduce el concepto de la puerta de enlace, que facilita las copias de seguridad completas.

    Desventajas :

Respuesta inicial

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

  • Apache Solr : Apache Solr ofrece las capacidades de Lucene en un servidor de búsqueda rápida y fácil de usar con funciones adicionales como facetado, escalabilidad y mucho más

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

    • Tenga en cuenta que Amazon ElastiCache es compatible con el protocolo de Memcached, un sistema de almacenamiento en 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 de Memcached existentes funcionarán perfectamente con el servicio (consulte Memcached para obtener más información).

[énfasis mío]

Tal vez esto se haya confundido con las siguientes dos tecnologías relacionadas de una manera u otra:

  • ElasticSearch : es un motor de búsqueda de código abierto (Apache 2), distribuido, desarrollado, sobre Apache Lucene.

  • Amazon CloudSearch : Amazon CloudSearch es un servicio de búsqueda totalmente 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 usan el mismo motor de búsqueda, es decir, Apache Lucene .

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

Como tal, probablemente sería más útil comparar ElasticSearch con la recientemente presentada Amazon CloudSearch (consulte la publicación introductoria Comience a buscar en una hora por menos de $ 100 al mes ), ya que ambos afirman cubrir los mismos casos de uso en principio.

Agregue un documento anidado en solr búsqueda de datos muy compleja y anidada también muy compleja. Pero Elastic Search es fácil de agregar documentos anidados y buscar

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

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

  • Datos
    • Propósito: Representar varios tipos de datos y fuentes
  • Construcción de documentos
    • Propósito: Construir información del documento para indexar
  • Indexación y búsqueda
    • Propósito: construir y consultar un índice de documento
  • Mejora logica
    • Propósito: Lógica adicional para procesar consultas de búsqueda y resultados.
  • Servicio de plataforma de busqueda
    • 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 de empresas.

He creado una tabla con las principales diferencias entre elasticsearch, Solr y Splunk. Puedes usarla como actualización de 2016:

He estado trabajando tanto en solr como en la búsqueda elástica de aplicaciones .Net. La principal diferencia a la que me he enfrentado es.

Búsqueda elástica:

  • Más código y menos configuración, sin embargo, hay que cambiar los api pero aún es un cambio de código
  • para tipos complejos, escriba dentro de tipos, es decir, tipos anidados (no se pudo lograr en solr)

Solr:

  • Menos código y más configuración y, por tanto, menos mantenimiento.
  • para agrupar los resultados durante la consulta (mucho trabajo para lograr en la búsqueda elástica en definitiva, no directamente)

He utilizado Elasticsearch durante 3 años y Solr durante aproximadamente un mes. Creo que el cluster de elasticsearch 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. Uno de los casos de uso en el que estuve atascado con la agregación de histogramas que estaba disponible en ES, no se encontró en Solr.

Imagina el caso de uso:

  1. Una gran cantidad (100+) de índices de búsqueda pequeños (10Mb-100Mb, 1000-100000).
  2. Se están utilizando por una gran cantidad de aplicaciones (microservicios).
  3. Cada aplicación puede utilizar más de un índice.
  4. Pequeño por índice de tamaño, sí. Pero la carga enorme (cientos de solicitudes de búsqueda por segundo) y las solicitudes son complejas (agregaciones múltiples, condiciones, etc.)
  5. No se permiten tiempos muertos
  6. Todo eso lleva años trabajando, y está en constante crecimiento.

La idea de tener una instancia de ES individual para cada índice es una sobrecarga enorme en este caso.

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

¿Por qué?

PRIMERO.

El principal problema es la compatibilidad con la parte posterior de la base, por descuido

¡Los cambios de ruptura son tan geniales! (Nota: imagine un servidor SQL que requiere que haga pequeños cambios en todas sus declaraciones SQL, cuando se actualice ... no puedo imaginarlo. Pero para ES es normal)

¡Las depresiones que caerán en el próximo lanzamiento importante son tan sexys! (Nota: ya sabes, Java contiene algunas desaprobaciones, que tienen más de 20 años, pero aún funcionan en la versión real de Java ...)

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

Asi que. Si desea actualizar ES (porque necesita nuevas funciones 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.

La API del cliente no será 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? - si Pero no le ayuda cuando necesita cambiar alguna configuración de índice anterior.

Para vivir con eso, necesita invertir constantemente una gran cantidad de poder en ... la compatibilidad hacia adelante de sus aplicaciones / servicios con las futuras versiones de ES. O necesita crear (y, de todos modos, admitir constantemente) algún tipo de middleware entre su aplicación / servicios y ES, que le proporciona una API cliente compatible. (Y, no puede usar Transport Client (porque requería una actualización jar para todas las actualizaciones ES de versiones menores), y este hecho no le hace la vida más fácil)

¿Se ve simple y barato? No, no es. Lejos de ahi. El mantenimiento continuo de la infraestructura compleja que se basa en ES es muy caro en todos los sentidos posibles.

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

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

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

Nota: Sphinxsearch / Manticore son de hecho interesantes. No está basada en Lucine, y como resultado es muy diferente. Contiene varias características únicas de la caja que ES no tiene y se vuelven locas con índices de tamaño pequeño / medio.

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 de 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, algunos de los códigos me parecieron no intuitivos. Entonces, contacté con un componente de la pila de ELK, Kibana, desde una perspectiva de código abierto, y descubrí que podía generar el código un tanto críptico de la búsqueda de elastics en Kibana con mucha facilidad. Además, también podría incluir consultas de Chrome Sense en Kibana. Si usa Kibana para evaluar, acelerará aún más su evaluación. Lo que tardó horas en ejecutarse en otras plataformas estaba en funcionamiento en JSON en Sense encima de elasticsearch (interfaz RESTful) en unos pocos minutos (conjuntos de datos más grandes); en segundos en el mejor de los casos. La documentación para elasticsearch, mientras que más de 700 páginas, no respondía a las preguntas que normalmente se resolvían en SOLR u otra documentación de Lucene, lo que obviamente demoraba más en analizar. Además, es posible que desee echar un vistazo a los agregados en la búsqueda elástica, que han llevado Facetado a un nuevo nivel.

Imagen más amplia: 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 algún algoritmo TF / IDF, Frecuencia de texto / Frecuencia de documentos inversa, elasticsearch extiende el algoritmo de esta década de 1960 a un nuevo nivel, incluso utilizando BM25, Best Match 25 y otros algoritmos de clasificación de relevancia. Entonces, si está calificando o clasificando palabras, frases u oraciones, elasticsearch realiza esta calificación sobre la marcha, sin la gran sobrecarga de otros enfoques de análisis de datos que llevan horas, otro ahorro de tiempo de elasticsearch. Con es, combinando algunas de las fortalezas del agrupamiento de las agregaciones con la clasificación y clasificación de relevancia de los datos JSON en tiempo real, puede encontrar una combinación ganadora, dependiendo de su enfoque ágil (historias) o arquitectónico (casos de uso).

Nota: vimos una discusión similar sobre agregaciones arriba, pero no sobre agregaciones y puntuación de relevancia - mis disculpas por cualquier superposición. Divulgación: no trabajo para elástico y no podré beneficiarme en el futuro cercano de su excelente trabajo debido a un camino arquitectónico diferente, a menos que haga un trabajo de caridad con elasticsearch, lo cual no sería una mala idea

Si ya estás usando SOLR, quédate con él. Si estás iniciando, ve a la búsqueda elástica.

Se han solucionado los problemas principales máximos en SOLR y es bastante maduro.

Solo uso la búsqueda elástica. Desde que encontré solr es muy difícil empezar. Características de la búsqueda elástica:

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

Veo que algunas de las respuestas anteriores están un poco desactualizadas. Desde mi perspectiva, y trabajo con Solr (Cloud y no Cloud) y 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 comunidad de contribuyentes en crecimiento
  • 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 puntos de referencia de rendimiento directo. Una persona de LinkedIn comparó Solr contra ES con Sensei una vez, pero los resultados iniciales deben ignorarse porque utilizaron una configuración no experta tanto para Solr como para ES.
  • Diseño: La gente ama a Solr. La API de Java es un tanto detallada, pero a la gente le gusta cómo se organiza. El código de Solr desafortunadamente no siempre es muy bonito. Además, ES tiene fragmentación, replicación en tiempo real, documentos y enrutamiento incorporados. Si bien algo de esto también existe en Solr, se siente un poco como un pensamiento posterior.
  • Soporte: hay empresas que proporcionan soporte técnico y de consultoría tanto para Solr como para ElasticSearch. Creo que la única compañía que brinda soporte para ambos es Sematext (divulgación: soy el fundador de Sematext)
  • Escalabilidad: ambos se pueden escalar a grupos muy grandes. ES es más fácil de escalar que la versión Pre-Solr 4.0 de Solr, pero con Solr 4.0 ya no es así.

Para obtener más información sobre el tema de Solr vs. ElasticSearch, visite 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 realiza una comparación directa y neutral entre Solr y ElasticSearch. Divulgación: trabajo en sematexto.

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í (o en otra parte) sobre cómo se comparan en términos de rendimiento.

Por eso decidí realizar mi propia investigation . Tomé un microservicio de fuente de datos heterogéneo ya codificado que ya usaba Solr para la 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 un 13% más alto cuando se trató de indexar documentos, pero Solr fue diez veces más rápido. Cuando se trataba de solicitar documentos, Solr tenía un rendimiento cinco veces mayor y era cinco veces más rápido que ElasticSearch.