Acredito que manter registros primários em um banco de dados SQL e duplicá-los em um banco de dados noSQL é uma abordagem muito comum.

O ElasticSearch tem uma página de status contínua sobre sua resiliência . Mesmo na versão mais recente, o ElasticSearch pode perder dados em vários situações . Uma grande mudança na estrutura de um índice ElasticSearch (como adicionar analisadores) requer que você reindexar todos os documentos. Esse processo é mais seguro se você tiver outra fonte para os documentos. No final das contas, o ElasticSearch não foi projetado para armazenar documentos de forma consistente - eu só escolheria usar o ElasticSearch como o armazenamento principal em situações em que a perda ocasional de dados não é um desastre.

Ao contrário do ElasticSearch, o MongoDB foi projetado para ser resiliente . Você deve ser capaz de armazenar documentos com segurança no MongoDB. Descobri que tentar fazer pesquisas de texto completo no MongoDB pode ser um pouco doloroso, pelo menos em comparação com o ElasticSearch. Na minha opinião, para pesquisa de texto, a única vantagem que o MongoDB tem sobre o TEXTO COMPLETO é que ele é distribuído.

Estamos executando o ElasticSearch e o MySQL agora - e os benefícios superam em muito as dificuldades de infraestrutura extra e lidar com a replicação entre os dois. Anteriormente, havíamos tentado usar uma solução noSQL como o armazenamento de dados primário, com resultados desastrosos. A execução de um ES em conjunto com um MySQL oferece a você o melhor dos dois mundos - consistência e segurança de dados em SQL, com a pesquisa de texto completo escalável e eficaz no ES.