Question

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

Pouvez-vous donner les raisons de votre choix (s)?

Était-ce utile?

La solution

En tant que créateur de ElasticSearch, peut-être que je peux vous donner un raisonnement pourquoi je suis allé de l'avant et a créé en premier lieu.)

En utilisant pur Lucene est difficile. Il y a beaucoup de choses que vous devez prendre soin de si vous voulez qu'il fasse vraiment bien, et aussi, sa bibliothèque, donc pas de support distribué, il est juste une bibliothèque Java embarqué que vous devez maintenir.

En termes de facilité d'utilisation Lucene, retour lorsque (presque 6 ans maintenant), j'ai créé Compass. Son objectif était de simplifier l'utilisation Lucene et de faire tous les jours Lucene plus simple. Ce que je suis venu dans le temps et le temps est à nouveau l'exigence d'être en mesure d'avoir Compass distribué. J'ai commencé à travailler dessus à partir de Compass, en intégrant des solutions de réseau de données comme GigaSpaces, la cohérence, et en terre cuite, mais il ne suffit pas.

À la base, une solution Lucene distribuée doit être fragmentées. En outre, avec l'avancement de HTTP et JSON comme API omniprésentes, cela signifie qu'une solution que de nombreux systèmes différents avec des langues différentes peut facilement être utilisé.

Voilà pourquoi je suis allé de l'avant et créé ElasticSearch. Il a un modèle distribué très avancé, parle JSON en mode natif, et expose de nombreuses fonctionnalités de recherche avancées, de façon transparente tous exprimés par DSL JSON.

Solr est également une solution pour exposer un serveur d'indexation / recherche sur HTTP, mais je dirais que ElasticSearch fournit un modèle distribué bien supérieur et la facilité d'utilisation (mais manque actuellement sur certaines des fonctionnalités de recherche, mais pas pour longtemps, et dans tous les cas, le plan est d'obtenir tous les Compass fonctionnalités dans ElasticSearch). Bien sûr, je suis partial, puisque je créé ElasticSearch, de sorte que vous pourriez avoir besoin de vérifier vous-même.

En ce qui concerne Sphinx, je l'ai pas utilisé, donc je ne peux pas commenter. Ce que je peux vous renvoyer est ce fil au forum Sphinx que je pense prouve la modèle supérieur distribué de ElasticSearch.

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

Autres conseils

Je l'ai utilisé Sphinx, Solr et ElasticSearch. Solr / ElasticSearch sont construites au-dessus de Lucene. Il ajoute de nombreuses fonctionnalités communes:. Serveur web api, facettage, la mise en cache, etc

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

Si vous souhaitez personnaliser votre recherche à tous, ElasticSearch et Solr sont les meilleurs choix. Ils sont très extensibles: vous pouvez écrire vos propres plug-ins pour ajuster la notation des résultats.

Certains usages par exemple:

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

Nous utilisons régulièrement Lucene pour indexer et    recherche des dizaines de millions de documents.    Les recherches sont assez rapides, et nous utilisons    mises à jour incrémentielles qui ne prennent pas    un long moment. Il nous a pris un certain temps    pour y arriver. Les points forts de    Lucene son évolutivité, une grande    gamme de fonctionnalités et un actif    communauté de développeurs. L'utilisation nue    Lucene requiert une programmation en Java.

Si vous commencez à nouveau, l'outil pour vous dans la famille Lucene est Solr , qui est beaucoup plus facile à mettre en place que Lucene nu, et a presque toute la puissance de Lucene. Il peut importer des documents de base de données facilement. Solr sont écrits en Java, de sorte que toute modification de Solr nécessite des connaissances Java, mais vous pouvez faire beaucoup simplement en modifiant légèrement les fichiers de configuration.

J'ai aussi entendu de bonnes choses à propos de Sphinx, en particulier en conjonction avec une base de données MySQL. Je n'ai pas utilisé, cependant.

OMI, vous devez choisir en fonction:

  • La fonctionnalité requise - par exemple avez-vous besoin d'un égrappoir français? Lucene et Solr ont un, je ne sais pas sur les autres.
  • La maîtrise de la langue de mise en œuvre - Ne touchez pas Java Lucene si vous ne connaissez pas Java. Vous devrez peut-être C ++ pour faire des choses avec Sphinx. Lucene a également été porté dans autre langues . Cela est surtout important si vous souhaitez étendre le moteur de recherche.
  • Facilité d'expérimentation -. Je crois 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 rubis, les interfaces XML et JSON en tant que serveur RESTful. Lucene ne vous donne un accès programmatique à travers Java. Compass et Hibernate Search enveloppent de Lucene qui l'intègrent dans des cadres plus larges.

Nous utilisons Sphinx dans un projet vertical de recherche avec 10.000.000 + d'enregistrements MySql et 10+ base de données. Il a obtenu un excellent support pour très MySQL et haute performance sur l'indexation, la recherche est rapide mais peut-être un peu moins de Lucene. Cependant, il est le bon choix si vous avez besoin rapidement indexer tous les jours et utiliser un db MySQL.

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

résultat de l'échantillon:

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

Sphinx temps de requête:

0.001 sec.

Sphinx temps de recherche (1k simultanée):

=> 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.

MySQL temps de recherche (1k simultanée):

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

La seule ElasticSearch vs comparaison des performances Solr j'ai pu trouver jusqu'à présent est ici:

Solr vs ElasticSearch Deathmatch!

Lucene est agréable et tout, mais leur mot d'arrêt mis est terrible. Je devais ajouter manuellement une tonne de mots d'arrêt à StopAnalyzer.ENGLISH_STOP_WORDS_SET juste pour l'obtenir partout près utilisable.

Je ne l'ai pas utilisé Sphinx mais je sais que les gens ne jurent que par sa vitesse et sa « facilité d'installation pour génialité » quasi-magique rapport.

Essayez indextank.

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

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top