Actualmente estoy buscando otros métodos de búsqueda en lugar de tener una gran consulta SQL. Vi Elasticsearch recientemente y jugué con whoosh (una implementación de Python de un motor de búsqueda).
¿Puede dar razones para su (s) elección (es)?
Actualmente estoy buscando otros métodos de búsqueda en lugar de tener una gran consulta SQL. Vi Elasticsearch recientemente y jugué con whoosh (una implementación de Python de un motor de búsqueda).
¿Puede dar razones para su (s) elección (es)?
Respuestas:
Como creador de ElasticSearch, tal vez pueda darle un poco de razonamiento sobre por qué seguí adelante y lo creé en primer lugar :).
Usar puro Lucene es un desafío. Hay muchas cosas que debe tener en cuenta si quiere que realmente funcione bien, y además, es una biblioteca, por lo que no tiene soporte distribuido, es solo una biblioteca Java integrada que necesita mantener.
En términos de usabilidad de Lucene, hace mucho tiempo (hace casi 6 años), creé Compass. Su objetivo era simplificar el uso de Lucene y simplificar el uso diario de Lucene. Lo que encontré una y otra vez es el requisito de poder distribuir Compass. Comencé a trabajar en él desde Compass, integrándome con soluciones de cuadrícula de datos como GigaSpaces, Coherence y Terracotta, pero no es suficiente.
En esencia, una solución Lucene distribuida necesita ser fragmentada. Además, con el avance de HTTP y JSON como API ubicuas, significa que se puede usar fácilmente una solución que permite utilizar muchos sistemas diferentes con diferentes idiomas.
Es por eso que seguí adelante y creé ElasticSearch. Tiene un modelo distribuido muy avanzado, habla JSON de forma nativa y expone muchas funciones de búsqueda avanzada, todas expresadas sin problemas a través de 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 facilidad de uso (aunque actualmente carece de algunas de las características de búsqueda, pero no por mucho tiempo, y en cualquier caso, el plan es obtener todas las características de Compass en ElasticSearch). Por supuesto, soy parcial, ya que creé ElasticSearch, por lo que es posible que deba verificarlo usted mismo.
En cuanto a Sphinx, no lo he usado, así que no puedo comentar. Lo que puedo recomendar es este hilo en el foro Sphinx que creo que prueba el modelo distribuido superior de ElasticSearch.
Por supuesto, ElasticSearch tiene muchas más funciones que solo ser distribuido. En realidad, está construido con una nube en mente. Puede consultar la lista de funciones en el sitio.
He usado Sphinx, Solr y Elasticsearch. Solr / Elasticsearch están construidos sobre Lucene. Agrega muchas funcionalidades comunes: API de servidor web, facetado, almacenamiento en caché, etc.
Si desea tener una configuración simple de búsqueda de texto completo, Sphinx es una 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 resultados.
Algunos usos de ejemplo:
Usamos 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 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 desnudo 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 bases de datos fácilmente. Solr está escrito en Java, por lo que cualquier modificación de Solr requiere conocimiento de Java, pero puede hacer mucho simplemente modificando los archivos de configuración.
También he escuchado cosas buenas sobre Sphinx, especialmente en conjunto con una base de datos MySQL. Sin embargo, no lo he usado.
OMI, debes elegir de acuerdo con:
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 excelente soporte para MySQL y un alto rendimiento en indexación, la investigación es rápida pero quizás un poco menos que Lucene. Sin embargo, es la opción correcta si necesita indexar rápidamente todos los días y usar un db MySQL.
Un experimento para comparar ElasticSearch y Solr
My sphinx.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
}
Script 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 muestra:
[array] =>
"id" => 123,
"title" => "My post title.",
"content" => "My <p>post</p> content.",
...
[ and other fields ]
Tiempo de consulta de 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 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)
La única comparación de rendimiento de elasticsearch vs solr que he podido encontrar hasta ahora está aquí:
Lucene es agradable y todo, pero su conjunto de palabras de parada es horrible. Tuve que agregar manualmente una tonelada de palabras de detención a StopAnalyzer.ENGLISH_STOP_WORDS_SET solo para que sea casi utilizable.
No he usado Sphinx, pero sé que la gente confía en su velocidad y en su relación casi mágica de "facilidad de configuración e increíble".
Prueba indextank.
Como el caso de la búsqueda elástica, se concibió 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 ajustar sin reindexar.