Particionamiento

Utilice el particionamiento para escalar una aplicación. Puede definir el número de particiones en la política de despliegue.

Acerca del particionamiento

El particionamiento no es como la escritura en bandas de RAID (Redundant Array of Independent Disks), que corta cada instancia a lo largo de todas las bandas. Cada partición aloja los datos completos para las entradas individuales. El particionamiento es un medio muy eficaz para escalar, pero no puede aplicarse a todas las aplicaciones. Las aplicaciones que requieren garantías transacciones entre grandes conjuntos de datos no se escalan y no se pueden particionar eficazmente. WebSphere eXtreme Scale no da soporte actualmente a la confirmación de dos fases entre particiones.

Importante: Seleccione el número de particiones cuidadosamente. El número de particiones definidas en la política de despliegue afecta directamente al número de servidores de contenedor al que se puede escalar una aplicación. Cada partición está compuesta de un fragmento primario y el número configurado de fragmentos de réplica. La fórmula (Número_Particiones*(1 + Número_Réplicas)) es el número de contenedores que se pueden utilizar para escalar de forma horizontal una única aplicación.

Uso de particiones

Una cuadrícula de datos puede tener hasta miles de particiones. Una cuadrícula de datos se puede escalar hasta el número resultante de la multiplicación del número de particiones por el número de fragmentos por partición. Por ejemplo, si tiene 16 particiones y cada partición tiene un primario y una réplica, o dos fragmentos, podrá escalarla de forma potencial a 32 Máquinas virtuales Java. En este caso, se define un fragmento para cada JVM. Debe elegir un número razonable de particiones basándose en el número esperado de Máquinas virtuales Java que probablemente vaya a utilizar. Cada fragmento aumenta el uso de procesador y memoria para el sistema. El sistema se ha diseñado para escalar de forma horizontal para manejar esta sobrecarga según el número disponible de Máquinas virtuales Java de servidor.

Las aplicaciones no deben utilizar miles de particiones si la aplicación se ejecuta en una cuadrícula de datos de cuatroMáquinas virtuales Java de servidor de contenedor. La aplicación se debe configurar para que tenga un número razonable de fragmentos para cada JVM de servidor de contenedor. Por ejemplo, una configuración no razonable sería establecer 2000 particiones con dos fragmentos que se ejecutan en cuatro Máquinas virtuales Java de contenedor. Esta configuración genera 4000 fragmentos que se colocan en cuatro Máquinas virtuales Java de contenedor o 1000 fragmentos por JVM de contenedor.

Por el contrario, una mejor configuración sería tener menos de 10 fragmentos para cada JVM de contenedor esperado. Esta configuración todavía proporciona la posibilidad de permitir una escalada elástica que es diez veces la configuración inicial, mientras que se mantiene un número razonable de fragmentos por JVM de contenedor.

Considere este ejemplo de escalado: actualmente tiene seis servidores físicos con dos Máquinas virtuales Java de contenedor por servidor físico. Espera que crezca hasta 20 servidores físicos a lo largo de los próximos tres años. Con 20 servidores físicos, tiene 40 Máquinas virtuales Java de servidor de contenedor y elige 60 para ser pesimista. Desea tener cuatro fragmentos por JVM de contenedor. Potencialmente tiene 60 contenedores o un total de 240 fragmentos. Si tiene un fragmento primario y una réplica por partición, tendrá 120 particiones. Este ejemplo le proporciona 240 dividido por 12 Máquinas virtuales Java de contenedor, o 20 fragmentos por JVM de contenedor para el despliegue inicial con el potencial de poder escalar de forma horizontal a 20 máquinas, más adelante.

ObjectMap y particionamiento

Con la estrategia de colocación FIXED_PARTITION predeterminada, las correlaciones se dividen entre las particiones y las claves realizan un método hash en particiones diferentes. No es necesario que el cliente sepa a qué partición pertenecen las claves. Si un mapSet tiene varias correlaciones, las correlaciones se deben confirmar en transacciones distintas.

Entidades y particionamiento

Las entidades del gestor de entidades tienen una optimización que ayuda a los clientes que trabajan con entidades en un servidor. El esquema de entidad en el servidor relativo al conjunto de correlaciones puede especificar una sola entidad raíz. El cliente debe acceder a todas las entidades a través de la entidad raíz. El gestor de entidades puede encontrar las entidades relacionadas en dicha raíz en la misma partición sin necesitar que las correlaciones relacionadas tengan una clave común. La entidad raíz establece afinidad con una única partición. Esta partición se utiliza en todas las búsquedas de entidad dentro de la transacción una vez establecida la afinidad. Esta afinidad puede ahorrar memoria porque las correlaciones relacionadas no necesitan una clave común. La entidad raíz debe especificarse con una anotación de entidad modificada, como se muestra en el ejemplo siguiente:
@Entity(schemaRoot=true)
Utilice la entidad para encontrar la raíz del gráfico del objeto. El gráfico del objeto define la relación entre una o varias entidades. Cada entidad enlazada se debe resolver con la misma partición. Se presupone que todas las entidades hija están en la misma partición que la raíz. Sólo se puede acceder a las entidades hija de este gráfico del objeto desde un cliente de la entidad raíz. Las entidades raíz siempre son necesarias en entornos con particiones si se utiliza un cliente eXtreme Scale para comunicarse con el servidor. Sólo se puede definir un tipo de entidad raíz por cliente. Las entidades raíz no son necesarias cuando se utilizan ObjectGrdi de estilo XTP (Extreme Transaction Processing), ya que todas las comunicaciones a la partición se realizan mediante acceso local directo y no mediante el mecanismo de cliente y servidor.