Prima di tutto, c'è un'importante distinzione da fare qui:MongoDB è un database generico, Elasticsearch è un motore di ricerca di testo distribuito supportato da Lucene. Le persone hanno parlato dell'utilizzo di Elasticsearch come database generico, ma sanno che non era il suo design originale. Penso che i database e i motori di ricerca NoSQL generici siano diretti al consolidamento, ma allo stato attuale i due provengono da due campi molto diversi.
Nella mia azienda utilizziamo sia MongoDB che Elasticsearch. 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 questo può richiedere la reindicizzazione di quel record in modo elastico. Solo per questo motivo, l'utilizzo di elastic come unico archivio dati non è una buona opzione per noi, poiché non possiamo aggiornare i campi selezionati; avremmo bisogno di reindicizzare un documento nella sua interezza. Questa non è una limitazione elastica, è così che funziona Lucene, il motore di ricerca alla base di elastic. Nel tuo caso, il fatto che i record non vengano modificati una volta archiviati ti evita di dover fare quella scelta. Detto questo, se la sicurezza dei dati è un problema, ci penserei due volte sull'utilizzo di Elasticsearch come unico meccanismo di archiviazione per i tuoi dati. Potrebbe arrivare a un certo punto, ma non sono sicuro che sia ancora lì.
In termini di velocità, non solo Elastic/Lucene è alla pari con la velocità di interrogazione di Mongo, nel tuo caso dove c'è "pochissima costante in termini di quali campi vengono utilizzati per il filtraggio in qualsiasi momento", potrebbero essere ordini di magnitudine più veloce, soprattutto quando i set di dati diventano più grandi. La differenza sta nelle implementazioni di query sottostanti:
- Elastic/Lucene utilizza il modello dello spazio vettoriale e gli indici invertiti per il recupero delle informazioni, che sono metodi altamente efficienti per confrontare la somiglianza dei record con una query. Quando esegui una query su Elastic/Luce, conosce già la risposta; la maggior parte del suo lavoro consiste nel classificare i risultati per te in base a quelli che più probabilmente corrispondono ai termini della tua ricerca. Questo è un punto importante:i motori di ricerca, al contrario dei database, non possono garantirti risultati esatti; classificano i risultati in base a quanto si avvicinano alla tua query. Accade solo che la maggior parte delle volte i risultati siano vicini all'esatto.
- L'approccio di Mongo è quello di un datastore più generico; confronta i documenti JSON l'uno con l'altro. Puoi ottenere grandi prestazioni da esso con tutti i mezzi, 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 eseguire query, è necessario creare con cura le chiavi composte in modo che riducano il set di dati che verrà interrogato il più velocemente possibile. Per esempio. la prima chiave dovrebbe filtrare la maggior parte del set di dati, la seconda dovrebbe filtrare ulteriormente ciò che è rimasto e così via. Se le tue query non corrispondono alle chiavi e all'ordine di quelle chiavi negli indici definiti, le tue prestazioni diminuiranno leggermente. D'altra parte, Mongo è un vero database, quindi se la precisione è ciò di cui hai bisogno, le risposte che fornirà saranno esatte.
Per i vecchi record in scadenza, Elastic ha una funzione TTL incorporata. 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 dare consigli specifici. Si spera che qui ci sia abbastanza per iniziare.
