2010-03-30 5 views
34

Su un nuovo progetto ho bisogno di un uso intenso di lucene per l'implementazione di un ricercatore. Questo ricercatore sarà un pezzo molto importante (e grande) del progetto. È valido o conveniente sostituire Database relazionale + Lucene con MongoDb?MongoDB è un'alternativa valida al db + lucene relazionale?

modifica: Ok, chiarirò: non sto chiedendo il rischio, posso pagare quel prezzo in questo progetto. Il mio punto è: MongoDB è orientato a questo genere di cose? Posso creare un motore di ricerca completo con la stessa perfomance che posso ottenere su Lucene ?. Un amico mi ha indicato MongoDB come alternativa, ma non vedo se la performance di Lucene viene fornita con l'alternativa del documento (e poi, lo vedrò anche in MongoDB), o, d'altra parte, l'indice invertito e le ottimizzazioni sono complete indipendente dall'orientamento del documento.

+0

I miei 2 centesimi: vorrei adottare un approccio a componenti, in cui è possibile avere in seguito la possibilità di modificare l'origine dati sottostante –

+1

Ok, chiarirò: non sto chiedendo il rischio, posso pagare quel prezzo in questo progetto. Il mio punto è: MongoDB è orientato a questo genere di cose? Posso creare un motore di ricerca completo con la stessa perfomance che posso ottenere su Lucene ?. Un amico mi segnala MongoDB come alternativa, ma non vedo se la performance di Lucene viene fornita con l'alternativa al documento (e poi, lo vedrò anch'io in MongoDB), o, d'altra parte, l'indice invertito e le ottimizzazioni sono completamente indipendente dall'orientamento del documento. – Hugo

risposta

1

Non ho familiarità con MongoDB, quindi non posso rispondere direttamente alla domanda, ma vorrei sottolineare che a differenza di Lucene (che ha circa dieci anni) e dei database relazionali (che esistono da decenni) MongoDB è meno di tre anni.

In questa fase del gioco è probabile che stia ancora maturando. Potrebbe essere adatto alle tue esigenze (e sono curioso di vedere se qualcuno che ha familiarità con l'uso farà il suo ingresso qui), ma dovrai tenerne conto nella tua equazione. Sei disposto a pagare il prezzo per utilizzare la tecnologia all'avanguardia?

Anche se si rivela stabile ed efficiente, è possibile che si verifichino problemi con supporto limitato sotto forma di siti Web/esercitazioni ecc. (A causa della piccola base di utenti). Stai anche prendendo la possibilità che sarà interrotto.

Può valere la pena cogliere questa occasione, ma è necessario farlo con gli occhi aperti e non accecati dall'effetto "oh, guarda l'effetto del nuovo giocattolo".

+0

Sure Kris, ho notato che, in questo caso particolare, posso pagare quel prezzo. Grazie. – Hugo

+0

Se il giocattolo viene interrotto, può sempre spostare i dati su un RDBMS :) –

-7

No, non lo è, dal momento che MongoDB non è relazionale.

0

Lucene è un prodotto consolidato e stabile. Purtroppo lo stesso non è ancora vero per MongoDB. Quindi penserei che Lucene più un RDBMS sia un'opzione molto meno rischiosa.

Naturalmente, in una certa misura dipende dalla natura del progetto: quanto è importante "molto importante (e grande)"? L'altra cosa è, hai una precedente esperienza di MongoDB (non sto indovinando)? Se riesci ad avere accesso a persone che hanno una certa esperienza, ciò potrebbe mitigare il rischio.

2

del possibile Guardare ma più lento (see here)

  • Si dovrà fare suddivisione delle parole e che deriva la vostra auto.
  • Classifica di query 'richiede il codice utente fornito di farlo'
19

Tecnicamente si può fare ricerca a testo integrale con MongoDB, ma vi state perdendo su un terreno che un completo fornitore di ricerca ha da offrire. Adoro MongoDB, ma lo assocerei a un provider di ricerca a testo integrale (come Lucene o Sphinx) se il tempo di implementazione è un problema. Penso che la conveniente capacità di MongoDB di indicizzare gli array di parole sia meglio lasciata alla codifica e alla ricerca basata sul tagging rispetto alla ricerca full-text.

La ricerca (Recupero informazioni) non consiste semplicemente nell'acquisire tutti i documenti corrispondenti, se si desidera che i risultati della ricerca abbiano una qualsiasi rilevanza, sarà necessario qualcosa sulla falsariga di TF-IDF, corrispondenza frase (parole in una sequenza punteggio più alto) o un numero qualsiasi di altre tecniche IR per migliorare la precisione della ricerca. Se usi MongoDB dovrai implementarlo tutto da capo.

Se si vuole veramente implementarlo tutto da zero ma non preoccuparsi del lato di archiviazione raw delle cose, MongoDB è molto vicino al miglior archivio DB su cui si potrebbe implementarlo (non si può pensare a molti altri), ma non è ancora una buona opzione.

2

MongoDb è un NoSQL, Lucene e Solr sono i motori di ricerca, e l'aggiunta di un'altra cosa per il confronto è cache come Terracota con EHCache. Tutti hanno il loro scopo.

Se è richiesta la ricerca con testo completo con impostazioni di pertinenza, come la visualizzazione dei risultati con la corrispondenza del testo nella classifica del titolo del prodotto più della corrispondenza del testo nella descrizione e molte di tali funzionalità basate sul testo. Anche classifica, pertinenza, suono macthing eguale, parziali abbinamenti di parole ecc. Ecc. Tutto questo è gestito al meglio da sistemi di archiviazione basati sulla ricerca come SOLR e Lucene.

Se il criterio è solo per il recupero e non è necessario che gli oggetti dei dati di presentazione siano durevoli, utilizzare semplicemente un cache lke Terracota.

Se è necessario un recupero più rapido e anche bisogno di colloborare e aggregare i dati in un'origine dati e anche bisogno di dati aggregati per essere durevoli, quindi utilizzare NOSQL come Mongodb.

Problemi correlati