Pregunta

Estoy buscando a través de otros métodos de búsqueda en lugar de tener una gran consulta SQL. Vi elasticsearch recientemente y jugaba con zas "Whoosh" (una implementación de Python de un motor de búsqueda).

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

¿Fue útil?

Solución

Como el creador de Elasticsearch, tal vez pueda darle un poco de razonamiento sobre por qué seguí adelante y creé en el primer lugar:.)

El uso de pura Lucene es un reto. Hay muchas cosas que usted necesita para cuidar de si usted quiere que haga muy bien, y también, su biblioteca, así que no hay soporte distribuido, es sólo una biblioteca de Java embebido que es necesario mantener.

En términos de facilidad de uso Lucene, camino de regreso cuando (casi 6 años), creé brújula. Su objetivo era simplificar el uso de Lucene Lucene y hacer todos los días más simple. Lo que me encontré con una y otra vez es el requisito para poder tener Brújula distribuido. Empecé a trabajar en él desde dentro del compás, mediante la integración con soluciones de redes de datos como GigaSpaces, coherencia y terracota, pero no es suficiente.

En su esencia, una solución Lucene distribuido necesita ser fragmentada. También, con el avance de HTTP y JSON como APIs ubicuos, significa que una solución que muchos sistemas diferentes con diferentes idiomas puede fácilmente ser utilizado.

Esta es la razón por la que siguió 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 es también una solución para la exposición de un servidor de indexación / búsqueda a través de HTTP, pero yo diría que Elasticsearch proporciona una gran modelo distribuido superior y facilidad de uso (aunque actualmente carecen de algunas de las funciones de búsqueda, pero no por mucho tiempo, y en cualquier caso, el plan es conseguir que todos Brújula características en Elasticsearch). Por supuesto, soy parcial, ya que he creado Elasticsearch, por lo que puede que tenga que comprobar por sí mismo.

En cuanto a la Esfinge, no he usado, así que no puedo comentar. Lo que puedo hacer referencia a que es este hilo en el foro Sphinx que creo que demuestra la modelo distribuido superior del Elasticsearch.

Por supuesto, Elasticsearch tiene muchas más funciones que acaba de ser distribuidos. En realidad, es construido con una nube en mente. Puede comprobar la lista de características en el sitio.

Otros consejos

He utilizado Sphinx, Solr y Elasticsearch. Solr / Elasticsearch se construye encima de Lucene. Se agrega muchas funcionalidades comunes:. Api servidor web, facetado, el almacenamiento en caché, etc.

Si quiere simplemente tener una configuración de búsqueda de texto simple completa, Sphinx es una mejor opción.

Si desea personalizar su búsqueda en absoluto, Elasticsearch y Solr son las mejores opciones. Son muy extensible: puede escribir sus propios plugins para ajustar la puntuación resultado.

Algunos usos de ejemplo:

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

Utilizamos Lucene para indexar y regularidad    buscar decenas de millones de documentos.    Las búsquedas son lo suficientemente rápido, y utilizamos    actualizaciones incrementales que no toman    mucho tiempo. Que no llevarnos algún tiempo    para llegar hasta aquí. Los puntos fuertes de    Lucene es su escalabilidad, una gran    gama de características y un activo    comunidad de desarrolladores. usando desnuda    Lucene requiere la programación en Java.

Si usted está comenzando de nuevo, la herramienta para usted en la familia Lucene es Solr , la cual es mucho más fácil de instalar que Lucene desnuda, y tiene casi todo el poder de Lucene. Se puede importar documentos de bases de datos fácilmente. Solr está escrito en Java, por lo que cualquier modificación de Solr requiere conocimientos de Java, pero se puede hacer mucho con sólo ajustar los archivos de configuración.

También he oído cosas buenas sobre Sphinx, especialmente en conjunción con una base de datos MySQL. no lo han utilizado, sin embargo.

OMI, se debe elegir de acuerdo a:

  • La funcionalidad requerida - por ejemplo, Por qué necesita un analizador lingüístico francés? Lucene y Solr tiene uno, no sé acerca de los otros.
  • El dominio del lenguaje de implementación - No toque de Java Lucene si usted no sabe de Java. Es posible que necesite C ++ para hacer cosas con Sphinx. Lucene también ha sido portado en otra idiomas . Esto es sobre todo importante si se quiere extender el motor de búsqueda.
  • Facilidad de experimentación -. Creo Solr es el mejor en este aspecto
  • Interfaz con otro software - Esfinge tiene una buena interfaz con MySQL. Solr es compatible con las interfaces de rubí, XML y JSON como un servidor REST. Lucene sólo le da acceso mediante programación a través de Java. Brújula y Hibernate Buscar son envolturas de Lucene que lo integran en los marcos más grandes.

Utilizamos Sphinx en un proyecto de búsqueda vertical con 10.000.000 + de los registros de base de datos MySQL y 10+ diferente. Tiene muy excelente soporte para MySQL y un alto rendimiento en la indexación, la investigación es rápido pero quizás un poco menos de Lucene. Sin embargo, es la elección correcta si es necesario indexar rápidamente todos los días y utilizar una base de datos MySQL.

Mi 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 la muestra:

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

Esfinge tiempo de consulta:

0.001 sec.

Sphinx tiempo de consulta (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.

MySQL tiempo de consulta (1k concurrente):

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

El único elasticsearch vs comparación de rendimiento Solr que he podido encontrar hasta ahora está aquí:

Solr vs A muerte elasticsearch!

Lucene es agradable y todo, pero la palabra de parada establecido es horrible. He tenido que añadir manualmente un montón de palabras vacías a StopAnalyzer.ENGLISH_STOP_WORDS_SET sólo para obtener en cualquier lugar cerca utilizable.

No he utilizado Sphinx pero sé personas juran por su velocidad y casi mágica "que facilitan la configuración de genialidad" relación.

Trate indextank.

Como el caso de la búsqueda elástica, que fue concebido para ser mucho más fácil de usar que Lucene / Solr. También incluye sistema de puntuación muy flexible que puede ser ajustado sin reindexar.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top