ElasticSearch, Sfinks, Lucene, Solr, Xapian. Które pasuje do jakiego zastosowania? [Zamknięte]

Obecnie patrzę na inne metody wyszukiwania zamiast na ogromne zapytanie SQL. Ostatnio widziałem elasticsearch i bawiłem się z whoosh (implementacja wyszukiwarki w Pythonie).

Czy możesz podać powody swojego wyboru?

Jako twórca ElasticSearch, może mogę podać kilka powodów, dla których postanowiłem i stworzyłem go w pierwszej kolejności :).

Korzystanie z czystej Lucene jest wyzwaniem. Jest wiele rzeczy, na które musisz uważać, jeśli chcesz, aby naprawdę dobrze działało, a także, że jest to biblioteka, więc nie ma rozproszonego wsparcia, to tylko wbudowana biblioteka Java, którą musisz utrzymywać.

Jeśli chodzi o użyteczność Lucene, dawno temu (prawie 6 lat) stworzyłem Compass. Jego celem było uproszczenie korzystania z Lucene i uproszczenie codziennej Lucene. To, co napotykałem raz za razem, to wymóg, aby mieć możliwość dystrybucji Compass. Zacząłem nad tym pracować z poziomu Compass, integrując się z rozwiązaniami sieci danych, takimi jak GigaSpaces, Coherence i Terracotta, ale to nie wystarczy.

U podstaw rozproszonego rozwiązania Lucene należy podzielić. Ponadto, wraz z postępem HTTP i JSON jako wszechobecnych interfejsów API, oznacza to, że można łatwo zastosować wiele różnych systemów z różnymi językami.

Właśnie dlatego stworzyłem ElasticSearch. Ma bardzo zaawansowany model rozproszony, mówi natywnie JSON i udostępnia wiele zaawansowanych funkcji wyszukiwania, wszystkie płynnie wyrażone za pomocą JSON DSL.

Solr jest także rozwiązaniem do eksponowania serwera indeksowania / wyszukiwania przez HTTP, ale argumentowałbym, że ElasticSearch zapewnia znacznie lepszy rozproszony model i łatwość użycia (chociaż obecnie brakuje niektórych funkcji wyszukiwania, ale nie na długo i w żadnym innym w tym przypadku plan polega na przeniesieniu wszystkich funkcji kompasu do ElasticSearch). Oczywiście jestem stronniczy, ponieważ stworzyłem ElasticSearch, więc być może będziesz musiał sprawdzić sam.

Jeśli chodzi o Sfinksa, nie użyłem go, więc nie mogę komentować. Mogę odesłać cię do tego wątku na forum Sphinx, który, jak sądzę, dowodzi doskonałego rozproszonego modelu ElasticSearch.

Oczywiście ElasticSearch ma o wiele więcej funkcji niż tylko dystrybucję. W rzeczywistości jest zbudowany z myślą o chmurze. Możesz sprawdzić listę funkcji na stronie.

Użyłem Sphinx, Solr i Elasticsearch. Solr / Elasticsearch są zbudowane na bazie Lucene. Dodaje wiele typowych funkcji: interfejs serwera WWW, faceting, buforowanie itp.

Jeśli chcesz mieć prostą konfigurację wyszukiwania pełnotekstowego, Sphinx jest lepszym wyborem.

Jeśli chcesz w ogóle dostosować wyszukiwanie, lepszym wyborem są Elasticsearch i Solr. Są bardzo rozszerzalne: możesz pisać własne wtyczki, aby dostosować punktację wyników.

Niektóre przykładowe zastosowania:

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

Używamy Lucene regularnie do indeksowania i przeszukiwania dziesiątek milionów dokumentów. Wyszukiwanie jest dość szybkie i korzystamy z aktualizacji przyrostowych, które nie zajmują dużo czasu. Dotarcie tutaj zajęło nam trochę czasu. Mocną stroną Lucene jest jego skalowalność, szeroki zakres funkcji i aktywna społeczność programistów. Używanie nagiej Lucene wymaga programowania w Javie.

Jeśli zaczynasz od nowa, narzędziem dla ciebie w rodzinie Lucene jest Solr , który jest o wiele łatwiejszy do skonfigurowania niż nagi Lucene i ma prawie całą moc Lucene. Może łatwo importować dokumenty bazy danych. Solr są napisane w Javie, więc każda modyfikacja Solr wymaga znajomości języka Java, ale można wiele zrobić, modyfikując pliki konfiguracyjne.

Słyszałem także dobre rzeczy o Sphinx, szczególnie w połączeniu z bazą danych MySQL. Jednak nie użyłem tego.

IMO, powinieneś wybrać według:

• Wymagana funkcjonalność - np. Czy potrzebujesz francuskiego stempera? Lucene i Solr mają jedno, nie wiem o pozostałych.
• Biegła znajomość języka implementacji - nie dotykaj Java Lucene, jeśli nie znasz Java. Możesz potrzebować C ++ do robienia rzeczy ze Sphinx. Lucene została również przeniesiona na inne języki . Jest to szczególnie ważne, jeśli chcesz rozszerzyć wyszukiwarkę.
• Łatwość eksperymentowania - uważam, że Solr jest najlepszy pod tym względem.
• Współpraca z innym oprogramowaniem - Sphinx ma dobry interfejs z MySQL. Solr obsługuje interfejsy Ruby, XML i JSON jako serwer RESTful. Lucene zapewnia ci programowy dostęp tylko przez Javę. Compass i Hibernate Search to opakowania Lucene, które integrują go z większymi platformami.

Używamy Sfinksa w projekcie wyszukiwania pionowego z ponad 10 000 000 rekordów MySql i ponad 10 różnymi bazami danych. Ma bardzo doskonałe wsparcie dla MySQL i wysoką wydajność indeksowania, badania są szybkie, ale może trochę mniej niż Lucene. Jest to jednak właściwy wybór, jeśli potrzebujesz szybko indeksować codziennie i używać bazy danych MySQL.

Eksperyment w celu porównania ElasticSearch i Solr

Mój 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
}

Skrypt testowy:

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

Przykładowy wynik:

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

Czas zapytania Sfinksa:

0.001 sec.

Czas zapytania Sfinksa (równoczesny 1k):

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

Czas zapytania MySQL:

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

Czas zapytania MySQL (równoczesny 1k):

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

Jedyne porównanie wydajności elasticsearch vs solr, jakie udało mi się znaleźć do tej pory, to:

Solr vs elasticsearch Deathmatch!

Lucene jest fajna, ale ich zestaw słów jest okropny. Musiałem ręcznie dodać tonę słów stop do StopAnalyzer.ENGLISH_STOP_WORDS_SET tylko po to, aby zbliżyć je w dowolnym miejscu do użycia.

Nie korzystałem ze Sfinksa, ale wiem, że ludzie przysięgają na jego szybkość i niemal magiczny stosunek „łatwości konfiguracji do niesamowitości”.

Wypróbuj indextank.

W przypadku wyszukiwania elastycznego pomyślano, że jest znacznie łatwiejszy w użyciu niż lucene / solr. Zawiera również bardzo elastyczny system oceniania, który można modyfikować bez ponownego indeksowania.