Attualmente sto cercando altri metodi di ricerca piuttosto che avere un'enorme query SQL. Di recente ho visto elasticsearch e ho giocato con whoosh (un'implementazione Python di un motore di ricerca).
Puoi dare dei motivi per le tue scelte?
Attualmente sto cercando altri metodi di ricerca piuttosto che avere un'enorme query SQL. Di recente ho visto elasticsearch e ho giocato con whoosh (un'implementazione Python di un motore di ricerca).
Puoi dare dei motivi per le tue scelte?
Risposte:
Come creatore di ElasticSearch, forse posso darti qualche ragionamento sul perché sono andato avanti e l'ho creato in primo luogo :).
L'uso di Lucene puro è una sfida. Ci sono molte cose di cui devi fare attenzione se vuoi che funzioni davvero bene, e inoltre, è una libreria, quindi nessun supporto distribuito, è solo una libreria Java incorporata che devi mantenere.
In termini di usabilità di Lucene, già da quando (quasi 6 anni), ho creato Compass. Il suo obiettivo era semplificare l'utilizzo di Lucene e semplificare la vita quotidiana di Lucene. Ciò che ho riscontrato più volte è il requisito per poter distribuire Compass. Ho iniziato a lavorarci da Compass, integrandomi con soluzioni di griglia di dati come GigaSpaces, Coherence e Terracotta, ma non è abbastanza.
Alla base, una soluzione distribuita di Lucene deve essere messa a fuoco. Inoltre, con l'avanzamento di HTTP e JSON come API onnipresenti, significa che è possibile utilizzare facilmente molti sistemi diversi con lingue diverse.
Ecco perché sono andato avanti e ho creato ElasticSearch. Ha un modello distribuito molto avanzato, parla nativamente JSON ed espone molte funzionalità di ricerca avanzate, tutte espresse senza soluzione di continuità tramite JSON DSL.
Solr è anche una soluzione per esporre un server di indicizzazione / ricerca su HTTP, ma direi che ElasticSearch offre un modello distribuito molto superiore e una facilità d'uso (sebbene al momento manchi su alcune delle funzionalità di ricerca, ma non per molto, e in qualsiasi caso, il piano è quello di ottenere tutte le funzionalità Compass in ElasticSearch). Certo, sono di parte, da quando ho creato ElasticSearch, quindi potrebbe essere necessario verificare da soli.
Per quanto riguarda Sphinx, non l'ho usato, quindi non posso commentare. Quello che posso fare riferimento a questo thread nel forum Sphinx, che penso dimostra il modello distribuito superiore di ElasticSearch.
Naturalmente, ElasticSearch ha molte più funzioni rispetto alla semplice distribuzione. In realtà è costruito pensando a una nuvola. È possibile controllare l'elenco delle funzionalità sul sito.
Ho usato Sphinx, Solr ed Elasticsearch. Solr / Elasticsearch sono costruiti su Lucene. Aggiunge molte funzionalità comuni: API del server Web, sfaccettatura, memorizzazione nella cache, ecc.
Se vuoi solo avere una semplice configurazione di ricerca full-text, Sphinx è la scelta migliore.
Se vuoi personalizzare la tua ricerca, Elasticsearch e Solr sono le scelte migliori. Sono molto estensibili: puoi scrivere i tuoi plugin per regolare il punteggio dei risultati.
Alcuni esempi di utilizzo:
Usiamo Lucene regolarmente per indicizzare e cercare decine di milioni di documenti. Le ricerche sono abbastanza veloci e utilizziamo aggiornamenti incrementali che non richiedono molto tempo. Ci è voluto del tempo per arrivare qui. I punti di forza di Lucene sono la sua scalabilità, una vasta gamma di funzionalità e una comunità attiva di sviluppatori. L'uso di Lucene nudo richiede la programmazione in Java.
Se stai ricominciando da capo, lo strumento per te nella famiglia Lucene è Solr , che è molto più facile da installare rispetto a Lucene nudo, e ha quasi tutto il potere di Lucene. Può importare facilmente documenti di database. Solr sono scritti in Java, quindi qualsiasi modifica di Solr richiede conoscenze Java, ma puoi fare molto semplicemente modificando i file di configurazione.
Ho anche sentito cose positive su Sphinx, soprattutto in combinazione con un database MySQL. Non l'ho usato, però.
IMO, dovresti scegliere in base a:
Usiamo Sphinx in un progetto di ricerca verticale con oltre 10.000.000 di record MySql e oltre 10 database diversi. Ha un supporto eccellente per MySQL e alte prestazioni sull'indicizzazione, la ricerca è veloce ma forse un po 'meno di Lucene. Tuttavia è la scelta giusta se hai bisogno di indicizzare rapidamente ogni giorno e utilizzare un db MySQL.
Un esperimento per confrontare ElasticSearch e Solr
My 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 di prova:
<?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");
?>
Risultato del campione:
[array] =>
"id" => 123,
"title" => "My post title.",
"content" => "My <p>post</p> content.",
...
[ and other fields ]
Tempo di query Sfinge:
0.001 sec.
Tempo di query Sfinge (1k simultaneo):
=> 0.346 sec. (average)
=> 0.340 sec. (average of last 10 query)
Tempo di query MySQL:
"SELECT * FROM hb_posts WHERE id = 123;"
=> 0.001 sec.
Tempo di query MySQL (1k simultaneo):
"SELECT * FROM my_posts WHERE id = 123;"
=> 1.612 sec. (average)
=> 1.920 sec. (average of last 10 query)
L'unico confronto delle prestazioni tra elasticsearch e solr che sono stato in grado di trovare finora è qui:
Lucene è simpatica e tutto, ma la loro parola d'ordine è terribile. Ho dovuto aggiungere manualmente un sacco di parole di stop a StopAnalyzer.ENGLISH_STOP_WORDS_SET solo per renderlo ovunque utilizzabile.
Non ho usato Sphinx ma so che la gente giura per la sua velocità e il rapporto quasi magico tra "facilità di installazione e bellezza".
Prova indextank.
Come nel caso della ricerca elastica, è stato concepito per essere molto più facile da usare rispetto a lucene / solr. Include anche un sistema di punteggio molto flessibile che può essere modificato senza reindicizzare.