Je pense que conserver des enregistrements primaires dans une base de données SQL et les dupliquer dans une base de données noSQL est une approche très courante.
ElasticSearch a une page d'état en cours sur leur résilience . Même dans la dernière version, ElasticSearch peut perdre des données dans un certain nombre de situations . Un changement majeur dans la structure d'un index ElasticSearch (comme l'ajout d'analyseurs) nécessite que vous ré-indexer tous les documents. Ce processus est plus sûr si vous avez une autre source pour les documents. En fin de compte, ElasticSearch n'est pas conçu pour stocker systématiquement des documents - je ne choisirais jamais d'utiliser ElasticSearch comme magasin principal que dans les situations où la perte occasionnelle de données n'est pas une catastrophe.
Contrairement à ElasticSearch, MongoDB est conçu pour être résilient . Vous devriez pouvoir stocker en toute sécurité des documents dans MongoDB. J'ai trouvé qu'essayer de faire des recherches en texte intégral dans MongoDB peut être un peu pénible, du moins par rapport à ElasticSearch. À mon avis, pour la recherche de texte, le seul avantage de MongoDB par rapport à MySQL TEXTE INTÉGRAL c'est qu'il est distribué.
Nous utilisons actuellement ElasticSearch et MySQL - et les avantages l'emportent largement sur les tracas d'une infrastructure supplémentaire et la gestion de la réplication entre les deux. Nous avions précédemment tenté d'utiliser une solution noSQL comme magasin de données principal, avec des résultats désastreux. L'exécution d'un ES en conjonction avec un MySQL vous offre le meilleur des deux mondes :la cohérence et la sécurité des données dans SQL, avec la recherche en texte intégral évolutive et efficace dans ES.
