Uważam, że przechowywanie podstawowych rekordów w bazie danych SQL i powielanie ich do bazy danych noSQL jest bardzo powszechnym podejściem.
ElasticSearch ma bieżącą stronę statusu dotyczącą ich odporności . Nawet w najnowszej wersji ElasticSearch może utracić dane w wielu różnych sytuacje . Poważna zmiana w strukturze indeksu ElasticSearch (np. dodanie analizatorów) wymaga ponownie indeksuj wszystkie dokumenty. Ten proces jest bezpieczniejszy, jeśli masz inne źródło dokumentów. Podsumowując, ElasticSearch nie jest przeznaczony do spójnego przechowywania dokumentów — wybrałbym ElasticSearch jako podstawowy magazyn tylko w sytuacjach, w których okazjonalna utrata danych nie jest katastrofą.
W przeciwieństwie do ElasticSearch, MongoDB ma być odporny . Powinieneś być w stanie bezpiecznie przechowywać dokumenty w MongoDB. Odkryłem, że próby wyszukiwania pełnotekstowego w MongoDB mogą być trochę bolesne, przynajmniej w porównaniu z ElasticSearch. Moim zdaniem, jeśli chodzi o wyszukiwanie tekstowe, jedyną przewagą MongoDB nad PEŁNOTEKSTOWY jest to, że jest rozpowszechniany.
W tej chwili korzystamy z ElasticSearch i MySQL — a korzyści znacznie przewyższają kłopoty z dodatkową infrastrukturą i radzenie sobie z replikacją między nimi. Wcześniej próbowaliśmy użyć rozwiązania noSQL jako podstawowego magazynu danych, z katastrofalnymi skutkami. Uruchamianie ES w połączeniu z MySQL zapewnia to, co najlepsze z obu światów — spójność i bezpieczeństwo danych w SQL oraz skalowalne, efektywne wyszukiwanie pełnotekstowe w ES.
