it-swarm.com.de

Wie zuverlässig ist ElasticSearch als primärer Datenspeicher gegen Faktoren wie Schreibverlust und Datenverfügbarkeit?

Ich arbeite an einem Projekt mit der Anforderung, ein allgemeines Dashboard zu entwickeln, in dem ein Benutzer verschiedene Arten von Gruppierungen, Filtern und Drilldowns für verschiedene Felder durchführen kann. Hierfür suchen wir einen Suchspeicher, der das Slice and Dice von Daten ermöglicht.

Es würde mehrere Datenquellen geben und diese im Suchspeicher speichern. Möglicherweise ist eine Vorberechnung der Quelldaten erforderlich, die von einer Zwischenkomponente durchgeführt werden kann.

Ich habe mehrere Blogs durchgesehen, um zu verstehen, ob ES auch als primärer Datenspeicher zuverlässig verwendet werden kann. Es hängt hauptsächlich von dem Anwendungsfall ab, den wir suchen. Einige der Informationen zum vorliegenden Anwendungsfall:

  • Rund 300 Millionen Rekorde pro Jahr mit 1-2 KB.
  • Unter der Annahme, dass Daten für ein Jahr gespeichert werden, verfügen wir heute über 300 GB, aber der Anwendungsfall kann bei einem Datenwachstum auf 400 bis 500 GB ansteigen.
  • Derzeit sind wir uns nicht sicher, wie wir Daten pushen sollen, aber ungefähr können es bis zu 2-3 Millionen Datensätze pro 5 Minuten sein.
  • Die Suchanfragen sind gering, erfordern jedoch komplexe Abfragen, mit denen Daten für die letzten 6 Wochen bis 6 Monate durchsucht werden können.
  • das Dokument wird in fast allen Feldern des Dokuments indiziert.

Einige Blogs sagen, dass es zuverlässig genug ist, um als primärer Datenspeicher verwendet zu werden -

Und einige Blogs sagen, dass ES nur wenige Einschränkungen hat -

Hat jemand Elastic Search als einzige Wahrheit für Daten verwendet, ohne über einen Primärspeicher wie PostgreSQL, DynamoDB oder RDS zu verfügen? Ich habe nachgesehen, dass ES bestimmte Probleme wie Split Brains und Indexkorruption hat, bei denen ein Problem mit dem Datenverlust auftreten kann. Ich möchte wissen, ob jemand ES verwendet hat und Probleme mit den Daten hat

Vielen Dank.

61
Harshit Agrawal

Kurze Antwort: Es hängt von Ihrem Anwendungsfall ab, aber Sie möchten ihn wahrscheinlich nicht als primären Speicher verwenden.

Längere Antwort: Sie sollten wirklich alle möglichen Probleme verstehen, die im Zusammenhang mit Ausfallsicherheit und Datenverlust auftreten können. Elastic hat einige gute Dokumentation dieser Probleme , die Sie wirklich verstehen sollten, bevor Sie es als primären Datenspeicher verwenden. Außerdem ist Aphyrs Beitrag zum Thema eine gute Ressource.

Wenn Sie die Risiken verstehen, die Sie eingehen, und wenn Sie der Meinung sind, dass diese Risiken akzeptabel sind (z. B. weil ein geringer Datenverlust für Ihre Anwendung kein Problem darstellt), können Sie dies ausprobieren.

32
Cory

Generell ist es eine gute Idee, redundante Datenspeicherlösungen zu entwerfen. Zum Beispiel könnte es ein schneller und zuverlässiger Ansatz sein, zuerst alles als flache Daten in einen statischen Speicher wie s3 zu verschieben und dann ES-Pull- und -Index-Daten von dort zu erhalten. Wenn Sie mehr Flexibilität bei der Nutzung von ORM benötigen, können Sie eine RDS- oder Redshift-Ebene dazwischen haben. Auf diese Weise können die Daten jederzeit in ES wiederhergestellt werden.

Es hängt von Ihren Bedürfnissen und Anforderungen ab, wie Sie das Gleichgewicht zwischen Redundanz und Flexibilität/Leistung einstellen. Wenn viele Daten betroffen sind, können Sie die Rohdaten statisch speichern und nur einige Teile davon mit ES indizieren.

Amazon Lambda bietet tolle Funktionen:

Viele Entwickler speichern Objekte in Amazon S3, während sie Amazon DynamoDB zum Speichern und Indizieren der Objektmetadaten und zum Aktivieren der Hochgeschwindigkeitssuche verwenden. Mit AWS Lambda ist es einfach, alles synchron zu halten, indem eine Funktion ausgeführt wird, mit der der Index in Amazon DynamoDB jedes Mal automatisch aktualisiert wird, wenn Objekte von Amazon S3 hinzugefügt oder aktualisiert werden.

7
marekful