Elasticsearch devient de plus en plus populaire au fil des années, aidant les clients à explorer et analyser leurs données différemment avec la recherche. Plus récemment, il a été présenté dans le quadrant de Gartner. Avec Elasticsearch, c’est incroyable à quel point il est facile de lancer un cluster et de se mettre au travail. Cependant, si vous ne configurez pas votre cluster en conséquence, vous rencontrerez des problèmes tôt ou tard.

Dans cet article, nous nous concentrerons sur l’ajustement du comportement par défaut d'Elasticsearch concernant le stockage des champs originaux. Nous prêterons également attention aux bénéfices et inconvénients potentiels en termes de performance qui peuvent survenir.

Ce que nous avons essayé de faire

Dans un article précédent sur l’App Fonction, j’ai écrit sur l’extraction et le traitement de texte à partir de documents PDF. Maintenant, je vais partager comment nous avons rendu tous les résultats de calcul disponibles pour la recherche en optimisant la performance.

Notre jeu de données est composé de documents JSON combinant du texte extrait et des attributs à partir de PDF. La taille du texte est, en moyenne, de 200K caractères. L’expérience utilisateur doit être la même que celle d'un célèbre moteur de recherche comme Google. De plus, lorsqu’un utilisateur saisit une requête, il doit recevoir une réponse rapidement. Un résultat après 1 minute n’a pas de sens dans nos cas d’utilisation.

Notre jeu de données sera de 32 To de données indexées. De plus, nous savons que l’extensibilité horizontale d'Elasticsearch est bien meilleure que son extensibilité verticale et qu'il peut facilement gérer les données et la charge de travail. Ce sera une question d’architecture et de nombre de nœuds.

Au début, nous avons un cluster composé de 21 nœuds comme estimation de base. Il y a certaines optimisations et configurations qui méritent d’être mentionnées et expérimentées, par exemple, les champs stockés et les surlignements. Nous nous concentrerons sur la configuration des champs stockés dans cette première partie.

Le champ stocké dans Elasticsearch

Dans Elasticsearch, un champ stocké vous permet de récupérer sa valeur originale dans un résultat de requête. Le document original sera stocké dans un champ appelé source_, qui sera retourné. Dans la plupart des cas, c’est ainsi que vous obtenez le document original à partir de votre recherche. Par défaut, le source_ contient tous les champs, y compris les grands, à moins que vous n'excluiez/incluiez explicitement des champs.

Elasticsearch lira le _source depuis le disque chaque fois que vous exécutez une requête, le analysera en JSON et le retournera. Lire un tel champ stocké contenant un texte long peut être un problème de performance tant au niveau du CPU (analyse de la structure JSON large) que des entrées/sorties du disque (lecture de nombreuses données). De plus, lire une quantité de données inutilement importante depuis le disque saturera le cache du système de fichiers le rendant moins efficace. Selon la taille du grand champ de texte et les cas d’utilisation, il serait judicieux d'ajuster le comportement par défaut pour obtenir une meilleure performance.

Ajuster le _source dans Elasticsearch

Elasticsearch offre la possibilité d'exclure des champs de cet _source particulier. Il vous donne également la possibilité de stocker un champ spécifique par lui-même, séparément du _source. De cette façon, vous pourrez retourner des informations précieuses comme « titre » et d'autres métadonnées attachées au document sans avoir à analyser et lire du texte long.

Pour stocker votre champ séparément, vous devez configurer votre mappage d'index : - L'exclure du _source. - Spécifier store: true pour le stocker séparément.

{
"mappings": {
  "_source": {
    "excludes": ["content"]
  },
  "properties": {
    "content": {
      "type": "text",
      "store": true
    },
    "author": {
      "type": "keyword"
    },
    "title": {
      "type": "keyword"
    }
  }
}
}

Bien que la solution offre un potentiel d'amélioration des performances considérable, elle apporte également des inconvénients importants que vous devez connaître.

Comme expliqué dans la documentation officielle, exclure des champs du _source désactivera également certaines fonctionnalités utiles :

• APIs Update, update_by_query et reindex.

• La fonctionnalité de surlignage des champs non stockés. Le surlignage des résultats de recherche nécessite que le champ soit stocké d'une manière ou d'une autre.

• Mettre à jour un index vers une version majeure. À un moment donné, vous ne pourrez pas mettre à niveau davantage.

• Capacité à déboguer les requêtes en visualisant le document original.

• Toute fonctionnalité future potentielle nécessitant le _source original contenant tous les champs.

Ce que nous recommandons dans Elasticsearch

Il est maintenant évident que ce type d'amélioration des performances est coûteux. Certains scénarios nous viennent à l'esprit :

• Si vous utilisez le texte long uniquement pour construire l'index inversé pour la recherche en texte intégral, il sera judicieux de l'exclure du _source. Vous réduirez potentiellement votre charge de travail en entrée/sortie et CPU, mais aussi l'utilisation du disque.

• Si nous avons des cas particuliers rares où nous devons récupérer le texte long, il sera judicieux de le stocker séparément du champ _source.

Selon nos cas d'utilisation (champ large de 200 Ko), nous n'avons pas constaté d'amélioration notable en stockant le champ texte long séparément justifiant de tels inconvénients. Nous croyons que le cache du système de fichiers a fait la différence.

Comme indiqué dans cet article sur l'optimisation des performances d'Elasticsearch, il est judicieux d'exclure explicitement le champ du _source lorsque la taille du champ est suffisamment grande (100 Mo) pour que l’amélioration des performances l'emporte sur les inconvénients. Dans ce cas très particulier, nous recommandons fortement de conserver les données dans un stockage de données séparé pour :

• Mettre à jour des documents en supprimant et ré-indexant manuellement.

• Mettre à jour des indices vers une version majeure.

Lors de la mise à niveau, vous devrez repartir avec un cluster vide et ré-indexer tous les documents manuellement. Dans certains cas, cela pourrait être inacceptable d'un point de vue commercial, et vous devrez alors travailler avec deux clusters séparés pour minimiser les temps d'arrêt. Vous pourriez également travailler avec un seul cluster si celui-ci est suffisamment grand pour indexer vos données deux fois.

Conclusion

Nous avons initialement cru que notre jeu de données inclurait un champ de texte volumineux. Nous avons rapidement réalisé que notre champ n'était pas si volumineux, et Elasticsearch est capable de gérer un champ de texte beaucoup plus grand que nous le pensions. L'idée de stocker le champ de texte volumineux séparément peut sembler intrigante au début, mais elle n'apporte aucun avantage de performance précieux dans notre dataset. Nous croyons toujours fermement qu'elle pourrait augmenter les performances dans certains cas particuliers exceptionnels.

Dans l'ensemble, exclure des champs du _source doit être une décision réfléchie. Dans la plupart des cas, nous ne recommandons pas de modifier le _source sauf si un champ est suffisamment grand pour justifier les inconvénients. Pour en savoir plus sur ce sujet, nous vous invitons à lire cette discussion.