Impegni e ricerca NRT in SolrCloud

1. Panoramica

Solr è una delle soluzioni di ricerca basate su Lucene più popolari. È veloce, distribuito, robusto, flessibile e ha una comunità di sviluppatori attiva alle spalle. SolrCloud è la nuova versione distribuita di Solr .

Una delle sue caratteristiche chiave qui è la ricerca quasi in tempo reale (NRT) , ovvero i documenti sono disponibili per la ricerca non appena vengono indicizzati.

2. Indicizzazione in SolrCloud

Una raccolta in Solr è composta da più frammenti e ogni frammento ha varie repliche. Una delle repliche di un frammento viene selezionata come leader per quel frammento quando viene creata una raccolta:

  • Quando un client tenta di indicizzare un documento, al documento viene prima assegnato un frammento in base all'hash dell'id del documento
  • Il client ottiene l'URL del leader di quel frammento dal guardiano dello zoo e, infine, la richiesta di indice viene effettuata a quell'URL
  • Lo shard leader indicizza il documento localmente prima di inviarlo alle repliche
  • Una volta che il leader riceve un riconoscimento da tutte le repliche attive e in fase di ripristino, restituisce la conferma all'applicazione client di indicizzazione

Quando indicizziamo un documento in Solr, non va direttamente all'indice. È scritto in quello che viene chiamato tlog (registro delle transazioni). Solr utilizza il registro delle transazioni per garantire che i documenti non vadano persi prima del loro commit, in caso di arresto anomalo del sistema.

Se il sistema si arresta in modo anomalo prima che i documenti nel registro delle transazioni vengano salvati, ovvero persistiti su disco, il registro delle transazioni viene riprodotto quando il sistema si riavvia, portando a zero la perdita di documenti.

Ogni richiesta di indice / aggiornamento viene registrata nel registro delle transazioni che continua a crescere fino a quando non viene emesso un commit.

3. Si impegna in SolrCloud

Un'operazione di commit significa finalizzare una modifica e mantenerla su disco. SolrCloud fornisce due tipi di operazioni di commit e cioè. un commit e un soft commit.

3.1. Commit (Hard Commit)

Un commit o un hard commit è quello in cui Solr scarica su disco tutti i documenti non salvati in un registro delle transazioni. Il registro delle transazioni attivo viene elaborato e quindi viene aperto un nuovo file di registro delle transazioni.

Aggiorna anche un componente chiamato ricercatore in modo che i documenti appena impegnati diventino disponibili per la ricerca. Un ricercatore può essere considerato come una visualizzazione di sola lettura di tutti i documenti impegnati nell'indice.

L'operazione di commit può essere eseguita esclusivamente dal client chiamando l' API di commit :

String zkHostString = "zkServer1:2181,zkServer2:2181,zkServer3:2181/solr"; SolrClient solr = new CloudSolrClient.Builder() .withZkHost(zkHostString) .build(); SolrInputDocument doc1 = new SolrInputDocument(); doc1.addField("id", "123abc"); doc1.addField("date", "14/10/2017"); doc1.addField("book", "To kill a mockingbird"); doc1.addField("author", "Harper Lee"); solr.add(doc1); solr.commit();

Allo stesso modo, può essere automatizzato come autoCommit specificandolo nel file solrconfig.xml , vedere la sezione 3.4.

3.2. SoftCommit

Softcommit è stato aggiunto da Solr 4 in poi, principalmente per supportare la funzione NRT di SolrCloud. È un meccanismo per rendere i documenti ricercabili quasi in tempo reale, saltando gli aspetti costosi degli hard commit.

Durante un softcommit, il registro delle transazioni non viene troncato, ma continua a crescere. Tuttavia, viene aperto un nuovo ricercatore , che rende visibili i documenti dall'ultimo softcommit per la ricerca. Inoltre, alcune delle cache di primo livello in Solr vengono invalidate, quindi non è un'operazione completamente gratuita.

Quando specifichiamo il maxTime per softcommit come 1000, significa che il documento sarà disponibile nelle query entro e non oltre 1 secondo dal momento in cui è stato indicizzato.

Questa funzione garantisce a SolrCloud la potenza della ricerca quasi in tempo reale, poiché i nuovi documenti possono essere ricercati anche senza impegnarli. Softcommit può essere attivato solo come autoSoftCommit specificandolo nel file olrconfig.xml , vedere la sezione 3.4.

3.3. Autocommit e Autosoftcommit

Il file solrconfig.xml è uno dei file di configurazione più importanti in SolrCloud. Viene generato al momento della creazione della raccolta. Per abilitare autoCommit o autoSoftCommit , è necessario aggiornare le seguenti sezioni nel file:

 10000 30000 true   6000 1000 

maxTime: il numero di millisecondi dal primo aggiornamento senza commit dopo il quale dovrebbe avvenire il successivo commit / softcommit.

maxDocs: il numero di aggiornamenti che si sono verificati dall'ultimo commit e dopo i quali dovrebbe avvenire il successivo commit / softcommit.

openSearcher: questa proprietà dice a Solr se aprire o meno un nuovo ricercatore dopo un'operazione di commit. Se è vero , dopo un commit, il vecchio cercatore viene chiuso e un nuovo ricercatore viene aperto, rendendo il documento impegnato visibile per la ricerca . Se è falso , il documento non sarà disponibile per la ricerca dopo il commit.

4. Ricerca quasi in tempo reale

La ricerca quasi in tempo reale si ottiene in Solr utilizzando una combinazione di commit e softcommit. Come accennato in precedenza, quando un documento viene aggiunto a Solr, non sarà visibile nei risultati della ricerca fino a quando non verrà inserito nell'indice.

I commit normali sono costosi, motivo per cui i softcommit sono utili. Tuttavia, poiché softcommit non mantiene i documenti, è necessario impostare l' intervallo maxTime di autocommit (o maxDocs ) su un valore ragionevole, a seconda del carico che ci aspettiamo.

4.1. G et s in tempo reale

C'è un'altra funzionalità fornita da Solr che è in realtà in tempo reale: l' API get . L' API get può restituirci un documento che non è nemmeno ancora soft commit.

Cerca direttamente nei log delle transazioni se il documento non viene trovato nell'indice. Quindi possiamo attivare una chiamata API get , immediatamente dopo il ritorno della chiamata all'indice e saremo ancora in grado di recuperare il documento.

Tuttavia, come tutte le cose troppo buone, qui c'è un problema. Dobbiamo passare l' id del documento nella chiamata get API. Naturalmente, possiamo fornire altre query di filtro insieme all'ID , ma senza ID , la chiamata non funziona:

//localhost:8985/solr/myCollection/get?id=1234&fq=name:baeldung

5. conclusione

Solr ci fornisce un po 'di flessibilità per quanto riguarda la modifica della capacità NRT. Per ottenere le migliori prestazioni dal server, dobbiamo sperimentare i valori di commit e softcommit, in base al nostro caso d'uso e al carico previsto.

Non dovremmo mantenere il nostro intervallo di commit troppo lungo, altrimenti il ​​nostro registro delle transazioni aumenterà fino a raggiungere dimensioni considerevoli. Tuttavia, non dovremmo eseguire i nostri softcommit troppo frequentemente.

Si consiglia inoltre di eseguire un adeguato test delle prestazioni del nostro sistema prima di passare alla produzione. Dovremmo controllare se i documenti stanno diventando ricercabili entro il nostro intervallo di tempo desiderato.