Userò questa domanda a condividere alcune esperienze a scrivere un piccolo motore di ricerca da zero (nessuna ricerca specifico sono state utilizzate librerie) per un set di dati abbastanza piccolo (in realtà cerca in StackOverflow poiché non era né troppo piccolo né troppo grande per funzionare su un singolo server). Check it out. Di seguito sono le mie conclusioni sull'argomento.
Crawler
In primo luogo, il crawler è una cosa difficile da fare. Il vero problema è scrivere i dati sul disco alla stessa velocità con cui si ottengono le pagine web. La struttura dati principale è un indice invertito e quindi quando si ottiene la parola "banana" è necessario estrarre dal disco l'indice "banana" (elenco dei documenti in cui si verifica - insieme alle posizioni nel documento) aggiungerlo con il nuovo record e scriverlo indietro Man mano che la lista cresce, tirare e scrivere di nuovo sta rallentando. Quindi un trucco sarebbe quello di dividere gli indici invertiti (e i documenti) in partizioni, ad esempio 1-1000 documenti nella prima partizione e così via. L'altro "trucco" è durante la scansione di una partizione per mantenere gli indici in memoria e scaricarli su disco solo al termine della partizione.
Bit importante: che cosa utilizzare per memorizzare i dati? Ci sono molte opzioni e dopo molti esperimenti ho trovato che il leveldb è la scelta migliore fino ad oggi. E non dimenticare i dischi SSD!
Quindi, tutto sommato, la scansione della maggior parte dello stackoverflow (~ 13.000.000 di pagine) in questo modo utilizzando una macchina (4 GB di RAM) richiede circa 2 mesi. E i dati risultanti (l'indice invertito, il testo senza testo grezzo, ecc.) - circa 80 GB di spazio su disco.
Ricerca
L'obiettivo è di farlo in fretta e con alta qualità. Una cosa da capire è che se vuoi che sia veloce, non puoi cercare l'intero set di dati. Fortunatamente, avevo tutto partizionato in modo che la ricerca prendesse le prime 100 partizioni dove appaiono le parole chiave (indice separato per quello) e se trova risultati "abbastanza buoni" - si ferma, se non lo è - ne prende altri 100 e così via.
La parte più lenta sta leggendo gli indici dal disco e deserializzandolo.Leveldb supporta la lettura sequenziale veloce, quindi i dati devono essere archiviati in modo che la maggior parte di essi possa essere letta in sequenza. Una volta nella memoria, l'intersezione è abbastanza veloce.
Ora la qualità. Questo è il più duro e mai abbastanza buono. Il mio primo tentativo era di mantenere gli indici invertiti non solo per il testo, ma anche per i titoli, il testo del link e gli URL. Ogni colpo in questi aggiunge alcuni punti al documento. Un'altra cosa è riformulare la query usando i sinonimi e in qualche modo controllare quale query ha funzionato meglio. Probabilmente meriterebbe un post a parte.
In ogni caso, spero che sia utile leggere!
Grazie! L'ho visto una volta ma ho dimenticato dov'era. – davemackey