Lokaler Speichercache

Im einfachsten Fall kann WebSphere eXtreme Scale als lokaler (nicht verteilter) speicherinterner Datengrid-Cache verwendet werden. Dies kann insbesondere für Anwendungen mit sehr vielen gemeinsamen Zugriffen von Vorteil sein, in denen mehrere Threads auf transiente Daten zugreifen und diese ändern müssen. Die in einem lokalen Datengrid gespeicherten Daten können indexiert und mit Abfragen abgerufen werden. Abfragen helfen Ihnen bei der Arbeit mit großen speicherinternen Datasets. Die mit Java Virtual Machine (JVM) bereitgestellte Unterstützung ist zwar einsatzfähig, besitzt aber eine eingeschränkte Datenstruktur.

Die lokale speicherinterne Cachetopologie für WebSphere eXtreme Scale wird verwendet, um einen konsistenten, transaktionsorientierten Zugriff auf temporäre Daten in einer einzelnen Java Virtual Machine zu unterstützen.

Abbildung 1. Szenario mit einem lokalen speicherinternen Speichercache
Szenario mit lokalem Speichercache

Vorteile

  • Einfaches Setup: Ein ObjectGrid kann programmgesteuert oder deklarativ über die ObjectGrid-XML-Implementierungsdeskriptordatei oder mit anderen Frameworks wie Spring erstellt werden.
  • Schnell: Jede BackingMap kann gesondert für eine optimale Speicherauslastung und gemeinsamen Zugriff optimiert werden.
  • Ideal für Topologien mit einer einzigen JVM und einer kleinen Dateigruppe oder für das Caching von Daten, auf die häufig zugegriffen wird.
  • Transaktionsorientiert: BackingMap-Aktualisierungen können zu einer einzigen Arbeitseinheit gruppiert und als letzter Teilnehmer in zweiphasige Transaktionen wie JTA-Transaktionen (Java Transaction Architecture) integriert werden.

Nachteile

  • Keine Fehlertoleranz.
  • Die Daten werden nicht repliziert. Speichercaches eignen sich am besten für schreibgeschützte Referenzdaten.
  • Keine Skalierbarkeit. Die für die Datenbank erforderliche Speicherkapazität kann die JVM möglicherweise nicht bereitstellen.
  • Es treten Probleme auf, wenn JVMs hinzugefügt werden.
    • Die Daten sind nicht so einfach partitionierbar.
    • Der Status muss in den JVMs manuell repliziert werden, da die einzelnen Cacheinstanzen ansonsten verschiedene Versionen derselben Daten enthalten könnten.
    • Das Ungültigmachen von Einträgen ist kostenintensiv.
    • Jeder Cache muss einzeln vorbereitet werden. Die Vorbereitungs- oder Aufwärmphase ist der Zeitraum, in dem eine Gruppe von Daten geladen wird, damit der Cache mit gültigen Daten gefüllt wird.

Einsatz

Die Implementierungstopologie mit dem lokalen Speichercache sollte nur verwendet werden, wenn die Menge der zwischenzuspeichernden Daten klein ist (in eine einzige JVM passt) und relativ stabil ist. Bei diesem Ansatz müssen veraltete Daten toleriert werden. Die Verwendung von Evictor (Bereinigungsprogramm), um nur die am häufigsten verwendeten oder die zuletzt verwendeten Daten im Cache zu verwalten, kann dabei helfen, den Cache klein zu halten und die Relevanz der Daten zu erhöhen.