Ik ben van mening dat het bewaren van primaire records in een SQL-database en het dupliceren ervan naar een noSQL-database een veel voorkomende benadering is.
ElasticSearch heeft een doorlopende statuspagina over hun veerkracht . Zelfs in de nieuwste versie kan ElasticSearch gegevens verliezen in een aantal verschillende situaties . Een grote verandering in de structuur van een ElasticSearch-index (zoals het toevoegen van analysers) vereist dat u opnieuw indexeren alle documenten. Dit proces is veiliger als u een andere bron voor de documenten heeft. Uiteindelijk is ElasticSearch niet ontworpen om documenten consistent op te slaan - ik zou ElasticSearch alleen als primaire opslag gebruiken in situaties waar incidenteel gegevensverlies geen ramp is.
In tegenstelling tot ElasticSearch is MongoDB ontworpen om veerkrachtig te zijn . U zou documenten veilig in MongoDB moeten kunnen opslaan. Ik heb gemerkt dat het zoeken in volledige tekst in MongoDB een beetje pijnlijk kan zijn, tenminste in vergelijking met ElasticSearch. Naar mijn mening is voor het zoeken naar tekst het enige voordeel dat MongoDB heeft ten opzichte van MySQL's VOLLEDIGE TEKST is dat het wordt uitgedeeld.
We gebruiken nu ElasticSearch en MySQL - en de voordelen wegen ruimschoots op tegen het gedoe van extra infrastructuur en het omgaan met replicatie tussen beide. We hadden eerder geprobeerd een noSQL-oplossing als primaire datastore te gebruiken, met rampzalige resultaten. Door een ES in combinatie met een MySQL uit te voeren, krijgt u het beste van twee werelden:consistentie en veiligheid van gegevens in SQL, met de schaalbare, effectieve full-text search in ES.