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
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.