Ich glaube, dass das Aufbewahren primärer Datensätze in einer SQL-Datenbank und das Duplizieren in eine NoSQL-Datenbank ein sehr verbreiteter Ansatz ist.
ElasticSearch hat eine fortlaufende Statusseite über ihre Resilienz . Auch in der neusten Version kann ElasticSearch Daten in verschiedenen Arten verlieren Situationen . Eine größere Änderung in der Struktur eines ElasticSearch-Index (z. B. das Hinzufügen von Analysetools) erfordert, dass Sie neu indexieren alle Dokumente. Dieser Vorgang ist sicherer, wenn Sie eine andere Quelle für die Dokumente haben. Letztendlich ist ElasticSearch nicht darauf ausgelegt, Dokumente konsistent zu speichern – ich würde ElasticSearch immer nur in Situationen als primären Speicher verwenden, in denen gelegentlicher Datenverlust keine Katastrophe darstellt.
Im Gegensatz zu ElasticSearch ist MongoDB widerstandsfähig . Sie sollten in der Lage sein, Dokumente sicher in MongoDB zu speichern. Ich habe festgestellt, dass der Versuch, Volltextsuchen in MongoDB durchzuführen, ein wenig schmerzhaft sein kann, zumindest im Vergleich zu ElasticSearch. Meiner Meinung nach hat MongoDB für die Textsuche den einzigen Vorteil gegenüber VOLLTEXT ist, dass es verteilt wird.
Wir führen derzeit ElasticSearch und MySQL aus – und die Vorteile überwiegen bei weitem den Aufwand für zusätzliche Infrastruktur und den Umgang mit der Replikation zwischen den beiden. Wir hatten zuvor versucht, eine noSQL-Lösung als primären Datenspeicher zu verwenden, mit katastrophalen Ergebnissen. Wenn Sie ein ES in Verbindung mit einem MySQL ausführen, erhalten Sie das Beste aus beiden Welten – Konsistenz und Sicherheit von Daten in SQL mit der skalierbaren, effektiven Volltextsuche in ES.
