Come configurare Lucene / Solr per una web app B2B?

Question

Data:

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

Informazioni Forse rilevanti:

• Diversi nuovi clienti ogni settimana (in qualsiasi momento durante le ore lavorative)
• più server web e server di database (gli utenti possono accedere attraverso un qualsiasi web server)
• Let soggiorno agnostica del linguaggio o la marca sql, dal momento che Lucene (e Solr) hanno una larghezza di supporto

Ad esempio:

Joel Spolsky ha detto in Podcast # 11 che il suo prodotto ospitato web app, FogBugz On-Demand , usa Lucene. Ha migliaia di clienti on-demand. E ogni cliente riceve un proprio database.

Indice per client e memorizzarlo nella banca dati del cliente . Non sono sicuro sui dettagli. E io non sono sicuro se questo è un grave mod per Lucene.

La questione:

In che modo si imposta Lucene ricerca in modo che ogni cliente può cercare solo all'interno del suo database?

Come faresti di impostazione dell'indice (es)?
Dove memorizzare l'indice (es)?
Avreste bisogno di aggiungere un filtro a tutte le query di ricerca?
Se un client annullato, come è possibile eliminare la loro (parte del) Indice? (Questo può essere banale - non ancora sicuro)

possibili soluzioni:

Crea un indice per ogni client (database)

• Pro: ricerca è più veloce (oltre un index-for-all metodo). Gli indici sono relativi alla dimensione dei dati del cliente.
• Con:. Non sono sicuro di ciò che questo comporta, né so se questo è al di là portata di Lucene

Avere un unico, gigantesco indice con un campo database_name. Sempre includere database_name come filtro.

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

Un'ultima cosa:
Vorrei anche accettare una risposta che utilizzi Solr (l'estensione di Lucene). Forse è meglio adatto per questo problema. Non è sicuro.

Answer 1

mi chiamò dal FogBugz StackExchange. Il mio nome è Jude, io sono la corrente dell'architetto ricerca di FogBugz.

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

• Per motivi legati alla portabilità dei dati, la sicurezza, ecc, teniamo tutti i nostri database On Demand e indici separati.
• Mentre noi utilizziamo Lucene (Lucene.NET, in realtà), abbiamo modded il suo back-end abbastanza sostanzialmente in modo che possa conservare il suo indice del tutto nel database. Inoltre, una cache locale è mantenuto su ogni hosting in modo che colpi di database non necessari possono essere evitati per quanto possibile.
• I nostri filtri sono quasi interamente di database-side (dato che sono utilizzati da aspetti di FogBugz al di fuori della ricerca), in modo da query nostra ricerca parser separa in componenti full-text e non full-text, esegue le ricerche, e combina i risultati. Questo è un po 'un peccato, in quanto invalida molte ottimizzazioni utili che Lucene è in grado di fare.

Ci sono alcuni vantaggi per quello che abbiamo fatto. Gestire gli account è molto semplice, dal momento che i dati dei clienti e il loro indice sono memorizzati nello stesso posto. Ci sono alcuni aspetti negativi troppo, anche se, come ad esempio una serie di ricerche veramente fastidiosi limite in cui sottoperformare i nostri standard minimi. Retrospettivamente, la nostra ricerca era fresco e ben fatto per il suo tempo. Se dovessi farlo di nuovo, tuttavia, vorrei scoraggiare questo approccio .

È sufficiente, a meno che il dominio di ricerca è molto speciale o siete disposti a dedicare uno sviluppatore di incredibilmente veloce la ricerca, probabilmente stai andando a essere superato 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 usare elasticsearch, Solr o Xapian per la mia full-text soluzione di ricerca di database-backed. Come per i quali, che dipende dalle vostre esigenze ausiliari (piattaforma, tipo di query, estensibilità, la tolleranza per una serie di stranezze su un altro, ecc.)

Sul tema di una grande indice contro molti dispersi indici (!): Entrambi possono lavoro. Credo che la decisione davvero bugie con che tipo di architettura si sta cercando di costruire, e che tipo di prestazioni necessarie. Si può essere abbastanza flessibile se si decide che un 2-seconda risposta di ricerca è ragionevole, ma una volta che si inizia a dire che qualcosa di più di 200ms è inaccettabile, le opzioni cominciano a sparire piuttosto velocemente. Pur mantenendo un unico grande indice di ricerca per tutti i tuoi clienti può essere di gran lunga più efficace di gestire un sacco di piccoli indici, non è necessariamente più veloce (come lei ha sottolineato). Personalmente ritengo che, in un ambiente sicuro, il vantaggio di mantenere i dati dei clienti separati, non è da sottovalutare. Quando l'indice si corrompe, non porterà tutti ricerca ad una battuta d'arresto; stupide piccoli bug non esporre dati sensibili; account utente soggiorno Modulare è più facile da estrarre una serie di conti e li plop su un nuovo server; ecc.

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

[1]: Nel 2013, FogBugz ha iniziato alimentando la sua ricerca e la capacità di filtraggio con elasticsearch. Ci piace.

Answer 2

Shalin Shekhar Mangar mi rispose al Solr-user mailing list e per e-mail privato. Shalin è un collaboratore di Solr e un autore del libro di prossima Solr in azione .

La sua risposta alla mailing list:

Come sarebbe si imposta l'indice (es)?

  

mi piacerebbe guardare la creazione di più core per ogni cliente. Potrebbe essere necessario per l'installazione   schiavi come pure a seconda del traffico di ricerca.

Da dove memorizzare l'indice (es)?

  

Impostazione 5K core su una scatola non funziona. Quindi è necessario partizione   i clienti in più scatole ciascuna con un sottoinsieme di core.

avresti bisogno per aggiungere un filtro a tutte le query di ricerca?

  

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

Se un client annullato, come è possibile eliminare la loro (parte del) Indice? (Questo può essere banale - non ancora sicuro)

  

Con differenti core per ogni cliente, this'd essere 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. Vedere http://wiki.apache.org/solr/LotsOfCores - non sono stato in grado di spingere questi cambiamenti in Solr ancora.

Answer 3

Sono ancora poco chiare su cosa esattamente da 5K database utenti stanno cercando, per cui è necessario Lucene, e le dimensioni dei dati in ogni 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 query. L'autenticazione sarà ancora un problema e un modo (hacker) per avvicinarlo sarebbe quello di rendere l'URL difficile da indovinare.

2. Il tuo server web può interrogare il Solr istanza / core a seconda di ciò che hanno accesso a.

suggerirei stare lontano dall'approccio filtro e la creazione di un indice enorme che unisce tutti i database.

HTH