JPA-L2-Cache-Plug-in

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.

Tipp: Das JPA-L2-Cache-Plug-in erfordert eine Anwendung, die die JPA-APIs verwendet. Wenn Sie APIs von WebSphere eXtreme Scale für den Zugriff auf eine JPA-Datenquelle verwenden möchten, verwenden Sie den JPA-Loader. Weitere Informationen finden Sie unter JPA-Loader.

Hinweise zur JPA-L2-Cachetopologie

Die folgenden Faktoren haben Auswirkungen auf den zu konfigurierenden Topologietyp:
  1. Wie viele Daten werden schätzungsweise zwischengespeichert?
  2. Welches Verhältnis zwischen Lese- und Schreiboperationen erwarten Sie?
    Das Verhältnis zwischen Lese- und Schreiboperationen wirkt sich auf die Leistung des L2-Caches aus. Jede Topologie verarbeitet Lese- und Schreiboperationen anders. Anwendungen, die größtenteils schreibgeschützt sind, sollten, sofern möglich, integrierte und domäneninterne Topologien verwenden. Anwendungen, die mehr Schreiboperationen durchführen, sollten domäneninterne Topologien verwenden.
  3. Wie ist der Prozentsatz abgefragter Daten im Vergleich zum Prozentsatz anhand eines Schlüssels gefundener Daten?

    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.

  4. Welcher Veraltungsstand der Daten wird toleriert?

    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.

Domäneninterne Topologie

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.

Abbildung 1. Domäneninterne JPA-Topologie
Integrierte partitionierte JPA-Topologie
Zugehörige JPA-Cachekonfigurationseigenschaften für die domäneninterne Topologie:
ObjectGridName=ObjectGrid-Name,ObjectGridType=EMBEDDED,PlacementScope=CONTAINER_SCOPE,PlacementScopeTopology=HUB | RING

Vorteile:

  • Lese- und Aktualisierungsoperationen im Cache sind lokal.
  • Die Konfiguration ist einfach.

Einschränkungen:

  • Diese Topologie eignet sich optimal, wenn die Container-Server alle Partitionsdaten enthalten.
  • Replikat-Shards werden, selbst wenn sie konfiguriert sind, nie verteilt, weil jeder Container-Server ein primäres Shard hostet. Alle primären Shards werden auf den anderen primären Shards repliziert, so dass diese primären Shards zu gegenseitigen Replikaten werden.

Integrierte Topologie

Tipp: Für eine optimale Leistung sollten Sie eine domäneninterne Topologie in Erwägung ziehen.

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.

Abbildung 2. Integrierte JPA-Topologie
Integrierte JPA-Topologie
Zugehörige JPA-Cachekonfigurationseigenschaften für die integrierte Topologie:
ObjectGridName=ObjectGrid-Name,ObjectGridType=EMBEDDED,MaxNumberOfReplicas=Anzahl_der_Replikate,ReplicaMode=SYNC | ASYNC | NONE
Vorteile:
  • Alle Leseoperationen im Cache sind schnelle lokale Zugriffe.
  • Die Konfiguration ist einfach.
Einschränkungen:
  • Das Datenvolumen ist auf die Größe des Prozesses beschränkt.
  • Alle Cacheaktualisierungen werden über ein einziges primäres Shard gesendet, woraufhin ein Engpass entsteht.

Integrierte, partitionierte Topologie

Tipp: Für eine optimale Leistung sollten Sie eine domäneninterne Topologie in Erwägung ziehen.
Vorsicht:
Verwenden Sie den JPA-Abfragecache nicht für eine integrierte partitionierte Topologie. Im Abfragecache werden Abfrageergebnisse gespeichert, die eine Sammlung von Entitätsschlüsseln sind. Der Abfragecache rurft alle Entitätsdaten aus dem Datencache ab. Da der Datencache auf mehrere Prozesse verteilt ist, können diese zusätzlichen Aufrufe die Vorteile des L2-Caches aufheben.

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.

Abbildung 3. Integrierte, partitionierte JPA-Topologie
Integrierte partitionierte JPA-Topologie
Zugehörige JPA-Cachekonfigurationseigenschaften für die integrierte partitionierte Topologie:
ObjectGridName=ObjectGrid-Name,ObjectGridType=EMBEDDED_PARTITION,ReplicaMode=SYNC | ASYNC | NONE,
NumberOfPartitions=Anzahl_Partitionen,ReplicaReadEnabled=TRUE | FALSE

Vorteile:

  • Es können große Datenvolumen gespeichert werden.
  • Die Konfiguration ist einfach.
  • Cacheaktualisierungen werden auf mehrere Prozesse verteilt.

Einschränkungen:

  • Die meisten Lese- und Aktualisierungsoperationen im Cache werden über Fernzugriff durchgeführt.

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.

Ferne Topologie

Vorsicht:
Verwenden Sie den JPA-Abfragecache nicht für eine ferne Topologie. Im Abfragecache werden Abfrageergebnisse gespeichert, die eine Sammlung von Entitätsschlüsseln sind. Der Abfragecache rurft alle Entitätsdaten aus dem Datencache ab. Da der Datencache fern ist, können diese zusätzlichen Aufrufe die Vorteile des L2-Caches aufheben.
Tipp: Für eine optimale Leistung sollten Sie eine domäneninterne Topologie in Erwägung ziehen.

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.

Abbildung 4. Ferne JPA-Topologie
Ferne JPA-Topologie
Zugehörige JPA-Cachekonfigurationseigenschaften für die ferne Topologie:
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:

  • Es können große Datenvolumen gespeichert werden.
  • Der Anwendungsprozess ist frei von zwischengespeicherten Daten.
  • Cacheaktualisierungen werden auf mehrere Prozesse verteilt.
  • Flexible Konfigurationsoptionen

Einschränkungen:

  • Alle Lese- und Aktualisierungsoperationen im Cache werden über Fernzugriff durchgeführt.