Vergleichen In-Memory-Cluster-Computer-Systeme

Question

Ich arbeite an Spark (Berkeley) Cluster Computing System. Bei meiner Recherche erfuhr ich etwas über andere In-Memory-Systeme wie Redis, Memcachedb usw. Es wäre großartig, wenn mir jemand einen Vergleich zwischen SPARK und REDIS (und MEMCACHEDB) geben könnte. In welchen Szenarien hat Spark einen Vorteil gegenüber diesen anderen In-Memory-Systemen?

Answer 1

Sie sind komplett verschiedene Tiere.

Redis und memcachedb sind verteilte Speicher. Redis ist ein reines In-Memory-System mit optionaler Persistenz mit verschiedenen Datenstrukturen. Memcachedb bietet eine Memcached-API zusätzlich zu Berkeley-DB. In beiden Fällen werden sie eher von OLTP-Anwendungen oder letztendlich für einfache Echtzeitanalysen (spontane Aggregation von Daten) verwendet.

Sowohl Redis als auch memcachedb fehlen Mechanismen, um effizient die gespeicherten Daten parallel zu iterieren. Sie können nicht einfach eine Verarbeitung auf die gespeicherten Daten scannen und anwenden. Sie sind nicht dafür ausgelegt. Abgesehen vom manuellen Sharding auf Clientseite können sie auch nicht in einem Cluster skaliert werden (eine Redis-Clusterimplementierung wird jedoch ausgeführt).

Spark ist ein System zur Beschleunigung großer Analyseaufträge (und insbesondere der iterativen) durch die Bereitstellung von verteilten In-Memory-Datensätzen. Mit Spark können Sie effiziente iterative Map/Reduce-Jobs auf einem Cluster von Maschinen implementieren.

Redis und Spark basieren beide auf In-Memory-Datenverwaltung. Aber Redis (und memcached) spielen im gleichen Umfeld wie die anderen OLTP NoSQL-Speicher, während Spark einem Hadoop-Map/Reduce-System sehr ähnlich ist.

Redis ist gut in der Ausführung zahlreicher schneller Speicher/Retrieval-Operationen bei hohem Durchsatz mit Latenzzeiten unter einer Millisekunde. Spark glänzt bei der Implementierung großskaliger iterativer Algorithmen für maschinelles Lernen, Graphenanalyse, interaktives Data Mining usw. auf einer beträchtlichen Datenmenge.

Update: weitere Frage zu Sturm

Die Frage ist Spark Sturm zu vergleichen (siehe Kommentar unten).

Spark basiert immer noch auf der Idee, dass es bei einem großen Datenvolumen günstiger ist, den Prozess in die Daten zu verschieben, als die Daten in den Prozess zu verschieben. Jeder Knoten speichert seine Datasets (oder speichert sie zwischen), und Jobs werden an die Knoten gesendet. So bewegt sich der Prozess zu den Daten. Es ist sehr ähnlich zu Hadoop map/reduce, nur dass Speicher zur Vermeidung von I/Os aggressiv verwendet wird, was es für iterative Algorithmen effizient macht (wenn die Ausgabe des vorherigen Schritts die Eingabe des nächsten Schritts ist). Shark ist nur eine Abfrage-Engine, die auf Spark basiert (unterstützt analytische Ad-hoc-Abfragen).

Sie können Storm als das komplette architektonische Gegenteil von Spark sehen. Storm ist eine verteilte Streaming-Engine. Jeder Knoten implementiert einen grundlegenden Prozess, und Datenelemente fließen in ein Netzwerk von miteinander verbundenen Knoten (im Gegensatz zu Spark). Mit Storm werden die Daten in den Prozess verschoben.

Beide Frameworks werden verwendet, um Berechnungen von großen Datenmengen zu parallelisieren.

Storm ist jedoch gut darin, zahlreiche generierte/gesammelte kleine Datenelemente dynamisch zu verarbeiten (z. B. Berechnung einiger Aggregationsfunktionen oder Analysen in Echtzeit auf einem Twitter-Stream).

Spark wird auf ein Korpus von vorhandenen Daten (wie Hadoop) angewendet, das in den Spark-Cluster importiert wurde, bietet schnelle Scanfunktionen aufgrund von In-Memory-Management und minimiert die globale Anzahl von I/Os für iterative Algorithmen.