WebSphere eXtreme Scale enthält Cache-Plug-ins der Stufe 2 (L2) für die JPA-Provider OpenJPA und Hibernate. Wenn Sie eines dieser Plug-ins verwenden, verwendet Ihre Anwendung die JPA-API. Es wird ein Datengrid zwischen Anwendung und Datenbank eingeführt, das die Antwortzeiten verbessert.
Die Verwendung von eXtreme Scale als L2-Cache-Provider erhöht die Leistung beim Lesen und Abfragen von Daten und reduziert die Last der Datenbank. WebSphere eXtreme Scale bietet im Vergleich mit integrierten Cacheimplementierungen verschiedene Vorteile, weil der Cache automatisch in allen Prozessen repliziert wird. Wenn ein Client einen Wert zwischenspeichert, können alle anderen Clients den zwischengespeicherten Wert, der sich lokal im Speicher befindet, verwenden.
Sie können die Topologie und die Eigenschaften für den L2-Cache-Provider in der Datei persistence.xml konfigurieren. Weitere Informationen zum Konfigurieren dieser Eigenschaften finden Sie unter Konfigurationseigenschaften des JPA-Caches.
Wenn der JPA-Abfragecache aktiviert ist, wird er von Abfrageoperationen genutzt. Aktivieren Sie den JPA-Abfragecache nur für Anwendungen mit einem hohen Lese/Schreib-Verhältnis, z. B., wenn Stand der Leseoperationen 99 % erreicht. Wenn Sie den JPA-Abfragecache verwenden, müssen Sie den Integrierte Topologie oder den Domäneninterne Topologie verwenden.
Die Find-by-key-Operation (Suchen nach Schlüsseln) ruft eine Zielentität ab, wenn die Zielentität keine Beziehung hat. Wenn die Zielentität Beziehungen mit dem Abruftyp EAGER hat, werden diese Beziehungen zusammen mit der Zielentität abgerufen. Im JPA-Datencache verursacht der Abruf dieser Beziehungen einige wenige Cachetreffer, um alle Beziehungsdaten abzurufen.
In einem System mit wenigen JVMs treten Latenzzeiten bei Schreiboperationen während der Datenreplikation auf. Das Ziel des Caches ist die Verwaltung einer synchronisierten Datenansicht in allen JVMs. Wenn Sie die domäneninterne Topologie verwenden, treten bei Schreiboperationen Verzögerungen während der Datenreplikation auf. Anwendungen, die diese Topologie verwenden, müssen veraltete Leseoperationen und gleichzeitige Schreiboperationen tolerieren, die Daten überschreiben.
Bei einer domäneninternen Topologie werden primäre Shards an jeden Container-Server in der Topologie verteilt. Diese primären Shards enthalten die vollständigen Daten für die Partition. Alle primären Shards können auch Schreiboperationen im Cache ausführen. Diese Konfiguration schaltet Engpässe in der integrierten Topologie aus, in der alle Schreiboperationen im Cache über ein einziges primäres Shard erfolgen.
In einer domäneninternen Topologie werden keine Replikat-Shards erstellt, selbst wenn Sie Replikate in Ihren Konfigurationsdateien definiert haben. Jedes redundante primäre Shard enthält eine vollständige Kopie der Daten, sodass jedes primäre Shard auch als Replikat-Shard betrachtet werden kann. Diese Konfiguration verwendet ähnlich wie in der integrierten Topologie eine einzige Partition.
ObjectGridName=ObjectGrid-Name,ObjectGridType=EMBEDDED,PlacementScope=CONTAINER_SCOPE,PlacementScopeTopology=HUB | RING
Vorteile:
Einschränkungen:
Eine integrierte Topologie erstellt einen Container-Server im Prozessbereich jeder Anwendung. OpenJPA und Hibernate lesen die Speicherkopie des Caches direkt und schreiben in alle anderen Kopien. Sie können die Schreibleistung durch den Einsatz asynchroner Replikation verbessern. Diese Standardtopologie liefert die beste Leistung, wenn die zwischengespeicherte Datenmenge in einen einzigen Prozess passt. Bei einer integrierten Topologie erstellen Sie eine einzige Partition für die Daten.
ObjectGridName=ObjectGrid-Name,ObjectGridType=EMBEDDED,MaxNumberOfReplicas=Anzahl_der_Replikate,ReplicaMode=SYNC | ASYNC | NONE
Wenn die zwischengespeicherten Daten nicht in einen einzigen Prozess passen, können Sie die integrierte partitionierte Topologie verwenden. In dieser Topologie werden die Daten auf mehrere Prozesse verteilt. Die Daten werden so auf die primären Shards verteilt, dass jedes primäre Shard einen Teil der Daten enthält. Sie können diese Option auch verwenden, wenn die Latenzzeit der Datenbank hoch ist.
ObjectGridName=ObjectGrid-Name,ObjectGridType=EMBEDDED_PARTITION,ReplicaMode=SYNC | ASYNC | NONE,
NumberOfPartitions=Anzahl_Partitionen,ReplicaReadEnabled=TRUE | FALSE
Vorteile:
Einschränkungen:
Um beispielsweise 10 GB Daten mit maximal 1 GB pro JVM zu speichern, sind zehn Java Virtual Machines erforderlich. Die Anzahl der Partitionen muss daher auf mindestens 10 gesetzt werden. Im Idealfall wird die Anzahl der Partitionen auf eine Primzahl gesetzt, so dass in jedem Shard eine angemessene Speichermenge zugeteilt wird. Gewöhnlich entspricht der Wert der Einstellung "numberOfPartitions" der Anzahl der Java Virtual Machines. Bei dieser Einstellung enthält jede JVM eine Partition. Wenn Sie die Replikation aktivieren, müssen Sie die Anzahl der Java Virtual Machines im System erhöhen. Andernfalls wird in jeder JVM zusätzlich eine Replikatpartition gespeichert, die genauso viel Speicher belegt wie eine primäre Partition.
Im Abschnitt Speicher dimensionieren und Partitionsanzahl berechnen finden Sie Informationen zur Maximierung der Leistung der von Ihnen ausgewählten Konfiguration.
In einem System mit vier Java Virtual Machines und einem numberOfPartitions-Wert von 4 beispielsweise enthält jede JVM eine primäre Partition. Bei einer Leseoperation besteht eine Chance von 25 %, dass die Daten aus einer lokal verfügbaren Partition abgerufen werden, was im Vergleich mit dem Abruf der Daten aus einer fernen JVM wesentlich schneller ist. Wenn eine Leseoperation, z. B. eine Abfrage, eine Sammlung von Daten abrufen muss, die gleichmäßig auf vier Partitionen verteilt sind, sind 75 % der Aufrufe ferne und 25 % der Aufrufe lokale Aufrufe. Wenn die Einstellung "ReplicaMode" auf SYNC oder ASYNC und die Einstellung "ReplicaReadEnabled" auf true gesetzt wird, werden vier Relikatpartitionen erstellt und auf vier Java Virtual Machines verteilt. Jede JVM enthält eine primäre Partition und eine Replikatpartition. Die Chance, dass die Leseoperation lokal ausgeführt wird, erhöht sich auf 50 %. Die Leseoperation, die eine Sammlung von Daten abrufen muss, die gleichmäßig auf vier Partitionen verteilt sind, hat 50 % ferne Aufrufe und 50% lokale Aufrufe. Lokale Aufrufe sind wesentlich schneller als ferne Aufrufe. Mit jedem fernen Aufruf nimmt die Leistung ab.
In einer fernen Topologie werden alle zwischengespeicherten Daten in einem oder mehreren gesonderten Prozessen gespeichert, was die Speicherbelegung der Anwendungsprozesse verringert. Sie können Ihre Daten auf unterschiedliche Prozesse verteilen, indem Sie ein partitioniertes, repliziertes eXtreme-Scale-Datengrid implementieren. Im Gegensatz zu den integrierten und integrierten partitionierten Konfigurationen, die in den vorherigen Abschnitten beschrieben wurden, müssen Sie ein fernes Datengrid unabhängig von der Anwendung und vom JPA-Provider verwalten.
ObjectGridName=ObjectGrid-Name,ObjectGridType=REMOTE
Der ObjectGrid-Typ REMOTE erfordert keine Eigenschaftseinstellungen, weil das ObjectGrid und die Implementierungsrichtlinie gesondert von der JPA-Anwendung definiert werden. Das JPA-Cache-Plug-in stellt über Fernzugriff eine Verbindung zu einem vorhandenen fernen ObjectGrid her.
Da alle Interaktionen mit dem ObjectGrid über Fernzugriff erfolgen, hat diese Topologie die geringste Leistung von allen ObjectGrid-Typen.
Vorteile:
Einschränkungen: