Red Hat Training

A Red Hat training course is available for Red Hat JBoss Enterprise Application Platform

13.6.4. Partitionnement d'indexes

Dans certains cas, il est utile de partitionner (sharding) les données indexées d'une entité donnée en plusieurs indexes Lucene.

Avertissement

Le paritionnement n'a lieu d'être que si les avantages sont plus importants que les inconvénients. La recherche d' indexes partitionnés sera normalement plus lente car pour une simple recherche, toutes les partitions doivent être ouvertes.
Cas possibles d'utilisation du partitionnement :
  • Un index unique est trop volumineux, donc les temps de mises à jour ralentissent l'application.
  • Une recherche typique ne touchera qu'un sous-ensemble d'indexes, comme quand les données sont segmentées naturellement par client, région ou application.
Par défaut, le partitionnement n'est pas activé à moins que le nombre de partitions soit configuré. Pour ce faire, utiliser la propriété hibernate.search.<indexName>.sharding_strategy.nbr_of_shards.

Exemple 13.68. Activer le partitionnement de l'index

Dans cet exemple, 5 partitions sont activées. 
hibernate.search.<indexName>.sharding_strategy.nbr_of_shards = 5
La stratégie IndexShardingStrategy est chargée de diviser les données en sous-indexes. La stratégie de partitionnement par défaut divise les données en fonction de la valeur de hachage de la représentation de la chaîne d'ID (générée par le FieldBridge). Cela garantit un partitionnement assez équilibré. Vous pouvez remplacer la stratégie par défaut avec une IndexShardingStrategy personnalisée. Pour utiliser votre statégie personnalisée, vous devez définir la propriété hibernate.search.<indexName>.sharding_strategy.

Exemple 13.69. Spécifier une stratégie de partitionnement personnalisée

hibernate.search.<indexName>.sharding_strategy = my.shardingstrategy.Implementation
La propriété IndexShardingStrategy permet également d'optimiser les recherches en sélectionnant dans quelle partition (shard) exécuter la requête. En activant un filtre, une stratégie de partitionnement peut sélectionner un sous-ensemble de sections permettant de répondre à une requête (IndexShardingStrategy.getIndexManagersForQuery) et ainsi accélérer l'exécution de la requête.
Chaque partition correspond à un IndexManager indépendant, et donc peut être configuré pour utiliser un fournisseur et un serveur de sauvegarde différents. Les noms d'indexes IndexManager pour l'entité Animal dans Exemple 13.70, « Configuration de partitionnement pour l'entité Animal » sont Animal.0 à Animal.4. En d'autres termes, chaque partition porte le nom de l'index auquel il appartient, suivi de . (point) et son numéro d'index.

Exemple 13.70. Configuration de partitionnement pour l'entité Animal

hibernate.search.default.indexBase = /usr/lucene/indexes
hibernate.search.Animal.sharding_strategy.nbr_of_shards = 5
hibernate.search.Animal.directory_provider = filesystem
hibernate.search.Animal.0.indexName = Animal00 
hibernate.search.Animal.3.indexBase = /usr/lucene/sharded
hibernate.search.Animal.3.indexName = Animal03
Dans Exemple 13.70, « Configuration de partitionnement pour l'entité Animal », la configuration utilise la stratégie de hachage de chaîne d'identification par défaut et partitionne l'index Animal en 5 sous indexes. Tous les sous-indexes sont des instances du système de fichiers et du répertoire où est stocké chaque sous-index comme suit :
  • pour le sous-index 0 : /usr/lucene/indexes/Animal00 (indexBase partagée mais indexName substitué)
  • pour le sous-index 1 : /usr/lucene/indexes/Animal.1 (indexBase partagé, indexName par défaut)
  • pour le sous-index 2 : /usr/lucene/indexes/Animal.1 (indexBase partagé, indexName par défaut)
  • pour le sous-index 3 : /usr/lucene/indexes/Animal03 (indexBase substitué, indexName substitué)
  • pour le sous-index 4 : /usr/lucene/indexes/Animal.4 (indexBase partagé, indexName par défaut)
Lorsque vous implémentez une IndexShardingStrategy, n'importe quel champ peut être utilisé pour déterminer la sélection de partitionnement. Considérons que pour traiter des suppressions, avec les opérations purge et purgeAll, l'implémentation soit amenée à retourner un ou plusieurs indexes sans être en mesure de lire toutes les valeurs de champ ou l'identificateur principal. Dans ce cas, l'information ne suffit pas pour choisir un seul indice, tous les indexes doivent être retournés, afin que l'opération de suppression puisse être propagée à tout index susceptible de contenir les documents devant être supprimés.
Rapporter un bogue