Elasticsearch 8 : le langage naturel fait son entrée

Points de terminaison, fonctions, paramètres, attributs… Qui dit nouvelle version majeure d’ElasticSearch dit évolution des API. La dernière (8.0), fraîchement publiée, ne fait pas exception. Sur l’interface REST, en particulier, elle apporte son lot de ruptures susceptibles de nécessiter une mise à jour des applications.

Pour amortir le choc, Elastic a mis en place un mode de compatibilité avec l’API 7.x. En opt-in pour chaque requête, implémenté via les en-têtes Accept et Content-Type. Son rôle : adapter tant que possible URL, corps des requêtes/réponses et paramètres HTTP.

Ce mécanisme permet notamment d’ignorer des paramètres devenus invalides, comme interval pour les histogrammes de date. Ou de contourner des fonctionnalités qu’Elasticsearch ne prend plus en charge, à l’image des types de schémas personnalisés. Ou encore de remplacer un endpoint par un autre.

Le mode de compatibilité n’agit cependant pas sur tout. Dont, évidemment, les changements qui n’offrent pas d’alternative. Exemple pour la recherche cross-cluster. Avec l’API 7.x, les clusters distant pouvaient utiliser toute version mineure située sur la même branche majeure que le cluster local ; voire la dernière mineure de la précédente branche majeure. Avec Elasticsearch 8.0, la limite de rétrocompatibilité est à [mineure -1].

NLP et sécurité par défaut

Autre nouveauté d’Elasticsearch 8 : une forme de security by design, à travers l’activation automatique de certains éléments au premier démarrage. En l’occurrence :

– Création des certificats TLS pour la communication internœuds et Elasticsearch-Kibana
– Création d’un mot de passe pour l’utilisateur elastic et d’un token d’enregistrement pour Kibana

Elastic met aussi en avant :

– Une meilleure protection contre les accès directs aux index système
D’une part, il faut désormais la permission allow_restricted_indices. De l’autre, le rôle de superutilisateur ne donne plus de droits en écriture.

– En aperçu, une nouvelle API pour le kNN (recherche des k plus proches voisins d’un vecteur). Exploitant l’algorithme HNSW, elle est moins précise que l’ancienne, mais plus rapide.

– L’optimisation du stockage pour les champs keyword, match_only_text et text. En moyenne, il utilise 3,5 % d’espace en moins.

– Une indexation plus rapide des champs geo_point et geo_shape

– La prise en charge des modèles PyTorch – préentraînés – pour le traitement du langage naturel

Photo d’illustration © agsandrew – Shutterstock