Utilisation du partitionnement pour étendre une application. Vous pouvez définir le nombre de partitions dans votre stratégie de déploiement.
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.
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.
@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.