Credo che mantenere i record primari in un database SQL e duplicarli in un database noSQL sia un approccio molto comune.
ElasticSearch ha una pagina di stato in corso sulla loro resilienza . Anche nella versione più recente, ElasticSearch può perdere dati in un certo numero di situazioni . Un cambiamento importante nella struttura di un indice ElasticSearch (come l'aggiunta di analizzatori) richiede che tu reindicizza tutti i documenti. Questo processo è più sicuro se hai un'altra fonte per i documenti. Alla fine della giornata, ElasticSearch non è progettato per archiviare i documenti in modo coerente:sceglierei sempre di utilizzare ElasticSearch come archivio principale solo in situazioni in cui la perdita occasionale di dati non è un disastro.
A differenza di ElasticSearch, MongoDB è progettato per essere resiliente . Dovresti essere in grado di archiviare in modo sicuro i documenti in MongoDB. Ho scoperto che provare a eseguire ricerche di testo completo in MongoDB può essere un po' doloroso, almeno rispetto a ElasticSearch. A mio parere, per la ricerca di testo, l'unico vantaggio che MongoDB ha rispetto a TESTO COMPLETO è che è distribuito.
Stiamo eseguendo ElasticSearch e MySQL in questo momento e i vantaggi superano di gran lunga i problemi dell'infrastruttura aggiuntiva e la gestione della replica tra i due. In precedenza avevamo tentato di utilizzare una soluzione noSQL come datastore principale, con risultati disastrosi. L'esecuzione di un ES in combinazione con un MySQL ti offre il meglio di entrambi i mondi:coerenza e sicurezza dei dati in SQL, con la ricerca full-text scalabile ed efficace in ES.
