Strategia su come eseguire la scansione/indicizzazione di pagine Web aggiornate di frequente?

Question

Sto cercando di creare un motore di ricerca di nicchia molto piccolo, utilizzando Nutch per eseguire la scansione di siti specifici. Alcuni dei siti sono notizie/siti di blog. Se eseguo la scansione, ad esempio, techcrunch.com, memorizzando e indicizzando la loro prima pagina o una qualsiasi delle loro pagine principali, quindi entro poche ore il mio indice per quella pagina non sarà aggiornato.

Un motore di ricerca di grandi dimensioni come Google ha un algoritmo per eseguire nuovamente la scansione delle pagine aggiornate di frequente molto frequentemente, anche ogni ora? Oppure segna molto frequentemente pagine molto aggiornate in modo che non vengano restituite?

Come posso gestire questo nella mia applicazione?

Answer 1

Cercate di mantenere un po 'per le statistiche sulla frequenza di aggiornamento di FrontPage. Rilevare un aggiornamento è facile, basta memorizzare ETag/Last-Modified e inviare le intestazioni If-None-Match/If-Updated-Since alla richiesta successiva. Mantenendo una frequenza di aggiornamento running average (ad esempio per gli ultimi 24 movimenti di ricerca per indicizzazione) è possibile determinare in modo abbastanza accurato la frequenza di aggiornamento delle frontpage.

Dopo aver eseguito la scansione di una prima pagina, è possibile determinare quando è previsto il prossimo aggiornamento e inserire un nuovo lavoro di ricerca per indicizzazione in un secchio proprio in quel momento (i bucket di un'ora sono in genere un buon bilanciamento tra veloce e gentile). Ogni ora devi semplicemente prendere il bucket corrispondente e aggiungere i lavori alla tua coda di lavoro. In questo modo puoi avere un numero qualsiasi di crawler e avere ancora il controllo sulla pianificazione delle singole scansioni.

Answer 2

Buona domanda. Questo è in realtà un argomento attivo nella community di ricerca WWW. La tecnica in questione è chiamato Re-crawl strategia o aggiornamento pagina politica.

Per quanto ne so ci sono tre diversi fattori che sono stati considerati nella letteratura:

• Cambio frequenza (come aver visto spesso il contenuto di una pagina web viene aggiornata)
  • [1]: Formalizzato la nozione di "freschezza" dei dati e utilizzare uno poisson process per modellare il cambiamento delle pagine web.
  • [2]: Frequenza stimatore
  • [3]: più compatta della pianificazione
• Rilevanza (quanta influenza il contenuto della pagina aggiornata ha sui risultati della ricerca)
  • [4] : Massimizza la qualità dell'esperienza utente per coloro che interrogano il motore di ricerca
  • [5]: Determina le frequenze di scansione (quasi) ottimali
• Informazioni longevità (le vite di frammenti contenuti che appaiono e scompaiono da pagine web nel tempo, che si manifesta non fortemente correlato con la frequenza del cambiamento)
  • [6]: distinguere tra effimero e persistenti contenuti

Si potrebbe decidere quale fattore è più importante per l'applicazione e gli utenti. Quindi è possibile controllare il riferimento sottostante per maggiori dettagli.

---

Edit: discuto brevemente lo stimatore di frequenza di cui al [2] per iniziare. Sulla base di questo, dovresti essere in grado di capire cosa potrebbe esserti utile negli altri documenti. :)

Seguire l'ordine che ho indicato di seguito per leggere questo documento. Non dovrebbe essere troppo difficile da capire fino a quando si sa una certa probabilità e statistiche 101 (forse molto meno se si prende la formula stimatore):

Fase 1. Aprire le Sezione 6.4 - Applicazione ad un Web crawler. Qui Cho ha elencato 3 approcci per stimare la frequenza di cambiamento della pagina web.

• Politica uniforme: un crawler rivisita tutte le pagine alla frequenza di una volta alla settimana.
• Politica inganno: nelle prime 5 visite, un crawler visita ciascuna pagina alla frequenza di una volta alla settimana. Dopo le 5 visite, il crawler stima le frequenze di cambio delle pagine utilizzando lo stimatore naive (Sezione 4.1)
• La nostra politica: Il crawler utilizza lo stimatore proposto (Sezione 4.2) per stimare la frequenza dei cambiamenti.

Passaggio 2. La politica ingenua. Si prega di andare alla sezione 4. Potrete leggere:

Intuitivamente, possiamo utilizzare X/T (X: il numero di modifiche rilevate, T: periodo di monitoraggio) come la frequenza stimata di cambiamento.

La sezione di sottosezione 4.1 appena dimostrato questa stima è polarizzata ⁷, in consistente ⁸ e efficiente ⁹.

Passaggio 3. Lo stimatore migliorato. Vai alla sezione 4.2. Il nuovo stimatore si presenta come di seguito:

dove \bar X è n - X (il numero di accessi che l'elemento non cambia) e n è il numero di accessi. Quindi basta prendere questa formula e stimare la frequenza del cambiamento. Non è necessario comprendere la prova nel resto della sottosezione.

Passo 4. Ci sono alcuni trucchi e tecniche utili discussi nella Sezione 4.3 e Sezione 5 che potrebbero essere utili a voi. La sezione 4.3 ha discusso su come gestire gli intervalli irregolari. La Sezione 5 ha risolto la domanda: quando è disponibile la data di ultima modifica di un elemento, come possiamo utilizzarlo per stimare la frequenza di cambiamento? Lo stimatore proposto con data dell'ultimo modifica è mostrato sotto:

La spiegazione all'algoritmo sopra dopo Fig.10 nel documento è molto chiaro.

Fase 5. Ora, se avete interesse, è possibile dare un'occhiata al sistema di sperimentazione ed i risultati nella sezione 6.

Quindi il gioco è fatto. Se ti senti più sicuro ora, vai avanti e prova la carta freschezza in [1].

---

Riferimenti

[1] http://oak.cs.ucla.edu/~cho/papers/cho-tods03.pdf

[2] http://oak.cs.ucla.edu/~cho/papers/cho-freq.pdf

[3] http://hal.inria.fr/docs/00/07/33/72/PDF/RR-3317.pdf

[4] http://wwwconference.org/proceedings/www2005/docs/p401.pdf

[5] http://www.columbia.edu/~js1353/pubs/wolf-www02.pdf

[6] http://infolab.stanford.edu/~olston/publications/www08.pdf

Answer 3

Io non sono un esperto in questo argomento con uno sforzo d'immaginazione, ma Sitemaps sono un modo per alleviare questo problema.

Nei suoi termini più semplici, una Sitemap XML di solito chiamato Sitemap, con un S maiuscola, è una lista delle pagine del tuo sito web. La creazione e l'invio di una Sitemap da parte di consente a Google di conoscere tutte le pagine del tuo sito, compresi gli URL che potrebbero non essere rilevabili tramite il normale processo di scansione di Google. Inoltre, puoi utilizzare Sitemaps anche per fornire a Google i metadati relativi a tipi specifici di contenuti sul tuo sito, inclusi video, immagini, mobile e Notizie.

Google lo utilizza in modo specifico per aiutarli a eseguire la scansione dei siti di notizie.Puoi trovare ulteriori informazioni here su Sitemaps e informazioni su Google News e Sitemap here.

In genere, è possibile trovare Sitemaps.xml nel file robots.txt di un sito Web. Per esempio, del sito TechCrunch è solo

http://techcrunch.com/sitemap.xml

che trasforma questo problema in analisi XML su base regolare. Se non riesci a trovarlo nel file robots.txt, puoi sempre contattare il web master e vedere se lo forniranno.

UPDATE 1 24 ottobre 2012 10:45,

ho parlato con uno dei membri del mio team e mi ha dato alcune informazioni aggiuntive su come gestiamo questo problema. Voglio davvero ribadire che questo non è un problema semplice e richiede molte soluzioni parziali.

Un'altra cosa che facciamo è monitorare diverse "pagine indice" per le modifiche su un determinato dominio. Ad esempio, prendi il il New York Times. Creiamo una pagina di indice per un dominio di primo livello in:

http://www.nytimes.com/

Se si dà un'occhiata alla pagina, si può notare ulteriori aree sub come World, Stati Uniti, Politica, affari, ecc Creiamo pagine indice aggiuntive per tutti loro. Business ha ulteriori pagine di indice annidate come Global, DealBook, Markets, Economy, ecc. Non è raro che un URL abbia più di 20 pagine di indice. Se notiamo altri URL aggiunti all'indice, li aggiungiamo alla coda per eseguire la scansione.

Ovviamente questo è molto frustrante perché potrebbe essere necessario farlo manualmente per ogni sito Web che si desidera sottoporre a scansione. Si consiglia di prendere in considerazione il pagamento di una soluzione. Usiamo SuprFeedr e ne siamo abbastanza contenti.

Inoltre, molti siti Web offrono ancora RSS che è un modo efficace di scansione delle pagine. Consiglio comunque di contattare un webmaster per verificare se hanno qualche soluzione semplice per aiutarti.

Answer 4

Gli algoritmi di Google sono per lo più chiusi, non diranno come lo fanno.

Ho costruito un crawler utilizzando il concetto di directed graph e basato la frequenza di ricerca per indicizzazione nelle pagine 'degree centrality. Si potrebbe considerare un sito Web come un grafico diretto con pagine come nodi e collegamenti ipertestuali come spigoli. Un nodo con alta centralità sarà probabilmente una pagina che viene aggiornata più spesso. Almeno, questa è l'ipotesi.

Questo può essere implementato memorizzando gli URL e i collegamenti tra loro. Se si esegue la scansione e non si eliminano collegamenti, il grafico per sito aumenterà. Calcolando per ogni nodo per sito la (normalizzata) in e outdegree ti fornirà una misura della pagina che è più interessante da ri-sottoporre a scansione più spesso.