Creo que mantener registros primarios en una base de datos SQL y duplicarlos en una base de datos noSQL es un enfoque muy común.
ElasticSearch tiene una página de estado continua sobre su resiliencia . Incluso en la versión más reciente, ElasticSearch puede perder datos en varias situaciones . Un cambio importante en la estructura de un índice de ElasticSearch (como agregar analizadores) requiere que reindexar todos los documentos. Este proceso es más seguro si tiene otra fuente para los documentos. Al fin y al cabo, ElasticSearch no está diseñado para almacenar documentos de manera consistente; yo solo elegiría usar ElasticSearch como almacenamiento principal en situaciones en las que la pérdida ocasional de datos no sea un desastre.
A diferencia de ElasticSearch, MongoDB está diseñado para ser resistente . Debería poder almacenar documentos de forma segura en MongoDB. Descubrí que tratar de realizar búsquedas de texto completo en MongoDB puede ser un poco doloroso, al menos en comparación con ElasticSearch. En mi opinión, para la búsqueda de texto, la única ventaja que tiene MongoDB sobre MySQL TEXTO COMPLETO es que se distribuye.
Estamos ejecutando ElasticSearch y MySQL en este momento, y los beneficios superan con creces las molestias de la infraestructura adicional y el manejo de la replicación entre los dos. Anteriormente habíamos intentado usar una solución noSQL como almacén de datos principal, con resultados desastrosos. Ejecutar un ES junto con un MySQL le brinda lo mejor de ambos mundos:consistencia y seguridad de los datos en SQL, con la búsqueda de texto completo escalable y efectiva en ES.
