Elasticsearch 2.0

Posté par (page perso) . Édité par palm123, tankey, Benoît Sibaud et Pierre Jarillon. Modéré par ZeroHeure. Licence CC by-sa
38
30
oct.
2015
Base de données

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

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:

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:

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 :

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 !

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.