Elasticsearch, Sphinx, Lucene, Solr, Xapian. Welches passt für welche Verwendung? [abgeschlossen

Question

Ich betrachte derzeit andere Suchmethoden, anstatt eine riesige SQL -Abfrage zu haben. ich sah Elasticsarch Vor kurzem und gespielt mit rauschen (Eine Python -Implementierung einer Suchmaschine).

Können Sie Gründe für Ihre Wahl angeben?

Answer 1

Als Schöpfer von Elasticsearch kann ich Ihnen vielleicht ein paar Gründe dafür geben, warum ich es in erster Linie erstellt habe :).

Die Verwendung von reinem Lucene ist eine Herausforderung. Es gibt viele Dinge, auf die Sie sich kümmern müssen, wenn Sie möchten, dass es wirklich gut funktioniert, und es ist auch eine Bibliothek. Es ist also keine verteilte Unterstützung. Es handelt sich nur um eine eingebettete Java -Bibliothek, die Sie pflegen müssen.

In Bezug auf die Usabilität von Lucene habe ich vor langer Zeit (jetzt fast 6 Jahre) Kompass erstellt. Sein Ziel war es, die Verwendung von Lucene zu vereinfachen und Lucene zu vereinfachen. Was ich immer wieder begegnet bin, ist die Anforderung, Kompassverteilungen verteilt zu werden. Ich habe angefangen, in dem Kompass daran zu arbeiten, indem ich mich in Datengitterlösungen wie Gigaspaces, Kohärenz und Terrakotta integrierte, aber es reicht nicht aus.

Im Kern muss eine verteilte Lucene -Lösung geschützt werden. Mit der Weiterentwicklung von HTTP und JSON als allgegenwärtige APIs bedeutet dies auch, dass eine Lösung, die viele verschiedene Systeme mit unterschiedlichen Sprachen leicht verwendet werden können.

Deshalb habe ich Elasticsearch erstellt. Es verfügt über ein sehr fortschrittliches verteiltes Modell, spricht JSON nativ und enthält viele fortschrittliche Suchfunktionen, die alle nahtlos über JSON DSL ausgedrückt werden.

SolR ist auch eine Lösung, um einen Indexierungs-/Suchserver über HTTP freizulegen, aber ich würde argumentieren Elasticsarch Bietet ein viel überlegenes verteiltes Modell und eine einfache Benutzerfreundlichkeit (obwohl es derzeit an einigen der Suchfunktionen fehlt, jedoch nicht lange, und auf jeden Fall ist der Plan, alles zu bekommen Kompass Funktionen in Elasticsarch). Natürlich bin ich voreingenommen, seit ich Elasticsarch erstellt habe, also müssen Sie möglicherweise selbst überprüfen.

Was Sphinx betrifft, ich habe es nicht benutzt, also kann ich nicht kommentieren. Was ich Sie verweisen kann, ist Dieser Thread im Sphinx Forum Was ich denke, beweist das überlegene verteilte Modell der Elasticsearch.

Natürlich hat Elasticsearch viel mehr Funktionen als nur verteilt zu werden. Es wird tatsächlich mit einer Wolke gebaut. Sie können die Funktionsliste auf der Website überprüfen.

Answer 2

Ich habe Sphinx, Solr und Elasticsearch verwendet. Solr/Elasticsearch sind auf Lucene aufgebaut. Es fügt viele gemeinsame Funktionen hinzu: Webserver -API, Facetting, Caching usw.

Wenn Sie nur ein einfaches Setup für Volltextsuche haben möchten, ist Sphinx eine bessere Wahl.

Wenn Sie Ihre Suche überhaupt anpassen möchten, sind Elasticsearch und Solr die bessere Entscheidungen. Sie sind sehr erweiterbar: Sie können Ihre eigenen Plugins schreiben, um das Ergebnis der Ergebnisse anzupassen.

Einige Beispielanwendungen:

• Sphinx: craigslist.org
• Solr: CNET, Netflix, Digg.com
• Elasticsearch: Foursquare, Github

Answer 3

Wir verwenden Lucene regelmäßig, um zig Millionen von Dokumenten zu indexieren und zu durchsuchen. Die Suchanfragen sind schnell genug und wir verwenden inkrementelle Updates, die nicht lange dauern. Es dauerte einige Zeit, um hierher zu kommen. Die starken Punkte von Lucene sind seine Skalierbarkeit, eine große Auswahl an Merkmalen und eine aktive Gemeinschaft von Entwicklern. Die Verwendung von bloßem Lucene erfordert die Programmierung in Java.

Wenn Sie neu beginnen, ist das Werkzeug für Sie in der Lucene -Familie Solr, was viel einfacher zu errichten ist als bloße Lucene und hat fast die gesamte Macht von Lucene. Es kann Datenbankdokumente problemlos importieren. Solr sind in Java geschrieben, daher erfordert jede Änderung von Solr Java -Wissen. Sie können jedoch viel durchführen, indem Sie Konfigurationsdateien optimieren.

Ich habe auch gute Dinge über Sphinx gehört, insbesondere in Verbindung mit einer MySQL -Datenbank. Habe es jedoch nicht benutzt.

IMO, Sie sollten nach:

• Die erforderliche Funktionalität - z. B. benötigen Sie einen französischen Stemmer? Lucene und Solr haben einen, ich weiß nichts über die anderen.
• Kenntnisse in der Implementierungssprache - Berühren Sie Java Lucene nicht, wenn Sie Java nicht kennen. Möglicherweise benötigen Sie C ++, um Sachen mit Sphinx zu machen. Lucene wurde ebenfalls portiert Sonstiges Sprachen. Dies ist meistens wichtig, wenn Sie die Suchmaschine erweitern möchten.
• Leichtigkeit des Experimentierens - Ich glaube, Solr ist in diesem Aspekt am besten.
• Schnittstelle mit einer anderen Software - Sphinx hat eine gute Schnittstelle zu MySQL. Solr unterstützt Ruby-, XML- und JSON -Schnittstellen als erholsamer Server. Lucene bietet Ihnen nur einen programmatischen Zugriff über Java. Kompass und Hibernate -Suche sind Wrapper von Lucene, die es in größere Frameworks integrieren.

Answer 4

Wir verwenden Sphinx in einem vertikalen Suchprojekt mit 10.000.000 + MySQL -Datensätzen und 10+ unterschiedlichen Datenbank. Es hat sehr hervorragende Unterstützung für MySQL und eine hohe Leistung bei der Indexierung, die Forschung ist schnell, aber vielleicht etwas weniger als Lucene. Es ist jedoch die richtige Wahl, wenn Sie jeden Tag schnell indizieren und eine MySQL -DB verwenden müssen.

Answer 5

Ein Experiment zu Vergleichen Sie Elasticsearch und Solr

Answer 6

Mein 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
}

Testskript:

<?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");
?>

Beispielergebnis:

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

Sphinx -Abfragezeit:

0.001 sec.

Sphinx -Abfragezeit (1K gleichzeitig):

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

MySQL Abfragezeit:

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

MySQL -Abfragezeit (1K gleichzeitig):

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

Answer 7

Der einzige Elasticsearch vs Solr -Leistungsvergleich, den ich bisher finden konnte, ist hier:

Solr gegen Elasticsearch Deathmatch!

Answer 8

Lucene ist nett und alles, aber ihr Stop -Wort -Set ist schrecklich. Ich musste Stopanalyzer manuell eine Menge Stoppwörter hinzufügen.

Ich habe Sphinx nicht verwendet, aber ich weiß, dass die Leute durch ihre Geschwindigkeit und nahezu magische "Leichtigkeit des Setups to Awesomeness" -Verhältnisses schwören.

Answer 9

Versuchen Sie es mit Underxtank.

Als elastischer Suche wurde es als viel einfacher zu verwenden als Lucene/Solr. Es enthält auch ein sehr flexibles Bewertungssystem, das ohne Reindexing optimiert werden kann.