Filtraggio / ricerca efficienti

Question

Abbiamo un'applicazione ospitata che gestisce pagine di contenuti. Ogni pagina può avere un numero di campi personalizzati e alcuni campi standard (data e ora, nome utente, email utente, ecc.)

Con potenzialmente centinaia di siti diversi che utilizzano il sistema: qual è un modo efficace per gestire il filtro / la ricerca? Immagina una vista a griglia che desideri restringere. Puoi filtrare su campi specifici (userid, data) oppure puoi inserire una ricerca full-text.

Ad esempio, " tutte le pagine avviate da userid 10 " sarebbe una query piuttosto veloce contro un database MySQL. Ma cose come " tutte le pagine avviate da un utente il cui userid è 10 e corrisponde a [qualche query di ricerca] " farebbe schifo contro il database, quindi è adatto per un motore di ricerca come Lucene.

Fondamentalmente mi chiedo come altri grandi siti facciano questo genere di cose. Utilizzano un motore di ricerca al 100% per tutti i tipi di filtraggio? Mescolano le query del database con un motore di ricerca?

Se utilizziamo solo un motore di ricerca, c'è un problema con il tempo di ritardo necessario affinché un oggetto nuovo / aggiornato venga visualizzato nell'indice di ricerca. Cioè, ho letto che non è intelligente aggiornare l'indice immediatamente e invece farlo in batch. Anche se ciò significa ogni 5 minuti, gli utenti si confonderanno quando la loro pagina aggiunta di recente non viene immediatamente elencata quando visualizzano un semplice elenco di pagine (ad esempio una query di ricerca di " categoria: 5 ").

Stiamo usando MySQL e stiamo osservando attentamente Lucene per la ricerca. C'è qualche altra tecnologia che non conosco?

Il mio pensiero è quello di offrire una semplice pagina di filtro che utilizza MySQL per filtrare i campi di base. Quindi offri una pagina di ricerca full-text separata che presenti risultati simili a Google. È questo l'unico modo?

Answer 1

Solr o grassyknoll forniscono entrambi interfacce leggermente più astratte a Lucene.

Detto questo: Sì. Se sei principalmente un sito orientato al contenuto, che fornisce ricerche full-text sui tuoi dati, c'è qualcosa in gioco oltre LIKE. Sebbene le indicizzazioni FULLTEXT di MySql non siano perfette, nel frattempo potrebbe essere un segnaposto accettabile.

Supponendo che tu crei un indice Lucene, collegare Lucene Documents ai tuoi oggetti relazionali è piuttosto semplice, aggiungi semplicemente una proprietà memorizzata al documento al momento dell'indice (questa proprietà può essere un url, ID, GUID ecc.) Quindi, cercando diventa un sistema a 2 fasi: 1) Invia query alle indici Lucene (Visualizza risultati semplici come il titolo) 2) Ottieni informazioni più dettagliate sull'oggetto dai tuoi negozi relazionali con la sua chiave

Poiché l'istanza di Documents è relativamente costosa in Lucene, si desidera solo memorizzare i campi cercati nell'indice Lucene, al contrario di cloni completi dei propri oggetti relazionali.

Answer 2

Non cancellare MySQL così facilmente!

Implementalo utilizzando il database ad es. una selezione con un "mi piace" nella clausola where o altro.

Profilalo, aggiungi indici se necessario. Distribuisci una beta, in modo da ottenere numeri reali dai modelli di dati effettivi dell'utente: non tutte le colonne potrebbero essere ugualmente chieste dopo, ecc.

Se la performance fa schifo, allora è quando consideri altre opzioni. Puoi considerare di ottimizzare il tuo SQL, il tuo database, la macchina su cui è in esecuzione il database e infine utilizzare un altro stack tecnologico ...

Answer 3

Nel caso in cui desideri utilizzare MySQL o PostgreSQL, una soluzione open source che funziona alla grande con essa è Sphinx: http://www.sphinxsearch.com/

Stiamo riscontrando lo stesso problema e considerando Sphinx e Lucene come possibili soluzioni.