Si può fare in modo che l'indice Apache Solr sia transazionale in modo coerente con il DB che viene indicizzato?

Question

Sono nuovo di Solr. Sto cercando di creare un server che memorizza i dati strutturati in un database e che può essere cercato utilizzando Solr/Lucene. Il server può essere raggruppato in un numero qualsiasi di nodi identici per l'alta disponibilità.

Sembra che la configurazione standard Solr memorizzi l'indice in un file sul file system. Questo sembra introdurre alcuni problemi con coerenza e clustering.

Come faccio a rendere l'indice coerente con la transazione con il DB? C'è un modo per fare questo? (ad esempio, un modo per rendere i commit al DB coordinato con commit all'indice Solr?)

C'è un modo per memorizzare l'indice nel DB (relazionale)? Ciò risolverebbe i problemi di coerenza e i problemi di cluster, ma non trovo molta letteratura su come farlo.

Se configurato come un cluster, ciascun nodo del cluster deve mantenere la propria copia dell'indice. Non è chiaro se più istanze di Solr possano aggiornare un singolo indice o meno.

Oppure - ci arrendiamo accettando che l'indice non è garantito per essere coerente, ricostruirlo ogni giorno o così? Cosa fanno normalmente le persone a riguardo?

Answer 1

Q> Come si rende l'indice coerente per transazione con il DB?
A> Non è possibile. Probabilmente puoi inventare un altro livello di transazione in cima, ma ci vorranno anni per svilupparsi e non raggiungerai comunque il 100% di coerenza. Ad esempio, è possibile inviare dati sia al DB che a Solr e commettere solo dopo l'arrivo di entrambi i dati, ma questo non sarà atomico.

Q> C'è un modo per memorizzare l'indice nel DB (relazionale)?
A> Con Lucene 4.0, è possibile (scrivendo il proprio codec). Ma questo non risolverà il tuo problema.

Q> Se configurato come un cluster, ciascun nodo del cluster deve mantenere la propria copia dell'indice?
A> Sì.

Q> Non è chiaro se più istanze di Solr possano aggiornare un singolo indice o meno.
A> Più istanze Lucene/Solr non possono scrivere sugli stessi file di indice. Max che puoi fare è creare più IndexSearcher s. Ma questo è probabilmente fatto a livello di Solr comunque.

Q> si rinuncia accettare che l'indice non è garantito per essere coerente?
A> Sì. Penso che tu sia troppo db-centrico. Pensa a Solr/Lucene come pensi a Google: scommetto che non distribuiranno il loro intero indice atomicamente in tutto il mondo. Se i risultati della ricerca avranno incongruenze minori a seconda del server che hai colpito (per alcuni secondi ovviamente), non è un grosso problema.

Q> ricostruirlo ogni giorno o così? Cosa fanno normalmente le persone a riguardo?
A> Lucene ha near-real time search ma al livello di base è sufficiente inviare aggiornamenti dell'indice e eseguire il commit mentre le modifiche del db si verificano, quindi riaprire il lettore di indici per visualizzare questi aggiornamenti. Tutto questo è fatto automaticamente in Solr.

Answer 2

Conoscere questo è un po 'vecchio ma potrebbe aiutare qualcuno. Puoi provare solrcloud con lo zookeeper Apache.

Apache Solr include la possibilità di configurare un cluster di server Solr che combina la tolleranza agli errori e l'alta disponibilità. Chiamato SolrCloud, queste funzionalità forniscono funzionalità di indicizzazione e ricerca distribuita, supportando le seguenti funzionalità con poca configurazione:

Central configuration for the entire cluster 
Automatic load balancing and fail-over for queries 
ZooKeeper integration for cluster coordination and configuration. 

Zookeeper è un gestore cluster per solr. Funziona davvero bene con solr.

https://cwiki.apache.org/confluence/display/solr/SolrCloud 

http://zookeeper.apache.org/doc/trunk/zookeeperOver.html