Jeg mener, at det er en meget almindelig tilgang at holde primære poster i en SQL-database og duplikere dem til en noSQL-database.
ElasticSearch har en løbende statusside om deres resiliens . Selv i den nyeste version kan ElasticSearch miste data i en række forskellige situationer . En større ændring i strukturen af et ElasticSearch-indeks (såsom tilføjelse af analysatorer) kræver, at du genindekser alle dokumenter. Denne proces er mere sikker, hvis du har en anden kilde til dokumenterne. I sidste ende er ElasticSearch ikke designet til konsekvent at gemme dokumenter - jeg ville kun vælge at bruge ElasticSearch som den primære butik i situationer, hvor lejlighedsvis tab af data ikke er en katastrofe.
I modsætning til ElasticSearch er MongoDB designet til at være resiliant . Du bør være i stand til sikkert at gemme dokumenter i MongoDB. Jeg har fundet ud af at prøve at lave fuldtekstsøgninger i MongoDB kan være lidt smertefuldt, i det mindste sammenlignet med ElasticSearch. Efter min mening, for tekstsøgning, er den eneste fordel MongoDB har i forhold til MySQL's FULDTEKST er, at det er fordelt.
Vi kører ElasticSearch og MySQL lige nu - og fordelene opvejer i høj grad besværet med ekstra infrastruktur og håndtering af replikering mellem de to. Vi havde tidligere forsøgt at bruge en noSQL-løsning som det primære datalager, med katastrofale resultater. At køre en ES sammen med en MySQL giver dig det bedste fra begge verdener - konsistens og sikkerhed af data i SQL, med den skalerbare, effektive fuldtekstsøgning i ES.