Plug-in de cache niveau 2 (L2) JPA

WebSphere eXtreme Scale inclut des plug-in de mémoire cache de niveau 2 pour les fournisseurs OpenJPA et Hibernate Java Persistence API (JPA). Lorsque vous utilisez l'un de ces plug-in, l'application utilise l'API JPA. Une grille de données est introduite ente l'application et la base de données pour améliorer les temps de réponse.

L'utilisation d'eXtreme Scale en tant que fournisseur de cache de niveau 2 améliore les performances lors de la lecture et de l'interrogation des données et réduit la charge pesant sur la base de données. WebSphere eXtreme Scale présente plusieurs avantages par rapport aux implémentations de cache pré-intégrées car le cache est automatiquement répliqué entre tous les processus. Lorsqu'un client met une valeur en cache, tous les autres clients peuvent utiliser la valeur mise en cache en local.

Vous pouvez configurer la topologie et les propriétés pour le fournisseur de cache L2 dans le fichier persistence.xml. Pour plus d'informations sur la configuration de ces propriétés, voir Propriétés de configuration du cache JPA.

Conseil : Le plug-in de cache L2 JPA requiert une application qui utilise les API JPA. Si vous souhaitez utiliser les API WebSphere eXtreme Scale pour accéder à une source de données JPA, utilisez le chargeur JPA. Pour plus d'informations, voir Chargeurs JPA.

Remarques relatives à la topologie cache L2 JPA

Les facteurs suivants affectent le type de topologie à configurer :
  1. Quelle quantité de données voulez-vous placer en mémoire cache ?
  2. Quel est le taux de lecture/écriture prévu ?
    Ce taux affecte les performances du cache L2. Chaque topologie gères différemment les opérations de lecture et d'écriture. Les applications qui fonctionnent principalement en lecture seule doivent utiliser des topologies intra-domaines lorsque cela est possible. Les applications qui exécutent des opération d'écriture principalement doivent utiliser des topologies intra-domaines.
  3. Quel est le pourcentage de données recherchées par rapport au pourcentage de données trouvées par une clé ?

    Lorsque le cache des requêtes JPA est activé, les opérations d'interrogation l'utilisent. Activez ce cache pour les applications avec des taux de lecture/écriture élevés uniquement, par exemple, lorsque vous approchez de 99 % d'opérations de lecture. Si vous utilisez le cache des requêtes JPA, vous devez utiliser Topologie imbriquée ou Topologie intra-domaine.

    L'opération de recherche par clé recherche une entité cible si l'entité cible n'a pas de relation. Si l'entité cible a des relations avec le type de recherche EAGER, ces relations sont recherchées avec l'entité cible. Dans le cache de données JPA, un petit nombre de réussites en mémoire obtient toutes les données de relation lors de la recherche de ces relations.

  4. Quel est niveau d'obsolescence toléré des données ?

    Dans un système comportant un petit nombre de machines JVM, il existe une latence de réplication des données pour les opérations d'écriture. Le cache a pour fonction de gérer une vue de données synchronisée dans toutes les machines JVM. Lorsque vous utilisez la topologie intra-domaine, il existe un délai de réplication de données pour les opérations d'écriture. Les applications qui utilisent cette topologie doivent pouvoir tolérer les lectures obsolètes et les écritures simultanées qui peuvent remplacer les données.

Topologie intra-domaine

Avec une topologie intra-domaine, les fragments primaires sont placés sur chaque serveur de conteneur dans la topologie. Ces fragments primaires contiennent l'ensemble des données de la partition. N'importe lequel de ces fragments primaires peut également exécuter des opérations d'écriture dans la mémoire cache. Cette configuration élimine le goulot d'étranglement dans la topologie intégrée dans lequel toutes les opérations d'écriture de la mémoire cache doivent passer par un fragment primaire unique.

Dans une topologie intra-domaine, aucun fragment de réplique n'est créé, même si vous avez défini des répliques dans vos fichiers de configuration. Chaque fragment primaire redondant contient une copie complète des données, de sorte qu'il peut également être considéré comme un fragment de réplique. Cette configuration utilise une partition unique, similaire à la topologie intégrée.

Figure 1. Topologie intra-domaine JPA
Topologie partitionnée intégrée JPA
Propriétés de configuration du cache JPA associées pour la topologie intra-domaine :
ObjectGridName=objectgrid_name,ObjectGridType=EMBEDDED,PlacementScope=CONTAINER_SCOPE,PlacementScopeTopology=HUB | RING

Avantages :

  • Lectures de cache et des mises à jour localement
  • Simple à configurer.

Limitations :

  • Cette topologie est la mieux adaptée lorsque les serveurs de conteneur peuvent contenir l'ensemble des données de la partition.
  • Les fragments de réplique, même s'ils sont configurés, ne sont jamais placés, car chaque serveur de conteneur héberge un fragment primaire. Toutefois, tous les fragments primaires sont répliqués avec les autres fragments primaires, de sorte que ces fragments primaires deviennent des répliques les uns des autres.

Topologie imbriquée

Conseil : Envisagez d'utiliser une topologie intra-domaine pour obtenir de meilleures performances.

Une topologie imbriquée crée un serveur de conteneur dans l'espace de traitement de chaque application. Les plug-in OpenJPA et Hibernate lisent directement la copie en mémoire du cache et écrivent dans toutes les autres copies. Vous pouvez améliorer les performances d'écriture à l'aide de la réplication asynchrone. Cette topologie par défaut produit un résultat optimal lorsque la quantité de données mises en cache est suffisamment réduite pour être traitée par un seul processus. Avec une topologie intégrée, créez une seule partition pour les données.

Figure 2. Topologie imbriquée JPA
Topologie imbriquée JPA
Propriétés de configuration du cache JPA de la topologie intégrée :
ObjectGridName=objectgrid_name,ObjectGridType=EMBEDDED,MaxNumberOfReplicas=num_replicas,ReplicaMode=SYNC | ASYNC | NONE
Avantages :
  • Toutes les lectures de cache sont des accès locaux rapides.
  • Simple à configurer.
Limitations :
  • La quantité de données est limitée à la taille du processus.
  • Toutes les mises à jour de cache sont envoyées via un fragment primaire, ce qui crée un goulot d'étranglement.

Topologie imbriquée et partitionnée

Conseil : Envisagez d'utiliser une topologie intra-domaine pour obtenir de meilleures performances.
ATTENTION :
N'utilisez pas le cache des requêtes JPA avec un topologie partitionnée. Le cache de requêtes stocke les résultats des requêtes qui sont une collection de clés d'entité. Le cache de requêtes recherche toutes les données d'entité dans le cache de données. Comme l'antémémoire données est divisée entre plusieurs processus, ces appels supplémentaires peuvent faire perdre les avantages du cache L2.

Lorsque les données en mémoire cache sont trop volumineuses pour tenir dans un seul processus, vous pouvez utiliser la topologie partitionnée intégrée. Cette topologie divise le données dans plusieurs processus. Les données sont divisées entre les fragments primaires de sortie que chaque fragment primaire contient un sous-ensemble des données. Vous pouvez toujours utiliser cette option lorsque la latence de la base de données est élevée.

Figure 3. Topologie imbriquée et partitionnée JPA
Topologie partitionnée intégrée JPA
Propriétés de configuration du cache JPA de la topologie partitionnée intégrée :
ObjectGridName=objectgrid_name,ObjectGridType=EMBEDDED_PARTITION,ReplicaMode=SYNC | ASYNC | NONE,
NumberOfPartitions=num_partitions,ReplicaReadEnabled=TRUE | FALSE

Avantages :

  • Stocke de grandes quantités de données.
  • Simple à configurer.
  • Les mises à jour de cache sont réparties sur plusieurs processus.

Limitation :

  • La plupart des lectures et des mises à jour de cache sont distantes.

Par exemple, pour mettre en cache 10 Go de données avec un maximum de 1 Go par machine JVM, 10 machines virtuelles Java sont nécessaires. Le nombre de partitions doit par conséquent être défini sur 10 ou plus. Idéalement, le nombre de partitions doit être un nombre premier où chaque fragment stocke une quantité raisonnable de mémoire. Le paramètre numberOfPartitions est généralement égal au nombre de machines virtuelles Java. Chaque machine virtuelle Java stocke une partition à l'aide de ce paramètre. Si vous activez la réplication, vous devez augmenter le nombre de machines virtuelles Java dans le système. Dans le cas contraire, chaque machine virtuelle Java stocke également une réplique de partition qui consomme autant de mémoire que la partition principale.

Consultez Définition de la taille de la mémoire et calcul du nombre de partitions pour optimiser les performances de la configuration choisie.

Par exemple, dans un système avec quatre machines virtuelles Java et avec la valeur de paramètre numberOfPartitions 4, chaque machine virtuelle Java héberge une partition principale. Une opération de lecture a 25 pourcents de chances d'extraire des données d'une partition disponible en local, ce qui est sensiblement plus rapide qu'à partir d'une machine virtuelle Java distante. Si une opération de lecture, telle que l'exécution d'une requête, doit extraire une collection de données impliquant une répartition égale de quatre partitions, 75 pourcents des appels sont distants et 25 pourcents sont locaux. Si le paramètre ReplicaMode est défini sur SYNC ou ASYNC et si le paramètre ReplicaReadEnabled est défini sur true, quatre répliques de partitions sont créées et réparties entre quatre machines virtuelles Java. Chaque machine virtuelle Java héberge une partition principale et une réplique. L'opération de lecture a désormais à 50 pourcents de chances de s'exécuter en local. L'opération de lecture qui extrait une collection de données impliquant une répartition égale de quatre partitions comporte 50 pourcents d'appels distants et 50 pourcents d'appels locaux. Les appels locaux sont considérablement plus rapides que les appels distants. Dès que des appels distants sont effectués, les performances chutent.

Topologie distante

ATTENTION :
N'utilisez pas le cache des requêtes JPA avec une topologie distante. Le cache des requêtes stocke les résultats des requêtes qui sont une collection de clés d'entité. Le cache de requêtes recherche toutes les données d'entité dans le cache de données. Comme l'antémémoire données est distante, ces appels supplémentaires peuvent faire perdre les avantages du cache L2.
Conseil : Envisagez d'utiliser une topologie intra-domaine pour obtenir de meilleures performances.

Une topologie distante stocke toutes les donnés mises en cache dans un ou plusieurs processus, ce qui réduit la sollicitation de la mémoire par les processus applicatifs. Vous pouvez tirer parti de la répartition de vos données dans des processus distincts en déployant une grille de données eXtreme Scale partitionnée répliquée. Contrairement aux configurations intégrées et intégrées et partitionnées décrites dans les sections précédentes, si vous souhaitez gérer la grille de données distante, vous devez le faire indépendamment de l'application et du fournisseur JPA.

Figure 4. Topologie distante JPA
Topologie distante JPA
Propriétés de configuration du cache JPA de la topologie distante :
ObjectGridName=objectgrid_name,ObjectGridType=REMOTE

Le type d'ObjectGrid REMOTE ne nécessite pas de paramètres de propriété car l'ObjectGrid et la règle de déploiement sont définis distinctement de l'application JPA. Le plug-in de cache JPA se connecte à distance à un ObjectGrid éloigné existant.

Toute interaction avec la grille d'objets étant éloignée, cette topologie offre les moins bonnes performances parmi tous les types de grille d'objets.

Avantages :

  • Stocke de grandes quantités de données.
  • Le processus applicatif est exempt de données en cache.
  • Les mises à jour de cache sont réparties sur plusieurs processus.
  • Options de configuration souples.

Limitation :

  • Toutes lectures et mises à jour de cache sont distantes.