Come installare Lucene/Solr per un'app Web B2B?

Question

Data:

• 1 di database per client (clienti commerciali)
• 5000 clienti
• I clienti hanno tra i 2 a 2000 utenti (media è ~ 100 utenti/client)
• 100k a 10 milioni di record per database
• Gli utenti devono cercare spesso quei record (è il modo migliore di navigare i loro dati)

informazioni Possibilmente rilevanti:

• Diversi nuovi clienti ogni settimana (in qualsiasi momento durante le ore lavorative)
• server web multiple e server di database (gli utenti possono accedere tramite qualsiasi web server)
• Restiamo agnostica di lingua o SQL marca, dal momento che Lucene (e Solr) hanno una larghezza di supporto

Per esempio:

Joel Spolsky ha dichiarato in Podcast #11 che il suo prodotto di app Web ospitato, FogBugz On-Demand, utilizza Lucene. Ha migliaia di clienti on-demand. E ogni cliente ottiene il proprio database.

Utilizzano uno index per client and store it in the client's database. Non sono sicuro dei dettagli. E non sono sicuro che questa sia una mod seria per Lucene.

la domanda:

Come ti configurazione di ricerca Lucene in modo che ogni cliente può cercare solo all'interno del suo database?

Come impostare gli indici?
Dove memorizzi gli indici?
Dovresti aggiungere un filtro a tutte le query di ricerca?
Se un cliente ha annullato, come cancellereste il loro (parte dell'indice)? (Questo può essere banale - non ancora sicuro)

Possibili soluzioni:

fare un indice per ogni client (database)

• Pro: la ricerca è più veloce (oltre un index metodo globale). Gli indici sono relativi alla dimensione dei dati del cliente.
• Contro: Non sono sicuro di ciò che questo comporta, né so se questo va oltre lo scopo di Lucene.

Avere un unico indice gigantesco con un campo database_name. Includere sempre database_name come filtro.

• Pro: Non sono sicuro. Forse buono per supporto tecnico o fatturazione per cercare tutti i database per informazioni.
• Con: La ricerca è più lenta (rispetto al metodo index-per-client). Sicurezza difettosa se il filtro di query viene rimosso.

Un'ultima cosa:
Vorrei anche accettare una risposta che utilizza Solr (l'estensione di Lucene). Forse è più adatto a questo problema. Non sono sicuro.

Answer 1

Mi hai chiamato dal FogBugz StackExchange. Mi chiamo Jude, sono l'attuale architetto di ricerca di FogBugz.

Ecco un abbozzo di come il FogBugz On architettura di ricerca demand è impostato [1]:

• Per motivi legati alla portabilità dei dati, la sicurezza, ecc, teniamo tutti i nostri On banche dati della domanda e indici separati.
• Mentre usiamo Lucene (Lucene.NET, in realtà), abbiamo modulato il suo backend in modo abbastanza sostanziale in modo che possa memorizzare il suo indice interamente nel database. Inoltre, su ogni webhost viene mantenuta una cache locale, in modo tale che, quando possibile, si possano evitare inutili accessi al database.
• I nostri filtri sono quasi interamente lato database (poiché vengono utilizzati da aspetti di FogBugz al di fuori della ricerca), quindi il nostro parser di ricerca separa le query in componenti full-text e non full-text, esegue le ricerche e combina i risultati. Questo è un po 'sfortunato, poiché svuota molte utili ottimizzazioni che Lucene è in grado di fare.

Ci sono alcuni vantaggi a ciò che abbiamo fatto. La gestione degli account è abbastanza semplice, poiché i dati dei clienti e il loro indice sono memorizzati nello stesso posto. Ci sono anche alcuni aspetti negativi, ad esempio una serie di ricerche di casi davvero fastidiose che hanno sottoperformato i nostri standard minimi. Retrospettivamente, la nostra ricerca è stata interessante e ben fatta per il suo tempo. Se dovessi farlo di nuovo, tuttavia, vorrei scoraggiare questo approccio.

Semplicemente, a meno che il tuo dominio di ricerca sia molto speciale o sei disposto a dedicare uno sviluppatore a una ricerca incredibilmente veloce, probabilmente sarai sovraperformato da un prodotto eccellente come ElasticSearch, Solr o Xapian.

Se fossi facendo questo oggi, a meno che il mio dominio di ricerca è stato estremamente preciso, probabilmente usano elasticsearch, Solr o Xapian per la mia soluzione di ricerca full-text del database-backed. Per quanto riguarda ciò, ciò dipende dalle vostre esigenze ausiliarie (piattaforma, tipo di query, estensibilità, tolleranza per una serie di stranezze rispetto a un'altra, ecc.)

Sull'argomento di un indice di grandi dimensioni rispetto a molti (!) Indici dispersi: Entrambi possono funzionare. Penso che la decisione dipenda davvero dal tipo di architettura che stai cercando di costruire e dal tipo di prestazioni di cui hai bisogno. Puoi essere abbastanza flessibile se decidi che una risposta di ricerca di 2 secondi è ragionevole, ma una volta che inizi a dire che qualcosa di oltre 200ms non è accettabile, le tue opzioni iniziano a scomparire abbastanza rapidamente. Mantenere un unico grande indice di ricerca per tutti i tuoi clienti può essere enormemente più efficiente rispetto alla gestione di molti piccoli indici, non è necessariamente più veloce (come hai sottolineato). Personalmente ritengo che, in un ambiente sicuro, il vantaggio di mantenere separati i dati dei clienti non sia da sottovalutare. Quando il tuo indice viene corrotto, non fermerà tutta la ricerca; stupidi piccoli bug non espongono i dati sensibili; gli account utente rimangono modulari: è più facile estrarre un insieme di account e trasferirli su un nuovo server; eccetera.

io non sono sicuro se questo ha risposto alla tua domanda, ma spero che io almeno soddisfatto la vostra curiosità :-)

[1]: Nel 2013, ha iniziato FogBugz potenziare le proprie capacità di ricerca e filtraggio con elasticsearch. Ci piace.

Answer 2

Non sono ancora chiaro su quali siano esattamente i database 5K che gli utenti stanno cercando, perché è necessario Lucene e le dimensioni dei dati in ciascun database. Ma io prenderò un colpo in ogni caso:

1. Si dovrebbe essere guardando Multicore Solr (ogni core = 1 indice) e si dispone di un URL univoco per interrogare. L'autenticazione sarà ancora un problema e un modo (hacker) per avvicinarsi sarebbe rendere difficile indovinare l'URL.

2. I server Web possono interrogare l'istanza/core Solr in base a ciò a cui hanno accesso.

Suggerirei di stare lontano dall'approccio del filtro e creare un enorme indice che combina tutti i database.

HTH

Answer 3

Shalin Shekhar Mangar mi rispose al Solr-user mailing list e per e-mail privato. Shalin è un contributore di Solr e un autore del libro in uscita Solr in Action.

sua risposta sulla mailing list:

Come sarebbe si imposta l'indice (es)?

Guarderei all'installazione di più core per ogni client. Potrebbe essere necessario impostare gli slave in base al traffico di ricerca.

Dove memorizzate gli indici?

L'impostazione di core 5K su una casella non funzionerà. Quindi sarà necessario suddividere i client in in più box ciascuno con un sottoinsieme di core.

Sarebbe necessario aggiungere un filtro a tutte le query di ricerca?

No, ma sarà necessario inviare la query al host corretto (forse un DB mappatura vi aiuterà)

Se un client annullato, come è possibile eliminare la loro (parte del) indice? (questo potrebbe essere banale, non lo so ancora)

Con diversi core per ogni cliente, questo sarà abbastanza facile.

La sua risposta per e-mail:

ho lavorato su un simile caso d'uso in passato e abbiamo usato l'approccio multi-core con alcune ottimizzazioni pesanti sul lato Solr. Vedi http://wiki.apache.org/solr/LotsOfCores - Non sono ancora riuscito a trasferire queste modifiche in Solr.