elasticsearch vs MongoDB per l'applicazione di filtraggio [chiuso]

Questa domanda riguarda il fare una scelta architettonica prima di approfondire i dettagli di sperimentazione e implementazione. Riguarda l'idoneità, in termini di scalabilità e prestazioni, di elasticsearch vs MongoDB, per uno scopo in qualche modo specifico.

Ipoteticamente entrambi archiviano oggetti dati con campi e valori e consentono di eseguire query su quel corpo di oggetti. Quindi presumibilmente filtrare sottoinsiemi di oggetti in base ai campi selezionati ad-hoc, è qualcosa che si adatta a entrambi.

La mia applicazione ruoterà attorno alla selezione di oggetti in base a criteri. Selezionerebbe gli oggetti filtrando simultaneamente per più di un singolo campo, in modo diverso, i suoi criteri di filtraggio delle query comprenderanno tipicamente tra 1 e 5 campi, forse più in alcuni casi. Considerando che i campi scelti come filtri sarebbero un sottoinsieme di una quantità molto maggiore di campi. Immagina circa 20 nomi di campi esistenti e ogni query è un tentativo di filtrare gli oggetti in base a pochi campi su quei 20 campi complessivi (può essere inferiore o superiore a 20 nomi di campi complessivi esistenti, ho appena usato questo numero per dimostrare il rapporto di campi ai campi utilizzati come filtri in ogni query discreta). Il filtro può essere basato sull'esistenza dei campi scelti, nonché sui valori dei campi, ad esempio filtrando gli oggetti che hanno il campo A e il loro campo B è compreso tra xe y,

La mia applicazione eseguirà continuamente questo tipo di filtraggio, mentre non ci sarebbe nulla o pochissima costante in termini di quali campi vengono utilizzati per il filtraggio in qualsiasi momento. Forse negli indici elasticsearch devono essere definiti, ma forse anche senza indici la velocità è alla pari con quella di MongoDB.

Per quanto riguarda i dati che entrano nel negozio, non ci sono dettagli speciali a riguardo .. Gli oggetti non sarebbero quasi mai cambiati dopo essere stati inseriti. Forse i vecchi oggetti dovrebbero essere eliminati, mi piacerebbe supporre che entrambi gli archivi di dati supportino la scadenza eliminando le cose internamente o da una domanda fatta dall'applicazione. (Meno frequentemente, anche gli oggetti che soddisfano una determinata query dovrebbero essere eliminati).

Cosa ne pensi? E hai sperimentato questo aspetto?

Sono interessato alle prestazioni e alla scalabilità di esso, di ciascuno dei due archivi di dati, per questo tipo di attività. Questo è il tipo di domanda di progettazione architettonica, e i dettagli delle opzioni specifiche del negozio o dei punti cardine della query che dovrebbero renderlo ben progettato sono i benvenuti come dimostrazione di un suggerimento ben ponderato.

Grazie!

Prima di tutto, c'è un'importante distinzione da fare qui: MongoDB è un database di uso generale, Elasticsearch è un motore di ricerca di testo distribuito supportato da Lucene. Le persone hanno parlato dell'utilizzo di Elasticsearch come database per scopi generici, ma sanno che non era il suo "design originale". Penso che i database NoSQL e i motori di ricerca per uso generale siano diretti al consolidamento, ma allo stato attuale, i due provengono da due campi molto diversi.

Stiamo usando MongoDB e Elasticsearch nella mia azienda. Archiviamo i nostri dati in MongoDB e utilizziamo Elasticsearch esclusivamente per le sue capacità di ricerca full-text. Inviamo solo un sottoinsieme dei campi di dati mongo che dobbiamo interrogare su elastic. Il nostro caso d'uso differisce dal tuo in quanto i nostri dati Mongo cambiano continuamente: un record, o un sottoinsieme dei campi di un record, può essere aggiornato più volte al giorno e ciò può richiedere la reindicizzazione di quel record in elastico. Solo per questo motivo, l'utilizzo di elastic come unico archivio dati non è una buona opzione per noi, in quanto non è possibile aggiornare i campi selezionati; avremmo bisogno di reindicizzare un documento nella sua "interezza. Questo non è un limite elastico, ecco come funziona Lucene, il motore di ricerca sottostante elastico. Nel tuo caso, il fatto che i record abbiano vinto ' essere cambiato una volta memorizzato ti evita di dover fare quella scelta. Detto questo, se la sicurezza dei dati è una preoccupazione, ci penserei due volte sull'utilizzo di Elasticsearch come unico meccanismo di archiviazione per i tuoi dati. Potrebbe arrivare lì ad un certo punto ma non sono sicuro che sia ancora lì.

In termini di velocità, non solo Elastic / Lucene è alla pari della velocità di interrogazione di Mongo, nel tuo caso in cui esiste "una costante molto piccola in termini di quali campi vengono utilizzati per il filtraggio in qualsiasi momento", potrebbe essere un ordine di magnitudo più veloce, specialmente quando i set di dati diventano più grandi. La differenza sta nelle implementazioni di query sottostanti:

• Elastic / Lucene utilizza il Vector Space Model e gli indici invertiti per il recupero delle informazioni , che sono modi altamente efficienti di confrontare la somiglianza dei record con una query. Quando richiedi Elastic / Lucene, conosce già la risposta; la maggior parte del suo lavoro consiste nel classificare i risultati per quelli più probabili in modo che corrispondano ai termini della query. Questo è un punto importante: i motori di ricerca, al contrario dei database, non possono garantire risultati esatti; classificano i risultati in base alla vicinanza alla query. Accade solo che il più delle volte i risultati siano quasi esatti.
• L'approccio di Mongo è quello di un archivio dati più generico; confronta i documenti JSON tra loro. Puoi ottenere prestazioni eccezionali da esso in ogni modo, ma devi creare con cura i tuoi indici in modo che corrispondano alle query che eseguirai. In particolare, se si dispone di più campi in base ai quali verrà eseguita la query, è necessario creare con cura le chiavi compostein modo da ridurre il set di dati che verrà interrogato il più rapidamente possibile. Ad esempio, la tua prima chiave dovrebbe filtrare la maggior parte del tuo set di dati, la seconda dovrebbe filtrare ulteriormente ciò che rimane, e così via e così via. Se le tue query non corrispondono alle chiavi e all'ordine di quelle chiavi negli indici definiti, le tue prestazioni diminuiranno un po '. D'altra parte, Mongo è un vero database, quindi se l'accuratezza è ciò di cui hai bisogno, le risposte che darà saranno esatte.

Per i vecchi record in scadenza, Elastic ha una funzione TTL integrata. Mongo l'ha appena introdotto a partire dalla versione 2.2, credo.

Dal momento che non conosco i tuoi altri requisiti come la dimensione dei dati prevista, le transazioni, l'accuratezza o l'aspetto dei tuoi filtri, è difficile formulare raccomandazioni specifiche. Spero che ci sia abbastanza qui per iniziare.