Cuadrículas de datos, particiones y fragmentos

Una cuadrícula de datos se divide en particiones. Una partición contiene un subconjunto exclusivo de los datos. Una partición contiene uno o más fragmentos: un fragmento primario y fragmentos de réplica. Los fragmentos de réplica no están necesariamente en una partición, pero puede utilizarlos para proporcionar alta disponibilidad. Si su despliegue es una cuadrícula de datos en memoria independiente o un espacio de proceso de base de datos en memoria, el acceso a los datos en eXtreme Scale se basa en gran medida en fragmentos.

Los datos de una partición se almacenan en un conjunto de fragmentos en tiempo de ejecución. Este conjunto de fragmentos incluye un fragmento primario y posiblemente uno más fragmentos réplica. Un fragmento es la unidad más pequeña que eXtreme Scale puede añadir a una Máquina virtual Java o eliminar de ésta.

Existen dos estrategias de colocación: colocación de partición fija (valor predeterminado) y colocación por contenedor. El tema siguiente se centra en el uso de la estrategia de colocación de partición fija.

Número total de fragmentos

Si el entorno incluye 10 particiones que contienen 1 millón de objetos sin réplicas, existirán 10 fragmentos, cada uno de los cuales almacenará 100.000 objetos. Si añadiera una réplica a este escenario, existiría un fragmento adicional en cada partición. En este caso, existen 20 fragmentos: 10 fragmentos primarios y 10 fragmentos de réplica. Cada uno de estos fragmentos almacena 100.000 objetos. Cada partición se compone de un fragmento primario y uno o más (N) fragmentos réplica. La determinación del número óptimo de fragmentos es clave. Si configura pocos fragmentos, los datos no se distribuyen equitativamente entre los fragmentos, lo que produce errores de memoria insuficiente y problemas de sobrecarga del procesador. Para escalar, debe tener como mínimo 10 fragmentos para cada JVM . Al desplegar inicialmente la cuadrícula de datos, utilizaría potencialmente muchas particiones.

Escenarios de número de fragmentos por JVM

Escenario: número pequeño de fragmentos para cada JVM

Los datos se añaden a una JVM y se eliminan de ésta mediante unidades de fragmentos. Los fragmentos nunca se dividen en partes. Si existen 10 GB de datos y existen 20 fragmentos para alojar estos datos, cada fragmento incluye de media 500 MB de datos. Si nueve Mäquinas virtuales Java alojan la cuadrícula de datos, de promedio cada JVM tiene dos fragmentos. Como 20 no es divisible entre 9, unas cuantas Mäquinas virtuales Java tienen tres fragmentos, con la distribución siguiente: Puesto que cada fragmento incluye 500 MB de datos, la distribución de datos no es uniforme. Las 7 Mäquinas virtuales Java con 2 fragmentos contienen cada uno 1 GB de datos. Las 2 Mäquinas virtuales Java con 3 fragmentos tienen el 50% más de datos, o 1,5 GB, que es una carga de memoria mucho mayor. Dado que los dos Mäquinas virtuales Java alojan tres fragmentos, estos reciben 50% más solicitudes para sus datos. Como resultado, si se tienen pocos fragmentos para cada JVM se produce desequilibrio. Para aumentar el rendimiento, debe incrementar el número de fragmentos para cada JVM .

Escenario: número mayor de fragmentos por JVM

Para este escenario el número de fragmentos es mucho mayor. En este escenario, existen 101 fragmentos con nueve Mäquinas virtuales Java que alojan 10 GB de datos. En este caso, cada fragmento contiene 99 MB de datos. La distribución de fragmentos de las Mäquinas virtuales Java es la siguiente: Las 2 Mäquinas virtuales Java con 12 fragmentos tienen sólo 99 MB más de datos que los otros fragmentos, que es una diferencia del 9%. Este escenario se distribuye mucho más equitativamente que la diferencia del 50% en este escenario con pocos fragmentos. Desde una perspectiva de uso del procesador, solo existe un 9% de trabajo adicional para las dos Mäquinas virtuales Java con los 12 fragmentos en comparación con las siete Mäquinas virtuales Java que tienen 11 fragmentos. Al incrementar el número de fragmentos en cada JVM , los datos y el uso del procesador se distribuyen de manera más equilibrada y uniforme.

Al crear el sistema, use 10 fragmentos para cada JVM como escenario de tamaño máximo, o cuando el sistema está ejecutando su número máximo de Mäquinas virtuales Java en el horizonte de planificación.

Factores adicionales de ubicación

El número de particiones, la estrategia de colocación, y el número y tipo de réplicas se establecen en la política de despliegue. El número de fragmentos que se colocan depende de la política de despliegue que define. Los atributos minSyncReplicas, developmentMode, maxSyncReplicas y maxAsyncReplicas afectan al lugar dónde se ponen las particiones y las réplicas.

Los factores siguientes afectan al momento en que se pueden poner los fragmentos:
  • Los mandatos xscmd -c suspendBalancing y xscmd -c resumeBalancing.
  • El archivo de propiedades de servidor, que tiene la propiedad placementDeferralInterval que define el número de milisegundos antes de que los fragmentos se pongan en los servidores de contenedor.
  • El atributo numInitialContainers en la política de despliegue.

Si no se coloca el número máximo de réplicas durante el inicio inicial, se podrían colocar réplicas adicionales si se inician posteriormente servidores adicionales. Al planificar el número de fragmentos por JVM, el número máximo de fragmentos primarios y de réplica depende de tener suficientes JVM iniciadas para dar soporte al número máximo de réplicas. Una réplica nunca se coloca en el mismo proceso que su primario. Si se pierde un proceso, se perderá tanto el primario como la réplica. Cuando el atributo developmentMode se establece en false, el primario y las réplicas no se ponen en el mismo servidor físico.