WebSphere eXtreme Scale incluye los plug-ins de memoria caché de nivel (L2) para los proveedores OpenJPA e Hibernate Java Persistence API (JPA). Cuando se utiliza uno de estos plug-ins, la aplicación utiliza la API JPA. Se introduce una cuadrícula de datos entre la aplicación y la base de datos, lo cual mejora los tiempos de respuesta.
EL uso de eXtreme Scale como un proveedor de memoria caché de nivel 2 aumenta el rendimiento al leer y consultar datos y reduce la carga de la base de datos. WebSphere eXtreme Scale tiene ventajas sobre las implementaciones de memoria caché incorporadas porque la memoria caché se duplica automáticamente entre todos los procesos. Cuando un cliente almacena en memoria caché un valor, todos los demás clientes son capaces de utilizar el valor almacenado en memoria caché que está localmente en la memoria.
Puede configurar la topología y propiedades del proveedor de memoria caché L2 en el archivo persistence.xml. Para obtener más información sobre cómo configurar estas propiedades, consulte Propiedades de configuración de la memoria caché JPA.
Cuando están habilitadas, las operaciones de consulta utilizan la memoria caché de consulta de JPA. Habilite la memoria caché de consulta de JPA sólo para aplicaciones con una alta proporción de lectura respecto a grabación, por ejemplo cuando se aproxime al 99% de operaciones de lectura. Si utiliza JPA la memoria caché de consulta de JPA, debe utilizar la Topología incorporada o la Topología interna del dominio.
La operación de búsqueda por clave capta una entidad de destino si la entidad de destino no tiene ninguna relación. Si la entidad de destino tiene relaciones con el tipo de captación EAGER, se captan estas relaciones junto con la entidad de destino. En la memoria caché de datos JPA, la captación de estas relaciones hace unos pocos aciertos de caché obtengan todos los datos de relación.
En un sistema con pocas JVM, existe la latencia de réplica de datos para operaciones de grabación. El objetivo de la memoria caché es mantener una vista de datos sincronizados final en todas las JVM. Cuando se utiliza la topología interna del dominio, existe un retardo de réplica de datos para las operaciones de grabación. Las aplicaciones que utilizan esta topología deben ser capaces de tolerar lecturas obsoletas y grabaciones simultáneas que pueden sobrescribir los datos.
Con una topología interna del dominio, los fragmentos primarios se colocan en cada uno de los servidores de contenedor de la topología. Estos fragmentos internos contiene el conjunto completo de datos para la partición. Cualquiera de estos fragmentos primarios también puede completar operaciones de grabación de memoria caché. Esta configuración elimina el cuello de botella en la topología incorporada donde todas las operaciones de grabación de memoria caché deben pasar por un único fragmento primario.
En una topología interna del dominio, no se crean fragmentos de réplica, incluso si tiene definidas réplicas en los archivos de configuración. Cada fragmento primario redundante contiene una copia completa de los datos, de forma que cada fragmento primario también se puede considerar un fragmento de réplica. Esta configuración utiliza una partición única, similar a la topología incorporada.
ObjectGridName=nombre_objectgridx,ObjectGridType=EMBEDDED,PlacementScope=CONTAINER_SCOPE,PlacementScopeTopology=HUB | RING
Ventajas:
Limitaciones:
Una topología incorporada crea un servidor de contenedor en el espacio de proceso de cada aplicación. OpenJPA e Hibernate leen directamente con la copia en memoria de la memoria caché y escriben en todas las demás copias. Puede mejorar el rendimiento de la escritura utilizando la réplica asíncrona. El rendimiento de esta topología predeterminada es mejor cuando el volumen de datos en caché es lo suficientemente pequeño para caber en un solo proceso. Con una topología incorporada, cree una única partición para los datos.
ObjectGridName=nombre_objectgrid,ObjectGridType=EMBEDDED,MaxNumberOfReplicas=núm_réplicas,ReplicaMode=SYNC | ASYNC | NONE
Cuando los datos en memoria caché son demasiado voluminosos para caber en un solo proceso, puede utilizar la topología incorporada particionada. Esta topología divide los datos en varios procesos. Los datos se dividen entre los fragmentos primarios, de modo que cada fragmento primario contiene un subconjunto de los datos. Aún puede utilizar esta opción cuando la latencia de base de datos sea alta.
ObjectGridName=nombre_objectgrid,ObjectGridType=EMBEDDED_PARTITION,ReplicaMode=SYNC | ASYNC | NONE,
NumberOfPartitions=núm_particiones,ReplicaReadEnabled=TRUE | FALSE
Ventajas:
Limitación:
Por ejemplo, para almacenar en memoria caché 10 GB de datos con un máximo de 1 GB por JVM, se necesitan 10 Máquinas virtuales Java. Por lo tanto, el número de particiones debe establecerse en 10 o más. De manera ideal, el número de particiones se debe establecer en un número primo donde cada fragmento almacena una cantidad razonable de memoria. Normalmente, el valor numberOfPartitions es igual al número de Máquinas virtuales Java. Con este valor, cada JVM almacena una partición. Si habilita las réplicas, debe aumentar el número de Máquinas virtuales Java en el sistema. De lo contrario, cada JVM también almacena una partición de réplica, que consume tanta memoria como una partición primaria.
Lea sobre Dimensionamiento de la memoria y cálculo del número de particiones para maximizar el rendimiento de la configuración elegida.
Por ejemplo, en un sistema con cuatro Máquinas virtuales Java, y el valor del parámetro numberOfPartitions de 4, cada JVM aloja una partición primaria. Una operación de lectura tiene un 25 por ciento de posibilidades de captar datos desde una partición disponible localmente, que es mucho más rápido que obtener los datos de una JVM remota. Si una operación de lectura como, por ejemplo, ejecutar una consulta, debe captar una colección de datos que implican 4 particiones de manera uniforme, el 75 por ciento de las llamadas son remotas y el otro 25 por ciento son locales. Si el valor ReplicaMode se establece en SYNC o ASYNC y el valor ReplicaReadEnabled está establecido en true, se crean las cuatro particiones de réplica y se expanden a lo largo de las cuatro Máquinas virtuales Java. Cada JVM aloja una partición primaria y una partición de réplica. La probabilidad de que la operación de lectura se ejecute de forma local aumenta a un 50 por ciento. La operación de lectura que capta una colección de datos que implican cuatro particiones de manera uniforme tiene un 50 por ciento de llamadas remotas y un 50 por ciento de llamadas locales. Las llamadas locales son mucho más rápidas que las memorias remotas. Siempre que se producen llamadas remotas, baja el rendimiento.
Una topología remota almacena todos los datos almacenados en la memoria caché en uno o más procesos separados, reduciendo el uso de la memoria de los procesos de la aplicación. Puede aprovechar la distribución de los datos en distintos procesos desplegando una cuadrícula de datos particionada y replicada de eXtreme Scale. A diferencia de las configuraciones incorporadas, e incorporadas particionadas, descritas en las secciones anteriores, si desea gestionar la cuadrícula de datos remota debe hacerlo de forma independiente de la aplicación y del proveedor JPA.
ObjectGridName=nombre_objectgrid,ObjectGridType=REMOTE
El tipo de ObjectGrid REMOTE no requiere ningún valor de propiedad porque el ObjectGrid y la política de despliegue están definidos independientemente de la aplicación JPA. El plug-in de memoria caché JPA se conecta remotamente a un ObjectGrid remoto.
Puesto que toda la interacción con ObjectGrid es remota, esta topología tiene el rendimiento más lento entre todos los tipos ObjectGrid.
Ventajas:
Limitación: