Grilles de données, partitions et fragments

Une grille de données est divisée en partitions. Une partition contient un sous-ensemble unique de données. Une partition contient un ou plusieurs fragments : un fragment primaire et des fragments de réplique. Les fragments de réplique ne sont pas nécessaires dans une partition, mais vous pouvez en utiliser pour fournir la haute disponibilité. Que votre déploiement soit une grille de données indépendante stockée en mémoire ou un espace de traitement de base de données interne, l'accès aux données dans eXtreme Scale repose en grande partie sur les fragments.

Les données d'une partition sont stockées dans un ensemble de fragments au moment de l'exécution. Cet ensemble de fragments inclut un fragment primaire et une ou plusieurs éventuels fragments réplique. Un fragment est la plus petite unité que eXtreme Scale puisse ajouter ou supprimer d'une machine virtuelle Java.

Il existe deux stratégies de placement : placement de partition fixe (par défaut) et placement par conteneur. La section ci-dessous porte sur l'utilisation de la stratégie de placement de partition fixe.

Nombre total de fragments

Si votre environnement comprend 10 partitions contenant un million d'objets sans réplique, il existe 10 fragments contenant chacun 100 000 objets. Si vous ajoutez une réplique à ce scénario, un fragment supplémentaire existe dans chaque partition. Dans ce cas, il existe 20 fragments : 10 fragments primaires et 10 fragments de réplique. Chacun de ces fragments contient 100 000 objets. Chaque partition est composée d'un fragment primaire et d'une ou plusieurs répliques (N). La définition du nombre optimal de fragments s'avère déterminante. Si vous configurez quelques fragments, les données ne sont pas réparties de façon homogène entre les fragments, ce qui entraîne des erreurs de mémoire insuffisante et des problèmes de surcharge du processeur. Vous devez disposer d'au moins 10 fragments pour chaque JVM lorsque vous effectuez des modifications. Lorsque vous déployez initialement la grille de données, vous utilisez potentiellement un grand nombre de partitions.

Scénarios de nombre de fragments par JVM

Scénario : petite quantité de fragments pour chaque JVM

Les données sont ajoutées et supprimées d'une JVM à partir d'unités de fragments. Les fragments ne sont jamais divisés en plusieurs éléments. Pour 10 Go de données et 20 fragments qui les contiennent, chaque fragment contient en moyenne 500 Mo de données. Si neuf machines virtuelles Java hébergent la grille de données, chaque JVM possède deux fragments en moyenne. Etant donné que le nombre 20 n'est pas divisible par 9, quelques machines virtuelles Java comportent trois fragments selon la distribution suivante : Etant donné que chaque fragment contient 500 Mo de données, les données ne sont pas réparties de façon égale. Les sept machines virtuelles Java dotées de deux fragments hébergent chacune 1 Go de données. Les deux machines virtuelles Java dotées de trois fragments contiennent 50 % de données en plus, soit 1,5 Go, ce qui représente une charge nettement supérieure pour la mémoire. Comme les deux machines virtuelles Java hébergent trois fragments, elles reçoivent aussi moitié plus de demande pour leurs données. En conséquence, un faible nombre de fragments pour chaque JVM génère un déséquilibre. Pour optimiser les performances, vous pouvez augmenter le nombre de fragments pour chaque JVM.

Scénario : quantité accrue de fragments pour chaque JVM

Dans ce scénario, augmentez nettement le nombre de fragments. Dans ce scénarios, il existe 101 fragments avec neuf machines virtuelles Java hébergeant 10 Go de données. Dans ce cas, chaque fragment contient 99 Mo de données. Les machines virtuelles Java présentent le distribution de fragments suivante : Les deux machines virtuelles Java dotées de 12 fragments contiennent 99 Mo de données en plus que les autres fragments, ce qui constitue une différence de 9 %. Ce scénario est beaucoup plus régulièrement réparti que la différence de 50 % dans le scénario avec quelques fragments. Du point de vue de l'utilisation du processeur, seulement 9 % de plus de travail existe pour les deux machines virtuelles Java dotées de 12 fragments par rapport aux sept machines virtuelles Java dotées de 11 fragments. En augmentant le nombre de fragments dans chaque JVM, l'utilisation des données et du processeur est répartie de façon égale et juste.

Lorsque vous créez votre système, utilisez 10 fragments pour chaque JVM dans le scénario de taille maximale correspondant ou lorsque le système exécute le nombre maximal de machines virtuelles Java dans le cadre de votre planification.

Facteurs supplémentaires de positionnement

Le nombre de partitions, la stratégie de placement et nombre et le type des répliques sont définis dans la stratégie de déploiement. Le nombre de fragments placés dépend de la stratégie de déploiement que vous définissez. Les attributs minSyncReplicas, developmentMode, maxSyncReplicas et maxAsyncReplicas affectent le placement des partitions et des répliques.

Les facteurs suivants affectent le moment où les fragments sont placés :
  • Les commandes xscmd -c suspendBalancing et xscmd -c resumeBalancing.
  • Le fichier des propriétés du serveur, qui contient la propriété placementDeferralInterval qui définit le délai en millisecondes précédant le placement des fragments sur les serveurs de conteneur.
  • L'attribut numInitialContainers dans la stratégie de déploiement.

Si le nombre maximal de répliques n'est pas placé au cours du démarrage initial, des répliques supplémentaires peuvent être placées si vous démarrez des serveurs supplémentaires ultérieurement. Lorsque vous planifiez le nombre de fragments par machine virtuelle Java, le nombre maximal de fragments primaires et de réplique est indépendant du fait de disposer d'un nombre suffisant de machines virtuelles Java pour prendre en charge le nombre maximal de répliques. Un fragment de réplique n'est jamais placé dans le même processus que le fragment primaire. Si un processus est perdu, le fragment principal et le fragment de réplique sont perdus. Lorsque l'attribut developmentMode a la valeur false, le fragment primaire et les fragments de réplique ne sont pas placés sur le même serveur physique.