Les langages orientés objet comme Java et les bases de données relationnelles prennent en charge les relations et les associations. Les relations diminuent la quantité d'espace de stockage utilisé grâce à l'utilisation de référence d'objet ou de clés externes.
Lorsque vous utilisez des relations dans une grille de données, les données doivent être organisées dans un arbre contraint. Un type de racine doit exister dans l'arborescence et tous les enfants ne doivent être associés qu'à une seule racine. Exemple : un département pourra avoir de nombreux salariés et un salarié pourra avoir de nombreux projets. Mais un projet ne pourra avoir de nombreux salariés qui appartiennent à des départements différents. Une fois qu'une racine est définie, tous les accès à cet objet root et à ses descendants sont gérés via la racine. WebSphere eXtreme Scale utilise le code de hachage de la clé de l'objet racine pour choisir une partition. Par exemple :
partition = (hashCode MOD numPartitions).
Lorsque toutes les données d'une relation sont liées à une seule instance d'objet, l'instance, l'arborescence peut être située en totalité dans la même partition et il suffit d'une transaction pour y accéder de manière très efficace. Si les données embrassent plusieurs relations, plusieurs partitions seront nécessaires, ce qui implique des appels distants supplémentaires, avec le risque de goulots d'étranglement pour les performances.
Certaines relations incluent des données de recherche ou de référence, telles que CountryName. Avec des données de recherche ou de référence, les données doivent exister dans chaque partition. Les données sont accessibles à n'importe quelle clé racine et le même résultat est renvoyé. Les données de référence de ce type ne doivent être utilisées que dans les cas où les données sont relativement statiques. La mise à jour de ces données peut être coûteuse, car les données doivent être mis à jour dans chaque partition. L'API DataGrid est une technique usuellement employée pour conserver à jour les données de référence.
La normalisation des données en utilisant des relations permet de réduire la quantité de mémoire utilisée par la grille de données, car la réplication des données diminue. Mais, en règle générale, plus l'on ajoute de données relationnelles et moindre est leur extensibilité. En effet, lorsque les données sont regroupées, la maintenance de leurs relations devient plus onéreuse et il devient difficile de leur conserver des tailles gérables. Comme la grille partitionne les données en fonction de la clé de la racine de l'arborescence, la taille de celle-ci n'est pas prise en compte. Par conséquent, si vous avez un grand nombre de relations pour une instance d'arborescence, la grille de données peuvent devenir déséquilibré, provoquant une partition détenant davantage de données que les autres.
Lorsque les données sont dénormalisées ou mises à plat, les données qui seraient normalement partagées entre deux objets sont dupliquées et chaque table peut être partitionnée indépendamment pour améliorer l'équilibre de la grille de données. Bien que cela augmente la quantité de mémoire utilisée, cela permet à l'application de se mettre à l'échelle puisqu'on est sûr que l'accès à une seule ligne de données donne accès à toutes les données nécessaires. C'est parfait pour les grilles qui sont essentiellement en lecture où la maintenance des données devient plus onéreuse.
Pour plus d'informations, voir Classifying XTP systems and scaling.
ObjectMap est l'API la plus rapide, la plus flexible et la plus granulaire de toutes les API d'accès aux données, car elle fournit une approche transactionnelle à base de sessions pour l'accès aux données présentes dans la grille des mappes. L'API ObjectMap permet aux clients d'utiliser des opérations communes CRUD (create, read, update et delete) pour gérer des paires clé-valeur d'objets dans la grille de données répartie.
Lorsqu'on utilise l'API ObjectMap, les relations entre les objets doivent être exprimées par l'incorporation dans l'objet parent de la clé externe de toutes les relations.
Exemple :
public class Department {
Collection<String> employeeIds;
}
L'API EntityManager simplifie la gestion des relations en extrayant les données persistantes des objets, y compris les clés externes. Lorsque l'objet est ultérieurement récupéré dans la grille de données, le graphique des relations est reconstruit, comme dans l'exemple suivant.
@Entity
public class Department {
Collection<String> employees;
}
L'API EntityManager est très semblable aux autres technologies Java de persistance d'objet comme JPA et Hibernate, en ce qu'elle synchronise un graphe d'instances d'objets Java gérés avec le stockage de persistance. Dans ce cas, le magasin persistant est une grille de données eXtreme Scale, où chaque entité est représentée sous la forme d'une mappe et où la mappe contient les données de l'entité plutôt que les instances d'objets.