Partitionnement

Utilisation du partitionnement pour étendre une application. Vous pouvez définir le nombre de partitions dans votre stratégie de déploiement.

A propos du partitionnement

Le partitionnement n'est pas similaire à la technologie RAID, qui divise chaque instance de chaque segment. Chaque partition héberge les données complètes d'entrées individuelles. Le partitionnement est un moyen très efficace d'extension, mais il n'est pas valable pour toutes les applications. Les applications qui nécessitent des garanties transactionnelles dans des ensembles de données volumineux ne sont pas évolutives et ne peuvent pas être partitionnées de manière efficace. WebSphere eXtreme Scale ne prend pas en charge actuellement la validation en deux phases dans les partitions.

Important : Sélectionnez le nombre de partitions avec précaution. Le nombre de partitions défini dans la règle de déploiement affecte directement le nombre de serveurs de conteneur sur lesquels une application peut évoluer. Chaque partition est composée d'un fragment primaire et du nombre configuré de fragments de réplique. La formule (Nombre_Partitions*(1 + Nombre_Répliques)) correspond au nombre de conteneurs qui peuvent être utilisés pour étendre une application.

Utiliser des partitions

Une grille de données peut comporter des milliers de partitions. Une grille de données peut évoluer jusqu'au produit du nombre de partitions multiplié par le nombre de fragments par partition. Si, par exemple, vous avez 16 partitions dont chacune comporte un fragment primaire et un fragment réplique, soit deux fragments, vous pouvez monter jusqu'à 32 machines virtuelles Java. Dans ce cas, il est défini un seul fragment pour chaque machine virtuelle Java. Vous devez choisir un nombre raisonnable de partitions en fonction du nombre de machines virtuelles Java que vous êtes censé utiliser. Pour le système, chaque fragment augmente l'utilisation de processeurs et de mémoire. Le système est conçu pour monter en puissance afin de gérer cette charge en fonction du nombre de machines virtuelles Java de serveurs qui sont disponibles.

Les applications ne doivent pas utiliser des milliers de partitions si l'application s'exécute sur une grille de données de quatre serveurs de conteneur machines virtuelles Java. L'application doit être configurée afin de disposer d'un nombre raisonnable de fragments pour chaque machine virtuelle Java de serveur de conteneur. Exemple de configuration déraisonnable : 2 000 partitions de deux fragments chacune, qui s'exécutent sur quatre machines virtuelles Java conteneurs. Résultat d'une telle configuration : 4 000 fragments placés dans quatre machines virtuelles Java conteneurs, soit 1 000 fragments par machine virtuelle Java conteneur.

Il serait plus intelligent d'avoir 10 fragments pour chacune des machines virtuelles Java attendues. Cette configuration n'empêche pas une évolutivité élastique de dix fois la configuration initiale tout en conservant une quantité raisonnable de fragments par machine virtuelle Java conteneur.

Supposons que vous disposiez de six serveurs physiques avec deux machines virtuelles Java de conteneur par serveur physique et que vous pensiez atteindre 20 serveurs physiques au cours des trois prochaines années. Avec 20 serveurs physiques, vous disposez de 40 machines virtuelles Java de serveur de conteneur et vous en choisissez 60 pour le mode pessimiste. Vous voulez utiliser quatre fragments par machine virtuelle Java de conteneur. Cela vous fait soixante conteneurs potentiels, soit un total de deux cent quarante fragments. Si vous avez un fragment primaire et un fragment réplique par partition, vous voudrez cent vingt partitions. Cet exemple vous donne 240 divisé par 12 machines virtuelles Java conteneurs, soit vingt fragments par machine virtuelle Java conteneur pour le déploiement initial avec le potentiel pour monter ultérieurement à vingt ordinateurs.

ObjectMap et partitionnement

Avec la stratégie FIXED_PARTITION de positionnement par défaut, les mappes sont fractionnées entre des partitions et des clés hachent vers les différentes partitions. Le client n'a pas besoin de savoir à quelles partitions appartiennent les clés. Si un groupe de mappes comporte plusieurs mappes, ces mappes doivent être validées dans des transactions distinctes.

Entités et partitionnement

Les entités EntityManager sont dotées d'une optimisation qui aide les clients utilisant des entités sur un serveur. Le schéma d'entités sur le serveur pour le groupe de mappes peut spécifier une seule entité racine. Le client doit accéder à toutes les entités via cette entité racine. Le gestionnaire d'entités peut alors trouver dans la même partition les entités liées à partir de cette racine sans avoir besoin que les mappes liées aient une clé commune. C'est l'entité racine qui établit l'affinité avec la partition. Cette partition sert à toutes les recherches d'entités au sein de la transaction une fois que l'affinité a été établie. Cette affinité peut économiser de la mémoire car les mappes liées ne nécessitent pas de clé commune. L'entité racine doit être spécifiée avec une annotation d'entité modifiée, comme dans l'exemple suivant :
@Entity(schemaRoot=true)
Utilisez l'entité pour trouver la racine du graphe d'objets. Le graphe d'objets définit les relations entre une ou plusieurs entités. Chaque entité liée par une même relation doit se résoudre vers la même partition. Toutes les entités enfants sont censées se trouver dans la même partition que la racine. Les entités enfants présentes dans le graphe d'objets ne sont accessibles à un client qu'à partir de leur entité racine. Les entités racines sont toujours requises dans les environnements partitionnés lorsqu'on utilise un client eXtreme Scale pour communiquer avec le serveur. Il n'est possible de définir qu'une seule entité racine par clients. Les entités racines ne sont pas requises lorsque vous utilisez des ObjectGrids de type XTP (Extreme Transaction Processing), car toute la communication avec la partition s'effectue par accès direct en local et non via le mécanisme client et serveur.