29 juin 2015 Nouveautés

Elasticsearch 2.0.0.beta1 bientôt disponible !

Par Clinton Gormley

Update November 2, 2015: The real deal is here! Learn more about Elasticsearch 2.0 GA.

Nous nous préparons à lancer Elasticsearch 2.0.0.beta1, qui bénéficie des améliorations disponibles dans Lucene 5.2.1. Cette nouvelle version apportera plusieurs fonctionnalités fantastiques. Par exemple :

Agrégations en pipeline

Il s'agit de la possibilité de réaliser des agrégations, comme des dérivées, des moyennes glissantes ou des suites arithmétiques, à partir des résultats d'autres agrégations. Ces calculs ont toujours été réalisables côté client, mais le fait de les déplacer dans Elasticsearch facilite l'élaboration de requêtes analytiques plus performantes tout en simplifiant considérablement le code côté client. Cette fonction ouvre la voie aux analyses prédictives et à la détection d'anomalies.

Fusion requête/filtre

Oubliez les filtres. Toutes les clauses de filtres sont désormais remplacées par des clauses de requêtes. Lorsqu'elles sont utilisées dans le contexte d'une requête, elles agissent sur le score de pertinence, et lorsqu'elles sont utilisées dans le contexte d'un filtre, elles permettent simplement d'exclure les documents qui ne correspondent pas aux critères, tout comme les filtres à l'heure actuelle. Cette restructuration signifie que l'exécution des requêtes peut être automatiquement optimisée pour se dérouler dans l'ordre le plus efficace. Par exemple, les requêtes lentes, comme des recherches de texte ou de localisation géographique, procèdent tout d'abord à une phase rapide mais approximative, puis affinent les résultats grâce à une deuxième phase plus lente et plus précise. Dans le contexte d'un filtre, les clauses souvent utilisées seront mises en cache automatiquement dès que cela sera pertinent.

Compression de stockage configurable

Le paramètre index.codec vous permet de choisir entre une compression selon l'algorithme LZ4 pour plus de rapidité (default) ou l'algorithme DEFLATE pour un index de plus petite taille (best_compression). Cette fonction est particulièrement utile pour le logging : les vieux index peuvent être passés en best_compression avant d'être optimisés.

Nous publierons bientôt des articles de blog sur ces sujets.

Performance et résilience

La liste de fonctionnalités disponibles semble plutôt courte pour la sortie d'une nouvelle version majeure. La raison est que la plupart des modifications de la version 2.0 portent sur des fonctions internes qui ne sont pas immédiatement visibles pour l'utilisateur.

Les thèmes majeurs de cette nouvelle version sont la performance, la stabilité, la solidité, la prédictibilité et la facilité d'utilisation :

  • Tout doit fonctionner comme prévu, sans surprises.
  • Elasticsearch doit fournir un retour pertinent si vous faites une fausse manipulation.
  • Vous ne devez pas avoir à modifier des paramètres complexes, alors qu'Elasticsearch est à même de prendre les meilleures décisions à votre place.
  • Et par-dessus tout, vos données doivent être en sécurité.

Ces objectifs ne sont pas tout à fait atteints (de nombreuses améliorations sont encore à venir), mais nous avons déjà réalisé d'énormes progrès, avec plus de 500 nouveaux commits dans la branche 2.x, par exemple :

  • L'utilisation par défaut de Doc Values sur disque plutôt qu'en mémoire, afin de limiter l'usage de la heap et d'améliorer la scalabilité.
  • La réduction de l'utilisation de la heap pendant les opérations de merge de segments.
  • L'amélioration de la compression des "norms", qui prenaient jusque là beaucoup d'espace heap.
  • Le fait que les écritures soient désormais durables par défaut, grâce au fsync systématique du journal de transaction après chaque requête.
  • Les modifications de fichiers sont toutes atomiques : fini les fichiers partiellement écrits.
  • Limitation automatique des merges.
  • Les requêtes par termes et par plages de valeurs sont plus rapides.
  • Les bitsets sont compressés pour une mise en cache plus efficace du filtre.
  • Les petites mises à jour de l'état du cluster sont gérés par des diffs.
  • Les exceptions JSON sont lisibles et structurées.
  • Les rapports de mémoire Lucene sont plus précis.
  • Le démarrage se fait uniquement en local par défaut, afin d'éviter qu'un noeud de développement ne rejoigne par erreur un autre cluster.
  • La relation parent/enfant est réécrite afin de bénéficier d'une exécution optimale des requêtes.
  • L'exécution se fait avec les autorisations minimales sous le Security Manager de Java.
  • Tous les plugins essentiels ont été déplacés vers le dépôt Elasticsearch principal et seront livrés en synchronisation parfaite avec chaque version d'Elasticsearch.

Bon à savoir avant la mise à niveau

Les mises à niveau importantes nous donnent l'occasion de passer un bon coup de balai. Nous essayons dans la mesure du possible de fournir une mise à niveau facile et rétrocompatible pour chacune de ces modifications. Cependant, il reste deux modifications pour lesquelles vous devrez intervenir avant de pouvoir passer à Elasticsearch 2.0.

La première concerne les mappings de champs et de types. À l'heure actuelle, les API de mapping sont trop tolérantes. Nous comptons sur les utilisateurs pour se renseigner sur les bonnes pratiques au lieu de trop verrouiller le système. Dans la version 2.0, les mappings sont plus stricts et plus sûrs, mais certaines des modifications ne seront pas rétrocompatibles. Vous en apprendrez plus à ce sujet dans l'article The Great Mapping Refactoring.

La seconde modification concerne les utilisateurs qui sont avec nous depuis Elasticsearch 0.20, ou même avant - versions qui fonctionnaient avec Lucene 3.x. Elasticsearch 2.x est basé sur Lucene 5, et cette version est fournie avec la prise en charge de la lecture des index écrits sous Lucene 4.x, mais pas Lucene 3.x.

Si vous avez des index créés avec Elasticsearch version 0.20 ou antérieure, vous ne pourrez pas créer de cluster sous Elasticsearch 2.x. Vous devrez supprimer ces index obsolètes ou bien les mettre à niveau avec l'API upgrade disponible à partir d'Elasticsearch version 1.6.0 ou ultérieure.

L'API upgrade effectue deux tâches :

  • Réécriture au dernier format de tous les segments utilisant un des anciens formats Lucene.
  • Ajout d'un paramètre permettant de marquer l'index afin qu'il soit lisible par Elasticsearch 2.x.

Bien qu'il soit pertinent de mettre tous les segments à niveau vers la dernière version, vous pouvez choisir de procéder au minimum de manipulations possible avant la mise à niveau : mettez à niveau uniquement les segments Lucene 3.x en spécifiant le paramètre only_ancient_segments.

Plugin Migration Elasticsearch

Nous avons publié le plugin Migration Elasticsearch pour vous aider à vérifier si vous devez mettre vos index à niveau ou effectuer toute autre action avant de migrer sous Elasticsearch 2.0. Veuillez le télécharger et l'exécuter sur votre cluster avant la mise à niveau.

Tout d'abord, installez le plugin :

./bin/plugin -i elastic/elasticsearch-migration
        

Le plugin peut être installé sur un cluster en ligne, et il n'est pas nécessaire de redémarrer le noeud.

Ensuite, ouvrez le plugin dans votre navigateur en suivant ce lien :

http://localhost:9200/_plugin/migration

(Modifiez localhost:9200 pour le remplacer par le nom d'hôte du noeud où est installé le plugin.)

Si vous rencontrez des bugs dans le plugin Migration ou avez des suggestions d'amélioration, veuillez ouvrir un ticket sur GitHub issue tracker.