ElasticSearch, Sphinx, Lucene, Solr, Xapian. Quels ajustements pour quel usage?
Je suis actuellement à la recherche 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 d'un moteur de recherche Python).
Pouvez-vous donner les raisons de votre choix?
En tant que créateur d'ElasticSearch, je peux peut-être vous expliquer pourquoi j'ai décidé de le créer :).
Utiliser Lucene pure est un défi. Vous devez prendre soin de bien des choses si vous voulez que le logiciel fonctionne vraiment bien. De plus, c'est une bibliothèque, donc pas de support distribué, c'est juste une bibliothèque intégrée Java que vous devez gérer.
Pour ce qui est de la facilité d’utilisation de Lucene, il ya très longtemps (presque 6 ans), j’ai créé Compass. Son objectif était de simplifier l'utilisation de Lucene et de simplifier son quotidien. Ce que j’ai rencontré maintes et maintes fois, c’est la nécessité de pouvoir distribuer Compass. J'ai commencé à travailler dessus à partir de Compass, en intégrant des solutions de grille de données telles que GigaSpaces, Coherence et Terracotta, mais cela ne suffit pas.
À la base, une solution Lucene distribuée doit être partagée. De plus, avec l'avancement de HTTP et de JSON en tant qu'API omniprésentes, cela signifie qu'une solution utilisable facilement par de nombreux systèmes différents avec des langues différentes.
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/de recherche sur HTTP, mais je dirais que 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 tous les cas, le plan consiste à intégrer toutes les fonctionnalités de Compass dans ElasticSearch). Bien sûr, je suis partial depuis que j'ai créé ElasticSearch. Vous devrez peut-être vérifier vous-même.
Quant à Sphinx, je ne l'ai pas utilisé, je ne peux donc rien en dire. Ce que je peux vous dire, c'est ce fil sur le forum Sphinx , ce qui prouve, à mon avis, le modèle distribué supérieur d'ElasticSearch.
Bien entendu, ElasticSearch propose bien plus de fonctionnalités que la simple distribution. 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 de serveur Web, facettes, mise en cache, etc.
Si vous souhaitez simplement configurer votre recherche en texte intégral, 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 du 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 nue nécessite une programmation en Java.
Si vous recommencez, l’outil pour vous dans la famille Lucene est Solr , qui est beaucoup plus facile à installer que Lucene nue et possède presque tout le pouvoir de Lucene. Il peut facilement importer des documents de base de données. Solr étant écrit en Java, toute modification de Solr nécessite Java connaissances, mais vous pouvez en faire beaucoup en modifiant simplement les fichiers de configuration.
J'ai aussi entendu de bonnes choses à propos de Sphinx, en particulier en liaison avec une base de données MySQL. Je ne l'ai pas utilisé, cependant.
OMI, vous devriez choisir selon:
- La fonctionnalité requise - par exemple avez-vous besoin d'un stemmer 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é dans otherlanguages . 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 ne vous donne qu'un accès par programme via Java. Compass et Hibernate Search sont des wrappers de Lucene qui l’intègrent dans de plus grands frameworks.
Nous utilisons Sphinx dans un projet de recherche verticale avec 10.000.000 + d'enregistrements MySql et 10+ bases de données différentes. Il offre un excellent support pour MySQL et des performances élevées en 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 chaque jour et d'utiliser une base de données MySQL.
Une expérience à 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 la suivante:
Lucene est gentille et tout, mais leur mot d'arrêt 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 à génial".
Essayez indextank.
Dans 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.