ElasticSearch, Sphinx, Lucene, Solr, Xapian. Qui convient à quel usage? [fermé]

J'examine actuellement d'autres méthodes de recherche plutôt que d'avoir une énorme requête SQL. J'ai vu elasticsearch récemment et j'ai joué avec whoosh (une implémentation Python d'un moteur de recherche).

Pouvez-vous donner les raisons de vos choix?

En tant que créateur d'ElasticSearch, je peux peut-être vous expliquer pourquoi je suis allé de l'avant et l'ai créé en premier lieu :).

L'utilisation de Lucene pur est difficile. Il y a beaucoup de choses dont vous devez faire attention si vous voulez qu'il fonctionne vraiment bien, et aussi, c'est une bibliothèque, donc pas de support distribué, c'est juste une bibliothèque Java intégrée que vous devez maintenir.

En termes d'utilisation de Lucene, il y a bien longtemps (presque 6 ans maintenant), j'ai créé Compass. Son objectif était de simplifier l'utilisation de Lucene et de simplifier Lucene au quotidien. Ce que j'ai rencontré maintes et maintes fois, c'est l'exigence de pouvoir distribuer Compass. J'ai commencé à travailler dessus depuis Compass, en intégrant des solutions de grille de données comme GigaSpaces, Coherence et Terracotta, mais ce n'est pas suffisant.

À la base, une solution Lucene distribuée doit être partagée. En outre, avec l'avancement de HTTP et de JSON en tant qu'API omniprésentes, cela signifie qu'une solution permettant à de nombreux systèmes différents avec différents langages d'être facilement utilisée.

C'est pourquoi j'ai décidé de créer ElasticSearch. Il a un modèle distribué très avancé, parle JSON en natif et expose de nombreuses fonctionnalités de recherche avancées, toutes exprimées de manière transparente via JSON DSL.

Solr est également une solution pour exposer un serveur d'indexation / recherche sur HTTP, mais je dirais qu'ElasticSearch fournit un modèle distribué bien supérieur et une facilité d'utilisation (bien qu'il manque actuellement certaines fonctionnalités de recherche, mais pas pour longtemps, et dans aucun Dans ce cas, le plan consiste à intégrer toutes les fonctionnalités de Compass dans ElasticSearch). Bien sûr, je suis partial, car j'ai créé ElasticSearch, vous devrez donc peut-être vérifier par vous-même.

Quant au Sphinx, je ne l'ai pas utilisé, je ne peux donc pas commenter. Ce que je peux vous référer, c'est à ce fil sur le forum Sphinx qui, je pense, prouve le modèle distribué supérieur d'ElasticSearch.

Bien sûr, ElasticSearch a beaucoup plus de fonctionnalités que d'être simplement distribué. Il est en fait construit avec un nuage à l'esprit. Vous pouvez consulter la liste des fonctionnalités sur le site.

J'ai utilisé Sphinx, Solr et Elasticsearch. Solr / Elasticsearch sont construits sur Lucene. Il ajoute de nombreuses fonctionnalités communes: API du serveur Web, facettage, mise en cache, etc.

Si vous voulez simplement avoir une configuration de recherche de texte intégral simple, Sphinx est un meilleur choix.

Si vous souhaitez personnaliser votre recherche, Elasticsearch et Solr sont les meilleurs choix. Ils sont très extensibles: vous pouvez écrire vos propres plugins pour ajuster le score des résultats.

Quelques exemples d'utilisations:

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

Nous utilisons régulièrement Lucene pour indexer et rechercher des dizaines de millions de documents. Les recherches sont assez rapides et nous utilisons des mises à jour incrémentielles qui ne prennent pas longtemps. Il nous a fallu un certain temps pour arriver ici. Les points forts de Lucene sont son évolutivité, une large gamme de fonctionnalités et une communauté active de développeurs. L'utilisation de Lucene nu nécessite une programmation en Java.

Si vous recommencez à zéro, l'outil pour vous dans la famille Lucene est Solr , qui est beaucoup plus facile à installer que Lucene nue, et a presque tout le pouvoir de Lucene. Il peut facilement importer des documents de base de données. Les Solr sont écrits en Java, donc toute modification de Solr nécessite des connaissances en Java, mais vous pouvez faire beaucoup de choses simplement en modifiant les fichiers de configuration.

J'ai également entendu de bonnes choses sur Sphinx, en particulier en conjonction avec une base de données MySQL. Je ne l'ai cependant pas utilisé.

OMI, vous devez choisir selon:

• La fonctionnalité requise - par exemple, avez-vous besoin d'un rameur français? Lucene et Solr en ont un, je ne connais pas les autres.
• Maîtrise du langage d'implémentation - Ne touchez pas Java Lucene si vous ne connaissez pas Java. Vous aurez peut-être besoin de C ++ pour faire des choses avec Sphinx. Lucene a également été portée dans d' autres langues . Ceci est surtout important si vous souhaitez étendre le moteur de recherche.
• Facilité d'expérimentation - je crois que Solr est le meilleur dans cet aspect.
• Interfaçage avec d'autres logiciels - Sphinx a une bonne interface avec MySQL. Solr prend en charge les interfaces ruby, XML et JSON en tant que serveur RESTful. Lucene vous donne uniquement un accès programmatique via Java. Compass et Hibernate Search sont des wrappers de Lucene qui l'intègrent dans des cadres plus larges.

Nous utilisons Sphinx dans un projet de recherche verticale avec plus de 10 000 000 d'enregistrements MySql et plus de 10 bases de données différentes. Il a un très bon support pour MySQL et de hautes performances sur l'indexation, la recherche est rapide mais peut-être un peu moins que Lucene. Cependant, c'est le bon choix si vous avez besoin d'indexer rapidement tous les jours et d'utiliser une base de données MySQL.

Une expérience pour comparer ElasticSearch et Solr

Mon 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 test:

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

Exemple de résultat:

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

Temps de requête Sphinx:

0.001 sec.

Temps de requête Sphinx (1k simultané):

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

Temps de requête MySQL:

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

Temps de requête MySQL (1k simultané):

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

La seule comparaison de performances elasticsearch vs solr que j'ai pu trouver jusqu'à présent est ici:

Solr vs elasticsearch Deathmatch!

Lucene est sympa et tout, mais leur jeu de mots vides est horrible. J'ai dû ajouter manuellement une tonne de mots vides à StopAnalyzer.ENGLISH_STOP_WORDS_SET juste pour que ce soit presque utilisable.

Je n'ai pas utilisé Sphinx mais je sais que les gens ne jurent que par sa vitesse et son rapport quasi-magique "facilité d'installation sur génialité".

Essayez indextank.

Comme le cas de la recherche élastique, il a été conçu pour être beaucoup plus facile à utiliser que lucene / solr. Il comprend également un système de notation très flexible qui peut être modifié sans réindexation.