tutorial solr lucene elasticsearch sphinx xapian

tutorial - solr vs elasticsearch



ElasticSearch, Sphinx, Lucene, Solr, Xapian. ¿Qué encaja para qué uso? (9)

He utilizado Sphinx, Solr y Elasticsearch. Solr / Elasticsearch se construyen sobre Lucene. Agrega muchas funcionalidades comunes: servidor web api, facetado, almacenamiento en caché, etc.

Si solo desea tener una configuración de búsqueda de texto completa, Sphinx es la mejor opción.

Si desea personalizar su búsqueda, Elasticsearch y Solr son las mejores opciones. Son muy extensibles: puede escribir sus propios complementos para ajustar la puntuación de los resultados.

Algunos usos de ejemplo:

  • Esfinge: craigslist.org
  • Solr: Cnet, Netflix, digg.com
  • Elasticsearch: Foursquare, Github

Actualmente estoy buscando otros métodos de búsqueda en lugar de tener una gran consulta SQL. He visto elasticsearch recientemente y jugué con whoosh (una implementación de Python de un motor de búsqueda).

¿Puede dar razones para su elección (s)?

Intenta indextank.

Como el caso de la búsqueda elástica, fue concebido para ser mucho más fácil de usar que lucene / solr. También incluye un sistema de puntuación muy flexible que se puede modificar sin tener que volver a indexar.

Lucene es agradable y todo, pero su conjunto de palabras de parada es horrible. Tuve que agregar manualmente un montón de palabras de parada a StopAnalyzer.ENGLISH_STOP_WORDS_SET solo para poder usarlo en cualquier lugar cercano.

No he usado Sphinx, pero sé que la gente confía en su velocidad y en la casi mágica "facilidad de configuración a lo increíble".

Mi esfinge.conf

source post_source { type = mysql sql_host = localhost sql_user = *** sql_pass = *** sql_db = *** sql_port = 3306 sql_query_pre = SET NAMES utf8 # query before fetching rows to index sql_query = SELECT *, id AS pid, CRC32(safetag) as safetag_crc32 FROM hb_posts sql_attr_uint = pid # pid (as ''sql_attr_uint'') is necessary for sphinx # this field must be unique # that is why I like sphinx # you can store custom string fields into indexes (memory) as well sql_field_string = title sql_field_string = slug sql_field_string = content sql_field_string = tags sql_attr_uint = category # integer fields must be defined as sql_attr_uint sql_attr_timestamp = date # timestamp fields must be defined as sql_attr_timestamp sql_query_info_pre = SET NAMES utf8 # if you need unicode support for sql_field_string, you need to patch the source # this param. is not supported natively sql_query_info = SELECT * FROM my_posts WHERE id = $id } index posts { source = post_source # source above path = /var/data/posts # index location charset_type = utf-8 }

Guión de prueba:

<?php require "sphinxapi.php"; $safetag = $_GET["my_post_slug"]; // $safetag = preg_replace("/[^a-z0-9/-_]/i", "", $safetag); $conf = getMyConf(); $cl = New SphinxClient(); $cl->SetServer($conf["server"], $conf["port"]); $cl->SetConnectTimeout($conf["timeout"]); $cl->setMaxQueryTime($conf["max"]); # set search params $cl->SetMatchMode(SPH_MATCH_FULLSCAN); $cl->SetArrayResult(TRUE); $cl->setLimits(0, 1, 1); # looking for the post (not searching a keyword) $cl->SetFilter("safetag_crc32", array(crc32($safetag))); # fetch results $post = $cl->Query(null, "post_1"); echo "<pre>"; var_dump($post); echo "</pre>"; exit("done"); ?>

Resultado de la muestra:

[array] => "id" => 123, "title" => "My post title.", "content" => "My <p>post</p> content.", ... [ and other fields ]

Tiempo de consulta de la esfinge:

0.001 sec.

Tiempo de consulta Sphinx (1k concurrente):

=> 0.346 sec. (average) => 0.340 sec. (average of last 10 query)

Tiempo de consulta de MySQL:

"SELECT * FROM hb_posts WHERE id = 123;" => 0.001 sec.

Tiempo de consulta MySQL (1k concurrente):

"SELECT * FROM my_posts WHERE id = 123;" => 1.612 sec. (average) => 1.920 sec. (average of last 10 query)

Usamos a Lucene regularmente para indexar y buscar decenas de millones de documentos. Las búsquedas son lo suficientemente rápidas, y utilizamos actualizaciones incrementales que no llevan mucho tiempo. Nos llevó algo de tiempo llegar hasta aquí. Los puntos fuertes de Lucene son su escalabilidad, una amplia gama de características y una comunidad activa de desarrolladores. El uso de Lucene básico requiere programación en Java.

Si está comenzando de nuevo, la herramienta para usted en la familia Lucene es Solr , que es mucho más fácil de configurar que Lucene, y tiene casi todo el poder de Lucene. Puede importar documentos de base de datos fácilmente. Los Solr están escritos en Java, por lo que cualquier modificación de Solr requiere conocimiento de Java, pero puede hacer mucho simplemente por ajustar los archivos de configuración.

También escuché cosas buenas sobre Sphinx, especialmente en conjunto con una base de datos MySQL. Aunque no lo he usado.

OMI, debe elegir de acuerdo a:

  • La funcionalidad requerida, por ejemplo, ¿necesitas un stemmer francés? Lucene y Solr tienen una, no sé sobre las otras.
  • Competencia en el lenguaje de implementación: no toque Java Lucene si no conoce Java. Es posible que necesites C ++ para hacer cosas con Sphinx. Lucene también ha sido portada a other languages . Esto es principalmente importante si desea extender el motor de búsqueda.
  • Facilidad de experimentación: creo que Solr es mejor en este aspecto.
  • Interfaz con otro software: Sphinx tiene una buena interfaz con MySQL. Solr admite las interfaces ruby, XML y JSON como un servidor RESTful. Lucene solo te da acceso programático a través de Java. Compass y Hibernate Search son envoltorios de Lucene que lo integran en marcos más grandes.

Utilizamos Sphinx en un proyecto de búsqueda vertical con más de 10,000,000 de registros MySql y más de 10 bases de datos diferentes. Tiene un soporte excelente para MySQL y un alto rendimiento en la indexación, la investigación es rápida pero tal vez un poco menos que Lucene. Sin embargo, es la opción correcta si necesita indexar rápidamente todos los días y usar una base de datos MySQL.

Como creador de ElasticSearch, quizás pueda darte un razonamiento sobre por qué seguí adelante y lo creé en primer lugar :).

Usar Lucene puro es un desafío. Hay muchas cosas de las que debe cuidarse si quiere que se desempeñen realmente bien, y también, es una biblioteca, por lo que no hay soporte distribuido, es solo una biblioteca Java incrustada que necesita mantener.

En términos de la facilidad de uso de Lucene, hace muchos años (hace casi 6 años) que creé Compass. Su objetivo era simplificar el uso de Lucene y hacer que Lucene fuera más simple todos los días. Lo que encontré una y otra vez es el requisito de poder distribuir Compass. Comencé a trabajar en ella desde Compass, al integrarme con soluciones de cuadrícula de datos como GigaSpaces, Coherence y Terracotta, pero no es suficiente.

En su núcleo, una solución distribuida de Lucene necesita ser fragmentada. Además, con el avance de HTTP y JSON como API ubicuas, significa que una solución que puede ser utilizada fácilmente por muchos sistemas diferentes con diferentes idiomas.

Por eso seguí adelante y creé ElasticSearch. Tiene un modelo distribuido muy avanzado, habla JSON de forma nativa y expone muchas características de búsqueda avanzada, todas expresadas a la perfección mediante JSON DSL.

Solr también es una solución para exponer un servidor de indexación / búsqueda a través de HTTP, pero diría que ElasticSearch proporciona un modelo distribuido muy superior y fácil de usar (aunque actualmente carece de algunas de las funciones de búsqueda, pero no por mucho tiempo ni en ningún otro lugar). caso, el plan es obtener todas las funciones de Compass en ElasticSearch). Por supuesto, estoy parcializado, ya que creé ElasticSearch, por lo que es posible que deba comprobarlo por sí mismo.

En cuanto a Sphinx, no lo he usado, así que no puedo comentar. Lo que puedo referirte es a este hilo en el foro de Sphinx que creo que prueba el modelo distribuido superior de ElasticSearch.

Por supuesto, ElasticSearch tiene muchas más características que solo ser distribuido. En realidad, está construido con una nube en mente. Puede consultar la lista de características en el sitio.