Devez-vous migrer vers Elasticsearch 6 ?

La nouvelle version du moteur de recherche vient de sortir ! Nos clients ont déjà commencé à nous poser la question de la migration et nous avons donc souhaité faire un tour d’horizon des avantages qu’elle apporte par rapport à la version 5.

Section intitulée les-nouveautes-de-la-version-6Les nouveautés de la version 6

Section intitulée des-index-moins-gourmands-en-disque-durDes index moins gourmands en disque dur

Vos index vont occuper moins de place sur le disque dur et c’est une super nouvelle pour la maintenance (déplacement de shards) et les performances.

La première explication est que le très gourmand champ _all est déprécié et n’est donc plus utilisé par défaut. Si vous suivez les bonnes pratiques, vous l’avez déjà désactivé et avez déjà bénéficié de ce gain de place.

La seconde amélioration vient de Lucene, dont le stockage est maintenant optimisé pour les index avec beaucoup de champs éparses, par exemple des champs qui ne sont pas présent dans tous vos documents.

Section intitulée tri-a-l-indexationTri à l’indexation

Vous le savez peut-être, Algolia trie les documents lors de l’indexation, et non lors de la recherche. La raison est simple : c’est beaucoup plus rapide lors des recherches si les documents sont déjà triés sur le disque dur ! Cela permet, entre autre, de s’arrêter dès les dix premiers résultats trouvés – plutôt que de récupérer les 4 millions de hits et de les trier en mémoire juste pour remonter le top 10…

Elasticsearch 6 permet maintenant de faire la même chose :

PUT scoreboard
{
    "settings" : {
        "index" : {
            "sort.field" : "points",
            "sort.order" : "desc"
        }
    },
    "mappings": {
        "score": {
            "properties": {
                "points": {
                  "type": "long"
                },
                "playerid": {
                  "type": "keyword"
                },
                "game" : {
                  "type" : "keyword"
                }
            }
        }
    }
}

Dans cet exemple, un tri est défini dans la configuration de l’index, sur la valeur du champ points.

Lors de la recherche, nous pourrons alors spécifier le même tri, désactiver le « total hits » (facultatif) et obtenir des temps de réponse très fortement réduits grâce au circuit breaker :

GET scores/score/_search
{
  "size": 3,
  "track_total_hits" : false,
  "sort": [
      { "points": "desc" }
  ]
}

Il est possible de spécifier plusieurs tris, et surtout, votre index est toujours triable comme vous voulez à la recherche. Contrairement à Algolia qui nécessite de créer un index réplica par tri, cette optimisation d’Elastic ne vous contraint pas – le seul inconvénient est que vos indexations seront plus lentes (on passe de 76k document par seconde à 47k dans ce benchmark). C’est donc à réserver aux contextes dans lesquels la vitesse d’écriture n’est pas critique.

Section intitulée meilleure-recuperation-de-shardMeilleure récupération de shard

Le cluster est maintenant capable de savoir précisément ce qu’un shard a manqué lors d’une coupure (reboot d’un node par exemple) et de ne rejouer qu’une partie des transactions, au lieu de télécharger à nouveau l’ensemble des segments. Chaque opération introduit un numéro unique de transaction propre à chaque shard, qui permet de savoir de façon certaine quelles sont les différences entre deux shards, quelque soit leurs segmentations, leurs positions… Un rolling restart sur un gros cluster va donc durer beaucoup moins longtemps !

Section intitulée disparition-des-typesDisparition des types

Les types sont dépréciés. Votre organisation de documents en Index – Type – Document va donc devoir être revue.

Plus précisément, dans la version 6, les index migrés depuis la version 5 seront rétrocompatibles, et auront toujours leurs différents types. Mais les nouveaux index ne pourrons plus déclarer qu’un seul type (du nom de votre choix).

Les APIs ne changent pas avant la version 7 du moteur, et la compatibilité avec les clients (PHP, JavaScript…) ne posera donc aucun problème.

Si vous utilisez la relation Parent – Child, vous allez devoir utiliser le nouveau type join, et placer vous même des clés de routing lors de l’indexation !

Section intitulée autres-ameliorationsAutres améliorations

Elasticsearch n’est que le coeur d’une stack très riche, et Kibana, Logstash et consorts ont aussi quelques fonctionnalités à vous offrir :

• Logstash va simplifier sa configuration pour permettre de séparer les différentes sources et workflows en différent fichiers, appelés « Pipelines » ;
• Dans Kibana, ces pipelines Logstash seront visualisables graphiquement, avec les temps de traitement des filtres, la quantité d’événements… sur chaque élément du graph (X-Pack Basic) ;

• ​Dans Kibana toujours, vous allez pouvoir exporter en CSV vos résultats de recherche en un clic ! Une feature très demandée enfin disponible 😋 !

• Kibana est plus accessible avec la navigation clavier et le contraste amélioré ;
• Un nouveau language de recherche arrive dans Kibana : Kuery. Désactivé par défaut, il devrait remplacer le Lucene Query Language de la barre de recherche : il est composé de clauses du Query DSL sous forme de fonctions, interprétées par Kibana :
  • is("response", 200) ;
  • range("bytes", gt=1000, lt=8000) ;
  • not(is("response", 404)).

Section intitulée x-pack-gold-s-amelioreX-Pack Gold 💸 s’améliore

Nous retrouvons évidemment beaucoup d’améliorations dans les fonctionnalités payantes de la suite Elastic :

• Les Watchers sont par exemple distribués, alors qu’ils étaient précédemment seulement exécutés sur le node master ;
• La possibilité de configurer les pipelines de Logstash graphiquement depuis des formulaires dans Kibana, ce qui permet de mettre à jour les traitements de vos logs sans connexion SSH, sans restart de service… ;
• Il est maintenant possible d’avoir des alertes lors de problèmes sur un cluster (il s’agit en fait de watcher built-in) ;

• La création d’alertes sur des seuils particuliers est maintenant graphique ! Vous avez donc un éditeur graphique et une représentation temps réelle de vos critères et de votre seuil d’alerte :

Section intitulée de-la-necessite-de-migrerDe la nécessité de migrer

Si vous utilisez encore la version 2.4, ou pire la version 1.7, je vous conseille de migrer dans l’année pour des raisons de sécurité principalement (et de performances ensuite). En effet, la branche 2 cesse d’être maintenue à la sortie de la version 6.0, et la branche 1 n’est plus maintenue depuis Janvier 2017. Le détail des fins de vie est documenté sur cette page.

Si vous utilisez Elasticsearch 5.x à l’heure où vous lisez ces lignes, la migration n’est pas urgente. Il faut la considérer par rapport à l’apport technique – est-ce que les nouveautés citées plus haut vous sont vraiment utiles ? Et est-ce que :

• Tous vos plugins sont compatibles ?
• Votre client Elasticsearch est à jour ? Par exemple, il faut maintenant envoyer un header Content-Type pour tous les appels à l’API !
• Vous n’utilisez pas les types (sinon vous auriez des développements à faire pour assurer la compatibilité) ;
• Tous les outils de la stack (Beats, Kibana, Logstash) sont-ils migrables ?

Soyez prêt, mais ne sautez pas sur la première version 6.0 dès la sortie, sauf si vous disposez d’un environnement de staging pour mettre à l’épreuve le logiciel avec votre usage.

Section intitulée de-la-facilite-de-migrerDe la facilité de migrer

La migration est facilitée pour cette version car les équipes d’Elastic ont réussi à faire en sorte qu’un index créé par Elasticsearch 5 puisse fonctionner avec Elasticsearch 6. Cela signifie qu’une mise à jour en « rolling restart » est possible et donc pas de downtime à prévoir… à la condition que vous soyez compatibles 😛.

X-Pack Basic propose aussi un nouveau Upgrade Assistant, qui reprend le Cluster Checker, le ReIndex Helper… dont nous avions besoin pour passer de la version 2 à la version 5.

Section intitulée pour-conclurePour conclure

J’espère que cet article vous aide à y voir plus clair sur cette nouvelle version, ses avantages et ses défauts.

Pour résumer en 4 points :

• Moins d’espace disque ;
• Une restauration plus rapide des shards ;
• La dépréciation des types ;
• Plein de nouveautés dans Kibana et les pipelines dans Logstash.

Sachez enfin que pour tous vos besoins d’audits, d’expertise, de formation Elasticsearch et de recherche full-text, nos experts interviennent sur site et à la journée : de quoi booster significativement l’expérience de vos équipes… ou de migrer vers Elasticsearch 6 !