Modèles d'index dans Elasticsearch : Comment utiliser les modèles composables

Elasticsearch vous permet d’indexer des données rapidement et en toute flexibilité. Essayez-le gratuitement dans le cloud ou exécutez-le en local pour découvrir à quel point l’indexation peut être simple.

Un index Elasticsearch peut être configuré par le biais de mappages, de paramètres et d'alias : 

• Les définitions de mappage spécifient le schéma de données.
• Les paramètres définissent la taille du groupe et les taux de rafraîchissement. 
• Les alias sont utilisés pour donner d'autres noms à l'index.

Lorsque nous indexons un document pour la première fois ou que nous créons un index vide à l'aide de l'API Create Index, l'index est créé avec les paramètres par défaut, sans schéma de données et sans alias. Ces valeurs par défaut fonctionnent assez bien dans les environnements de développement et de test, mais il se peut que nous devions personnaliser nos indices pour les environnements de production.

L'utilisation des mappages et des paramètres par défaut en production peut entraîner des performances médiocres en matière d'indexation et de recherche. L'instanciation manuelle des indices est un processus fastidieux et chronophage. Recréer de tels index dans chaque environnement est particulièrement peu pratique si nous disposons d'un schéma de correspondance élaboré ainsi que de paramètres et d'alias personnalisés.

Heureusement, Elasticsearch met à notre disposition un outil permettant d'appliquer automatiquement une configuration prédéfinie lors de la création d'index sous la forme de  modèles d' index.

Modèles d'index

Les modèles d'index nous permettent de créer des index avec une configuration définie par l'utilisateur. Lors de son instanciation, un index peut tirer la configuration de ces modèles, par exemple un nombre déterminé de shards et de réplicas ou des mappages de champs. Un modèle sera défini avec un modèle de nom et une certaine configuration. Si le nom de l'index correspond au modèle de dénomination du modèle, le nouvel index sera créé avec la configuration définie dans le modèle.

Elasticsearch a mis à jour sa fonctionnalité de modèle dans la version 7.8 avec des modèles composables. Cette nouvelle version permet de réutiliser beaucoup plus de modèles d'index, comme le montre cet article.

Types de modèles

Les modèles d'index peuvent être classés en deux catégories :

• Modèles d'index (ou modèles d'index composables): Les modèles d'index composables peuvent exister seuls ou être composés d'un ou de plusieurs modèles de composants (voir la deuxième catégorie).
• Modèles de composants : Le modèle de composant est un modèle réutilisable qui définit la configuration requise. En général, le modèle de composant doit être associé à un modèle d'index. Chaque modèle de composant peut être associé à un ou plusieurs modèles d'index. 

Comme vous pouvez le voir dans l'image ci-dessous, les modèles d'index A et B partagent des modèles de composants (dans ce cas, un seul - le modèle 3) entre eux. Un modèle d'index peut être constitué d'un ou de plusieurs modèles de composants et chacun des modèles de composants peut être associé à un ou plusieurs modèles d'index. Les deux types de modèles peuvent exister seuls, mais les modèles de composants ne sont d'aucune utilité s'ils ne sont pas rattachés à un modèle d'index.

L'idée générale est de développer un catalogue de modèles de composants qu'une organisation peut utiliser pour divers besoins (par exemple, en spécifiant les différents modèles de composants pour des environnements individuels) et de les attacher à divers index via les modèles d'index composables.

Comment créer des modèles composables (index)

Elasticsearch fournit un point de terminaison _index_template pour gérer les modèles d'index. L'utilisateur fournit tous les mappages, paramètres et alias nécessaires ainsi qu'un modèle de nom d'index dans ce modèle. Prenons l'exemple de la création d'un modèle pour une application de microservice, customer-order-service, qui est responsable de la logique de génération des commandes. 

Supposons que nous ayons besoin de créer un modèle pour les commandes des clients, représenté par un motif comportant des caractères génériques : *commandes. Ce modèle est censé contenir certains mappages et paramètres, tels que le champ order_date, ainsi que les numéros de shards et de réplicas.

Tout index qui est associé à ce modèle lors de sa création hérite des configurations définies dans ce modèle. Par exemple, un index black_friday_orders aura le champ order_date, les shards seront fixés à 5 et les réplicas à 2. En outre, tous les index créés à partir de ce modèle héritent également d'un nom d'alias unique ! Créons ce modèle orders_template avec un modèle d'index défini comme *orders et avec un schéma de correspondance consistant en un seul champ oder_date avec un format de date prédéfini dd-MM-yyyy. Le code ci-dessous montre comment créer ce modèle d'index.

Lorsque vous exécutez cette requête dans les DevTools de Kibana, le modèle est créé avec le modèle d'index *orders ainsi que le mappage prédéfini, les paramètres et un alias. L'index_patterns est un tableau de motifs de correspondance ; tout index correspondant à ce motif sera dérivé de la configuration du modèle. Vous pouvez exécuter ce qui suit pour récupérer le modèle persisté qui devrait réitérer ce que nous avons fait :

Il existe également une priorité, un nombre positif, définie lors de la création de l'attribut de modèle défini sur le modèle : chaque modèle est défini avec une priorité de sorte que toute modification conflictuelle provenant de différents modèles sera résolue en utilisant cette valeur, la priorité étant donnée à la valeur de priorité la plus élevée. Nous nous pencherons plus en détail sur la priorité des modèles ci-dessous.

Création d'un index avec le modèle

Maintenant que nous disposons d'un modèle - un schéma directeur pour la création d'index - l'étape suivante consiste à créer un index. Lorsque le nom de l'index correspond au modèle donné, les configurations modèles sont appliquées automatiquement. Pour le prouver, comme le montre le code ci-dessous, créons un tout nouvel index nommé : blackfriday_orders :

Comme le nom de l'index (blackfriday_orders) correspond au modèle de dénomination défini dans le modèle (c'est-à-dire *orders), l'index doit obtenir toute la configuration dérivée du modèle. Récupérons cet index fraîchement créé et vérifions si c'est bien le cas en exécutant le code suivant :

Il doit revenir :

Comme l'indique la réponse, la configuration de blackfriday_orders a été héritée du modèle. Nous pouvons essayer diverses combinaisons d'indices qui hériteront avec succès de la configuration modèle :

Cependant, les indices suivants n'hériteront pas de la configuration car leur nom ne correspond pas au modèle :

Il est important de se rappeler que tous les indices dérivés d'un modèle ont le même alias - all_orders - dans ce cas. L'avantage d'un tel alias est qu'il permet d'effectuer des requêtes sur cet alias unique plutôt que sur plusieurs indices.

Si nous créons un modèle pour les *commandes, tout index correspondant est censé adopter la configuration du modèle. En général, sciemment ou non, les équipes peuvent créer quelques modèles supplémentaires pour diverses raisons. Cela signifie que le nom de l'index peut parfois correspondre à deux modèles différents ! Elasticsearch doit décider quelles configurations de ces modèles il doit appliquer. Heureusement, ce dilemme peut être résolu en utilisant le modèle de priorité.

Création de modèles de composants

Nous avons appris à connaître les modèles d'index dans la première partie de cet article. La création de modèles avec la configuration intégrée présente quelques inconvénients, notamment le fait que la configuration n'est pas exportable pour d'autres modèles. Si nous souhaitons disposer d'une configuration similaire, par exemple pour les modèles liés aux clients (*customers), nous devrons peut-être recréer l'ensemble du modèle. Cela signifie que nous pouvons en créer des dizaines dans une organisation typique (et vous pouvez en avoir quelques autres en fonction de l'environnement).

Comme nous cherchons toujours à faciliter la réutilisation, Elasticsearch a redessiné les modèles en gardant à l'esprit la réutilisation. Les modèles de composants répondent à cette exigence. Si vous venez d'un milieu DevOps, il est fort probable que vous ayez besoin de créer des indices avec une configuration prédéfinie pour chacun des environnements. Plutôt que d'appliquer manuellement chacune de ces configurations, vous pouvez créer un modèle de composant pour chacun des environnements.

Un modèle de composant n'est rien d'autre qu'un bloc réutilisable de configurations que nous pouvons utiliser pour créer d'autres modèles d'index. Notez que les modèles de composants n'ont aucune valeur s'ils ne sont pas associés à des modèles d'index. Ils sont exposés via un point de terminaison _component_template. Voyons comment tout cela s'articule.

Modèle de configuration

Extrayons les paramètres que nous avons définis dans notre modèle d'index plus tôt et créons un modèle de composant à partir de celui-ci. Le modèle settings_component_template est censé comporter cinq shards primaires avec deux réplicas par shard primaire. La première étape, comme le montre le code ci-dessous, consiste à déclarer et à exécuter un modèle de composant avec cette configuration.

Comme le montre le code ci-dessus, nous utilisons le point de terminaison _component_template pour créer un modèle de composant. Le corps de la demande contient les informations relatives au modèle dans un objet modèle. Le modèle settings_component_template peut désormais être utilisé ailleurs dans les modèles d'index. Une différence notable est que ce modèle ne définit aucun modèle d'index ; il s'agit simplement d'un bloc de code qui configure certaines propriétés pour nous.

Modèle de correspondance

De la même manière, créons un autre modèle. Cette fois, nous allons extraire le schéma de correspondance que nous avons défini précédemment dans les modèles d'index autonomes. Le code ci-dessous illustre le script :

Modèle d'alias

Dans le même ordre d'idées, nous pouvons également avoir un modèle de composant avec les alias - deux alias (all_orders et sales_orders) :

Modèle d'index composable

Maintenant que nous disposons de ces trois modèles de composants, la prochaine étape consiste à les utiliser. Nous pouvons le faire en laissant un modèle d'index pour, par exemple, christmas_orders, l'utiliser :

La balise composed_of est une collection de tous les modèles de composants qui constituent ce modèle. Dans ce cas, nous choisissons les paramètres, les mappings et les alias des modèles de composants. Nous avons également relevé le niveau de priorité afin que ce modèle l'emporte sur tous les autres. Une fois le modèle prêt, tous les indices correspondant au motif *orders hériteront de la configuration de ces trois modèles de composants.

Cela dit, si nous souhaitons créer un nouveau modèle, par exemple clients, avec un seul des modèles existants (settings_component_template) et un modèle alias nouvellement créé (aliases_component_template - voir ci-dessous), nous pouvons le faire à l'aide de :

Le modèle d'index se présente comme suit :

Avez-vous vu que le modèle settings_component_template a été (ré)utilisé dans deux modèles différents ? C'est la force des modèles de composants.

Priorité au modèle

Il est possible que les développeurs créent plusieurs modèles d'index sans tenir compte du stock existant. Il est important de définir une priorité pour chacun de ces modèles afin que celui qui a la priorité la plus élevée soit utilisé. Par exemple, le modèle my_orders_template_1 remplace le modèle my_orders_template_2 dans l'extrait de code suivant :

Lorsque plusieurs modèles correspondent aux index créés, Elasticsearch applique toutes les configurations de tous les modèles correspondants, mais remplace tout ce qui a une priorité plus élevée.

Préséance des modèles

Enfin, vous vous interrogez peut-être sur la préséance des modèles : la configuration définie dans le modèle de composant est-elle prioritaire par rapport à celle définie dans le modèle d'index principal lui-même ? Ou l'inverse ? Il y a des règles à respecter :

• Un index créé avec des configurations explicites a la priorité sur tout le reste - cela signifie que si vous créez un index avec des configurations explicites, ne vous attendez pas à ce qu'elles soient remplacées par les modèles.
• Les anciens modèles (modèles créés avant la version 7.8) ont une priorité inférieure à celle des modèles composables.

Résumé

• Un index contient des mappings, des paramètres et des alias : les mappings définissent le schéma des champs, les paramètres définissent les paramètres de l'index tels que le nombre de shards et de réplicas, et les alias donnent des noms alternatifs à l'index.
• Les modèles permettent de créer des indices avec des configurations prédéfinies. Le fait de nommer un index avec un nom qui correspond au modèle d'index défini dans un modèle spécifique configurera automatiquement cet index conformément au modèle.
• Elasticsearch a introduit les modèles d'index composables dans la version 7.8. Les modèles d'index composables permettent la modularité et le changement de version des modèles.
• Les modèles composables sont constitués d'au moins un modèle de composant.
• Un modèle d'index peut également avoir sa propre configuration.
• Un modèle de composant est un modèle réutilisable avec une configuration prédéfinie, tout comme un modèle d'index composable.
• Toutefois, les modèles de composants sont censés faire partie d'un modèle d'index ; ils sont inutiles s'ils ne sont pas "composés" dans un modèle d'index.
• Les modèles de composants n'ont pas de modèle d'index défini, ce qui est une autre raison pour laquelle ils sont "censés" faire partie d'un modèle d'index.
• Chaque modèle a une priorité - un nombre positif. Plus le nombre est élevé, plus l'application du modèle est prioritaire.