Elasticsearch 2.0

Elasticsearch est un moteur de recherche distribué, RESTful, reposant sur la bibliothèque Apache Lucene et sous licence Apache 2.

Si vous ne le connaissez pas encore, vous pouvez vous reporter à la précédente dépêche, Sortie d'Elasticsearch en version 1.0 où un rapide test est disponible.

Vous pouvez aussi voir tous les contenus taggés avec elasticsearch.

Sommaire

• • Que s'est-il passé depuis la 1.0 ?
    • Version
    • Sécurité
    • Résilience
  • Les nouveautés de la 2.0
    • Refactoring des mapping
    • Meilleure compression des index
    • Meilleure exécution des requêtes
    • Enchainement d'agrégation
    • Delete by query
    • Réseau
  • Mise à jour

Que s'est-il passé depuis la 1.0 ?

Version

Depuis le 12 février 2014, 37 versions sont sorties, de la 1.0.0 à la 1.7.3 .

Ci-dessous les versions avec leurs principales fonctionnalités et un lien vers leurs annonces:

• 1.7 : Allocation des shards différée et priorisation de la récupération des index (Elasticsearch 1.7.0 and 1.6.1 released)
• 1.6 : Démarrages plus rapide avec les purges synchrones, allocation des shards non bloquant, filtrage de la réponse JSON, API de mise à jour des anciens index, configuration fine pour les scripts (Elasticsearch 1.6.0 released)
• 1.5 : Nouvelles fonctionnalités Inner hits et Shadow replicas ; amélioration de la résilience (Elasticsearch 1.5.0 Released)
• 1.4 : Amélioration de la résilience (Elasticsearch 1.4.0 And 1.3.5 Released)
• 1.3 : JSONP déactivé par défaut, Groovy comme nouveau langage de scripting par défaut, nouveaux types agrégations, etc. (Elasticsearch 1.3.0 And 1.2.3 Released)
• 1.2 : Java 7 obligatoire, scripts dynamiques déactivés par défaut, nouveau circuit breaker pour les fielddata, nouveau système de suggestion Context Suggester (Elasticsearch 1.2.0 and 1.1.2 released)
• 1.1 : Meilleure recherche multi-champs, templates de recherche, nouvelles agrégations cardinality, significant_terms et percentiles (Elasticsearch 1.1.0, 1.0.2 and 0.90.13 released)

Sécurité

Avec les scripts dynamiques et sans authentification par défaut, une faille dans la gestion des scripts a pu être exploitée au printemps 2014 (et ce malgré un article Securing Your Elasticsearch Cluster de décembre 2013).

Un article décrivant la faille et son exploitation : Insecure default in Elasticsearch enables remote code execution

À partir de la version 1.2, les configurations par défaut dans ce domaine ont été changées et la sécurité est devenue prioritaire dans les développements.

L'article qui a suivit cette histoire : Scripting and Security

LinuxFr.org a été touché par cette faille, voir la dépêche suivante : Quoi de neuf côté LinuxFr.org - Faille ElasticSearch sur juin/juillet 2014

Résilience

Le deuxième important point de travail de cette série 1.x est la résilience. Après avoir été bousculé par Aphyr sur la version 1.1, Elasticsearch a notifié dans une page de documentation tous les problèmes de résilience (Elasticsearch Resiliency Status)

Tous les articles d'Aphyr sur Elasticsearch.

Les nouveautés de la 2.0

Après deux bêta et une rc, Elasticsearch 2.0 est sorti le 28 octobre 2015:

• Elasticsearch 2.0.0 GA released
• Elasticsearch 2.0.0-rc1 released
• Elasticsearch 2.0.0-beta2 released
• Elasticsearch 2.0.0-beta1 released
• Elasticsearch 2.0.0.beta1 coming soon!

Ci-dessous, un résumé des articles du blog d'Elastic sur les nouveautés de cette version majeure.

Refactoring des mapping

Dans un même index, il est maintenant interdit pour deux types différents d'avoir deux champs de même nom mais de type différent. Aujourd'hui, ce genre de configuration peut donner des résultats faux, des exceptions et même des corruptions d'index.

L'accès à un champ par son nom court était ambigu, il est maintenant nécessaire d'utiliser le chemin complet.

La création de mapping dynamique est maintenant synchrone, c'est-à-dire que le nouveau mapping doit être accepté par un master. Un même champ pouvait être ajouté à deux shards en même temps mais avec deux types différents, ce qui conduisait à une corruption d'index.

Diverses simplifications dans la configuration des analyzers et des champs meta.

Tous les détails se trouvent dans l'article suivant The Great Mapping Refactoring.

Meilleure compression des index

Lucene 5.0 apporte un nouveau codec améliorant la compression des index.

Il est maintenant possible de choisir une meilleure compression avec un codec basé sur DEFLATE pour par exemple un index froid ou de conserver le codec basé sur LZ4 pour les index chauds.

Tous les détails sont dans l'article suivant : Store compression in Lucene and Elasticsearch

La notion de codecs pour Lucene a déjà été évoquée sur le blog d'Elastic : What is an Apache Lucene Codec?

Meilleure exécution des requêtes

Des modifications dans Lucene 5.0, 5.1 et 5.2 permettent aujourd'hui d'effacer pour l'utilisateur la distinction entre query et filter et c'est Elasticsearch qui va faire les choix de mise en cache ou non des résultats intermédiaires.

À l'origine, les filtres diffèrent des requêtes par le fait qu'ils ne font pas de scoring, mais peuvent être mis en cache. Dans Elasticsearch 2.0 c'est maintenant le même objet interne.

L'article suivant présente tout les détails : Better query execution coming to Elasticsearch 2.0

Enchainement d'agrégation

Les Pipeline Aggregations sont une nouveauté qui permet de faire des calculs sur des résultats d'agrégations précédentes.

Il y a une petite dizaine de nouvelles agrégations de ce type que je vous laisse découvrir en détails dans les articles suivants :

• Out of this world aggregations
• Staying in Control with Moving Averages - Part 1
• Staying in Control with Moving Averages - Part 2

Delete by query

L'API Delete by Query est désormais fourni sous forme de greffon.

La précédente implémentation, en effectuant un refresh après chaque suppression pouvait provoquer de nombreuses créations de segments et déclencher de nombreux merge. De plus elle pouvait provoquer des incohérences entre répliques.

Le plugin se base lui sur l'API scan/scroll. Tous les détails dans l'article The Delete by Query API Is now a plugin

Réseau

Il était très facile, certainement trop, pour des instances de développement d'Elasticsearch de former un cluster. À partir de cette version 2.0 seules les instances locales (localhost) pourront former un cluster, avec la configuration par défaut,

Autre changement côté réseau, le multicast, qui était assez bancal dû entre autre à des différences de comportement entre Linux et OS X, est désormais fourni en tant que greffon.

Le détail dans l'article suivant : Elasticsearch unplugged - Networking changes in 2.0

Mise à jour

Avant de mettre à jour, pensez à lire la page Breaking changes in 2.0. Un plugin est mis à disposition pour vérifier qu'un cluster peut être mis à jour directement ou s'il présente des incompatibilités : Elasticsearch Migration Plugin.

À vos claviers !

Aller plus loin

• Elasticsearch 2.0.0 GA released (472 clics)
• Elasticsearch: The Definitive Guide (302 clics)