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

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à.Si può fare in modo che l'indice Apache Solr sia transazionale in modo coerente con il DB che viene indicizzato?

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?

fonte

2012-10-19 AgilePro

Questo può aiutare con gli aggiornamenti di gara-zione su un unico documento http://stackoverflow.com/questions/12857218/versioning-and-optimistic-locking-in-solr-4-0 Avete problemi specifici come l'atomicità multi-doc in mente? – aitchnyu

Il problema specifico consiste semplicemente nel fornire un indice a un'applicazione enterprise con cluster. Ogni nodo sta aggiornando il database in modo indipendente. Poiché Solr non memorizza i dati in un DB, ogni nodo deve avere una propria copia di Solr in esecuzione e ciascuno sul proprio indice. Il problema è semplicemente quello di assicurarsi che ogni Solr venga informato di tutte le modifiche da ciascuno dei nodi del cluster. Nel caso in cui un nodo si ritiri, il database tornerà a uno stato coerente, ma l'indice Solr potrebbe avere più o meno aggiornamenti in esso. Questi indici saranno semplicemente sbagliati fino alla ricostruzione, che deve essere eseguita periodicamente. – AgilePro

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.

fonte

2012-10-19 09:51:29 mindas

Grazie! Queste sono grandi risposte. – AgilePro

Se si è soddisfatti, è possibile che si desideri contrassegnare la risposta come accettata. Questo è come funziona questo sito. – mindas

Sapete ... ci sono voluti 15 minuti di ricerca per capire che l'icona di controllo era qualcosa su cui cliccare per "accettare" una risposta. Ma ora lo so, grazie per il suggerimento. – AgilePro

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

fonte

2014-11-24 12:04:56

Questa è un'informazione interessante e utile, ma non affronta il problema della transazione. Il comportamento desiderato è quello di salvare la modifica SE E SOLO SE le modifiche vengono salvate anche nel DB relazionale. Per essere più specifico, se l'aggiornamento del DB fallisce, voglio che l'aggiornamento Solr non abbia successo. Ho dovuto accontentarmi del fatto che l'indice fosse approssimativamente a destra e di ricostruire l'indice su un programma (quotidiano) per affrontare le incongruenze. – AgilePro

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

risposta

Problemi correlati