Come gestire gli aggiornamenti molto frequenti per un indice di Lucene

Question

Sto cercando di prototipo di un'applicazione di indicizzazione/ricerca che utilizza le fonti molto volatili dati indicizzazione (forum, social network, ecc), qui sono alcuni dei requisiti di prestazioni,

1. tempo di ritorno molto veloce (con questo voglio dire che tutti i nuovi dati (come un nuovo messaggio su un forum) dovrebbero essere disponibili nei risultati di ricerca molto presto (meno di un minuto))

2. i è necessario eliminare i vecchi documenti su base abbastanza regolare per garantire che i risultati della ricerca non siano datati.

3. Ultimo ma non meno importante, l'applicazione di ricerca deve essere reattiva. (Latenza dell'ordine di 100 millisecondi, e dovrebbe sostenere almeno 10 QPS)

Tutti i requisiti che ho attualmente possono essere soddisfatti w/o utilizzando Lucene (e che mi permetteva di soddisfare tutti i 1,2 e 3), ma sto anticipando altri requisiti in futuro (come la rilevanza della ricerca, ecc.) che Lucene rende più facile da implementare. Tuttavia, poiché Lucene è progettato per casi d'uso molto più complessi di quello a cui sto lavorando attualmente, sto attraversando un periodo difficile per soddisfare le mie esigenze in termini di prestazioni.

Ecco alcune domande,

a. Ho letto che il metodo optimize() nella classe IndexWriter è costoso e non dovrebbe essere utilizzato da applicazioni che eseguono aggiornamenti frequenti, quali sono le alternative?

b. Per poter eseguire aggiornamenti incrementali, ho bisogno di continuare a inviare nuovi dati e di aggiornare il lettore di indici per assicurarmi che siano disponibili i nuovi dati. Questi stanno andando a influenzare 1 e 3 sopra. Dovrei provare gli indici duplicati? Quali sono alcuni approcci comuni per risolvere questo problema?

c. So che Lucene fornisce un metodo di eliminazione, che consente di eliminare tutti i documenti che corrispondono a una determinata query, nel mio caso, ho bisogno di cancellare tutti i documenti più vecchi di una certa età, ora l'unica opzione è aggiungere un campo data ad ogni documenta e usalo per cancellare i documenti più tardi. È possibile eseguire query di intervallo sugli ID dei documenti (posso creare il mio campo ID poiché penso che quello creato da Lucene continua a cambiare) per eliminare i documenti? È più veloce del confronto delle date rappresentate come stringhe?

So che queste sono domande molto aperte, quindi non sto cercando una risposta dettagliata, cercherò di trattare tutte le vostre risposte come suggerimenti e usarli per informare il mio progetto. Grazie! Per favore fatemi sapere se avete bisogno di altre informazioni.

Answer 1

A: Penso che con le ultime versioni di Lucene, il metodo di ottimizzazione non sia realmente necessario e con il mio suggerimento per l'elemento C, in realtà non dovrebbe essere necessario.

B: Ancora una volta, penso che con l'ultima versione di Lucene, i ricercatori siano a conoscenza del fatto che gli aggiornamenti sono fatti e possono gestirli senza che tu debba fare qualcosa di speciale.

C: Eviterei di eliminare e creo un nuovo indice ogni giorno. Se si memorizza l'età del documento nell'indice, è possibile utilizzare l'indice esistente per crearne uno nuovo. Durante la scrittura dell'indice, recupera tutti i giovani documenti, passali e aggiungili al tuo nuovo indice. Avere un metodo public util chiamato getCurrentIndex che viene utilizzato dagli utenti per ottenere l'ultimo indice live. Tieni 1 o 2 vecchi indici in giro per ogni evenienza e dovresti essere pronto.

Answer 2

Si potrebbe prendere in considerazione l'ipotesi di utilizzare Solr piuttosto che usare Lucene. Solr gestisce tutti i requisiti che hai menzionato (aggiornamenti quasi in tempo reale, eliminazione di documenti, prestazioni/sharding, query di intervallo) e lo farà meglio del tuo codice laminato a mano. Non dovrai affrontare problemi a livello di IndexReader, ad esempio quando aggiornare IndexReader dopo un aggiornamento.

Per quanto riguarda le query di intervallo, Solr dispone delle funzionalità TrieField, che velocizzano le query a intervallo numerico. Vedi http://www.lucidimagination.com/blog/2009/05/13/exploring-lucene-and-solrs-trierange-capabilities/

Answer 3

Lucene ora supporta Near Real Time Search. In sostanza, ottieni un Reader da IndexWriter ogni volta che esegui una ricerca. Le modifiche in memoria non vengono trasferite sul disco fino a quando non viene raggiunta la dimensione del buffer della RAM o un esplicito commit viene chiamato sul writer. Poiché l'IO del disco viene evitato saltando commit, le ricerche ritornano rapidamente anche con i nuovi dati.

Uno dei problemi con l'NRT di Lucene è l'algoritmo di unione Logaritmo dell'indice. Un'unione viene attivata dopo che 10 documenti sono stati aggiunti a un segmento. Successivamente, tali 10 segmenti vengono uniti per creare un segmento con 100 documenti e così via. Ora, se hai 999.999 documenti, e viene avviata un'unione, ci vorrà un po 'di tempo per tornare, rompendo la tua promessa "in tempo reale".

LinkedIn ha rilasciato Zoie, una libreria su Lucene che risolve questo problema. Questo è vivo nella produzione gestendo milioni di aggiornamenti e ricerche ogni giorno.

Principalmente, Lucene supporterà tutte le vostre esigenze, poiché state scartando vecchi aggiornamenti e la finestra mobile è di dimensioni pressoché costanti. In caso contrario, potrebbe essere necessario provare Zoie che è dimostrato sul campo di battaglia.

Answer 4

È possibile memorizzare nella cache il proprio indicizzatore per un breve periodo di tempo e riaprirlo. Usiamo per questo scopo asp.net WebCache che ha CacheItemUpdateCallback chiamato prima che l'elemento chached scada.