Вярвам, че поддържането на първични записи в SQL база данни и дублирането им в noSQL база данни е много често срещан подход.
ElasticSearch има текуща страница за състоянието за тяхната устойчивост . Дори в най-новата версия ElasticSearch може да загуби данни в различни ситуации . Голяма промяна в структурата на индекс на ElasticSearch (като добавяне на анализатори) изисква от преиндексиране всички документи. Този процес е по-безопасен, ако имате друг източник за документите. В края на краищата, ElasticSearch не е проектиран да съхранява последователно документи – бих избрал да използвам ElasticSearch като основно хранилище само в ситуации, при които случайната загуба на данни не е бедствие.
За разлика от ElasticSearch, MongoDB е проектиран да бъде устойчив . Трябва да можете безопасно да съхранявате документи в MongoDB. Открих, че опитите за търсене в пълен текст в MongoDB могат да бъдат малко болезнени, поне в сравнение с ElasticSearch. Според мен за текстово търсене единственото предимство на MongoDB пред ПЪЛЕН ТЕКСТ е, че се разпространява.
В момента изпълняваме ElasticSearch и MySQL - и ползите значително надвишават проблемите с допълнителната инфраструктура и справянето с репликацията между двете. Преди това се опитахме да използваме noSQL решение като основно хранилище на данни с катастрофални резултати. Изпълнението на ES във връзка с MySQL ви дава най-доброто от двата свята - последователност и безопасност на данните в SQL, с мащабируемото, ефективно пълно текстово търсене в ES.
