ECK demande nettement plus d'efforts que les solutions Elastic Cloud basées sur la Marketplace, mais il est plus automatisé que le déploiement de VM par vous-même, car l'opérateur Kubernetes s'occupera de l'orchestration du système et de la mise à l'échelle des nœuds.

Cette fois, nous allons travailler avec le service Azure Kubernetes (AKS), en utilisant Automatic. Dans les autres articles, vous apprendrez à utiliser Azure VM et Azure Marketplace.

Qu'est-ce qu'AKS Automatic ?

Azure Kubernetes Service (AKS) gère automatiquement la configuration des clusters, alloue dynamiquement les ressources et intègre les meilleures pratiques de sécurité tout en préservant la flexibilité de Kubernetes, ce qui permet aux développeurs de passer d'une image de conteneur à une application déployée en quelques minutes.

AKS Automatic supprime la plupart des frais généraux liés à la gestion des clusters et offre un bon équilibre entre simplicité et flexibilité. Le bon choix dépend de votre cas d'utilisation, mais la décision est plus facile à prendre si vous prévoyez de le faire :

• Déployer un environnement de test : Le déploiement est rapide et simple, ce qui le rend idéal pour les expériences rapides ou les clusters de courte durée.

• Travaillez sans exigences strictes en matière de VM, de stockage ou de réseau : AKS Automatic fournit des valeurs par défaut prédéfinies, de sorte que si celles-ci correspondent à vos besoins, vous n'avez pas besoin d'une configuration supplémentaire.

• Commencez avec Kubernetes pour la première fois : En prenant en charge une grande partie de la configuration du cluster, AKS Automatic réduit la courbe d'apprentissage et permet aux équipes de se concentrer sur leurs applications.

Pour Elasticsearch, nous allons utiliser Elastic Cloud on Kubernetes (ECK), qui est l'opérateur officiel d'Elastic Kubernetes qui simplifie l'orchestration des déploiements Kubernetes de la pile Elastic.

Comment configurer AKS Automatic

1. Connectez-vous au portail Microsoft Azure.

2. En haut à droite, cliquez sursur le bouton Cloud Shell pour accéder à la console et déployer le cluster AKS à partir de là. Vous pouvez également utiliser Azure Cloud Shell.

N'oubliez pas de mettre à jour l'identifiant du projet avec le vôtre pendant le tutoriel.

L'ouverture de l'AKS devrait ressembler à la capture d'écran ci-dessus.

3. Installez l'extension aks-preview Azure CLI. Cette version preview nous permettra de sélectionner --sku automatic lors de la création du cluster, ce qui activera la fonction AKS Automatic.

Si vous voyez ce message, cela signifie que l'extension AKS a été installée correctement.

4. Enregistrer les indicateurs de caractéristiques à l'aide de la commande az feature register

Vous verrez les détails de l'abonnement de fonctionnalité que nous venons de créer :

Vérifiez l'état de l'enregistrement jusqu'à ce qu'il passe de "En cours d'enregistrement" à "Enregistré". L'enregistrement peut prendre quelques minutes.

Exécutez az provider register pour propager les modifications.

5. Créer un groupe de ressources

Un groupe de ressources est un groupe logique de ressources Azure à gérer et à déployer.

6. Créez un cluster Autopilot. Nous le nommerons myAKSAutomaticCluster et utiliserons le groupe de ressources que nous venons de créer. Assurez-vous d'avoir 16 vCPUs disponibles sur l'une des tailles de VM suivantes : Standard_D4pds_v5, Standard_D4lds_v5, Standard_D4ads_v5, Standard_D4ds_v5, Standard_D4d_v5, Standard_D4d_v4, Standard_DS3_v2, Standard_DS12_v2 pour qu'AKS alloue des ressources.

* Si vous obtenez des erreurs MissingSubscriptionRegistration, revenez à l'étape 4 avec les abonnements manquants. Par exemple , The subscription is not registered to use namespace 'microsoft.insights' nécessite l'exécution de az provider register --namespace Microsoft.Insights.

Suivez la connexion interactive :

Un message demandant d'exécuter "az login" s'affiche. Vous devez exécuter cette commande et attendre.

7. Attendez qu'il soit prêt. Il faut environ 10 minutes pour le créer.

8. Configurer l'accès à la ligne de commande kubectl.

Notez que l'extension que nous avons installée active AKS Automatic.

9. Confirmez que les nœuds ont été déployés.

Vous verrez un message d'erreur interdit ; copiez l'identifiant de l'utilisateur dans le message d'erreur.

10. Ajoutez votre utilisateur au contrôle d'accès AKS.

Obtenir l'ID AKS. Copie la sortie de la commande.

Créez une attribution de rôle en utilisant l'identifiant AKS et l'identifiant principal de votre utilisateur.

11. Essayez de confirmer que les nœuds ont été déployés à nouveau.

12. Installez l'opérateur Elastic Cloud on the Kubernetes (ECK).

13. Créons une instance Elasticsearch à nœud unique avec les valeurs par défaut.

Nous avons désactivé nmap parce que la machine AKS par défaut a une valeur vm.max_map_count trop faible. Sa désactivation n'est pas recommandée pour la production, mais l'augmentation de la valeur de vm.max_map_count. Pour en savoir plus , cliquez ici.

14. Déployons également un cluster Kibana à nœud unique. Pour Kibana, nous allons ajouter un équilibreur de charge, qui nous donnera une IP externe que nous pouvons utiliser pour atteindre Kibana depuis notre appareil.

Par défaut, AKS Automatic configure l'équilibreur de charge comme étant public ; vous pouvez modifier ce comportement en définissant l'annotation des métadonnées :

service.beta.kubernetes.io/azure-load-balancer-internal: "true"

15. Vérifiez que vos pods fonctionnent.

16. Vous pouvez également lancer kubectl get elasticsearch et kubectl get kibana pour obtenir des statistiques plus spécifiques comme la version d'Elasticsearch, les nœuds et l'état de santé.

17. Accédez à vos services.

Cela vous montrera l'URL externe de Kibana sous EXTERNAL-IP. Le provisionnement de l'équilibreur de charge peut prendre quelques minutes. Copier la valeur de EXTERNAL-IP.

18. Obtenez le mot de passe Elasticsearch pour l'utilisateur 'elastic' :

19. Accédez à Kibana via votre navigateur :

a. URL : https://<EXTERNAL_IP>:5601

b. Nom d'utilisateur:elastic

c. Mot de passe:c44A295CaEt44D6xIzN6Zs5m (de l'étape précédente)

20. Lorsque vous accédez à Elastic Cloud à partir de votre navigateur, vous verrez l'écran de bienvenue.

Si vous souhaitez modifier les spécifications du cluster Elasticsearch, comme changer ou redimensionner les nœuds, vous pouvez appliquer à nouveau le manifeste YML avec les nouveaux paramètres :

Dans cet exemple, nous allons ajouter un nœud supplémentaire et modifier la RAM et la CPU. Comme vous pouvez le voir, kubectl get elasticsearch affiche maintenant 2 nœuds :

Il en va de même pour Kibana :

Nous pouvons ajuster le CPU/RAM du conteneur ainsi que l'utilisation de la mémoire de Node.js (max-old-space-size).

N'oubliez pas que les créances en volume existantes ne peuvent pas être réduites. Après avoir appliqué la mise à jour, l'opérateur effectuera les changements avec un minimum de temps d'interruption.

N'oubliez pas de supprimer la grappe lorsque vous avez terminé les tests afin d'éviter des coûts inutiles.

Conclusion

L'utilisation d'Azure AKS Automatic avec ECK fournit une solution équilibrée pour le déploiement d'Elasticsearch et de Kibana : elle réduit la complexité opérationnelle, assure une mise à l'échelle et des mises à jour automatisées, et tire parti de la flexibilité de Kubernetes. Cette approche est idéale pour les équipes qui souhaitent un processus de déploiement fiable, reproductible et maintenable sans avoir à gérer manuellement chaque détail de l'infrastructure, ce qui en fait un choix pratique pour les environnements de test et de production.

Étapes suivantes

Si vous souhaitez en savoir plus sur Kubernetes, vous pouvez consulter la documentation officielle ici :

• Elastic Cloud sur Kubernetes | Elastic Docs

• Introduction à Azure Kubernetes Service (AKS) Automatique (preview)

• AKS Automatic - Blog d'AKS Engineering

Qu'est-ce que le découpage récursif ?

Le découpage récursif parcourt une liste de sections fournies en séparant les modèles afin de diviser progressivement un document en segments plus petits jusqu'à ce qu'ils atteignent une taille maximale souhaitée.

Comment configurer le découpage récursif ?

Les valeurs configurables fournies par l'utilisateur pour le découpage récursif sont les suivantes :

• (obligatoire) max_chunk_size: Le nombre maximum de mots dans un bloc.

• L'un ou l'autre :

  • separators: Une liste de motifs de chaînes regex qui seront utilisés pour découper le document en morceaux.

  • separator_group: Une chaîne qui correspondra à une liste par défaut de séparateurs définis par Elastic à utiliser pour des types de documents spécifiques. Actuellement, markdown et plaintext sont disponibles.

Comment fonctionne le découpage récursif ?

Le processus de découpage récursif d'un document d'entrée, d'un max_chunk_size (mesuré en mots) et d'une liste de chaînes de séparation est le suivant :

1. Si le document d'entrée est déjà compris dans la taille maximale des morceaux, il renvoie un seul morceau couvrant l'ensemble du document d'entrée.

2. Découper le texte en morceaux potentiels sur la base des occurrences du séparateur. Pour chaque morceau potentiel :

   1. Si le morceau potentiel ne dépasse pas la taille maximale, il est ajouté à la liste des morceaux à renvoyer à l'utilisateur.

   2. Sinon, répétez l'étape 2, en utilisant uniquement le texte du morceau potentiel et en le séparant à l'aide du séparateur suivant dans la liste. S'il n'y a plus de séparateurs à essayer, il faut se rabattre sur le découpage en phrases.

Exemples de configuration du découpage récursif

Outre la taille des morceaux, la principale configuration du découpage récursif consiste à sélectionner les séparateurs à utiliser pour diviser vos documents. Si vous ne savez pas par où commencer, Elasticsearch propose quelques groupes de séparateurs par défaut qui peuvent être utilisés pour des cas d'utilisation courants.

Utilisation de groupes de séparation

Pour utiliser un groupe séparateur, il suffit d'indiquer le nom du groupe que vous souhaitez utiliser lors de la configuration des paramètres de regroupement. Par exemple :

Vous obtiendrez ainsi une stratégie de découpage récursif qui utilise la liste de séparateurs ["(?<!\\n)\\n\\n(?!\\n)", "(?<!\\n)\\n(?!\\n)")]. Cela fonctionne bien pour les applications génériques de texte brut, en séparant deux caractères de retour à la ligne, suivis d'un caractère de retour à la ligne.

Nous proposons également un groupe de séparateurs markdown qui utilisera la liste des séparateurs :

Cette liste de séparateurs fonctionnera bien pour les cas d'utilisation généraux de markdown, en séparant chacun des 6 niveaux d'en-tête et les caractères de coupure de section.

Lors de la création d'une ressource (point d'inférence/champ textuel sémantique), la liste des séparateurs correspondant au groupe de séparateurs du moment sera stockée dans vos configurations. Si le groupe de séparateurs est mis à jour ultérieurement, cela ne modifiera pas le comportement des ressources déjà créées.

Utilisation d'une liste de séparateurs personnalisée

Si l'un des groupes de séparateurs prédéfinis ne convient pas à votre cas d'utilisation, vous pouvez définir une liste personnalisée de séparateurs répondant à vos besoins. Notez que des expressions régulières peuvent être fournies dans la liste des séparateurs. Voici un exemple de paramètres de regroupement configurés avec des séparateurs personnalisés :

La stratégie de découpage en morceaux découpera 2 caractères de nouvelle ligne, suivis d'un caractère de nouvelle ligne, et enfin une chaîne de caractères “<my-custom-separator>”.

Un exemple de découpage récursif en action

Voyons un exemple de découpage récursif en action. Pour cet exemple, nous utiliserons les paramètres de découpage suivants avec une liste personnalisée de séparateurs qui découpent un document markdown en utilisant les deux premiers niveaux d'en-tête :

Examinons un simple document Markdown non tronqué :

Utilisons maintenant les paramètres de découpage définis ci-dessus pour découper le document en morceaux :

Remarque : la nouvelle ligne à la fin de chaque morceau (à l'exception du morceau 3) n'est pas mise en évidence, mais elle est incluse dans les limites du morceau.

Commencez dès aujourd'hui à utiliser le découpage récursif !

Pour plus d'informations sur l'utilisation de cette fonctionnalité, consultez la documentation sur la configuration des paramètres de regroupement.

En outre, ces cas d'utilisation sont généralement sensibles au temps, et passer par les étapes de développement habituelles (créer une branche de code et attendre une nouvelle version) est un processus qui prend beaucoup de temps.

Et si nous pouvions réaliser l'ensemble de ce processus par un simple appel d'API ou, mieux encore, en quelques clics dans Kibana ?

Règles d'interrogation

Elasticsearch 8.10 a introduit les règles de requête et le récupérateur de règles. Il s'agit d'outils conçus pour injecter des résultats épinglés dans les requêtes sans affecter le classement des résultats organiques sur la base de règles. Ils ne font qu'ajouter une logique d'entreprise aux résultats d'une manière simple et déclarative.

Voici quelques exemples d'utilisation courante des règles de requête :

• Mise en évidence des annonces ou des ventes promues: Afficher les articles en vente ou sponsorisés en haut de la page.

• Exclusion en fonction du contexte ou de la géolocalisation: Masquer certains éléments lorsque la réglementation locale ne permet pas de les afficher.

• Donner la priorité aux résultats clés: Veiller à ce que les recherches populaires ou fixes soient toujours en tête, quel que soit le classement organique.

Pour accéder à l'interface et interagir avec ces outils, vous devez cliquer sur le menu latéral de Kibana et aller dans Règles de requête, sous Pertinence:

Lorsque le menu des règles de requête s'affiche, cliquez sur Créer votre premier jeu de règles :

Ensuite, vous devez nommer votre jeu de règles.

Le formulaire permettant de définir chaque règle comporte trois éléments clés :

• Critères: Les conditions qui doivent être remplies pour que la règle s'applique. Par exemple, "lorsque le champ query_string contient la valeur Christmas" ou "lorsque le champ country est CO".

• Action: C'est ce que vous voulez qu'il se passe lorsque les conditions sont remplies. Il peut être épinglé (fixation d'un document dans les premiers résultats) ou exclu (masquage d'un document).

• Métadonnées: Il s'agit des champs qui accompagnent la requête lors de son exécution. Elles peuvent inclure des informations sur l'utilisateur (comme la localisation ou la langue) ainsi que des données de recherche (query_string). Il s'agit des valeurs utilisées par les critères pour décider d'appliquer ou non une règle.

Exemple : articles populaires

Imaginons que nous ayons un site de commerce électronique proposant différents articles. En vérifiant les mesures, nous remarquons que l'un des articles les plus vendus dans la catégorie des consoles est la "manette sans fil DualShock 4", en particulier lorsque les utilisateurs recherchent les mots clés "PS4" ou "PlayStation 4". Nous décidons donc de placer ce produit en tête des résultats lorsqu'un utilisateur effectue une recherche avec ces mots-clés.

Tout d'abord, nous allons indexer les documents pour chaque article à l'aide d'une requête API en bloc :

Si nous n'intervenons pas dans la requête, l'article apparaît généralement en quatrième position. Voici la requête :

Et voici les résultats

Créons une règle de requête pour modifier cela. Tout d'abord, ajoutons-le au jeu de règles comme suit :

Ou demande d'API équivalente :

Pour utiliser l'ensemble de règles dans notre requête, nous devons utiliser un type de règle de requête. Ce type de requête se compose de deux parties principales :

• match_criteria: Il s'agit des métadonnées utilisées pour la comparaison avec la requête de l'utilisateur. Dans cet exemple, le jeu de règles est activé lorsque le champ query_string a la valeur "PlayStation 4".

• requête: la requête réelle qui sera utilisée pour effectuer la recherche et obtenir les résultats organiques.

De cette façon, vous exécutez d'abord la requête organique, puis Elasticsearch applique les règles de votre ensemble de règles :

Exemple : métadonnées basées sur l'utilisateur

Une autre application intéressante des règles d'interrogation consiste à utiliser les métadonnées pour afficher des documents spécifiques sur la base d'informations contextuelles provenant de l'utilisateur ou de la page web.

Par exemple, imaginons que nous souhaitions mettre en avant des articles ou des ventes personnalisées en fonction du niveau de fidélité d'un utilisateur, représenté par une valeur numérique.

Nous pouvons le faire en intégrant ces métadonnées directement dans la requête, de sorte que les règles s'activent lorsque la valeur en question répond à certains critères.

Tout d'abord, nous allons indexer un document que seuls les utilisateurs ayant un niveau de fidélité élevé peuvent consulter :

Maintenant, créons une nouvelle règle dans le même jeu de règles pour que lorsque le niveau de fidélité est égal ou supérieur à 80, l'article apparaisse en tête des résultats.

Enregistrez la règle et le jeu de règles.

Voici la requête REST équivalente :

Désormais, lors de l'exécution d'une requête, nous devons inclure le nouveau paramètre loyalty_level dans les métadonnées. Si la condition de la règle est remplie, le nouveau document apparaît en tête des résultats.

Par exemple, lors de l'envoi d'une requête dont le niveau de fidélité est 80 :

Nous verrons le document de fidélisation en haut des résultats :

Dans le cas ci-dessous, le niveau de fidélité étant de 70, la règle n'est pas respectée et l'objet ne doit pas apparaître en haut de la liste :

Voici les résultats :

Exemple : exclusion immédiate

Supposons que notre manette sans fil DualShock 4 (ID 2) soit temporairement indisponible et ne puisse être vendue. Ainsi, au lieu de supprimer manuellement le document ou d'attendre qu'un processus de données se mette en place, l'équipe commerciale décide de le supprimer des résultats de recherche en attendant.

Nous utiliserons un processus similaire à celui que nous venons d'appliquer aux articles populaires, mais cette fois-ci, au lieu de sélectionner Épinglé, nous choisirons Exclure. Cette règle fonctionne comme une sorte de liste noire. Changez les critères en Toujours pour que l'exclusion fonctionne à chaque fois que la requête est exécutée.

La règle devrait ressembler à ceci :

Enregistrez la règle et le jeu de règles pour appliquer les modifications. Voici la requête REST équivalente :

Maintenant, lorsque nous exécutons à nouveau la requête, vous verrez que l'élément ne figure plus dans les résultats, bien que la règle préalable soit de l'épingler. En effet, les exclusions ont la priorité sur les résultats de l'épinglage.

Conclusion

Les règles de requête permettent d'ajuster très facilement la pertinence sans modifier le code. La nouvelle interface utilisateur Kibana vous permetd'effectuer ces modifications en quelques secondes, ce qui vous donne, ainsi qu'à votre équipe commerciale, un meilleur contrôle sur vos résultats de recherche.

Au-delà du commerce électronique, les règles de requête peuvent servir à de nombreux autres scénarios : mise en évidence des guides de dépannage dans les portails d'assistance, mise en évidence des documents internes clés dans les bases de connaissances, promotion des dernières nouvelles dans les sites d'information ou filtrage des offres d'emploi ou des listes de contenu expirées. Ils peuvent même appliquer des règles de conformité, par exemple en masquant les documents à diffusion restreinte en fonction du rôle de l'utilisateur ou de la région.

Nous allons utiliser Elastic Cloud Service sur AWS, qui est le service Elasticsearch géré officiel qui simplifie le déploiement et l'orchestration de tous les composants d'Elastic Stack via l'infrastructure native d'AWS.

Si vous souhaitez savoir comment installer et configurer Elasticsearch sur AWS EC2, consultez ce blog.

Qu'est-ce qu'AWS Marketplace ?

Elastic sur AWS Marketplace offre une expérience de recherche et d'analyse entièrement gérée où AWS s'occupe du provisionnement de l'infrastructure, de la sécurité et du scaling, tandis que les développeurs se concentrent sur la création d'applications de recherche. Cela permet aux équipes de déployer des clusters Elasticsearch de niveau entreprise en quelques minutes grâce à des intégrations AWS prédéfinies.

Quand utiliser Elastic sur AWS Marketplace ?

Elastic sur AWS Marketplace est parfaitement adapté aux organisations disposant d'une infrastructure AWS existante et souhaitant déployer Elasticsearch avec des services gérés, une sécurité intégrée et des intégrations AWS transparentes sans frais opérationnels supplémentaires.

Comment configurer Elastic Cloud sur AWS Marketplace

Étape 1 : Accédez à AWS Marketplace

1. Connectez-vous à AWS

• Dans la barre de recherche, recherchez AWS Marketplace

2. Dans le panneau de navigation de gauche, cliquez sur Discover products (Découvrir les produits), puis recherchez Elasticsearch

3. Cliquez sur Elastic Cloud (Elasticsearch Service)

Étape 2 : abonnez-vous au service

1. Sélectionnez purchase options (options d'achat) ou cliquez sur Try for free (Essayer gratuitement)

2. Examinez les détails des tarifs, les conditions générales et les détails d'achat.

3. Cliquez sur le bouton Subscribe (S'abonner)

4. Nous devons maintenant configurer le compte Elastic. Suivez les étapes sur AWS

a. Cliquez sur le bouton Activer l’intégration

b. Cliquez sur le bouton Sign in (Connexion) ou Create a vendor account (Créer un compte vendeur)

c. Cliquez sur le bouton Launch template (Lancer le modèle)

d. Cliquez sur le bouton Launch Software (Lancer le logiciel)

Étape 3. Configurez votre nouveau compte dans Elastic

1. Créez votre compte Elastic

2. Validez votre adresse e-mail

3. Saisissez votre nom et les informations de votre entreprise

4. Répondez à un court questionnaire Elastic

5. Sélectionnez la région dans laquelle vous souhaitez héberger Elastic Cloud. Par défaut, votre région AWS actuelle sera sélectionnée

6. Attendez qu'Elastic se déploie

7. Votre déploiement est connecté à votre abonnement AWS Marketplace

Annuler votre abonnement

Pour annuler votre abonnement

1. Accédez à la console AWS

Recherchez AWS Marketplace dans la barre de recherche. Cliquez sur AWS Marketplace

2. Cliquez sur Elastic Cloud subscription (Abonnement Elastic Cloud)

3. Cliquez sur le bouton Actions, puis sur Cancel subscription (Annuler l'abonnement)

4. Confirmez l'annulation, cliquez sur Yes puis sur le bouton cancel subscription

5. Un message de confirmation apparaîtra en haut de la page

Étapes suivantes

Démarrez votre expérience Elastic Cloud avec un essai gratuit de 7 jours comprenant un déploiement unique et trois projets Elastic Cloud (Elasticsearch Service). Connectez-vous simplement à votre compte AWS et cliquez sur "View Purchase Options" (Voir les options d'achat) pour commencer immédiatement à utiliser la plateforme Search AI d'Elastic sur Elastic Cloud (Elasticsearch Service). L'essai offre un accès complet aux solutions de recherche, de sécurité et d'observabilité sans aucun surcoût lié à la gestion de l'infrastructure.

Les systèmes distribués comme Elasticsearch peuvent être très complexes, avec de nombreux facteurs qui peuvent affecter leurs performances et leur stabilité. Les Shards font partie des concepts les plus fondamentaux d'Elasticsearch, et la compréhension de leur fonctionnement vous permettra de gérer efficacement un cluster Elasticsearch.

Cet article explique ce qu'est un serveur primaire et un serveur réplique, leur impact sur un cluster Elasticsearch et les outils qui permettent de les adapter à des besoins différents.

Comprendre les tessons

Les données contenues dans un index Elasticsearch peuvent prendre des proportions considérables. Afin de rester gérable, chaque donnée est conservée dans un index, et les index sont un index divisé en un certain nombre de morceaux. Chaque tesson Elasticsearch est un index Apache Lucene, chaque index Lucene individuel contenant un sous-ensemble des documents de l'index Elasticsearch. Le fractionnement des indices de cette manière permet de contrôler l'utilisation des ressources. Un index Apache Lucene a une limite de 2 147 483 519 (2³¹ - 129) documents.

Parfois, les indices doivent être déplacés d'un nœud à l'autre à des fins de rééquilibrage. Étant donné que ce processus peut être à la fois long et coûteux en ressources, les indices ne doivent pas devenir trop volumineux, ce qui permet de maintenir le temps de récupération à un niveau raisonnable. En outre, comme les indices sont composés de segments Lucene qui doivent être constamment fusionnés, il est important que les segments ne deviennent pas trop grands. Pour ces raisons, Elasticsearch divise les données d'index en morceaux plus petits et plus faciles à gérer, appelés shards primaires, qui peuvent être plus facilement distribués sur un certain nombre de machines. Les shards répliqués sont simplement une copie exacte d'un shard primaire correspondant et nous verrons leur fonction plus loin dans cet article.

Il est important de disposer d'un nombre adéquat de fragments pour garantir les performances. Il est donc judicieux de planifier à l'avance. Lorsque les requêtes sont exécutées en parallèle sur différents nuages, elles s'exécutent plus rapidement qu'un index composé d'un seul nuage, mais uniquement si chaque nuage est situé sur un nœud différent et s'il y a suffisamment de nœuds dans la grappe. En même temps, cependant, les ensembles consomment de la mémoire et de l'espace disque, à la fois en termes de données indexées et de métadonnées de grappe. Le fait d'avoir un trop grand nombre de shards (également appelé oversharding) peut ralentir les requêtes, les demandes d'indexation et les opérations de gestion, c'est pourquoi il est essentiel de maintenir un bon équilibre.

Le nombre de groupes primaires est défini au moment de la création de l'index pour cette instance d'index spécifique. Si vous avez besoin ultérieurement d'un nombre différent d'unités primaires, vous pouvez utiliser les API de redimensionnement :division(plus d'unitésprimaires), réduction (moins d'unités primaires) ou clonage (le même nombre d'unités primaires avec de nouveaux paramètres pour les réplicas). Ces opérations copient des segments Lucene et évitent une réindexation complète de tous les documents. Lors de la création d'un index, vous pouvez définir le nombre de shards primaires et de shards répliqués comme paramètres de l'index :

(Si vous ne spécifiez pas le nombre de shards ou de répliques, la valeur par défaut est 1, à partir d'Elasticsearch 7.0). Le nombre idéal d'unités de stockage doit être déterminé en fonction de la quantité de données contenues dans un index. En règle générale, un fonds optimal doit contenir de 10 à 50 Go de données, avec moins de 200 millions de documents par fonds. Par exemple, si vous prévoyez d'accumuler environ 300 Go de journaux d'application par jour, il serait raisonnable d'avoir environ 10 fichiers dans cet index, à condition que vous disposiez d'un nombre suffisant de nœuds pour les héberger.

Au cours de leur vie, les tessons peuvent passer par un certain nombre d'états, notamment

• Initialisation : Un état initial avant que le tesson puisse être utilisé.

• Démarré : État dans lequel le groupe de stockage est actif et peut recevoir des demandes.

• Relocalisation : Un état qui se produit lorsque les shards sont en train d'être déplacés vers un autre nœud. Cela peut s'avérer nécessaire dans certaines conditions, par exemple lorsque le nœud sur lequel ils se trouvent manque d'espace disque.

• Non assigné : État d'un tesson qui n'a pas été affecté. Une raison est fournie lorsque cela se produit, par exemple, si le nœud hébergeant le dépôt n'est plus dans le cluster (NODE_LEFT) ou en raison d'une restauration dans un index fermé (EXISTING_INDEX_RESTORED).

Pour afficher tous les shards, leur état et d'autres métadonnées, vous pouvez utiliser la requête suivante :

Pour visualiser les dépôts d'un index spécifique, vous pouvez ajouter le nom de l'index à l'URL, par exemple, sensor :

Cette commande produit une sortie, comme dans l'exemple suivant. Par défaut, les colonnes affichées comprennent le nom de l'index, le nom (i.e. ) du dépôt, s'il s'agit d'un dépôt primaire ou d'une réplique, son état, le nombre de documents, la taille sur le disque, ainsi que l'adresse IP et l'ID du nœud où se trouve le dépôt.

Comprendre les répliques

Alors que chaque nuage contient une seule copie des données, un index peut contenir plusieurs copies du nuage. Il y a donc deux types de tessons, le tesson primaire et une copie, ou réplique. Chaque réplique d'un groupe de données primaire est toujours située sur un nœud différent, ce qui garantit la haute disponibilité de vos données en cas de défaillance d'un nœud. Outre la redondance et leur rôle dans la prévention des pertes de données et des temps d'arrêt, les répliques peuvent également contribuer à améliorer les performances de recherche en permettant aux requêtes d'être traitées en parallèle avec le shard principal, et donc plus rapidement.

Il existe des différences importantes dans la manière dont se comportent les disques primaires et les disques répliques. Bien qu'ils soient tous deux capables de traiter les requêtes, les demandes d'indexation (c.-à-d. les demandes d'accès à la base de données) ne sont pas traitées. l'ajout de données à l'index) doivent d'abord passer par les disques primaires avant d'être répliqués dans les disques répliques. Comme nous l'avons vu plus haut, si un shard primaire devient indisponible, par exemple en raison d'une déconnexion de nœud ou d'une défaillance matérielle, un réplica est promu pour reprendre son rôle.

Si les répliques peuvent être utiles en cas de défaillance d'un nœud, il est important de ne pas en avoir trop, car elles consomment de la mémoire, de l'espace disque et de la puissance de calcul lors de l'indexation. Une autre différence entre les shards primaires et les réplicas est que le nombre de shards primaires ne peut pas être modifié après la création de l'index, alors que le nombre de réplicas peut être modifié dynamiquement à tout moment en mettant à jour les paramètres de l'index.

Un autre facteur à prendre en compte pour les répliques est le nombre de nœuds disponibles. Les répliques sont toujours placées sur des nœuds différents de ceux du groupe principal, car deux copies des mêmes données sur le même nœud n'offriraient aucune protection en cas de défaillance de ce nœud. Par conséquent, pour qu'un système prenne en charge n répliques, il doit y avoir au moins n + 1 nœuds dans la grappe. Par exemple, s'il y a deux nœuds dans un cluster et qu'un index est configuré avec six répliques, une seule réplique sera allouée. En revanche, un système à sept nœuds est parfaitement capable de gérer un shard primaire et six répliques.

Optimisation des grappes et des répliques

Même après la création d'un index avec le bon équilibre entre les unités primaires et les unités répliquées, celles-ci doivent être surveillées, car la dynamique autour d'un index évolue au fil du temps. Par exemple, lorsqu'il s'agit de séries chronologiques, les indices contenant des données récentes sont généralement plus actifs que les indices plus anciens. Sans réglage de ces indices, ils consommeraient tous la même quantité de ressources, malgré leurs exigences très différentes.

L'API de l'indice de reconduction peut être utilisée pour séparer les indices les plus récents des plus anciens. Il peut être configuré pour créer automatiquement un nouvel index lorsqu'un certain seuil - taille d'un index sur le disque, nombre de documents ou âge - est atteint. Cette API est également utile pour contrôler la taille des fichiers. Étant donné que le nombre de groupes ne peut pas être facilement modifié après la création de l'index, les groupes continueront d'accumuler des données si aucune condition de transfert n'est remplie. Pour les index plus anciens qui ne nécessitent que des accès peu fréquents, le rétrécissement et la fusion forcée d'un index sont deux moyens différents de réduire leur empreinte mémoire et disque. La première permet de réduire le nombre d'unités dans un index, tandis que la seconde réduit le nombre de segments Lucene et libère l'espace utilisé par les documents qui ont été supprimés.

Shards primaires et répliques comme base d'Elasticsearch

Elasticsearch s'est forgé une solide réputation en tant que plateforme distribuée de stockage, de recherche et d'analyse pour d'énormes volumes de données. Toutefois, à une telle échelle, des problèmes se posent inévitablement. C'est pourquoi il est si important et fondamental pour Elasticsearch de comprendre le fonctionnement des shards primaires et répliqués, car cela permet d'optimiser la fiabilité et les performances de la plateforme.

Il est essentiel de savoir comment ils fonctionnent et comment les optimiser pour obtenir un cluster Elasticsearch plus robuste et plus performant. Si vous rencontrez régulièrement des réponses lentes aux requêtes ou des pannes, ces connaissances peuvent être la clé pour surmonter ces obstacles.

Suivez la documentation officielle d'Elasticsearch pour en savoir plus sur les clusters, les nœuds et les shards, sur la taille des shards, sur l 'allocation des shards et sur la récupération.

Ce sujet est également disponible sous forme de cours d'introduction sur la chaîne YouTube de la communauté Elastic.

Enfin, si vous ne voulez pas vous préoccuper des nœuds, des unités de stockage ou des répliques, vous pouvez essayer Elastic Cloud Serverless. Cette offre Elastic Cloud est entièrement gérée par Elastic et automatisée pour évoluer avec votre charge de travail. Un essai gratuit peut vous aider à vous familiariser avec d'autres avantages de l'approche sans serveur.

• bg_count (background count) : Nombre de documents trouvés dans l'ensemble de données parent.

• doc_count : Nombre de documents trouvés dans l'ensemble de données de résultat

Par exemple, dans un ensemble de données sur les ventes de téléphones, nous pouvons rechercher des termes significatifs sur les ventes de l'iPhone 16 comme suit :

Ensuite, la réponse nous donne :

Houston ne figure pas parmi les 10 premières villes de l'ensemble des données, ni parmi les premières villes pour l'iPhone 16. Toutefois, l'agrégation des termes significatifs a montré que l' iPhone 16 est acheté de manière disproportionnée dans cette ville par rapport au reste des données. Voyons plus en détail les chiffres :

• Au niveau supérieur :

  • doc_count : 122 - La requête correspond à 122 documents au total

  • bg_count : 424 - Le jeu d'arrière-plan (tous les documents de vente) contient 424 documents.

• Dans le seau de Houston :

  • doc_count : 12 - Houston apparaît dans 12 des 122 résultats de la requête

  • bg_count : 14 - Houston apparaît dans 14 des 424 documents de l'ensemble de données de base.

Cela nous indique que sur 424 achats totaux, seuls 14 ont eu lieu à Houston, soit 3,3% de tous les achats. Toutefois, si nous ne prenons en compte que les ventes d'iPhone 16, nous constatons que 12 des 122 ventes ont eu lieu à Houston, soit 9,8%, 3 fois plus que dans l'ensemble de l'ensemble des données ; c'est significatif !

Voici ce que cela donne en termes de visualisation : Ventes totales par ville_région.

Nous pouvons voir qu'il y a 14 ventes à Houston, ce qui en fait la 14e ville en termes de ventes dans l'ensemble des données.

Maintenant, si nous appliquons un filtre pour ne regarder que les ventes d'iPhone 16, nous avons 12 ventes à Houston, ce qui en fait la deuxième ville avec le plus grand nombre de ventes pour ce modèle spécifique :

Comprendre l'agrégation des termes significatifs

Selon la documentation d'Elastic, les termes significatifs sont agrégation:

"(Trouve) des termes qui ont subi un changement significatif de popularité mesuré entre un ensemble de premier plan et un ensemble d'arrière-plan."

Cela signifie qu'il utilise des mesures statistiques pour comparer la fréquence d'un terme dans un sous-ensemble de données (l'ensemble de premier plan) à la fréquence du même terme dans l'ensemble de données parent (l'ensemble d'arrière-plan). De cette manière, la notation reflète la signification statistique plutôt que la fréquence d'apparition d'un terme dans les données.

Les principales différences entre une agrégation de termes significatifs et une agrégation de termes normaux sont les suivantes :

• Les termes significatifs comparent un sous-ensemble de données, tandis qu'une agrégation de termes ne fonctionne que sur l'ensemble de données résultant de la requête.

• Les résultats d'une agrégation de termes sont les termes les plus courants de l'ensemble de données, tandis que les résultats d'une agrégation de termes significatifs ignorent les termes courants pour trouver ce qui rend l'ensemble de données unique.

• Les termes significatifs peuvent avoir un impact plus important sur les performances, étant donné qu'ils doivent extraire des données du disque plutôt que de la mémoire, comme le fait l'agrégation des termes.

Application pratique (analyse du comportement du consommateur)

Préparation des données pour l'analyse

Pour cette analyse, nous avons généré un ensemble de données synthétiques sur les ventes de téléphones, comprenant le prix, les caractéristiques du téléphone, les données démographiques de l'acheteur et les commentaires. Nous avons également généré des embeddings à partir des commentaires de l'utilisateur afin de pouvoir lancer une requête sémantique ultérieurement. Nous avons utilisé le modèle multilingue e5 small, disponible prêt à l'emploi sur Elasticsearch.

Pour utiliser ce jeu de données sur Elasticsearch :

1. Téléchargez le fichier CSV (téléchargeable ici) à l'aide de la fonction Kibana Upload data files.

2. Créez un champ sémantique, comme indiqué dans ce blog, appelé "embedding", qui utilise le champ sémantique multilingual-e5-small model

3. Terminez l'importation en conservant le type de champ par défaut (mot-clé pour chaque champ à l'exception de purchase_date et user_feedback)). Veillez à ajouter le nom de l'index phone_sales_analysis pour pouvoir exécuter les requêtes présentées ici telles quelles.

L'objectif principal de cette analyse est de découvrir "ce qui différencie les acheteurs de l'iPhone 16 des autres segments de la populationet d'obtenir une segmentation des acheteurs à des fins de marketing. 

Il s'agit d'un exemple de document provenant de l'ensemble de données :

Comprendre les modèles démographiques

Ici, nous allons effectuer une analyse sur la population générale et la comparer aux résultats intéressants des agrégations de termes significatifs pour les utilisateurs de l'iPhone 16.

Modèles normaux

Pour comprendre les habitudes d'achat, nous pouvons regrouper les données de tous les documents dans différents domaines. Pour simplifier, nous nous concentrerons sur l'étude des professions des personnes qui ont acheté un téléphone. Nous pouvons le faire en envoyant une requête à Elasticsearch.

Cela nous indique que les principales professions de l'ensemble de données (par nombre d'enregistrements) sont les suivantes :

Les habitudes des utilisateurs de l'iPhone 16

Pour comprendre ce qui différencie les personnes qui ont acheté un iPhone 16, exécutons une agrégation de termes sur le même champ avec un filtre pour trouver ces personnes dans la requête, comme ceci :

Ainsi, pour les utilisateurs de l'iPhone 16, les principales professions sont les suivantes :

Nous pouvons constater que les utilisateurs de l'iPhone 16 ont des habitudes d'occupation différentes de celles des utilisateurs d'autres modèles de téléphone. Utilisons Kibana pour visualiser facilement les résultats :

Dans ce graphique, nous pouvons voir que la tendance pour l'iPhone 16 est différente de la tendance de la population entière.

Nous pouvons sauter toute cette analyse pour voir ce qui différencie les utilisateurs de l'iPhone 16 de la population générale en effectuant une agrégation de termes significatifs :

En résumé, nous obtenons cette réponse :

Valeurs des professions pour l'iPhone 16

doc_count

bg_count

occupation_distribution (niveau supérieur)

122

424

Médical & Seau pour les soins de santé

45

57

La réponse suggère clairement que les utilisateurs de l'iPhone 16 ont un problème (significatif !) peu commun. le nombre de personnes travaillant dans le domaine médical & par rapport à la population générale. Voyons ce que signifient les chiffres de la réponse :

• Au niveau supérieur :

  • doc_count : 122 - La requête correspond à 122 documents au total

  • bg_count : 424 - Le jeu d'arrière-plan (tous les documents de vente) contient 424 documents.

• Dans le secteur médical & Soins de santé :

  • doc_count : 45 - "Medical & Healthcare" apparaît dans 45 des 122 résultats de la requête

  • bg_count : 57 - "Medical & Healthcare" apparaît dans 57 des 424 documents totaux de l'ensemble de données d'arrière-plan.

Sur les 424 acheteurs, 57 travaillent dans le domaine médical & - soit 13,44%. Mais si l'on considère les acheteurs de l'iPhone 16, 45 sur 122 travaillent dans le domaine médical & - soit 36,88%. Cela signifie que nous avons deux fois plus de chances de trouver une personne travaillant dans le domaine médical & healthcare parmi les utilisateurs de l'iPhone 16 !

Nous pouvons appliquer cette même analyse à d'autres champs (âge, localisation, tranche de revenus, etc.) pour obtenir plus d'informations sur ce qui rend les utilisateurs de l'iPhone 16 uniques. 

Segmentation des consommateurs

Nous pouvons utiliser l'agrégation des termes significatifs pour extraire des informations sur les relations entre les produits, les catégories et les segments de clientèle. Pour ce faire, nous construisons une agrégation parente pour la catégorie que nous souhaitons explorer. Nous utilisons également une sous-agrégation des termes significatifs et des termes normaux pour trouver des informations intéressantes sur cette catégorie et les comparer à ce qu'utilisent la plupart des personnes dans cette profession.

Voyons, par exemple, ce que préfèrent les gens dans certains domaines d'activité :

1. Pour rendre l'analyse plus claire, limitons notre recherche à trois domaines de travail : ["Administratif & Support", "Technologie & Données", "Médical & Soins de santé"]

2. En ce qui concerne les agrégations, nous commençons par une agrégation des termes par profession

3. Ajoutez une sous-agrégation : termes par modèle de téléphone - pour savoir quels modèles les utilisateurs travaillant dans chaque domaine achètent.

4. Ajoutez une deuxième sous-agrégation : les termes significatifs par modèle de téléphone - pour trouver les modèles spéciaux dans chaque domaine de travail.

Décortiquons les résultats de l'agrégation :

Profession: Soutien administratif &

Agrégation de termes

Agrégation des termes significatifs

Ce tableau permet de déduire qu'il n'y a pas de différences significatives entre l'évolution de cette profession et celle de l'ensemble de la population.

Profession: Technologie & Données

Agrégation de termes

Agrégation des termes significatifs

Total des documents : 424

Documents dans cette profession : 71

modèle de téléphone

doc_count (ce modèle dans cette profession)

bg_count (ce modèle figure dans tous les documents)

% dans tous les documents

% dans cette profession

Google Pixel 8

12

22

5.19%

16.90%

OnePlus 11

9

14

3,30 %

12.68%

OnePlus 12 Pro

3

3

0,71 %

4.23%

Google Pixel 8 Pro

9

21

4.95%

12.68%

Rien Téléphone 2

5

8

1.89%

7.04%

Samsung Galaxy Z Fold5

4

6

1.42%

5.63%

OnePlus 12

8

20

4.72%

11,27 %

Profession: Médical : & Soins de santé

Agrégation de termes

Agrégation des termes significatifs

Total des documents : 424

Documents dans cette profession : 57

modèle de téléphone

doc_count (ce modèle dans cette profession)

bg_count (ce modèle figure dans tous les documents)

% dans tous les documents

% dans cette profession

iPhone 16

45

122

28.77%

78.95%

iPhone 15 Pro Max

3

13

3,07 %

5.26%

iPhone 15

7

40

9.43%

12.28%

Voyons ce que ces données nous apprennent :

• Medical & Les professionnels de la santé préfèrent l'iPhone 16 et sont très enclins à utiliser les téléphones Apple en général.

• Technologie & Les professionnels des données préfèrent les téléphones Android haut de gamme, mais n'utilisent pas nécessairement la marque Samsung. Dans cette catégorie, les iPhones ont également le vent en poupe.

• Les professionnels de l'assistance administrative & préfèrent les téléphones Samsung et Google, mais n'ont pas de tendance forte et unique.

Agrégation de termes significatifs et recherche hybride

La recherche hybride combine la recherche textuelle et les résultats sémantiques pour offrir une meilleure expérience de recherche. Dans ce contexte, une agrégation significative de termes peut fournir des indications sur les résultats d'une recherche contextuelle en répondant à la question suivante : "Qu'est-ce que cet ensemble de données a de particulier par rapport à l'ensemble des documents ? Qu'est-ce que cet ensemble de données a de particulier par rapport à tous les documents ?Pour illustrer cette fonctionnalité, voyons quels modèles sont surreprésentés lorsque les utilisateurs parlent de bonnes performances :

• Construisons une requête sémantique dans laquelle nous trouvons les meilleurs commentaires d'utilisateurs les plus proches de l'entrée "bonne performance" par rapport à l'intégration des champs.

• Nous utiliserons également une recherche textuelle avec les mêmes termes sur le champ de texte user_feedback

• Nous ajouterons également une requête de termes significatifs pour trouver des modèles de téléphone qui peuvent être trouvés plus fréquemment parmi ces résultats que dans l'ensemble des données.

Examinons un exemple de documents correspondants :

Voici la réponse que nous recevons :

Cela nous indique que si un iPhone 15 est rencontré 40 fois sur un total de 424 documents (9,4% des documents), il peut être trouvé 5 fois dans les 20 documents qui correspondent à la recherche sémantique "bonne performance" (25% des documents). Nous pouvons donc tirer une conclusion : un iPhone 15 a 2,7 fois plus de chances d'être trouvé lorsqu'on parle de bonnes performances que par hasard.

Conclusion

L'agrégation des termes significatifs permet de découvrir des détails uniques d'un ensemble de données en le comparant à l'univers des documents. Cela peut révéler des relations inattendues dans nos données, allant au-delà du nombre d'occurrences. Nous pouvons appliquer des termes significatifs dans divers cas d'utilisation qui permettent des fonctionnalités très intéressantes, par exemple :

• Trouvez des modèles lorsque vous travaillez sur la détection des fraudes - identifiez les transactions courantes pour les cartes de crédit volées.

• Informations sur la qualité de la marque à partir des avis des utilisateurs - détectez une marque dont le nombre d'avis négatifs est disproportionné.

• Repérer les documents mal classés - repérer les documents qui appartiennent à une catégorie (filtre de termes) et qui utilisent des mots peu courants de la catégorie dans une description (agrégation de termes significatifs).

Pour Elasticsearch, nous allons utiliser Elastic Cloud on Kubernetes (ECK), qui est l’opérateur Kubernetes officiel d’Elasticsearch et qui simplifie l’orchestration des déploiements Kubernetes pour tous les composants Elastic Stack.

Pour en savoir plus sur la façon de déployer des clusters Elasticsearch sur différentes infrastructures GCP, vous pouvez consulter nos articles de prise en main pour Google Cloud Compute et Google Cloud Marketplace.

Effort de déploiement d'Elasticsearch

Qu'est-ce que GKE Autopilot ?

Google Kubernetes Engine (GKE) Autopilot offre une expérience Kubernetes entièrement gérée où Google prend en charge la configuration du cluster, la gestion des nœuds, la sécurité et la mise à l'échelle, tandis que les développeurs se concentrent sur le déploiement des applications, permettant aux équipes de passer du code à la production en quelques minutes grâce à de bonnes pratiques intégrées.

Quand utiliser l’ECK dans Google Cloud ?

Elastic Cloud on Kubernetes (ECK) est parfaitement adapté aux entreprises qui disposent d'une infrastructure Kubernetes existante et souhaitent déployer Elasticsearch avec des fonctionnalités avancées telles que des rôles de nœuds dédiés, la haute disponibilité et l'automatisation.

Comment configurer ECK dans Google Cloud ?

1. Connectez-vous à la Google Cloud Console.

2. En haut à droite, cliquezsur le bouton Cloud Shell pour accéder à la console, et déployez le cluster GKE à partir de là. Sinon, vous pouvez utiliser la CLI gcloud.

N'oubliez pas de remplacer l'identifiant du projet par le vôtre pendant le tutoriel.

3. Activez l'API Google Kubernetes Engine.

Cliquez sur Suivant.

L'API Kubernetes Engine devrait désormais apparaître comme activée lorsque vous recherchez cette API.

4. Dans Cloud Shell, créez un cluster Autopilot. Nous le nommerons autopilot-cluster-1, et remplacerons également autopilot-test par l'identifiant de votre projet.

5. Attendez qu le cluster soit prêt. La création prend environ 10 minutes.

Un message de confirmation s’affiche après avoir correctement configuré le cluster.

6. Configurez l'accès à la ligne de commande kubectl.

Vous devriez voir :

Entrée kubeconfig générée pour autopilot-cluster-1

7. Installez l’opérateur Elastic Cloud on Kubernetes (ECK).

8. Créons une instance Elasticsearch à nœud unique avec les valeurs par défaut.

Si vous souhaitez consulter quelques recettes pour différentes configurations, suivez ce lien.

Gardez à l’esprit que si vous ne spécifiez pas de storageClass, ECK utilisera celui défini par défaut, qui, pour GKE, est standard-rwo et qui utilise le disque persistant Compute Engine CSI Driver, et créera un volume de 1 Go avec celui-ci.

Nous avons désactivé nmap, car la machine GKE par défaut a une valeur de vm.max_map_count trop basse. Il est recommandé de ne pas la désactiver pour la production, mais d'augmenter la valeur de vm.max_map_count. Vous pouvez en savoir plus sur la façon de procéder ici.

9. Déployons également un cluster Kibana à nœud unique. Pour Kibana, nous ajouterons un équilibreur de charge qui nous donnera une adresse IP externe que nous pourrons utiliser pour accéder à Kibana depuis notre appareil.

Notez l'annotation :

cloud.google.com/l4-rbs: "enabled"

Cette adresse est très importante car elle indique à Autopilot de fournir un équilibreur de charge accessible au public. Si l'adresse IP n'est pas définie, l'équilibreur de charge sera interne.

10. Vérifiez que vos pods sont en cours d'exécution.

11. Vous pouvez également run kubectl get elasticsearch et kubectl get kibana pour des statistiques plus spécifiques, telles que la version d'Elasticsearch, les nœuds et l'état d'intégrité.

12. Accédez à vos services.

Cela vous indiquera l'URL externe de Kibana sous EXTERNAL-IP. Le provisionnement de l'équilibreur de charge prend quelques minutes. Copiez la valeur de EXTERNAL-IP.

13. Obtenez le mot de passe Elasticsearch pour l’utilisateur "elastic" :

14. Accédez à Kibana depuis votre navigateur :

• URL : https://<EXTERNAL_IP>:5601

• Nom d'utilisateur:elastic

• Mot de passe : 28Pao50lr2GpyguX470L2uj5 (de l’étape précédente)

15. En accédant depuis votre navigateur, l'écran de bienvenue apparaît.

Si vous souhaitez modifier les spécifications du cluster Elasticsearch, comme modifier ou redimensionner les nœuds, vous pouvez réappliquer le fichier manifeste yml avec les nouveaux paramètres :

Dans cet exemple, nous allons ajouter un nœud supplémentaire et modifier la mémoire vive et le processeur. Comme vous pouvez le voir, kubectl get elasticsearch affiche maintenant 2 nœuds :

Il en va de même pour Kibana :

Nous pouvons ajuster le processeur/la RAM du conteneur ainsi que l'utilisation de la mémoire Node.js (max-old-space-size).

N'oubliez pas que les revendications de volume existantes ne peuvent pas être réduites. Après avoir appliqué la mise à jour, l'opérateur effectuera les modifications avec un temps de perturbation minimal.

N’oubliez pas de supprimer le cluster une fois les tests terminés pour éviter des coûts inutiles.

Étapes suivantes

Si vous souhaitez en savoir plus sur Kubernetes et Google Kubernetes Engine, consultez ces articles :

• Elastic Cloud sur Kubernetes | Elastic Docs

• Présentation de GKE Autopilot | Blog Google Cloud

• Aperçu d'Autopilot | Google Kubernetes Engine (GKE)

Nous ferons le point :

• Meilleures pratiques de production

  • Gestion des erreurs

  • Tests

• Environnements sans serveur

  • Exécuter le client sur Elastic Serverless

  • Exécution du client dans un environnement de services fonctionnels (function-as-a-service)

Vous pouvez consulter le code source avec les exemples ici.

Meilleures pratiques de production

Gestion des erreurs dans Elasticsearch

Une caractéristique utile du client Elasticsearch dans Node.js est qu'il expose des objets pour les erreurs possibles dans Elasticsearch afin que vous puissiez les valider et les traiter de différentes manières.

Pour les voir tous, cliquez ici : 

Revenons à l'exemple de la recherche et traitons certaines des erreurs possibles :

ResponseError en particulier, se produit lorsque la réponse est 4xx ou 5xx, ce qui signifie que la demande est incorrecte ou que le serveur n'est pas disponible.

Nous pouvons tester ce type d'erreur en générant des requêtes erronées, par exemple en essayant d'effectuer une recherche de terme sur un champ de type texte :

Erreur par défaut :

Erreur personnalisée :

Nous pouvons également capturer et traiter chaque type d'erreur d'une certaine manière. Par exemple, nous pouvons ajouter une logique de réessai dans un site TimeoutError.

Tests

Les tests sont essentiels pour garantir la stabilité de l'application. Pour tester le code d'une manière isolée d'Elasticsearch, nous pouvons utiliser la bibliothèque elasticsearch-js-mock lors de la création de notre cluster.

Cette bibliothèque nous permet d'instancier un client qui est très similaire au vrai client mais qui répondra à notre configuration en remplaçant seulement la couche HTTP du client par une couche fictive tout en gardant le reste identique à l'original.

Nous installerons la bibliothèque mocks et AVA pour les tests automatisés.

npm install @elastic/elasticsearch-mock

npm install --save-dev ava

Nous allons configurer le fichier package.json pour exécuter les tests. Veillez à ce qu'il en soit ainsi :

Créons maintenant un fichier test.js et installons notre client fictif :

Maintenant, ajoutez un simulacre de recherche sémantique :

Nous pouvons maintenant créer un test pour notre code, en nous assurant que la partie Elasticsearch renvoie toujours les mêmes résultats :

Exécutons les tests.

npm run test

C'est fait ! Désormais, nous pouvons tester notre application en nous concentrant à 100 % sur le code et non sur des facteurs externes.

Environnements sans serveur

Exécution du client avec Elastic Serverless

Nous avons abordé l'exécution d'Elasticsearch sur le Cloud ou sur site ; cependant, le client Node.js prend également en charge les connexions à Elastic Cloud Serverless.

Elastic Cloud Serverless vous permet de créer un projet dans lequel vous n'avez pas besoin de vous préoccuper de l'infrastructure puisqu'Elastic s'en charge en interne, et vous n'avez qu'à vous préoccuper des données que vous souhaitez indexer et de la durée pendant laquelle vous souhaitez y avoir accès.

Du point de vue de l'utilisation, Serverless découple le calcul du stockage, offrant des fonctionnalités d'autoscaling pour la recherche et l'indexation. Cela vous permet de n'augmenter que les ressources dont vous avez réellement besoin.

Le client effectue les adaptations suivantes pour se connecter à Serverless :

• Désactive le sniffing et ignore toutes les options liées au sniffing.

• Ignore tous les nœuds passés dans la configuration sauf le premier, et ignore toutes les options de filtrage et de sélection des nœuds.

• Active la compression et `TLSv1_2_method` (identique à la configuration pour Elastic Cloud)

• Ajoute un en-tête HTTP `elastic-api-version` à toutes les requêtes

• Utilise `CloudConnectionPool` par défaut au lieu de `WeightedConnectionPool`.

• Désactive les en-têtes `content-type` et `accept` en faveur des types MIME standard.

Pour connecter votre projet serverless, vous devez utiliser le paramètre serverMode : serverless.

Exécution du client sur une plateforme FaaS (Function-as-a-Service)

Dans l'exemple, nous avons utilisé un serveur Node.js, mais vous pouvez également vous connecter en utilisant un environnement de fonction en tant que service avec des fonctions telles que AWS lambda, GCP Run, etc.

Un autre exemple consiste à se connecter à des services comme Vercel, qui est également sans serveur. Vous pouvez consulter cet exemple complet de la manière de procéder, mais la partie la plus pertinente du point de terminaison de la recherche ressemble à ceci :

Ce point d'accès se trouve dans le dossier /api et est exécuté du côté du serveur, de sorte que le client ne contrôle que le paramètre "text" qui correspond au terme de la recherche.

L'utilisation de la fonction en tant que service implique que, contrairement à un serveur fonctionnant 24 heures sur 24 et 7 jours sur 7, les fonctions ne font appel qu'à la machine qui exécute la fonction et, une fois celle-ci terminée, la machine passe en mode repos afin de consommer moins de ressources.

Cette configuration peut être pratique si l'application ne reçoit pas trop de demandes ; dans le cas contraire, les coûts peuvent être élevés. Vous devez également tenir compte du cycle de vie des fonctions et des durées d'exécution (qui ne peuvent être que de quelques secondes dans certains cas).

Conclusion

Dans cet article, nous avons appris à gérer les erreurs, ce qui est crucial dans les environnements de production. Nous avons également abordé le test de notre application en simulant le service Elasticsearch, ce qui permet d'obtenir des tests fiables quel que soit l'état du cluster et de se concentrer sur notre code.

Enfin, nous avons montré comment mettre en place une pile entièrement sans serveur en provisionnant à la fois Elastic Cloud Serverless et une application Vercel.

Historique des filigranes

Il existe différents seuils "en filigrane" sur votre cluster Elasticsearch qui vous aident à suivre l'espace disque disponible. Lorsque le disque d'un nœud se remplit, le premier seuil à être franchi est le "filigrane de disque faible". Le deuxième seuil sera alors le "seuil de filigrane de disque élevé". Enfin, le "stade de l'inondation du disque" sera atteint. Une fois ce seuil dépassé, le cluster bloque l'écriture dans TOUS les index qui ont un shard (primaire ou réplique) sur le nœud qui a passé le filigrane. Les lectures (recherches) restent possibles.

Comment prévenir et gérer les cas où le disque est trop plein (surutilisation) ?

Il existe plusieurs méthodes pour gérer les cas où le disque Elasticsearch est trop plein :

1. Supprimer les anciennes données : En général, les données ne doivent pas être conservées indéfiniment. L'un des moyens de prévenir et de résoudre le problème des disques trop pleins est de veiller à ce que les données atteignant un certain âge soient archivées et supprimées de manière fiable. L'un des moyens d'y parvenir est d'utiliser l'ILM.

2. Augmenter la capacité de stockage : Si vous ne pouvez pas supprimer les données, vous pouvez ajouter des nœuds de données supplémentaires ou augmenter la taille des disques afin de conserver toutes les données sans nuire aux performances. Si vous devez ajouter de la capacité de stockage à la grappe, vous devez déterminer si vous devez ajouter uniquement de la capacité de stockage, ou à la fois de la capacité de stockage et des ressources RAM et CPU en proportion (voir la section sur le rapport entre la taille du disque, la RAM et le CPU ci-dessous).

Comment ajouter de la capacité de stockage à votre cluster Elasticsearch ?

1. Augmentez le nombre de nœuds de données : N'oubliez pas que les nouveaux nœuds doivent être de la même taille que les nœuds existants et de la même version d'Elasticsearch.

2. Augmenter la taille des nœuds existants : Dans les environnements en nuage, il est généralement facile d'augmenter la taille du disque et la RAM/CPU sur les nœuds existants.

3. Augmentez uniquement la taille du disque : Dans les environnements en nuage, il est souvent relativement facile d'augmenter la taille du disque.

4. Instantané et restauration: Si vous souhaitez que les anciennes données soient récupérées sur demande dans le cadre d'un processus automatisé à partir des sauvegardes, vous pouvez prendre des clichés des anciens index, les supprimer et restaurer temporairement les données sur demande à partir des clichés. 

5. Réduire le nombre de répliques par groupe : Une autre option pour réduire les données consiste à réduire le nombre de répliques de chaque groupe. Pour des raisons de haute disponibilité, il est préférable d'avoir une réplique par bloc de données, mais lorsque les données vieillissent, il est possible de se passer de répliques. Cela peut généralement fonctionner si les données sont persistantes ou si vous disposez d'une sauvegarde à restaurer en cas de besoin.

6. Créer des alertes : Afin d'éviter que les disques ne se remplissent à l'avenir et d'agir de manière proactive, vous devriez créer des alertes basées sur l'utilisation du disque qui vous préviendront lorsque le disque commencera à se remplir. 

Comment prévenir et traiter les cas où la capacité du disque est sous-utilisée ?

Si la capacité de votre disque est sous-utilisée, il existe plusieurs options pour réduire le volume de stockage de votre cluster.

Comment réduire le volume de stockage d'un cluster Elasticsearch ?

Il existe plusieurs méthodes pour réduire le volume de stockage d'un cluster.

1. Réduire le nombre de nœuds de données

Si vous souhaitez réduire le stockage des données et réduire les ressources RAM et CPU dans la même proportion, il s'agit de la stratégie la plus simple. Le déclassement des nœuds inutiles devrait permettre de réaliser les économies les plus importantes.

Avant de mettre le nœud hors service, vous devez.. :

• Assurez-vous que le nœud à mettre hors service n'est pas nécessaire en tant que nœud MASTER. Vous devez toujours avoir au moins trois nœuds ayant le rôle de nœud MASTER.

• Migrer les blocs de données hors du nœud à mettre hors service.

2. Remplacer les nœuds existants par des nœuds plus petits

Si vous ne pouvez pas réduire davantage le nombre de nœuds (en général, 3 est une configuration minimale), vous pouvez alors réduire la taille des nœuds existants. Il est conseillé de veiller à ce que tous les nœuds de données aient la même mémoire RAM et la même taille de disque, étant donné que l'équilibre des ensembles est basé sur le nombre d'ensembles par nœud.

La procédure serait la suivante :

• Ajouter de nouveaux nœuds plus petits à la grappe

• Faire migrer les shards à l'écart des nœuds à déclasser

• Arrêter les anciens nœuds

3. Réduire la taille des disques sur les nœuds

Si vous souhaitez uniquement réduire la taille des disques sur les nœuds sans modifier la mémoire vive ou l'unité centrale de la grappe, vous pouvez réduire la taille des disques pour chaque nœud. La réduction de la taille du disque sur un nœud Elasticsearch n'est pas un processus trivial.

La manière la plus simple de le faire est généralement d'effectuer les opérations suivantes :

• Migrations de shards depuis le nœud

• Arrêter le nœud

• Monter un nouveau volume de données sur le nœud avec la taille appropriée

• Copier toutes les données de l'ancien volume de disque vers le nouveau volume

• Détacher l'ancien volume A

• Démarrer le nœud et migrer les unités de stockage vers le nœud

Pour ce faire, vous devez disposer d'une capacité suffisante sur les autres nœuds pour stocker temporairement les fragments supplémentaires du nœud au cours de ce processus. Dans de nombreux cas, le coût de la gestion de ce processus peut dépasser les économies potentielles en termes d'utilisation du disque. Pour cette raison, il peut être plus simple de remplacer le nœud par un nouveau nœud ayant la taille de disque souhaitée (voir "Remplacer les nœuds existants par des nœuds plus petits" ci-dessus).

Lorsque vous payez pour des ressources inutiles, il est évident que vous pouvez réduire les coûts en optimisant l'utilisation de vos ressources.

La relation entre la taille du disque, la mémoire vive et le processeur

Le rapport idéal entre la capacité des disques et la mémoire vive dans votre cluster dépend de votre cas d'utilisation particulier. C'est pourquoi, lorsque vous envisagez de modifier votre capacité de stockage, vous devez également vous demander si vos ratios actuels Disque/RAM/CPU sont bien équilibrés et si, par conséquent, vous devez également ajouter/réduire la RAM/CPU dans les mêmes proportions.

Les besoins en RAM et en CPU dépendent du volume de l'activité d'indexation, du nombre et du type de requêtes, ainsi que de la quantité de données recherchées et agrégées. Elle est souvent proportionnelle à la quantité de données stockées sur la grappe, et doit donc également être liée à la taille du disque.

Le rapport entre la capacité du disque et la mémoire vive peut varier en fonction du cas d'utilisation. Voir quelques exemples ici :

Activité de l'indice

Conservation

Activité de recherche

Capacité du disque

RAM

Application de recherche d'entreprise

Ingestion modérée de billes

Longues

Lumière

2TB

32GB

Surveillance des applications

Ingestion intensive de bois

Court

Lumière

1TB

32GB

Commerce électronique

Indexation des données légères

Indéfinie

Lourd

500GB

32GB

N'oubliez pas que la modification de la configuration des machines des nœuds doit être effectuée avec précaution, car elle peut entraîner l'arrêt du nœud et vous devez veiller à ce que les fragments ne commencent pas à migrer vers vos autres nœuds déjà surchargés.

Dans cette première partie, nous passerons en revue

• Environnement

  • Frontend, backend ou serverless ?

  • Connexion du client

• Indexation des documents

  • Client Elasticsearch

  • Correspondances sémantiques

  • Aide en vrac

• Recherche de données

  • Requête lexicale

  • Requête sémantique

  • Requête hybride

Vous pouvez consulter le code source avec les exemples ici.

Qu'est-ce que le client Elasticsearch Node.js ?

Le client Elasticsearch Node.js est une bibliothèque JavaScript qui transpose les appels HTTP REST de l'API Elasticsearch en JavaScript. Il est ainsi plus facile à manipuler et dispose d'assistants qui simplifient les tâches telles que l'indexation de documents par lots.

Environnement

Frontend, backend ou serverless ?

Pour créer notre application de recherche à l'aide du client JavaScript, nous avons besoin d'au moins deux composants : un cluster Elasticsearch et un moteur d'exécution JavaScript pour exécuter le client.

Le client JavaScript prend en charge toutes les solutions Elasticsearch (Cloud, on-prem et Serverless), et il n'y a pas de différences majeures entre elles puisque le client gère toutes les variations en interne, vous n'avez donc pas à vous soucier de savoir laquelle utiliser.

Le moteur d'exécution JavaScript doit toutefois être exécuté à partir du serveur et non directement à partir du navigateur.

En effet, en appelant Elasticsearch depuis le navigateur, l'utilisateur peut obtenir des informations sensibles telles que la clé API du cluster, l'hôte ou la requête elle-même. Elasticsearch recommande de ne jamais exposer le cluster directement à l'internet et d'utiliser une couche intermédiaire qui abstrait toutes ces informations de sorte que l'utilisateur ne puisse voir que les paramètres. Pour en savoir plus sur ce sujet , cliquez ici.

Nous suggérons d'utiliser un schéma comme celui-ci :

Dans ce cas, le client n'envoie que les termes de recherche et une clé d'authentification pour votre serveur, tandis que votre serveur contrôle totalement la requête et la communication avec Elasticsearch.

Connexion du client

Commencez par créer une clé API en suivant ces étapes.

En suivant l'exemple précédent, nous allons créer un simple serveur Express, et nous y connecter en utilisant un client depuis un serveur Node.JS.

Nous allons initialiser le projet avec NPM et installer le client Elasticsearch et Express. Cette dernière est une bibliothèque qui permet d'activer des serveurs dans Node.js. En utilisant Express, nous pouvons interagir avec notre backend via HTTP.

Initialisons le projet :

npm init -y

Installer les dépendances :

npm install @elastic/elasticsearch express split2 dotenv

Laissez-moi vous expliquer :

• @elastic/elasticsearch: C'est le client officiel Node.js

• express: Il nous permettra de faire tourner un serveur nodejs léger pour exposer Elasticsearch.

• split2: divise les lignes de texte en un flux. Utile pour traiter nos fichiers ndjson une ligne à la fois

• dotenv: Permet de gérer les variables d'environnement à l'aide d'un fichier .env fichier

Créer un fichier .env à la racine du projet et ajoutez les lignes suivantes :

Ainsi, nous pouvons importer ces variables à l'aide du paquetage dotenv.

Créer un fichier server.js:

Ce code met en place un serveur Express.js de base qui écoute sur le port 3000 et se connecte à un cluster Elasticsearch en utilisant une clé API pour l'authentification. Il comprend un point d'extrémité /ping qui, lorsqu'on y accède par une requête GET, interroge le cluster Elasticsearch pour obtenir des informations de base à l'aide de la méthode .info() du client Elasticsearch. 

Si la requête aboutit, elle renvoie les informations sur le cluster au format JSON ; dans le cas contraire, elle renvoie un message d'erreur. Le serveur utilise également un intergiciel d'analyseur de corps pour traiter les corps de requête JSON.

Exécutez le fichier pour lancer le serveur :

node server.js

La réponse devrait ressembler à ceci :

Et maintenant, consultons le point de terminaison /ping pour vérifier l'état de notre cluster Elasticsearch.

Indexation des documents

Une fois connectés, nous pouvons indexer les documents à l'aide de mappings tels que semantic_text pour la recherche sémantique et text pour les requêtes en texte intégral. Avec ces deux types de champs, nous pouvons également effectuer une recherche hybride.

Nous allons créer un nouveau fichier load.js pour générer les correspondances et télécharger les documents.

Client Elasticsearch

Nous devons d'abord instancier et authentifier le client :

Correspondances sémantiques

Nous allons créer un index contenant des données sur un hôpital vétérinaire. Nous stockons les informations concernant le propriétaire, l'animal et les détails de la visite.

Les données sur lesquelles nous voulons effectuer une recherche en texte intégral, telles que les noms et les descriptions, seront stockées sous forme de texte. Les données des catégories, telles que l'espèce ou la race de l'animal, seront stockées sous forme de mots-clés.

En outre, nous copierons les valeurs de tous les champs dans un champ semantic_text afin de pouvoir effectuer une recherche sémantique sur ces informations également.

Aide en vrac

Un autre avantage du client est qu'il est possible d'utiliser l'assistant de masse pour indexer par lots. L'assistant de masse nous permet de gérer facilement des choses comme la concurrence, les tentatives, et ce qu'il faut faire avec chaque document qui passe par la fonction et qui réussit ou échoue.

L'une des caractéristiques intéressantes de cette aide est qu'elle permet de travailler avec des flux. Cette fonction vous permet d'envoyer un fichier ligne par ligne au lieu de stocker le fichier complet dans la mémoire et de l'envoyer à Elasticsearch en une seule fois.

Pour télécharger les données vers Elasticsearch, créez un fichier appelé data.ndjson à la racine du projet et ajoutez les informations ci-dessous (vous pouvez également télécharger le fichier avec le jeu de données à partir d'ici) :

Nous utilisons split2 pour streamer les lignes de fichiers pendant que l'assistant bulk les envoie à Elasticsearch.

Le code ci-dessus lit un fichier .ndjson ligne par ligne et indexe en bloc chaque objet JSON dans un index Elasticsearch spécifié à l'aide de la méthode helpers.bulk. Il diffuse le fichier en utilisant createReadStream et split2, met en place des métadonnées d'indexation pour chaque document et enregistre tous les documents qui ne sont pas traités. Une fois l'opération terminée, il enregistre le nombre d'éléments indexés avec succès.

En lieu et place de la fonction indexData, vous pouvez télécharger le fichier directement via l'interface utilisateur à l'aide de Kibana et utiliser l'interface utilisateur de téléchargement des fichiers de données.

Nous exécutons le fichier pour télécharger les documents vers notre cluster Elasticsearch.

node load.js

Recherche de données dans Elasticsearch

En revenant à notre fichier server.js, nous allons créer différents points de terminaison pour effectuer une recherche lexicale, sémantique ou hybride.

En résumé, ces types de recherche ne s'excluent pas mutuellement, mais dépendent du type de question à laquelle vous devez répondre.

Type de requête

Cas d'utilisation

Exemple de question

Requête lexicale

Les mots ou racines de mots de la question sont susceptibles d'apparaître dans les documents de l'index. Similitude des jetons entre la question et les documents.

Je cherche un t-shirt de sport bleu.

Requête sémantique

Les mots de la question ne sont pas susceptibles de figurer dans les documents. Similitude conceptuelle entre la question et les documents.

Je cherche des vêtements pour le froid.

Recherche hybride

La question contient des éléments lexicaux et/ou sémantiques. Similitude toxique et sémantique entre les questions et les documents.

Je cherche une robe taille S pour un mariage sur la plage.

Les parties lexicales de la question sont susceptibles de faire partie de titres et de descriptions, ou de noms de catégories, tandis que les parties sémantiques sont des concepts liés à ces domaines. Le bleu sera probablement un nom de catégorie ou une partie de la description, et le mariage à la plage ne le sera probablement pas, mais il peut être sémantiquement lié aux vêtements en lin.

Requête lexicale (/search/lexic?q=<query_term>)

La recherche lexicale, également appelée recherche en texte intégral, consiste à effectuer une recherche basée sur la similarité des mots-clés, c'est-à-dire qu'après une analyse, les documents qui contiennent les mots-clés de la recherche seront renvoyés.

Vous pouvez consulter notre tutoriel pratique sur la recherche lexicale ici.

Nous testons avec : coupe-ongles

Réponse :

Requête sémantique (/search/semantic?q=<query_term>)

La recherche sémantique, contrairement à la recherche lexicale, permet de trouver des résultats similaires à la signification des termes de recherche par le biais d'une recherche vectorielle.

Vous pouvez consulter notre tutoriel pratique sur la recherche sémantique ici.

Nous testons avec : Qui s'est fait faire une pédicure ?

Réponse :

Requête hybride (/search/hybrid?q=<query_term>)

La recherche hybride nous permet de combiner la recherche sémantique et la recherche lexicale, et d'obtenir ainsi le meilleur des deux mondes : vous bénéficiez de la précision de la recherche par jeton, ainsi que de la proximité de sens de la recherche sémantique.

Nous testons avec "Qui a reçu une pédicure ou un traitement dentaire ?"

Réponse :

Conclusion

Dans cette première partie de notre série, nous avons expliqué comment configurer notre environnement et créer un serveur avec différents points de terminaison de recherche pour interroger les documents Elasticsearch en suivant les meilleures pratiques client/serveur. Consultez la deuxième partie de notre série, dans laquelle vous découvrirez les meilleures pratiques de production et comment exécuter le client Elasticsearch Node.js dans des environnements sans serveur.

Le rôle des répliques dans Elasticsearch

Dans Elasticsearch, un index est une collection de documents qui sont répartis sur plusieurs shards primaires. Chaque groupe primaire est un index Apache Lucene autonome, et les documents d'un index sont répartis entre tous les groupes primaires. Pour garantir la haute disponibilité et la redondance des données, Elasticsearch permet à chaque nuage d'avoir une ou plusieurs copies, appelées répliques. Le paramètre number_of_replicas contrôle le nombre de répliques (copies) qu'Elasticsearch crée pour chaque réplique primaire d'un index. Par défaut, Elasticsearch crée une réplique pour chaque shard primaire, mais cela peut être modifié en fonction des besoins de votre système.

Configuration du nombre de répliques (number_of_replicas)

Le paramètre number_of_replicas peut être configuré au moment de la création de l'index ou mis à jour ultérieurement. Voici comment vous pouvez le définir lors de la création de l'index :

Dans cet exemple, Elasticsearch créera deux réplicas pour chaque fichier primaire de l'index my_index.

Pour mettre à jour le paramètre number_of_replicas d'un index existant, vous pouvez utiliser l'API _settings:

Cette commande mettra à jour l'index my_index pour qu'il y ait trois réplicas pour chaque groupe primaire.

Implications du paramètre number_of_replicas (nombre de répliques)

Le paramètre number_of_replicas a un impact significatif sur les performances et la résilience de votre cluster Elasticsearch. Voici quelques points clés à prendre en considération :

1. Redondance et disponibilité des données : L'augmentation du site number_of_replicas améliore la disponibilité de vos données en créant davantage de copies de chaque groupe de données. Si un nœud tombe en panne, Elasticsearch peut toujours servir des données à partir des répliques sur les nœuds restants.

2. Performances de recherche : Les répliques peuvent répondre à des demandes de lecture. Le fait de disposer d'un plus grand nombre de répliques peut donc améliorer les performances en matière de recherche en répartissant la charge sur un plus grand nombre de répliques.

3. Performance d'écriture : Cependant, chaque opération d'écriture doit être exécutée sur chaque copie d'un groupe de données. Par conséquent, une adresse number_of_replicas plus élevée peut ralentir les performances d'indexation car elle augmente le nombre d'opérations à effectuer pour chaque écriture.

4. Exigences en matière de stockage : Plus il y a de répliques, plus il y a d'espace de stockage. Vous devez vous assurer que votre cluster dispose d'une capacité suffisante pour stocker les répliques supplémentaires.

5. Résilience en cas de défaillance d'un nœud : Le site number_of_replicas doit être défini en fonction du nombre de nœuds de votre cluster. Si le site number_of_replicas est égal ou supérieur au nombre de nœuds, votre cluster peut tolérer la défaillance de plusieurs nœuds sans perte de données.

Bonnes pratiques pour définir le nombre de répliques (number_of_replicas)

Le réglage optimal de number_of_replicas dépend des exigences spécifiques de votre système. Toutefois, voici quelques bonnes pratiques générales :

• Pour un cluster à un seul nœud, number_of_replicas doit être fixé à 0, car il n'y a pas d'autres nœuds pour contenir des répliques.

• Pour un cluster à plusieurs nœuds, number_of_replicas doit être réglé sur au moins 1 pour assurer la redondance des données et la haute disponibilité.

• Si la performance de la recherche est une priorité, envisagez d'augmenter le site number_of_replicas. Toutefois, il convient de garder à l'esprit le compromis entre les performances d'écriture et les exigences en matière de stockage.

• Assurez-vous toujours que votre cluster dispose d'une capacité suffisante pour stocker les répliques supplémentaires.

Méthode 1 : Utilisation de l'API de mise à jour

API Update vous permet de mettre à jour un document en fournissant un script qui modifie la source du document. Vous pouvez utiliser cette API pour supprimer un champ d'un document en lui attribuant la valeur null. Voici un guide étape par étape pour y parvenir :

1. Identifiez l'index, le type de document (si vous utilisez Elasticsearch 6.x ou une version antérieure) et l'ID du document que vous souhaitez mettre à jour.

2. Utilisez l'API de mise à jour avec un script qui définit le champ comme nul ou, mieux encore, le supprime du document source. L'exemple suivant montre comment supprimer le champ "field_to_delete" d'un document dont l'ID est "1" dans l'index "my_index" :

3. Exécuter la demande. En cas de succès, Elasticsearch renvoie une réponse indiquant que le document a été mis à jour.

Note : Cette méthode ne supprime le champ que du document spécifié. Le champ existera toujours dans la cartographie et dans les autres documents de l'index.

Méthode 2 : Réindexation avec une source modifiée

Si vous souhaitez supprimer un champ de tous les documents d’un index, vous pouvez utiliser l’API Reindex pour créer un nouvel index avec la source modifiée. Voici comment procéder :

1. Créez un nouvel index avec les mêmes paramètres et mappages que l'index original. Vous pouvez utiliser l'API Get Index pour récupérer les paramètres et les mappages de l'index original.

2. Utilisez l'API Reindex pour copier les documents de l'index original vers le nouvel index, tout en supprimant le champ de la source. L'exemple suivant montre comment supprimer le champ "field_to_delete" de tous les documents de l'index "my_index" :

3. Vérifier que le nouvel index contient les documents corrects avec le champ supprimé.

4. Si tout semble correct, vous pouvez supprimer l'index original et, si nécessaire, ajouter un alias au nouvel index portant le nom de l'index original.

Méthode 3 : Mise à jour du mapping et réindexation

Si vous souhaitez supprimer un champ du mappage et de tous les documents d'un index, vous pouvez mettre à jour le mappage, puis réindexer les documents. Voici comment procéder :

1. Créez un nouvel index avec les mêmes paramètres que l'index original.

2. Récupérer les mappings de l'index original à l'aide de l'API "Get Mapping".

3. Modifiez les correspondances en supprimant le champ que vous souhaitez supprimer.

4. Appliquez les mappages modifiés au nouvel index à l'aide de l'API Put Mapping.

5. Utilisez l'API de réindexation pour copier les documents de l'index d'origine vers le nouvel index, comme décrit dans la méthode 2.

6. Vérifiez que le nouvel index contient les documents corrects avec le champ supprimé et que le champ n'est pas présent dans le mappage.

7. Si tout semble en ordre, vous pouvez supprimer l’index original et, si nécessaire, ajouter un alias au nouvel index avec le nom de l’index original.

Conclusion

Dans cet article, nous avons abordé trois méthodes pour supprimer un champ d'un document dans Elasticsearch : l'utilisation de l'API de mise à jour, la réindexation avec une source modifiée et la mise à jour du mappage et la réindexation. Chaque méthode a ses propres cas d'utilisation et ses propres compromis, choisissez donc celle qui répond le mieux à vos besoins. N'oubliez jamais de tester vos modifications et de vérifier les résultats avant de les appliquer aux environnements de production.

Historiquement, de nombreuses personnes ont utilisé le nested type de champ comme un mécanisme permettant de relier différents indices entre eux. Cependant, elle a été limitée par des requêtes coûteuses et une prise en charge incomplète dans Kibana, en particulier pour les visualisations de Lens.

Cet article se penche sur le processus de jonction de deux index dans Elasticsearch, en se concentrant sur les approches suivantes :

1. Utilisation de la requête terms

2. Utilisation du processeur enrich dans les pipelines d'ingestion

3. Logstash elasticsearch filter plugin

4. ES|QL ENRICH

5. ES|QL LOOKUP JOIN

Utilisation des termes de la requête

La requête terms est l'un des moyens les plus efficaces de joindre deux index dans Elasticsearch. Cette requête permet de retrouver des documents contenant un ou plusieurs termes exacts dans un champ spécifique. Nous verrons ici comment l'utiliser pour joindre deux indices.

Tout d'abord, vous devez extraire les données requises du premier index. Cela peut être fait en utilisant une simple requête GET et en extrayant les valeurs de l'attribut _source.

Une fois que vous avez les données du premier index, vous pouvez les utiliser pour interroger le deuxième index. Cette opération s'effectue à l'aide de la requête terms, dans laquelle vous indiquez le champ et les valeurs que vous souhaitez faire correspondre.

En voici un exemple :

Dans cet exemple, field_in_second_index est le champ du deuxième index que vous souhaitez faire correspondre aux valeurs du premier index. value1_from_first_index et value2_from_first_index sont les valeurs du premier index que vous voulez faire correspondre au deuxième index.

La recherche de termes permet également d'effectuer les deux étapes ci-dessus en une seule fois à l'aide d'une technique appelée " recherche de termes". Elasticsearch se chargera de récupérer de manière transparente les valeurs à faire correspondre à partir d'un autre index. Par exemple, si vous disposez d'un index des équipes contenant une liste de joueurs :

Il est possible d'interroger un index de personnes pour connaître toutes les personnes jouant dans l'équipe 1, comme indiqué ci-dessous :

Dans l'exemple ci-dessus, Elasticsearch récupère de manière transparente les noms des joueurs à partir du document avec l'identifiant team1 dans l'index teams (c'est-à-dire "john", "bill" et "michael") et trouver tous les documents de l'index des personnes contenant l'une de ces valeurs dans le champ "nom".

Pour les curieux, la requête SQL équivalente serait la suivante :

Utilisation du processeur d'enrichissement

Le enrich processeur est un autre outil puissant qui peut être utilisé pour joindre deux index dans Elasticsearch. Ce processeur enrichit les données des documents entrants en ajoutant des données provenant d'un index d'enrichissement prédéfini.

Voici comment utiliser le processeur d'enrichissement pour joindre deux indices :

1. Tout d'abord, vous devez créer une politique d'enrichissement. Cette politique définit l'index à utiliser pour l'enrichissement, le champ à utiliser et le(s) champ(s) à utiliser pour enrichir les documents entrants.

En voici un exemple :

2. Une fois la politique créée, vous devez l'exécuter pour créer l'index d'enrichissement à partir de votre nouvelle politique :

Cela permet de créer un nouvel index caché enrichi qui sera utilisé lors de l'enrichissement. Selon la taille de l'index source, cette opération peut prendre un certain temps. Assurez-vous que la politique d'enrichissement est entièrement construite avant de passer à l'étape suivante.

3. Une fois la politique d'enrichissement élaborée, vous pouvez utiliser le processeur d'enrichissement dans un pipeline d'acquisition pour enrichir les données des documents entrants :

Dans cet exemple, field_in_second_index est le champ du deuxième index qui doit correspondre au champ match_field du premier index. enriched_field est le nouveau champ du deuxième index qui contiendra les données enrichies de enrich_fields dans le premier index.

L'un des inconvénients de cette approche est que si les données changent sur first_index, la politique d'enrichissement doit être réexécutée. L'index enrichi n'est pas mis à jour ou synchronisé automatiquement à partir de l'index source à partir duquel il a été construit. Cependant, si first_index est relativement stable, cette approche fonctionne bien.

Plugin de filtre Logstash elasticsearch

Si vous utilisez Logstash, une autre option similaire au processeur enrich décrit ci-dessus consiste à utiliser le plugin de filtre elasticsearch pour ajouter des champs pertinents à l'événement sur la base d'une requête spécifiée. La configuration de notre pipeline Logstash se trouve dans un fichier .conf, tel que my-pipeline.conf.

Imaginons que notre pipeline extrait des logs d'Elasticsearch à l'aide du elasticsearch plugin d'entrée, avec une requête pour réduire la sélection :

Si nous voulons enrichir ces messages avec des informations provenant d'un index donné, nous pouvons utiliser le elasticsearch plugin de filtre dans la filter section pour enrichir nos journaux :

Le code ci-dessus trouvera les documents de l'index index_name où type est le début et le champ opération correspond au champ spécifié opid, puis copiera la valeur du champ @timestamp dans un nouveau champ nommé started.

Les documents enrichis sont ensuite envoyés à la source de sortie appropriée, en l'occurrence Elasticsearch à l'aide du elasticsearch plugin de sortie:

Si vous utilisez déjà Logstash, cette option peut être utile pour consolider votre logique d'enrichissement en un seul endroit et la traiter au fur et à mesure de l'arrivée de nouveaux événements. Cependant, si vous ne l'êtes pas, cela ajoute de la complexité à votre solution, et un autre composant que vous devez gérer et entretenir.

ES|QL ENRICH

L'introduction d'ES|QL, qui a été généralisée dans la version 8.14, est un langage de requête en ligne pris en charge par Elasticsearch qui permet le filtrage, la transformation et l'analyse des données. La commande de traitement ENRICH permet d'ajouter des données à partir d'indices existants à l'aide d'une politique d'enrichissement.

En reprenant la même politique my_enrich_policy que dans l'exemple original du processeur d'enrichissement, l'exemple ES|QL ressemblerait à ce qui suit :

Il est également possible de remplacer les champs de correspondance et d'enrichissement qui, dans notre exemple, sont respectivement field_in_first_index et field_to_enrich:

Bien que la limitation évidente soit que vous devez d'abord spécifier une politique d'enrichissement, ES|QL offre la flexibilité de modifier les champs selon les besoins.

ES|QL LOOKUP JOIN

Elasticsearch 8.18 introduit une nouvelle façon de joindre des index dans Elasticsearch, à savoir la commande LOOKUP JOIN. Cette commande fonctionne comme une jointure gauche-externe de type SQL en utilisant le nouveau mode d'indexation du côté droit de la jointure.

Si l'on reprend l'exemple précédent, la nouvelle requête est la suivante, où match_field doit être présent à la fois dans first_index et second_index:

L'avantage de LOOKUP JOIN par rapport aux autres approches est qu'il ne nécessite pas de politique enrich, et donc le traitement supplémentaire associé à la mise en place de la politique. Elle est utile lorsque l'on travaille avec des données d'enrichissement qui changent fréquemment, contrairement aux autres approches abordées dans cet article.

Conclusion

En conclusion, bien qu'Elasticsearch ne prenne pas en charge les opérations de jointure traditionnelles, il offre diverses fonctionnalités qui peuvent être utilisées pour obtenir des résultats similaires. Plus précisément, nous avons vu comment réaliser des opérations de jointure à l'aide de :

1. La requête terms

2. Le processeur enrich dans les pipelines d'acquisition

3. Logstash elasticsearch filter plugin

4. ES|QL ENRICH

5. ES|QL LOOKUP JOIN

Il est important de noter que ces méthodes ont leurs limites et doivent être utilisées judicieusement en fonction des besoins spécifiques et de la nature des données.

Mécanismes de notation dans Elasticsearch

Elasticsearch utilise par défaut un modèle de notation appelé Practical Scoring Function (BM25). Ce modèle est basé sur la théorie probabiliste de la recherche d'informations et prend en compte des facteurs tels que la fréquence des termes, la fréquence inverse des documents et la normalisation de la longueur des champs. Examinons brièvement ces facteurs :

1. Fréquence des termes (TF) : Elle représente le nombre de fois qu'un terme apparaît dans un document. Une fréquence de terme plus élevée indique une relation plus forte entre le terme et le document.

2. Fréquence inverse des documents (IDF) : Ce facteur mesure l'importance d'un terme dans l'ensemble de la collection de documents. Un terme qui apparaît dans de nombreux documents est considéré comme moins important, tandis qu'un terme qui apparaît dans moins de documents est considéré comme plus important.

3. Normalisation de la longueur du champ: Ce facteur tient compte de la longueur du champ dans lequel le terme apparaît. Les champs plus courts ont plus de poids, car le terme est considéré comme plus significatif dans un champ plus court.

Utiliser l'API Expliciter

L'API Explain d'Elasticsearch est un outil précieux pour comprendre le processus de notation. Il fournit une explication détaillée de la manière dont la note d'un document spécifique a été calculée. Pour utiliser l'API Expliciter, vous devez envoyer une requête GET au point de terminaison suivant :

Dans le corps de la demande, vous devez indiquer la requête pour laquelle vous voulez comprendre la notation. En voici un exemple :

La réponse de l'API Expliciter comprendra une ventilation détaillée du processus de notation, y compris les facteurs individuels (TF, IDF et normalisation de la longueur de champ) et leurs contributions à la note finale. Voici un exemple de réponse :

Dans cet exemple, la réponse montre que le score de 1,2 est un produit de la valeur IDF (2,2) et de la valeur tfNorm (0,5). L'explication détaillée permet de comprendre les facteurs contribuant à la note et peut être utile pour affiner la pertinence de la recherche.

Conclusion

La notation Elasticsearch est un aspect essentiel de la fourniture de résultats de recherche pertinents. En comprenant les mécanismes de notation et en utilisant l'API Explain, vous pouvez obtenir des informations sur les facteurs affectant les résultats de recherche et optimiser vos requêtes de recherche pour une meilleure pertinence et de meilleures performances.

Techniques avancées pour effectuer des recherches sur deux champs

1. Requête multiple

Une requête multiple vous permet de rechercher une seule chaîne de caractères dans plusieurs champs. Ceci est utile lorsque vous souhaitez trouver des documents qui contiennent la chaîne de requête donnée dans l'un ou l'autre des deux champs. Voici un exemple de requête multi-correspondance recherchant le terme "exemple" dans les champs "titre" ou "description" :

2. Requête Bool

Une requête bool vous permet de combiner plusieurs requêtes en utilisant la logique booléenne. Vous pouvez utiliser la clause "devrait" pour rechercher les documents qui correspondent à la requête dans l'un ou l'autre des deux champs. Voici un exemple de requête bool recherchant le terme "exemple" dans les champs "titre" et "description" :

3. Renforcement des champs au moment de la requête

Il peut arriver que vous souhaitiez accorder plus d'importance à un champ qu'à un autre lors de la recherche. Vous pouvez y parvenir en appliquant un facteur d'amplification au champ au moment de la requête. Une valeur de boost plus élevée donne plus de poids au champ, ce qui le rend plus susceptible d'influencer le résultat final de la recherche. Voici un exemple de requête à correspondances multiples avec un facteur d'amplification appliqué au champ "titre" :

Dans cet exemple, le champ "titre" a un facteur d'amplification de 3, ce qui signifie qu'il est trois fois plus important que le champ "description" pour déterminer le score de recherche.

4. Combinaison de requêtes avec différents facteurs d'amplification

Vous pouvez également combiner plusieurs requêtes avec différents facteurs d'augmentation à l'aide d'une requête bool. Cela vous permet d'affiner l'importance de chaque champ dans les résultats de la recherche. Voici un exemple de requête bool avec différents facteurs de boost appliqués aux champs "titre" et "description" :

Dans cet exemple, le champ "titre" a un facteur d'amplification de 3, tandis que le champ "description" a un facteur d'amplification de 1.

Conclusion

La recherche par deux champs dans Elasticsearch peut être réalisée à l'aide de techniques avancées telles que les requêtes à correspondances multiples, les requêtes bool et l'augmentation du nombre de champs au moment de la requête. En combinant ces techniques, vous pouvez créer des résultats de recherche plus précis et plus pertinents pour vos utilisateurs. Expérimentez différentes combinaisons de requêtes et de facteurs de stimulation pour trouver la configuration de recherche optimale pour votre cas d'utilisation spécifique.

Toutes les requêtes complètes et les résultats mentionnés dans cet article peuvent être trouvés dans notre dépôt de code Elasticsearch Labs.

Pourquoi mettre en œuvre une meilleure quantification binaire (BBQ) dans votre cas d'utilisation ?

Bien que les mathématiques soient intrigantes, elles sont essentielles si vous voulez comprendre pourquoi vos recherches vectorielles restent précises. En fin de compte, il s'agit d'une question de compression, car il s'avère qu'avec les algorithmes actuels de recherche vectorielle, vous êtes limité par la vitesse de lecture des données. Par conséquent, si vous pouvez placer toutes ces données dans la mémoire, vous bénéficiez d'un gain de vitesse significatif par rapport à la lecture à partir du stockage(la mémoire est environ 200 fois plus rapide que les disques SSD).

Il y a quelques points à garder à l'esprit :

• Les indices basés sur les graphes, tels que HNSW (Hierarchical Navigable Small World), sont les plus rapides pour la recherche vectorielle.

  • HNSW : un algorithme de recherche approximative du plus proche voisin qui construit une structure de graphe multicouche pour permettre des recherches de similarité efficaces en haute dimension.

• La vitesse de HNSW est fondamentalement limitée par la vitesse de lecture des données à partir de la mémoire ou, dans le pire des cas, à partir du stockage.

  • L'idéal est de pouvoir charger tous les vecteurs stockés dans la mémoire.

• Les modèles d'intégration produisent généralement des vecteurs avec une précision float32, soit 4 octets par nombre à virgule flottante.

• Enfin, selon le nombre de vecteurs et/ou de dimensions que vous avez, vous pouvez très rapidement manquer de mémoire pour conserver tous vos vecteurs.

Si l'on prend cela pour acquis, on constate qu'un problème se pose rapidement dès que l'on commence à ingérer des millions, voire des milliards de vecteurs, chacun ayant potentiellement des centaines, voire des milliers de dimensions. La section intitulée "Chiffres approximatifs sur les taux de compression" fournit quelques chiffres approximatifs.

De quoi avez-vous besoin pour commencer ?

Pour commencer, vous aurez besoin des éléments suivants :

• Si vous utilisez Elastic Cloud ou on-prem, vous aurez besoin d'une version d'Elasticsearch supérieure à 8.18. Alors que BBQ a été introduit dans la version 8.16, dans cet article, vous utiliserez vector_rescore, qui a été introduit dans la version 8.18.

• En outre, vous devrez également vous assurer qu'il existe un nœud d'apprentissage automatique (ML) dans votre cluster. (Remarque : un nœud ML doté d'un minimum de 4 Go est nécessaire pour charger le modèle, mais vous aurez probablement besoin de nœuds beaucoup plus grands pour des charges de travail de production complètes).

• Si vous utilisez Serverless, vous devrez sélectionner une instance optimisée pour les vecteurs.

• Vous aurez également besoin d'une connaissance de base des bases de données vectorielles. Si vous n'êtes pas encore familiarisé avec les concepts de recherche vectorielle dans Elastic, vous pouvez consulter les ressources suivantes :

  • Naviguer dans une base de données vectorielle élastique

  • Les grandes idées derrière la génération augmentée de recherche

Meilleure implémentation de la quantification binaire (BBQ)

Pour que ce blog reste simple, vous utiliserez les fonctions intégrées lorsqu'elles sont disponibles. Dans ce cas, vous disposez du modèle d'intégration vectorielle .multilingual-e5-small qui s'exécutera directement dans Elasticsearch sur un nœud d'apprentissage automatique. Notez que vous pouvez remplacer le modèle text_embedding par l'intégrateur de votre choix(OpenAI, Google AI Studio, Cohere et bien d'autres). Si le modèle que vous préférez n'est pas encore intégré, vous pouvez également apporter vos propres encastrements vectoriels denses).

Tout d'abord, vous devrez créer un point final d'inférence pour générer des vecteurs pour un morceau de texte donné. Vous exécuterez toutes ces commandes à partir de la console Kibana Dev Tools. Cette commande permet de télécharger le site .multilingual-e5-small. S'il n'existe pas encore, il configurera votre point d'accès ; cette opération peut prendre une minute. Vous pouvez voir le résultat attendu dans le fichier 01-create-an-inference-endpoint-output.json dans le dossier Outputs.

Une fois qu'il est revenu, votre modèle est configuré et vous pouvez tester que le modèle fonctionne comme prévu à l'aide de la commande suivante. Vous pouvez voir le résultat attendu dans le fichier 02-embed-text-output.json dans le dossier Outputs.

Si vous rencontrez des problèmes liés au fait que votre modèle formé n'est affecté à aucun nœud, il se peut que vous deviez démarrer votre modèle manuellement.

Créons maintenant un nouveau mappage avec deux propriétés, un champ de texte standard (my_field) et un champ vectoriel dense (my_vector) avec 384 dimensions pour correspondre à la sortie du modèle d'intégration. Vous pouvez également passer outre l'adresse index_options.type to bbq_hnsw. Vous pouvez voir le résultat attendu dans le fichier 03-create-byte-qauntized-index-output.json dans le dossier Outputs.

Pour s'assurer qu'Elasticsearch génère vos vecteurs, vous pouvez utiliser un pipeline d'ingestion. Ce pipeline nécessite trois éléments : le point final (model_id), le site input_field pour lequel vous souhaitez créer des vecteurs et le site output_field dans lequel vous souhaitez stocker ces vecteurs. La première commande ci-dessous crée un pipeline d'ingestion d'inférence, qui utilise le service d'inférence sous le capot, et la seconde teste le bon fonctionnement du pipeline. Vous pouvez voir le résultat attendu dans le fichier 04-create-and-simulate-ingest-pipeline-output.json dans le dossier Outputs. 

Vous êtes maintenant prêt à ajouter des documents à l'aide des deux premières commandes ci-dessous et à tester le fonctionnement de vos recherches à l'aide de la troisième commande. Vous pouvez vérifier le résultat attendu dans le fichier 05-bbq-index-output.json dans le dossier Outputs. 

Comme nous l'avons recommandé dans cet article, le recalage et le suréchantillonnage sont conseillés lorsque vous passez à des quantités de données non triviales, car ils permettent de maintenir une précision de rappel élevée tout en bénéficiant des avantages de la compression. À partir de la version 8.18 d'Elasticsearch, vous pouvez le faire de cette façon en utilisant rescore_vector. Le résultat attendu se trouve dans le fichier 06-bbq-search-8-18-output.json dans le dossier Outputs.

Comment ces résultats se comparent-ils à ceux que vous obtiendriez avec des données brutes ? Si vous refaites tout ce qui précède mais avec index_options.type: hnsw, vous verrez que les scores sont très comparables. Vous pouvez voir le résultat attendu dans le fichier 07-raw-vector-output.json dans le dossier Outputs.

Chiffres approximatifs sur les taux de compression

Les exigences en matière de stockage et de mémoire peuvent rapidement devenir un défi important lorsque l'on travaille avec la recherche vectorielle. La décomposition suivante illustre comment les différentes techniques de quantification réduisent considérablement l'empreinte mémoire des données vectorielles.

Vecteurs (V)

Dimensions (D)

brut (V x D x 4)

int8 (V x (D x 1 + 4))

int4 (V x (D x 0,5 + 4))

bbq (V x (D x 0,125 + 4))

10,000,000

384

14.31GB

3.61GB

1.83GB

0.58GB

50,000,000

384

71.53GB

18.07GB

9.13GB

2.89GB

100,000,000

384

143.05GB

36.14GB

18.25GB

5.77GB

Conclusion

BBQ est une optimisation que vous pouvez appliquer à vos données vectorielles pour les compresser sans sacrifier la précision. Il convertit les vecteurs en bits, ce qui vous permet d'effectuer des recherches efficaces dans les données et de faire évoluer vos flux de travail d'IA pour accélérer les recherches et optimiser le stockage des données.

Poursuite de l'apprentissage

Si vous souhaitez en savoir plus sur le barbecue, n'hésitez pas à consulter les ressources suivantes :

• Quantification binaire (BBQ) dans Lucene et Elasticsearch

• Meilleure quantification binaire (BBQ) vs quantification par produit

• Quantification scalaire optimisée : Une quantification binaire encore meilleure

• Meilleure quantification binaire (BBQ) : De l'octet au BBQ, le secret d'une meilleure recherche vectorielle par Ben Trent

Depuis la version 7.11, Elasticsearch définit par défaut automatiquement la taille du tas de la JVM en fonction des rôles et de la mémoire totale d'un nœud. L'utilisation du dimensionnement par défaut est recommandée pour la plupart des environnements de production. Toutefois, si vous souhaitez définir manuellement la taille du tas de votre JVM, vous devez en règle générale définir -Xms et -Xmx sur la MÊME valeur, soit 50% de votre RAM totale disponible, avec un maximum (approximatif) de 31 Go.

Une taille de tas plus importante permet à votre nœud de disposer de plus de mémoire pour les opérations d'indexation et de recherche. Cependant, votre nœud a également besoin de mémoire pour la mise en cache, de sorte que l'utilisation de 50% maintient un équilibre sain entre les deux. Pour cette même raison, en production, vous devez éviter d'utiliser d'autres processus gourmands en mémoire sur le même nœud qu'Elasticsearch.

En règle générale, l'utilisation du tas suit un schéma en dents de scie, oscillant entre 30 et 70% du tas maximum utilisé. En effet, la JVM augmente régulièrement le pourcentage d'utilisation du tas jusqu'à ce que le processus de ramassage des ordures libère à nouveau de la mémoire. Une forte utilisation du tas se produit lorsque le processus de ramassage des ordures n'arrive pas à suivre. Un indicateur d'une utilisation élevée du tas est lorsque le ramasse-miettes est incapable de réduire l'utilisation du tas à environ 30%.

Dans l'image ci-dessus, vous pouvez voir une dent de scie normale du tas de la JVM.

Vous verrez également qu'il existe deux types de ramassage d'ordures, le jeune et l'ancien GC.

Dans une JVM en bonne santé, le ramassage des ordures devrait idéalement répondre aux conditions suivantes :

• Le jeune GC est traité rapidement (dans les 50 ms).

• Le jeune GC n'est pas exécuté fréquemment (environ 10 secondes).

• L'ancienne CG est traitée rapidement (en moins d'une seconde).

• L'ancienne CG n'est pas exécutée fréquemment (une fois toutes les 10 minutes ou plus).

Comment résoudre le problème d'une utilisation trop importante de la mémoire du tas ou d'une performance non optimale de la JVM ?

Plusieurs raisons peuvent expliquer l'augmentation de l'utilisation de la mémoire du tas :

La surexploitation

Veuillez consulter le document sur le surdimensionnement ici.

Grandes tailles d'agrégation

Afin d'éviter des agrégations trop importantes, limitez au maximum le nombre d'agrégats (taille) dans vos requêtes.

Vous pouvez utiliser la journalisation lente des requêtes (slow logs) et la mettre en œuvre sur un index spécifique en procédant comme suit.

Les requêtes qui prennent beaucoup de temps pour donner des résultats sont probablement celles qui consomment beaucoup de ressources.

Taille excessive de l'index en vrac

Si vous envoyez des requêtes volumineuses, cela peut être la cause d'une consommation élevée de la mémoire vive. Essayez de réduire la taille des demandes d'index en vrac.

Questions de cartographie

En particulier, si vous utilisez "fielddata : true", cela peut être un utilisateur majeur de la mémoire vive de votre JVM.

La taille du tas n'est pas correctement définie

La taille du tas peut être définie manuellement par :

Définition de la variable d'environnement :

Édition du fichier jvm.options dans le répertoire de configuration d'Elasticsearch :

Le paramètre de la variable d'environnement est prioritaire sur le paramètre du fichier.

Il est nécessaire de redémarrer le nœud pour que le réglage soit pris en compte.

Le nouveau ratio de la JVM n'est pas correctement défini

Il n'est généralement PAS nécessaire de définir cette valeur, car Elasticsearch le fait par défaut. Ce paramètre définit le ratio de l'espace disponible pour les objets de "nouvelle génération" et d'"ancienne génération" dans la JVM.

Si vous constatez que les anciens GC deviennent très fréquents, vous pouvez essayer de définir spécifiquement cette valeur dans le fichier jvm.options de votre répertoire de configuration Elasticsearch.

Quelles sont les meilleures pratiques pour gérer l'utilisation de la taille du tas et la collecte des déchets de la JVM dans un grand cluster Elasticsearch ?

Les meilleures pratiques pour gérer l'utilisation de la taille du tas et le ramassage des ordures de la JVM dans un grand cluster Elasticsearch consistent à s'assurer que la taille du tas est fixée à un maximum de 50% de la RAM disponible et que les paramètres du ramassage des ordures de la JVM sont optimisés pour le cas d'utilisation spécifique. Il est important de surveiller la taille du tas et les mesures du ramassage des ordures pour s'assurer que le cluster fonctionne de manière optimale. Plus précisément, il est important de surveiller la taille du tas de la JVM, le temps de ramassage des ordures et les pauses de ramassage des ordures. En outre, il est important de surveiller le nombre de cycles de ramassage des ordures et le temps passé à les effectuer. En surveillant ces mesures, il est possible d'identifier tout problème potentiel lié à la taille du tas ou aux paramètres du ramassage des ordures et de prendre des mesures correctives si nécessaire.

L'API _split est souvent plus rapide que l'API _reindex. L'indexation doit être arrêtée avant les deux opérations, sinon les comptes des documents source_index et cible_index seront différents.

Méthode 1 - utilisation de l'API fractionnée

L'API de fractionnement est utilisée pour créer un nouvel index avec le nombre souhaité d'unités primaires en copiant les paramètres et en mappant un index existant. Le nombre désiré de fragments primaires peut être défini lors de la création. Les paramètres suivants doivent être vérifiés avant de mettre en œuvre l'API fractionnée :

1. L'index source doit être en lecture seule. Cela signifie que le processus d'indexation doit être arrêté.

2. Le nombre de groupes primaires dans l'index cible doit être un multiple du nombre de groupes primaires dans l'index source. Par exemple, si l'index source dispose de 5 groupes primaires, les groupes primaires de l'index cible peuvent être définis comme suit : 10, 15, 20, et ainsi de suite.

Remarque : si seul le numéro du fonds primaire doit être modifié, il est préférable d'utiliser l'API de fractionnement, qui est beaucoup plus rapide que l'API de réindexation.

Mise en œuvre de l'API fractionnée

Créer un index de test :

L'index source doit être en lecture seule pour pouvoir être scindé :

Les paramètres et les correspondances seront copiés automatiquement à partir de l'index source :

Vous pouvez vérifier l'état d'avancement avec :

Étant donné que les paramètres et les mappages sont copiés à partir des index source, l'index cible est en lecture seule. Activons l'opération d'écriture pour l'index cible :

Vérifier les index source et cible docs.count avant de supprimer l'index original :

Le nom de l'index et le nom de l'alias ne peuvent pas être identiques. Vous devez supprimer l'index source et ajouter le nom de l'index source comme alias à l'index cible :

Après avoir ajouté l'alias test_split_source à l'index test_split_target, vous devez le tester avec :

Méthode 2 - utilisation de l'API de réindexation

En créant un nouvel index à l'aide de l'API Reindex, il est possible d'indiquer n'importe quel nombre de comptes de tessons primaires. Après la création d'un nouvel index avec le nombre prévu de groupes primaires, toutes les données de l'index source peuvent être réindexées sur ce nouvel index.

Outre les fonctionnalités de l'API fractionnée, les données peuvent être manipulées à l'aide de la ligne de conduite ingest_pipeline dans l'API de réindexation. Avec le pipeline d'ingestion, seuls les champs spécifiés qui correspondent au filtre seront indexés dans l'index cible à l'aide de la requête. Le contenu des données peut être modifié à l'aide d'un script simple, et plusieurs index peuvent être fusionnés en un seul.

Mise en œuvre de l'API de réindexation

Créer un test de réindexation :

Copier les paramètres et les mappages de l'index source :

Créez un index cible avec des paramètres, des mappings et le nombre de tiroirs souhaité :

*Remarque : les paramètres number_of_replicas : 0 et refresh_interval : -1 augmentera la vitesse de réindexation.

Lancer le processus de réindexation. Les paramètres requests_per_second=-1 et slices=auto permettent d'ajuster la vitesse de réindexation.

Vous verrez l'identifiant de la tâche lorsque vous exécuterez l'API de réindexation. Copiez-le et vérifiez avec l'API _tasks :

Mettre à jour les paramètres une fois la réindexation terminée :

Vérifiez les index source et cible docs.count avant de supprimer l'index original, ils doivent être identiques :

Le nom de l'index et le nom de l'alias ne peuvent pas être identiques. Supprimer l'index source et ajouter le nom de l'index source comme alias à l'index cible :

Après avoir ajouté l'alias test_split_source à l'index test_split_target, testez-le en utilisant :

Résumé

Si vous souhaitez augmenter le nombre de tessons primaires d'un index existant, vous devez recréer les paramètres et les correspondances avec un nouvel index. Il existe deux méthodes principales pour ce faire : l'API de réindexation et l'API de scission. L'indexation active doit être arrêtée avant d'utiliser l'une ou l'autre méthode.

Les inconvénients de cette approche sont qu'elle nécessite une certaine duplication du matériel et qu'elle peut créer des difficultés lors du transfert et de la synchronisation de toutes les données.

Il peut également être nécessaire d'effectuer une procédure similaire si vous devez migrer des applications d'un centre de données à un autre.

Dans cet article, nous allons discuter et détailler trois façons de transférer des données entre les clusters Elasticsearch.

Comment migrer des données entre clusters Elasticsearch ?

Il existe trois façons de transférer des données entre les clusters Elasticsearch :

1. Réindexation à partir d'un cluster distant

2. Transfert de données à l'aide d'instantanés

3. Transférer des données avec Logstash

L'utilisation d'instantanés est généralement le moyen le plus rapide et le plus fiable de transférer des données. Toutefois, n'oubliez pas que vous ne pouvez restaurer un instantané que sur un cluster de version égale ou supérieure et jamais avec une différence de plus d'une version majeure. Cela signifie que vous pouvez restaurer un snapshot 6.x sur un cluster 7.x mais pas sur un cluster 8.x.

Si vous avez besoin d'augmenter de plus d'une version majeure, vous devrez réindexer ou utiliser Logstash.

Examinons maintenant en détail chacune des trois options de transfert de données entre clusters Elasticsearch.

1. Réindexation des données d'un cluster distant

Avant de commencer à réindexer, n'oubliez pas que vous devrez configurer les mappages appropriés pour tous les index sur le nouveau cluster. Pour ce faire, vous devez soit créer les index directement avec les mappings appropriés, soit utiliser des modèles d'index.

Réindexation à distance - configuration requise

Pour réindexer à distance, vous devez ajouter la configuration ci-dessous au fichier elasticseearch.yml pour le cluster qui reçoit les données, qui, dans les systèmes Linux, est généralement situé ici : /etc/elasticsearch/elasticsearch.yml. La configuration à ajouter est la suivante :

Si vous utilisez SSL, vous devez ajouter le certificat CA à chaque nœud et inclure ce qui suit dans la commande pour chaque nœud dans elasticsearch.yml :

Vous pouvez également ajouter la ligne ci-dessous à tous les nœuds Elasticsearch afin de désactiver la vérification SSL. Toutefois, cette approche est moins recommandée car elle n'est pas aussi sûre que l'option précédente :

Vous devrez effectuer ces modifications sur chaque nœud et procéder à un redémarrage progressif. Pour plus d'informations sur la manière de procéder, veuillez consulter notre guide.

Commande de réindexation

Après avoir défini l'hôte distant dans le fichier elasticsearch.yml et ajouté les certificats SSL si nécessaire, vous pouvez commencer à réindexer les données avec la commande ci-dessous :

Il peut donc être utile de fixer des valeurs généreuses pour les délais d'attente plutôt que de se fier aux valeurs par défaut.

Examinons maintenant d'autres erreurs courantes que vous pouvez rencontrer lors d'une réindexation à distance.

Erreurs courantes lors de la réindexation à distance

1. La réindexation ne figure pas sur la liste blanche

Si vous rencontrez cette erreur, cela signifie que vous n'avez pas défini l'adresse IP de l'hôte distant ou le nom du nœud DNS dans Elasticsearch comme décrit ci-dessus ou que vous avez oublié de redémarrer les services Elasticsearch.

Pour résoudre ce problème dans le cluster Elasticsearch, vous devez ajouter l'hôte distant à tous les nœuds Elasticsearch et redémarrer les services Elasticsearch.

2. Exception relative au handshake SSL

Cette erreur signifie que vous avez oublié d'ajouter le certificat reindex.ssl.certificate_authorities à elasticsearch.yml comme décrit ci-dessus. Pour l'ajouter :

2. Transfert de données à l'aide d'instantanés

N'oubliez pas, comme indiqué ci-dessus, que vous ne pouvez restaurer un instantané que sur un cluster de version égale ou supérieure et jamais avec une différence de plus d'une version majeure.

Si vous avez besoin d'augmenter de plus d'une version majeure, vous devrez réindexer ou utiliser Logstash.

Les étapes suivantes sont nécessaires pour transférer des données par le biais d'instantanés :

Étape 1. Ajouter le plugin de référentiel au premier cluster Elasticsearch - Afin de transférer des données entre clusters via des snapshots, vous devez vous assurer que le référentiel est accessible à la fois depuis le nouveau et l'ancien cluster. Les référentiels de stockage en nuage tels que AWS, Google et Azure sont généralement idéaux pour cela. Pour prendre des instantanés, veuillez consulter notre guide et suivre les étapes qu'il décrit.

Étape 2. Redémarrer le service Elasticsearch (rolling restart).

Étape 3. Créez un référentiel pour le premier cluster Elasticsearch.

Étape 4 - Ajouter le plugin de référentiel au deuxième cluster Elasticsearch.

Étape 5- Ajouter un référentiel en lecture seule au deuxième cluster Elasticsearch - Vous devrez ajouter un référentiel en répétant les mêmes étapes que celles que vous avez suivies pour créer le premier cluster Elasticsearch.

Remarque importante : lorsque vous connectez le deuxième cluster Elasticsearch au même référentiel AWS S3, vous devez définir le référentiel comme un référentiel en lecture seule :

C'est important parce que vous voulez éviter le risque de mélanger les versions d'Elasticsearch dans le même dépôt d'instantanés.

Étape 6 - Restauration des données vers le deuxième cluster Elasticsearch - Après avoir suivi les étapes ci-dessus, vous pouvez restaurer les données et les transférer vers le nouveau cluster. Veuillez suivre les étapes décrites dans cet article pour restaurer les données dans le nouveau cluster. 

3. Transfert de données à l'aide de Logstash

Avant de commencer à transférer les données avec logstash, n'oubliez pas que vous devrez configurer les mappings appropriés pour tous les index sur le nouveau cluster. Pour ce faire, vous devrez soit créer les index directement, soit utiliser des modèles d'index.

Pour transférer des données entre deux clusters Elasticsearch, vous pouvez configurer un serveur Logstash temporaire et l'utiliser pour transférer vos données entre les deux clusters. Pour les petits clusters, une instance de 2 Go de mémoire vive devrait suffire. Pour les clusters plus importants, vous pouvez utiliser des CPU à quatre cœurs avec 8 Go de RAM.

Pour des conseils sur l'installation de Logstash, voir ici.

Configuration de Logstash pour le transfert de données d'un cluster à l'autre

La configuration de base pour copier un index unique du cluster A vers le cluster B est la suivante :

Pour sécuriser elasticsearch, vous pouvez utiliser la configuration ci-dessous :

Métadonnées de l'index

Les commandes ci-dessus écrivent dans un seul index nommé. Si vous souhaitez transférer plusieurs index et préserver les noms d'index, vous devez ajouter la ligne suivante à la sortie de Logstash :

De même, si vous souhaitez conserver l'identifiant original du document, vous devrez ajouter :

Gardez à l'esprit que la définition de l'ID du document ralentira considérablement le transfert des données, aussi ne conservez-vous l'ID d'origine que si vous en avez besoin.

Synchronisation des mises à jour

Toutes les méthodes décrites ci-dessus prennent un temps relativement long, et il se peut que des données aient été mises à jour dans le cluster d'origine en attendant la fin du processus.

Il existe plusieurs stratégies pour permettre la synchronisation des mises à jour qui ont pu avoir lieu pendant le processus de transfert des données, et vous devriez réfléchir à ces questions avant d'entamer ce processus. Vous devez notamment réfléchir aux points suivants :

• Quelle méthode utilisez-vous pour identifier les données qui ont été mises à jour/ajoutées depuis le début du processus de transfert de données (par exemple, un champ "last_update_time" dans les données) ?

• Quelle méthode pouvez-vous utiliser pour transférer le dernier élément de données ?

• Existe-t-il un risque de duplication des documents ? En général, c'est le cas, à moins que la méthode que vous utilisez ne fixe l'ID du document à une valeur connue lors de la réindexation).

Les différentes méthodes permettant la synchronisation des mises à jour sont décrites ci-dessous.

1. Utilisation des systèmes de file d'attente

Certains systèmes d'ingestion/mise à jour utilisent des files d'attente qui vous permettent de "rejouer" les modifications de données reçues au cours des x derniers jours. Cela peut permettre de synchroniser les modifications effectuées.

2. Réindexation à distance

Répétez le processus de réindexation pour tous les éléments pour lesquels "last_update_time" > a été effectué il y a x jours. Vous pouvez le faire en ajoutant un paramètre "query" à la requête de réindexation.

3. Logstash

Dans l'entrée Logstash, vous pouvez ajouter une requête pour filtrer tous les éléments pour lesquels "last_update_time" > x jours ago. Toutefois, ce processus entraînera des doublons dans les données non chronologiques, à moins que vous n'ayez défini l'identifiant du document.

4. Instantanés

Il n'est pas possible de restaurer une partie seulement d'un index. Vous devez donc utiliser l'une des autres méthodes de transfert de données décrites ci-dessus (ou un script) pour mettre à jour toutes les modifications qui ont eu lieu depuis le processus de transfert de données.

Cependant, la restauration des instantanés est un processus beaucoup plus rapide que la réindexation/Logstash, il est donc possible de suspendre les mises à jour pendant une courte période de temps pendant que les instantanés sont transférés afin d'éviter le problème.

Ce blog explore la manière dont les grands modèles de langage (LLM) peuvent être utilisés pour identifier et générer automatiquement des synonymes, ce qui permet de charger ces termes de manière programmatique dans l'API de synonymes d'Elasticsearch.

Quand utiliser des synonymes ?

L'utilisation de synonymes peut être une solution plus rapide et plus rentable que la recherche vectorielle. Sa mise en œuvre est plus simple car elle ne nécessite pas de connaissances approfondies en matière d'encastrements ni de processus complexe d'ingestion de vecteurs.

En outre, la consommation de ressources est plus faible, car la recherche vectorielle nécessite une plus grande capacité de stockage et de mémoire pour l'indexation de l'incorporation et la recherche.

Un autre aspect important est la régionalisation de la recherche. Grâce aux synonymes, il est possible d'adapter les termes à la langue et aux coutumes locales. Ceci est utile dans les situations où les embeddings peuvent ne pas correspondre à des expressions régionales ou à des termes spécifiques à un pays. Par exemple, certains mots ou acronymes peuvent avoir des significations différentes selon la région, mais sont naturellement traités comme des synonymes par les utilisateurs locaux. Au Brésil, cette situation est assez courante. "Abacaxi" et "ananás" sont le même fruit (ananas), mais le second terme est plus couramment utilisé dans certaines régions du nord-est. "De même, le pão francês", bien connu dans le Sud-Est, peut être appelé "pão careca" dans le Nord-Est.

Comment utiliser les LLM pour générer des synonymes ?

Pour obtenir automatiquement des synonymes, on peut utiliser des LLM, qui analysent le contexte d'un terme et suggèrent des variations appropriées. Cette approche permet d'étendre dynamiquement les synonymes, ce qui garantit une recherche plus large et plus précise sans dépendre d'un dictionnaire fixe.

Dans cette démonstration, nous utiliserons un LLM pour générer des synonymes pour des produits de commerce électronique. De nombreuses recherches ne donnent que peu ou pas de résultats en raison de variations dans les termes recherchés. Les synonymes permettent de résoudre ce problème. Par exemple, une recherche sur "smartphone" peut englober différents modèles de téléphones mobiles, ce qui permet aux utilisateurs de trouver les produits qu'ils recherchent.

Produits requis

Avant de commencer, nous devons configurer l'environnement et définir les dépendances nécessaires. Nous utiliserons la solution fournie par Elastic pour exécuter Elasticsearch et Kibana localement dans Docker. Le code sera écrit en Python, v3.9.6, avec les dépendances suivantes :

Création de l'index des produits

Dans un premier temps, nous créerons un index des produits sans support de synonymes. Cela nous permettra de valider les requêtes et de les comparer à un index comprenant des synonymes.

Pour créer l'index, nous chargeons en masse un jeu de données de produits à l'aide de la commande suivante dans Kibana DevTools :

Générer des synonymes avec LLM

Dans cette étape, nous utiliserons un LLM pour générer dynamiquement des synonymes. Pour ce faire, nous intégrerons l'API OpenAI, en définissant un modèle et une invite appropriés. Le LLM recevra la catégorie et le nom du produit, en veillant à ce que les synonymes soient pertinents du point de vue contextuel.

À partir de l'index des produits créé, nous récupérerons tous les articles de la catégorie "Electronics" et enverrons leurs noms au LLM. Le résultat attendu sera quelque chose comme :

Avec les synonymes générés, nous pouvons les enregistrer dans Elasticsearch à l'aide de l'API Synonyms.

Gestion des synonymes avec l'API Synonyms

L'API Synonymes offre un moyen efficace de gérer les ensembles de synonymes directement dans le système. Chaque ensemble de synonymes se compose de règles de synonymie, selon lesquelles un groupe de mots est traité comme équivalent dans les recherches.

Exemple de création d'un jeu de synonymes

Cela crée un ensemble appelé "my-synonyms-set," où "hello" et "hi" sont traités comme des équivalents, ainsi que "bye" et "goodbye."

Mise en œuvre de la création de synonymes pour le catalogue de produits

Vous trouverez ci-dessous la méthode permettant de construire un ensemble de synonymes et de l'insérer dans Elasticsearch. Les règles de synonymie sont générées sur la base du mappage des synonymes suggérés par le LLM. Chaque règle possède un identifiant, correspondant au nom du produit au format "slug", et la liste des synonymes calculée par le LLM.

Vous trouverez ci-dessous la demande de création d'un ensemble de synonymes :

Une fois l'ensemble de synonymes créé dans le cluster, nous pouvons passer à l'étape suivante, qui consiste à créer un nouvel index avec prise en charge des synonymes à l'aide de l'ensemble défini.

Le code Python complet avec les synonymes générés par LLM et la création d'ensembles de synonymes définie par l'API Synonyms est ci-dessous :

Création d'un index avec prise en charge des synonymes

Un nouvel index sera créé dans lequel toutes les données de l'index products seront réindexées. Cet index utilisera le synonyms_filter, qui applique le products-synonyms-set créé précédemment.

Vous trouverez ci-dessous le mappage de l'index configuré pour utiliser les synonymes :

Réindexation de l'index products

Nous allons maintenant utiliser l'API Reindex pour migrer les données de l'index products vers le nouvel index products_02, qui prend en charge les synonymes. Le code suivant a été exécuté dans Kibana DevTools :

Après la migration, l'index products_02 sera alimenté et prêt à valider les recherches à l'aide du jeu de synonymes configuré.

Valider la recherche avec des synonymes

Comparons les résultats de recherche entre les deux index. Nous allons exécuter la même requête sur les deux index et vérifier si les synonymes sont utilisés pour récupérer les résultats.

Recherche dans l'index products (sans synonymes)

Nous utiliserons Kibana pour effectuer des recherches et analyser les résultats. Dans le menu Analytics > Discovery, nous allons créer une vue de données pour visualiser les données des index que nous avons créés.

Dans Discovery, cliquez sur Data View et définissez un nom et un modèle d'index. Pour l'index "products", nous utiliserons le modèle "products". Ensuite, nous répéterons le processus pour créer une nouvelle vue de données pour l'index "products_02", en utilisant le modèle "products_02".

Une fois les vues de données configurées, nous pouvons retourner sur Analytics > Discovery et commencer les validations.

Ici, après avoir sélectionné les produits DataView et effectué une recherche pour le terme "tablet", nous n'obtenons aucun résultat, même si nous savons qu'il existe des produits tels que "Kindle Paperwhite" et "Apple iPad Air".

Recherche dans l'index products_02 (support des synonymes)

Lors de l'exécution de la même requête sur la vue de données "products_synonyms", qui prend en charge les synonymes, les produits ont été récupérés avec succès. Cela prouve que le jeu de synonymes configuré fonctionne correctement, en garantissant que les différentes variations des termes recherchés renvoient les résultats escomptés.

Nous pouvons obtenir le même résultat en exécutant la même requête directement dans Kibana DevTools. Il suffit d'effectuer une recherche dans l'index products_02 à l'aide de l'API de recherche Elasticsearch :

Conclusion

La mise en œuvre de synonymes dans Elasticsearch a permis d'améliorer la précision et la couverture des recherches dans les catalogues de produits. Le principal facteur de différenciation était l'utilisation d'un LLM, qui générait des synonymes automatiquement et en fonction du contexte, éliminant ainsi le besoin de listes prédéfinies. Le modèle a analysé les noms et les catégories de produits, en veillant à ce que les synonymes soient pertinents pour le commerce électronique.

En outre, l'API Synonymes a simplifié la gestion des dictionnaires, en permettant de modifier dynamiquement les ensembles de synonymes. Grâce à cette approche, la recherche est devenue plus souple et plus adaptable aux différents types de requêtes des utilisateurs.

Ce processus peut être continuellement amélioré grâce à de nouvelles données et à des ajustements de modèles, ce qui garantit une expérience de recherche de plus en plus efficace.

Références

Exécuter Elasticsearch localement

https://www.elastic.co/guide/en/elasticsearch/reference/current/run-elasticsearch-locally.html

Synonymes API

https://www.elastic.co/guide/en/elasticsearch/reference/current/synonyms-apis.html

Aujourd'hui, nous annonçons la disponibilité générale du nouveau mode d'indexation d'Elasticsearch, logsdb, qui réduit l'empreinte de stockage des données de log jusqu'à 65% par rapport aux versions récentes d'Elasticsearch sans logsdb. Cette amélioration spectaculaire permet aux équipes chargées de l'observabilité et de la sécurité d'accroître la visibilité sans dépasser leur budget, tout en conservant l'accès immédiat à toutes les données à des fins d'analyse.

Logsdb optimise l'ordre des données, élimine les doublons en reconstruisant à la volée les valeurs des champs non stockés grâce à la fonctionnalité synthetic _source et améliore la compression au moyen d'algorithmes et codecs avancés, tout en utilisant le stockage en colonnes dans Elasticsearch pour un stockage et une récupération efficaces des logs.

Améliorez les analyses et réduisez les coûts en améliorant l'efficacité du stockage avec le mode d'indexation logsdb

Les logs fournissent des signaux critiques pour détecter et résoudre les problèmes d'observabilité et de sécurité, et leur utilité ne fait que croître à mesure que les avancées de l'IA facilitent l'analyse des données textuelles. Un stockage efficace et un accès performant sont donc plus importants que jamais.

Malheureusement, le volume croissant de logs généré par l'infrastructure et les applications augmente les coûts, contraignant les entreprises à faire des compromis qui entravent l'analyse : limiter la collecte, réduire la conservation ou reléguer les données récentes à des niveaux d'archivage cloisonnés.

Logsdb répond directement à ces défis. Grâce à une meilleure efficacité de stockage, vous pouvez collecter davantage de données et éviter les tracas liés à un filtrage des données compliqué. Vous pouvez conserver les logs plus longtemps pour favoriser la détection des menaces, la réponse aux incidents et la conformité. Et parce que toutes les données sont toujours consultables, vous pouvez obtenir rapidement des informations, quelle que soit la taille de votre ensemble de données.

Innovation technique associée au mode d'indexation logsdb

Le mode d'indexation Logsdb réduit considérablement l'empreinte de stockage des données de log grâce à un index trié intelligent, synthetic _source et une compression avancée. La mise en œuvre de cette solution peut réduire les besoins en stockage des logs jusqu'à 65 %, par rapport aux versions récentes d'Elasticsearch sans logsdb. Bien que logsdb utilise actuellement plus de processeur lors de l'indexation, son stockage efficace réduit les coûts globaux pour la majorité des clients. Pour les clients qui nécessitent une conservation à long terme, nous anticipons des réductions du coût total de possession pouvant atteindre 50 %.

Le tri intelligent des index améliore l'efficacité du stockage jusqu'à 30% et réduit la latence des requêtes sur certains ensembles de données de journalisation en localisant les données similaires à proximité les unes des autres. Par défaut, il trie les indices par host.name et @timestamp. Si vos données comportent des champs plus appropriés, vous pouvez les spécifier à la place.

La compression avancée réduit considérablement les besoins en stockage pour les données à forte teneur en texte, comme les journaux, grâce à la compression Zstandard (Zstd), à l'encodage delta, à l'encodage run-length et à d'autres codecs intelligents qui sont automatiquement sélectionnés. Les valeurs-documents, qui sont stockées dans un format en colonnes optimisé pour la compression et les performances, permettent de stocker et d'extraire efficacement les valeurs des champs pour le tri, l'agrégation et l'écriture de scripts.

La _source synthétique permet aux entreprises de réduire leurs besoins en stockage de 20 à 40% supplémentaires en supprimant le champ _source et en le reconstruisant entièrement ou partiellement à la demande. Bien que cette fonction nécessite parfois davantage de calculs pour l'indexation et la recherche, les tests montrent qu'elle apporte des améliorations nettes mesurables en termes d'efficacité. Synthetic _source s'appuie sur près de deux ans d'utilisation en production avec les métriques, avec de nombreuses améliorations pour les journaux, y compris la prise en charge de presque tous les types de champs.

Les économies de stockage résultantes sont répercutées à travers les différentes phases du cycle de vie des index. Une réduction du stockage de 65 % dans le niveau hot entraînera la même réduction dans les niveaux warm, cold et frozen, ainsi qu'une baisse de l'empreinte de stockage des snapshots avec un stockage en buckets.

Aucun compromis sur la visibilité : conservez tous vos logs pour l'observabilité et la sécurité

Les logs sont essentiels pour garantir la visibilité sur l'infrastructure et les applications. Ils fournissent le signal le plus simple et le plus critique pour le suivi et le dépannage. Cependant, les coûts augmentent proportionnellement aux volumes de logging. Cela contraint les clients à mettre en œuvre des politiques de filtrage et de gestion complexes, à supprimer des données prématurément et à reléguer les logs pertinents dans des magasins qui nécessitent un jour ou plus pour être réhydratés avant leur analyse. Sans un ensemble de données complet, facilement interrogeable et accessible, il est beaucoup plus difficile d'identifier et de résoudre les problèmes.

Le mode index de Logsdb s'appuie sur les fonctionnalités révolutionnaires d'Elasticsearch, telles que les instantanés consultables et l'importation automatique, pour résoudre ces problèmes pour les équipes chargées des opérations et de la sécurité :

Réduire les coûts : Logsdb réduit l'empreinte de stockage des journaux jusqu'à 65%, ce qui permet aux entreprises de réduire leurs dépenses de stockage tout en conservant davantage de données. Cela se traduit par des économies sur tous les niveaux de stockage - de l'état chaud à l'état gelé - et par une productivité accrue pour les équipes chargées de l'observabilité et de la sécurité qui utilisent ces données.

Préservez vos données précieuses : Logsdb conserve toutes les données de vos journaux et améliore l'efficacité opérationnelle sans avoir recours à des outils supplémentaires ou à des filtres compliqués. Grâce à des fonctionnalités telles que la _source synthétique, la valeur des données est préservée sans que l'intégralité du document source ne soit stockée.

Élargir la visibilité : Logsdb offre un accès efficace à toutes les données sur une seule plateforme, sans silos séparés pour l'observabilité, la sécurité et les données historiques. Pour les ingénieurs de fiabilité des sites (SRE), il accélère la résolution des problèmes en permettant l'analyse des journaux avec les métriques, les traces et les données commerciales. De même, pour les équipes des centres d'opérations de sécurité (SOC), il accélère les enquêtes et les mesures correctives en éliminant les angles morts.

Rationaliser l'accès aux données : Logsdb permet aux équipes SRE de conserver efficacement les données exploitables pour le dépannage, les tendances et l'analyse. De même, les équipes SOC peuvent rapidement rechercher toutes leurs données à des fins d'investigation et de chasse aux menaces sans encourir de coûts exorbitants.

Logsdb est prêt pour votre environnement

Le mode d'indexation Elasticsearch logsdb est généralement disponible pour les clients Elastic Cloud Hosted et Self-Managed à partir de la version 8.17 et est activé par défaut pour les logs dans Elastic Cloud Serverless.

Les fonctionnalités de base de logsdb (y compris l'index trié intelligent et la compression avancée) sont disponibles pour les entreprises disposant de licences Standard, Or et Platinum. Les capacités complètes de logsdb, qui réduisent encore les besoins en stockage (y compris synthetic _source), sont disponibles pour les clients Serverless et les entreprises avec une licence Entreprise.

Elasticsearch logsdb en action

Logsdb vous permet de conserver toutes vos données de logs et d'améliorer l'efficacité opérationnelle sans restreindre la collecte ni supprimer ou cloisonner vos données. Avec des fonctionnalités telles que l'index trié intelligent, la compression avancée et synthetic _source, conservez et analysez les données dont vous avez besoin avec le budget qui vous convient.

Vous voulez en faire l'expérience ? Essayez Elastic gratuitement.

La publication et la date de publication de toute fonctionnalité ou fonction décrite dans le présent article restent à la seule discrétion d'Elastic. Toute fonctionnalité ou fonction qui n'est actuellement pas disponible peut ne pas être livrée à temps ou ne pas être livrée du tout.

De nombreux sites de commerce électronique souhaitent améliorer leur expérience en matière de recherche de recettes. La recherche sémantique, lorsqu'elle est appliquée correctement, permet aux clients de trouver rapidement les ingrédients nécessaires sur la base de requêtes plus naturelles, telles que "quelque chose pour la Saint-Valentin" ou "les repas de Thanksgiving."

Dans cet article, nous allons montrer comment utiliser Elasticsearch pour mettre en œuvre une recherche sémantique qui prend en charge de telles requêtes. Nous configurerons un index pour stocker le catalogue des ingrédients et des produits d'un supermarché et nous montrerons comment cet index peut être utilisé pour améliorer les recherches de recettes. Tout au long de cet article, nous expliquerons comment créer cette structure de données et appliquer des techniques de traitement du langage naturel pour fournir des résultats pertinents correspondant à l'intention du client.

Tout le code présenté dans cet article a été développé en Python et est disponible sur GitHub. Vous pouvez accéder au référentiel pour examiner le code source, faire les ajustements nécessaires et mettre en œuvre les solutions directement dans votre environnement de développement.

Démarrer la mise en œuvre de la recherche sémantique

Pour commencer à mettre en œuvre la recherche sémantique, nous devons d'abord définir le modèle de langage naturel. Elastic fournit son propre modèle, ELSER, mais offre également un support pour l'intégration de modèles NLP provenant de divers fournisseurs, tels que Hugging Face. Cette flexibilité vous permet de choisir l'option qui répond le mieux à vos besoins.

Dans cet article, nous utiliserons ELSER, qui réduit la complexité du déploiement et de la gestion des modèles NLP. En outre, Elastic propose la fonction semantic_text, qui simplifie grandement le processus. Avec semantic_text, l'ensemble du processus de génération d'encarts devient simple et automatisé. Il vous suffit de définir un point d'inférence et de spécifier le champ qui recevra les embeddings dans votre mappage d'index. Lors de l'indexation des documents, des embeddings seront générés et automatiquement associés au champ spécifié.

Étapes de la configuration

Voici les étapes à suivre pour créer un index prenant en charge la recherche sémantique. En suivant ces instructions, vous aurez un index configuré et prêt pour les recherches sémantiques :

1. Créer le point d'inférence.

2. Créer l'index, en définissant le champ description comme semantic_text afin qu'il puisse recevoir les embeddings.

3. Indexer les données dans l'index "grocery-catalog", qui stockera un catalogue de produits. Ce catalogue a été obtenu à partir d'un ensemble de données disponible ici.

Application de la recherche sémantique dans les supermarchés

Maintenant que l'index est alimenté par les données sur les produits de l'épicerie, nous testons et validons les requêtes afin d'améliorer les résultats de recherche à l'aide de la recherche sémantique. Notre objectif est de fournir une expérience de recherche plus intelligente qui comprend le contexte et l'intention de l'utilisateur, en fournissant des résultats plus pertinents et plus précis.

Défis résolus par la recherche sémantique

Sur la base du catalogue de produits, examinons comment la recherche sémantique peut transformer l'expérience de recherche dans les magasins d'alimentation en abordant les questions de vocabulaire et de contexte avec lesquelles la recherche lexicale traditionnelle a souvent du mal à composer.

1. Interprétation des intentions culinaires

Problème 01: Un client peut rechercher "seafood for grilling", mais un système de recherche lexicale peut ne pas comprendre entièrement l'intention qui sous-tend la requête. Il se peut qu'il ne parvienne pas à identifier tous les produits de la mer adaptés aux grillades et qu'il ne renvoie que les produits dont le titre contient le terme exact "seafood" ou "grill".

Dans un premier temps, nous effectuerons une recherche lexicale et analyserons les résultats. Ensuite, nous ferons la même chose avec une recherche sémantique, en comparant les résultats pour le même terme de recherche.

Recherche lexicale

Résultats :

Type de recherche

Nom

Score

Lexique

Crabe des neiges Bairdi d'Alaska de Northwest Fish

10.453125

Lexique

M. Yoshida's, Sauce Original Gourmet

7.2289705

Lexique

Premium Seafood Variety Pack - 20 pièces

7.1924105

Lexique

Vivaneau rouge américain - entier, étêté, nettoyé

6.998647

Lexique

Pinces de homard & Arms, Sustainable Wild Caught

6.438654

La recherche lexicale a permis de trouver des produits de la mer adaptés à la cuisson au gril, tels que le vivaneau rouge américain et le crabe des neiges Bairdi de Northwest Fish Alaskan. Yoshida, qui n'est pas un produit de la mer mais une sauce pour la viande, ce qui suggère que l'algorithme lexical a eu du mal à comprendre le contexte de "pour les grillades."

Solution de recherche sémantique

Nous utilisons une requête qui combine le terme "seafood" avec des contextes de préparation tels que "grilling" pour obtenir une liste complète d'options, telles que les filets de poisson, les crevettes et les coquilles Saint-Jacques, qui sont idéales pour les grillades, même si les mots "grill" ou "seafood" n'apparaissent pas directement dans le nom du produit. Cela garantit que les résultats de la recherche correspondent mieux à l'intention du client.

Recherche sémantique de requêtes :

Type de recherche

Nom

Score

Sémantique

Branzino entier étêté et nettoyé

16.175909

Sémantique

Morue noire d'Alaska (morue charbonnière)

15.855331

Sémantique

Vivaneau rouge américain - entier, avec tête

15.454779

Sémantique

Crabe des neiges Bairdi d'Alaska de Northwest Fish

15.855331

Sémantique

Vivaneau rouge américain - entier, avec tête

15.3892355

La recherche sémantique a permis non seulement de trouver des produits directement liés au terme "seafood,", mais aussi de comprendre le contexte de "grilling," et de trouver des poissons entiers et des filets adaptés à la cuisson sur le gril. L'essentiel ici est la précision des résultats, qui incluent des poissons entiers tels que le branzino et le cabillaud noir d'Alaska, tous deux couramment utilisés pour les grillades.

Problème 02 : De nombreux clients recherchent des solutions rapides et faciles pour dîner après une longue journée de travail, en utilisant des termes tels que "easy weeknight meals." La recherche lexicale traditionnelle peut ne pas saisir pleinement le concept de repas rapide, en se concentrant souvent sur les produits dont le nom contient le mot "easy".

Comme dans le problème précédent, nous commencerons par effectuer une recherche lexicale. Ensuite, nous appliquerons une solution utilisant la recherche sémantique.

Recherche lexicale

Résultats :

Type de recherche

Nom

Score

Lexique

Étiquettes d'adresse Avery Easy Peel, 4200 pièces

8.017723

Lexique

Repas autochauffés d'urgence/portables 32

6.592727

Lexique

Poke de thon à nageoires jaunes en cubes de Coastal Seafood

5.836883

Lexique

Hefty Super Weight 12 oz Foam

5.8116536

Lexique

Serviette de table Vanity Fair Everyday, 2 plis, 110 unités

5.752989

La recherche lexicale a donné des résultats beaucoup moins pertinents, notamment des articles n'ayant aucun rapport avec les repas, tels que les étiquettes d'adresse Avery Easy Peel et les serviettes Vanity Fair Everyday Napkins. Ces produits ne répondent pas aux besoins des utilisateurs en matière de repas rapides. Si la recherche lexicale a permis de trouver un produit utile (Omeals Self Heating Emergency Meals), d'autres résultats, comme les serviettes et les étiquettes, ne correspondaient qu'aux mots "easy" ou "weeknight" dans leurs descriptions, sans vraiment répondre à l'intention de l'utilisateur de trouver une solution de repas rapide.

Solution de recherche sémantique

Nous avons mis en œuvre une requête qui comprend l'intention derrière les repas rapides et faciles. Il associe les produits qui peuvent être préparés rapidement, tels que les viandes précuites, les pâtes surgelées ou les kits repas, même s'ils ne comportent pas explicitement le mot "easy" dans leur nom. Cette approche permet aux clients de trouver les options les plus appropriées pour des dîners rapides en semaine, répondant ainsi à leur besoin de commodité.

Recherche sémantique

Résultats :

Type de recherche

Nom

Score

Sémantique

Repas autochauffés d'urgence/portables 32

14.610006

Sémantique

Nissin, Cup Noodles, Crevettes, 2.5 oz

13.751424

Sémantique

Mélange pour gaufres sans gluten Namaste & Mélange pour crêpes

13.73376

Sémantique

Idaho Spuds, pommes de terre rissolées Golden Grill

12.549422

Sémantique

Nissin, nouilles en coupe, poulet, 24 pièces

12.034527

La recherche sémantique a permis de trouver des produits clairement liés à des repas rapides et pratiques, tels que des nouilles instantanées (Cup Noodles), des pommes de terre précuites et des préparations pour crêpes, qui sont des choix typiques pour les dîners faciles en semaine. Cela démontre que la recherche sémantique peut saisir le concept derrière l'expression "easy weeknight meals," capturant l'intention de l'utilisateur de trouver des repas rapides et pratiques. Il est intéressant de noter que des produits appartenant à d'autres catégories, telles que "soda," peuvent également être inclus lorsqu'ils sont pertinents dans le contexte (par exemple, les boissons accompagnant les repas).

2. Termes régionaux et variations de vocabulaire

Problème: un client peut rechercher "soda," alors qu'un autre client peut utiliser "pop" pour le même produit. La recherche lexicale traditionnelle ne tient pas compte du fait que les deux termes renvoient au même élément.

Recherche lexicale

Résultats :

Type de recherche

Nom

Score

Lexique

Prime Hydration+ Sticks Mélange pour boisson à base d'électrolytes

14.492869

Lexique

Capri Sun, 100% Jus, Variety Pack

12.340851

Lexique

Boisson énergétique Joyburst, Frose Rose, 12

11.839179

Lexique

Pop-Tarts de Kellogg, givrés sucre brun cannelle

9.97788

Lexique

Mini barres Kind, emballage varié, 0.7

9.336912

La recherche lexicale se concentre sur les correspondances exactes entre les mots. Si des produits comme Prime Hydration et Capri Sun sont apparus, la correspondance directe avec le terme "pop" a également donné lieu à des résultats non pertinents, tels que Kellogg's Pop-Tarts, qui est un en-cas et non une boisson. Cela montre que la recherche lexicale peut être moins efficace lorsqu'un terme a plusieurs significations ou peut être ambigu.

Solution de recherche sémantique

Les requêtes sémantiques permettent de résoudre le problème des variations de vocabulaire que la recherche lexicale ne parvient pas à résoudre. En élargissant les termes de recherche, nous sommes en mesure d'obtenir des résultats basés sur la signification contextuelle, ce qui permet de fournir des réponses plus pertinentes et plus complètes.

Requête :

Résultats :

Type de recherche

Nom

Score

Sémantique

Olipop 12 oz Soda Prébiotique Variété

14.776867

Sémantique

Cocofusion antioxydante Bai, paquet de variétés, 18

14.663253

Sémantique

Boisson énergétique Monster, Zéro Ultra, 24

14.486348

Sémantique

Joyburst Energy Variété, 12 fl oz

14.007214

Sémantique

Boisson énergétique Joyburst, Frose Rose, 12

13.641038

La recherche sémantique renvoie des produits qui correspondent directement au concept de "pop" en tant que synonyme de "soda" (comme Olipop Prebiotics Soda), même si le terme exact "pop" n'est pas présent dans le nom du produit. La recherche a compris l'intention de l'utilisateur - une boisson rafraîchissante à faible teneur en sucre - et a pu renvoyer des produits pertinents, y compris des options telles que des sodas prébiotiques (Olipop) et des boissons énergisantes sans sucre (Monster Energy Drink).

Conclusion

La mise en œuvre de la recherche sémantique dans le contexte des magasins d'alimentation s'est avérée très efficace pour comprendre des requêtes complexes telles que "fruits de mer à griller" et "repas faciles à préparer en semaine." Cette approche nous a permis d'interpréter plus précisément les intentions des utilisateurs et de leur renvoyer des produits très pertinents.

En utilisant Elasticsearch et en simplifiant le processus avec ELSER, nous avons pu appliquer la recherche sémantique rapidement et efficacement, ce qui a permis d'améliorer considérablement les résultats de recherche et d'offrir une expérience d'achat plus souple et plus ciblée. Cela a permis non seulement d'optimiser le processus de recherche, mais aussi d'accroître la pertinence des résultats proposés aux clients.

Références

Modèle ELSER :

https://www.elastic.co/guide/en/elasticsearch/reference/current/put-inference-api.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/infer-service-elser.html

Texte sémantique :

https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-text.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-search.html

Ensemble de données :

https://www.kaggle.com/datasets/bhavikjikadara/grocery-store-dataset?select=GroceryDataset.csv

Recherche sémantique :

https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-search.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-search-semantic-text.html