NoSQL (MongoDB) vs Lucene (o Solr) come database

Con il movimento NoSQL in crescita basato su database basati su documenti, ultimamente ho esaminato MongoDB. Ho notato una sorprendente somiglianza con il modo di trattare gli oggetti come "Documenti", proprio come fa Lucene (e gli utenti di Solr).

Quindi, la domanda: perché dovresti usare NoSQL (MongoDB, Cassandra, CouchDB, ecc.) Su Lucene (o Solr) come "database"?

Quello che sto cercando (e sono sicuro che altri) stiano cercando in una risposta sono alcuni confronti profondi di essi. Saltiamo insieme le discussioni sul database relazionale, poiché hanno uno scopo diverso.

Lucene offre alcuni seri vantaggi, come potenti sistemi di ricerca e pesi. Per non parlare delle sfaccettature di Solr (che Solr verrà presto integrato in Lucene, yay!). Puoi usare i documenti Lucene per archiviare gli ID e accedere ai documenti come tali proprio come MongoDB. Mischiatelo con Solr e otterrete ora una soluzione bilanciata per il carico basata su WebService.

È anche possibile confrontare un provider di cache out-of-proc come Velocity o MemCached quando si parla di archiviazione di dati simili e scalabilità di MongoDB.

Le restrizioni su MongoDB mi ricordano l'utilizzo di MemCached, ma posso usare Microsoft Velocity e avere più potere di raggruppamento e raccolta delle liste su MongoDB (credo). Impossibile ottenere più veloce o scalabile della memorizzazione nella cache dei dati. Anche Lucene ha un fornitore di memoria.

MongoDB (e altri) presentano alcuni vantaggi, come la facilità d'uso della loro API. Nuova un documento, creare un ID e archiviarlo. Fatto. Bello e facile.

Questa è un'ottima domanda, qualcosa su cui ho riflettuto un bel po '. Riassumo le mie lezioni apprese:

1. Puoi facilmente usare Lucene / Solr al posto di MongoDB per praticamente tutte le situazioni, ma non viceversa. Il post di Grant Ingersoll lo riassume qui.

2. MongoDB ecc. Sembrano servire a uno scopo in cui non vi è alcun obbligo di ricerca e / o sfaccettatura. Sembra essere una transizione più semplice e probabilmente più facile per i programmatori che si disintossicano dal mondo RDBMS. A meno che non ci si abitui, Lucene & Solr hanno una curva di apprendimento più ripida.

3. Non ci sono molti esempi di utilizzo di Lucene / Solr come archivio dati, ma Guardian ha fatto qualche passo avanti e lo ha riassunto in un eccellente mazzo di diapositive , ma anche loro non sono impegnativi nel saltare totalmente sul carro Solr e "investigare" combinando Solr con CouchDB.

4. Infine, offrirò la nostra esperienza, sfortunatamente non posso rivelare molto sul caso aziendale. Lavoriamo sulla scala di diversi TB di dati, un'applicazione quasi in tempo reale. Dopo aver studiato varie combinazioni, ho deciso di restare con Solr. Fino ad ora nessun rimpianto (6 mesi e oltre) e non vedo alcun motivo per passare a qualcun altro.

Riepilogo: se non si dispone di un requisito di ricerca, Mongo offre un approccio semplice e potente. Tuttavia, se la ricerca è la chiave della tua offerta, probabilmente stai meglio attenendoti a una tecnologia (Solr / Lucene) e ottimizzandone il controllo - meno parti in movimento.

I miei 2 centesimi, spero che mi abbiano aiutato.

Non è possibile aggiornare parzialmente un documento in solr. Devi aggiornare nuovamente tutti i campi per aggiornare un documento.

E le prestazioni contano. Se non si esegue il commit, la modifica a solr non ha effetto, se si esegue il commit ogni volta, le prestazioni ne risentono.

Non esiste alcuna transazione in solr.

Poiché solr presenta questi svantaggi, a volte nosql è una scelta migliore.

Usiamo MongoDB e Solr insieme e si comportano bene. Puoi trovare il mio post sul blog qui dove ho descritto come utilizziamo queste tecnologie insieme. Ecco un estratto:

[...] Tuttavia osserviamo che le prestazioni della query di Solr diminuiscono all'aumentare della dimensione dell'indice. Ci siamo resi conto che la soluzione migliore è usare insieme sia Solr che Mongo DB. Quindi, integriamo Solr con MongoDB memorizzando i contenuti in MongoDB e creando un indice utilizzando Solr per la ricerca full-text. Archiviamo l'ID univoco per ciascun documento nell'indice Solr e recuperiamo il contenuto effettivo da MongoDB dopo aver cercato Solr. Ottenere documenti da MongoDB è più veloce di Solr perché non ci sono analizzatori, punteggi ecc. [...]

Si noti inoltre che alcune persone hanno integrato Solr / Lucene in Mongo facendo archiviare tutti gli indici in Solr e monitorando anche le operazioni di oplog e collegando a cascata gli aggiornamenti rilevanti in Solr.

Con questo approccio ibrido puoi davvero avere il meglio di entrambi i mondi con funzionalità come la ricerca di testo completo e letture veloci con un archivio dati affidabile che può anche avere una velocità di scrittura sorprendente.

È un po 'tecnico da configurare, ma ci sono molti oplog tailer che possono essere integrati in solr. Scopri cosa ha fatto il rangeespan in questo articolo.

http://denormalised.com/home/mongodb-pub-sub-using-the-replication-oplog.html

Dalla mia esperienza con entrambi, Mongo è ottimo per un utilizzo semplice e diretto. Il principale svantaggio di Mongo che abbiamo subito è la scarsa prestazione su query impreviste (non è possibile creare indici mongo per tutte le possibili combinazioni filtro / ordinamento, semplicemente non è possibile).

E qui dove Lucene / Solr prevale alla grande, in particolare con la cache FilterQuery, le prestazioni sono eccezionali.

Dal momento che nessun altro l'ha menzionato, vorrei aggiungere che MongoDB è privo di schemi, mentre Solr applica uno schema. Quindi, se è probabile che i campi dei tuoi documenti cambino, questo è uno dei motivi per scegliere MongoDB su Solr.

@ mauricio-scheffer ha menzionato Solr 4 - per coloro che sono interessati a ciò, LucidWorks sta descrivendo Solr 4 come "il server di ricerca NoSQL" e c'è un video su http://www.lucidworks.com/webinar-solr-4-the-nosql -search-server / dove entrano nei dettagli sulle funzionalità NoSQL (ish). (-Ish è per la loro versione di schemaless che in realtà è uno schema dinamico.)

Se si desidera solo archiviare i dati utilizzando il formato valore-chiave, Lucene non è raccomandato perché il suo indice invertito sprecherà troppo spazio su disco. E con il salvataggio dei dati su disco, le sue prestazioni sono molto più lente rispetto ai database NoSQL come redis perché i redis salvano i dati nella RAM. Il vantaggio maggiore per Lucene è che supporta molte query, quindi è possibile supportare query fuzzy.

Le soluzioni di terze parti, come una coda op-log di mongo, sono attraenti. Rimangono alcuni pensieri o domande sul fatto che le soluzioni possano essere strettamente integrate, assumendo una prospettiva di sviluppo / architettura. Non mi aspetto di vedere una soluzione strettamente integrata per queste funzionalità per alcuni motivi (in qualche modo speculativo e soggetto a chiarimenti e non aggiornato con gli sforzi di sviluppo):

• mongo è c ++, lucene / solr sono java
  • forse lucene potrebbe usare alcune librerie mongo
  • forse mongo potrebbe riscrivere alcuni algoritmi lucene, vedi anche:
    • http://clucene.sourceforge.net/
    • http://lucy.apache.org/
• lucene supporta vari formati di documenti
  • mongo è focalizzato su JSON (BSON)
• lucene usa documenti immutabili
  • gli aggiornamenti a campo singolo sono un problema, se disponibili
• gli indici lucene sono immutabili con operazioni di unione complesse
• le query mongo sono javascript
• mongo non ha analizzatori / tokenizzatori di testo (AFAIK)
• le dimensioni di mongo doc sono limitate, il che potrebbe andare controcorrente per lucene
• Le operazioni di aggregazione di mongo potrebbero non avere posto in lucene
  • lucene ha opzioni per archiviare i campi tra i documenti, ma non è la stessa cosa
  • solr fornisce in qualche modo aggregazioni / statistiche e query SQL / graph

MongoDB Atlas avrà presto un motore di ricerca basato su lucene. Il grande annuncio è stato fatto alla conferenza MongoDB World 2019 di questa settimana. Questo è un ottimo modo per incoraggiare un maggiore utilizzo del loro prodotto MongoDB Atlas ad alto reddito.

Speravo di vederlo implementato nella versione 4.2 di MongoDB Enterprise, ma non ci sono state notizie di portarlo sulla loro linea di prodotti on-prem.

Maggiori informazioni qui: https://www.mongodb.com/atlas/full-text-search