Kann ich Terracotta verwenden, um eine RAM-intensive Anwendung zu skalieren?

Question

Ich evaluiere Terracotta, um eine Anwendung zu skalieren, die derzeit an den RAM-Speicher gebunden ist. Es handelt sich um einen kollaborativen Filter, der etwa 2 Kilobyte Daten pro Benutzer speichert. Ich möchte Amazons EC2 nutzen, was bedeutet, dass ich auf 14 GB RAM beschränkt bin, was mir eine effektive Obergrenze von etwa 7 Millionen Benutzern pro Server gibt. Ich muss in der Lage sein, darüber hinaus zu skalieren.

Nach dem, was ich bisher gelesen habe, kann Terracotta einen geclusterten Heap haben, der größer ist als der verfügbare RAM auf jedem Server. Wäre es praktikabel, einen effektiven Cluster-Heap von 30 GB oder mehr zu haben, wenn jeder der Server nur 14 GB unterstützt?

Die Daten pro Benutzer (bei denen es sich größtenteils um Float-Arrays handelt) ändern sich sehr häufig, möglicherweise Hunderttausende Male pro Minute. Es ist nicht notwendig, dass jede einzelne dieser Änderungen in dem Moment, in dem sie auftritt, mit anderen Knoten im Cluster synchronisiert wird. Ist es möglich, nur einige Objektfelder in regelmäßigen Abständen zu synchronisieren?

Answer 1

Ich würde sagen, die Antwort ist ein eingeschränktes Ja. Terracotta ermöglicht es Ihnen, mit geclusterten Heaps zu arbeiten, die größer sind als die Größe einer einzelnen JVM, obwohl das nicht der häufigste Anwendungsfall ist.

Sie müssen jedoch a) die Größe der Arbeitsmenge und b) den Umfang des Datenverkehrs im Auge behalten. Zu a): Es gibt eine Reihe von Daten, die sich im Speicher befinden müssen, um die Arbeit zu einem bestimmten Zeitpunkt ausführen zu können, und wenn die Größe der Arbeitsmenge die Heap-Größe übersteigt, leidet die Leistung natürlich. Bei b) muss jedes im Heap-Cluster hinzugefügte/aktualisierte Datenelement an den Server gesendet werden. Terracotta ist am besten geeignet, wenn Sie feinkörnige Felder in Pojo-Diagrammen ändern. Bei der Arbeit mit großen Arrays werden die Möglichkeiten von Terracotta nicht optimal genutzt (was nicht heißen soll, dass es nicht auch manchmal auf diese Weise eingesetzt wird).

Wenn Sie viel Müll erzeugen, müssen die Terracotta-Speichermanager und der verteilte Garbage Collector in der Lage sein, mit diesem Müll Schritt zu halten. Es ist schwer zu sagen, ohne es auszuprobieren, ob Ihr Datenvolumen die verfügbare Bandbreite übersteigt.

Ihre Anwendung wird enorm davon profitieren, wenn Sie mehrere Server betreiben und die Daten nach Servern partitioniert sind oder ein gewisses Maß an Lokalität aufweisen. In diesem Fall benötigen Sie nur die Daten für die Partition eines Servers im Heap und der Rest muss nicht in den Speicher ausgelagert werden. Der Rest muss nicht in den Speicher ausgelagert werden. Er wird natürlich ausgelagert, wenn dies für die Ausfallsicherung/Verfügbarkeit erforderlich ist, falls andere Server ausfallen. Das bedeutet, dass Sie im Falle von partitionierten Daten nicht an alle Knoten senden, sondern nur Transaktionen an den Server schicken.

Rein rechnerisch ist es möglich, 30 GB an Daten zu indizieren, das heißt, es gibt keine harte Grenze.