Strategia per aggiornare l'indice di ricerca dopo aver corretto la generazione dell'indice

TL; DR: Puoi fare le cose più velocemente.

Ho avuto un problema simile. Risulta, con Lucene, ricostruire l'intero indice usando il codice ottimizzato per esso, partendo da zero, usando una query SELECT field1, field2 FROM table senza clausola where, era abbastanza veloce. Il motivo per il rapido tempo di esecuzione era probabilmente che il codice di interfacciamento di Lucene non aveva bisogno di preoccuparsi delle query di Lucene parallele e l'istruzione SQL poteva usare una scansione sequenziale.

Per questo motivo abbiamo avuto i metodi indexOne e indexAll , scritti separatamente.

Non sono sicuro che sia abbastanza veloce per il tuo caso, ma dovresti dare un'occhiata alle API di Lucene, vedere che tipo di caratteristiche che migliorano le prestazioni: non sincronizzare per ogni singolo elemento? Non ti importa delle query parallele? Ricostruisci l'indice da zero? Non ricordo quali caratteristiche dell'API di Lucene abbiamo utilizzato per ottenere le ottime prestazioni perché erano 8 anni fa, ma ricordo che le prestazioni di indexAll erano molto meglio di indexOne .

Naturalmente, questo tipo di approccio richiede alcuni tempi di inattività. Ma con un'ottimizzazione abbastanza buona, forse puoi spingere il tempo di fermo a un livello accettabile, da ore a minuti minuti.

Se non riesci a ridurre il tempo di inattività a un livello accettabile, la tua unica soluzione è un indicizzatore in background. Avevamo una tabella denominata indexqueue nel database e conteneva identificatori di oggetto. L'indicizzatore in background preleva regolarmente le righe da questa tabella e reindicizza solo le righe recuperate. Quindi inserisci semplicemente ogni identificatore di oggetto nella tabella indexqueue e attendi che tutto venga reindicizzato.

Per quanto riguarda il numero di record, abbiamo avuto milioni di record. Il tuo problema di centinaia di migliaia di record, con il leggero progresso delle prestazioni del computer in 8 anni e il grande progresso nella quantità di memoria del computer, è minuscolo in confronto ai milioni di record di problemi che abbiamo avuto. In passato utilizzavamo dischi rigidi e oggi i server utilizzano SSD!

Sono abbastanza sicuro che puoi reindicizzare migliaia di righe al secondo, se fai le cose in modo ottimale, a meno che, naturalmente, ogni riga non abbia una sorta di corpo di testo di 1000 pagine di testo. Questo rende centinaia di migliaia di righe al minuto.

Anche se introduci qualcosa come il tuo campo di versione nei documenti, non puoi sapere in anticipo quale tipo di bug ci sarà in futuro. Ce n'è sempre uno che rende necessario ricostruire l'intero indice. Quindi dovresti cercare una strategia che lo renda possibile.

Hai scritto

Recalculating the complete index requires multiple hours and the application is redeployed regularly as part of continuous deployment. Therefore it must be expected that the application is shut down in between the updating process.

e questo è in realtà il problema ed è la soluzione: non appena si disaccoppia l'applicazione principale (e le sue distribuzioni) dal processo / programma che ricalcola l'indice, il problema viene risolto. Quindi è possibile arrestare e ridistribuire l'applicazione senza arrestare il processo di ricalcolo.

Naturalmente, probabilmente dovrai prendere alcune misure aggiuntive come

• progettare il ricalcolo in modo che non interferisca con la funzione di ricerca dell'applicazione principale. Ad esempio, è possibile innanzitutto eseguire un processo di lunga durata che calcoli le modifiche necessarie all'indice senza applicarle e applicare le modifiche in seguito (che richiede probabilmente solo una frazione del tempo totale, se interessano solo una piccola parte del tempo voci di indice)

• registra se il ricalcolo è stato applicato con successo, quindi non viene applicato una seconda volta

• e, se necessario: prendere in considerazione l'implementazione di una strategia per riavviare il ricalcolo dell'indice in caso di interruzione nel punto in cui è stata interrotta.

Ecco un paio di soluzioni alternative al tuo problema:

1. Potresti utilizzare la strategia distribuzione blu-verde con il tuo indice di ricerca. Fondamentalmente si dovrebbe creare periodicamente l'indice fresco nella distribuzione in standby. Quando l'indice ha finito di costruire, cambieresti per utilizzare lo standby in produzione e il tuo indice live in precedenza diventerebbe il nuovo standby.
2. Puoi utilizzare l'indice di ricerca solo per la ricerca e cercare i documenti e gli attributi effettivi dal tuo database. Quindi i tuoi risultati di ricerca restituirebbero l'ID dell'articolo e tu invierai le copie aggiornate per l'attributo di ciascun articolo.