Opzioni per il clustering Lucene.NET?

Question

Sono interessato a eseguire Lucene.NET per un'applicazione che viene eseguita nei cluster di Windows. Il problema di ricerca in sé è ragionevolmente piccolo, ma il problema di stato/cluster deve ancora essere gestito.

Capisco che SOLR gestisce il mio scenario (e altro) ma che richiede un contenitore servlet (e Java) pone alcuni problemi per me. A seconda della complessità di un approccio basato su Lucene.NET, potrebbe comunque essere un'opzione di fiala.

La mia domanda ora è ciò che le opzioni che ho per gestire il problema di girare su più host:

• Persist su uno storage condiviso, comuni per tutti i nodi? Lucene.NET gestirà la concorrenza in modo trasparente? I server utilizzerebbero la RAM per la memorizzazione nella cache e in tal caso Lucene.NET gestirà l'invalidazione di questo in base ai file aggiornati in modo trasparente?

• Replica? Ogni server ha la propria copia di tutto ciò di cui ha bisogno. Su qualsiasi aggiornamento, tutti i server ottengono una nuova replica (o diff se questo è ragionevolmente semplice). Strumenti esistenti per questo o per me da gestire?

• Partizionamento del carico di lavoro/sharding? Ogni server gestisce solo i propri dati, sia per le letture che per gli aggiornamenti. Strumenti per gestirlo, unire risultati parziali, ecc.?

• Altre opzioni Potrei aver perso la mia indagine iniziale?

Quando la sperimentazione di una versione locale, mio ​​indice Lucene era nell'ordine di un paio di centinaia mega. A lungo termine posso vedere forse 1-5 GB. Se la frequenza degli aggiornamenti è una difficoltà, posso controllarla in modo abbastanza flessibile. Si prevede che i carichi di lettura/ricerca contemporanei siano molto moderati.

Answer 1

È possibile utilizzare lucene.net con più server, ma è necessario implementare un server di indicizzazione.

Tutte le modifiche apportate devono essere accodate e ogni tanto vengono indicizzati i documenti in sospeso. Inoltre devi immediatamente indicizzare se gli elementi x sono in coda (x dipende dall'impostazione dei tuoi documenti di unione che erano 25.000 per me).

Il ragionamento alla base di quanto sopra è che è necessario evitare di apportare piccole modifiche all'indice in quanto ciò ridurrà le prestazioni straordinarie a causa della creazione di molti piccoli file. Puoi eseguire 2 server di indicizzazione, ma solo 1 indicizzerà alla volta a causa del blocco sull'indice, l'unica ragione per farlo è di fallire se il primo scende, dipende dalle tue esigenze.

Ho utilizzato un indice di 15 Gb con 30 milioni di record. Lo scenario che ho avuto con questo era sotto l'azzurro.

• 1 ruolo lavoratore all'indice cambia

• 2 - 20 ruoli web che forniscono contenuti ciascuna azienda l'indice.

Cambiamenti sono stati spinti ogni 15 minuti e l'indice è stata fusa a 25.000 modifiche e ogni indice combinato contenente 250.000 documenti. Ogni server Web ha controllato la memoria BLOB per le modifiche ogni 15 minuti e ha bloccato il lettore di indici che è stato quindi invalidato se le modifiche sono state scaricate. Il massimo dei documenti per file è fondamentalmente quello di impedire ai server Web di scaricare molte modifiche precedenti.

Ho usato Lucene.AzureDirectory per iniziare, ma non era affidabile nel rilevare i blob modificati nell'archiviazione BLOB, quindi ho finito per iterare i BLOB e confrontarli localmente e scaricato se necessario.

Ora implementerei qualcosa di simile? la risposta è un grande no. Io userei elasticsearch o solr invece mentre stai reinventando la ruota.