Jag tror att att hålla primära poster i en SQL-databas och duplicera dem till en noSQL-databas är ett mycket vanligt tillvägagångssätt.
ElasticSearch har en pågående statussida om deras resiliency . Även i den senaste versionen kan ElasticSearch tappa data i ett antal olika situationer . En stor förändring i strukturen för ett ElasticSearch-index (som att lägga till analysatorer) kräver att du indexera om alla dokument. Denna process är säkrare om du har en annan källa för dokumenten. I slutändan är ElasticSearch inte utformat för att konsekvent lagra dokument - jag skulle bara någonsin välja att använda ElasticSearch som den primära butiken i situationer där tillfällig dataförlust inte är en katastrof.
Till skillnad från ElasticSearch är MongoDB utformad för att vara fjädrande . Du bör säkert kunna lagra dokument i MongoDB. Jag har upptäckt att det kan vara lite smärtsamt att försöka göra fulltextsökningar i MongoDB, åtminstone jämfört med ElasticSearch. Enligt min åsikt, för textsökning, är den enda fördelen MongoDB har jämfört med MySQL:s FULLTEXT är att den delas ut.
Vi kör ElasticSearch och MySQL just nu - och fördelarna uppväger avsevärt besvären med extra infrastruktur och att hantera replikering mellan de två. Vi hade tidigare försökt använda en noSQL-lösning som primär datalagring, med katastrofala resultat. Att köra en ES i kombination med en MySQL ger dig det bästa av två världar - konsistens och säkerhet för data i SQL, med den skalbara, effektiva fulltextsökningen i ES.