Elasticsearch 5.0.0

La vitesse d'indexation s'est considérablement améliorée dans la version 5.0.0 grâce à un certain nombre de modifications, comme l'amélioration des structures de données numériques (cf. Nouvelles structures de données), la réduction de la contention sur les verrous afin d'éviter les conflits entre les mises à jour d'un même document et la diminution des exigences de verrouillage lorsque fsync est effectué sur le journal de transaction. L'utilisation asynchrone de fsync sur plusieurs journaux bénéficie tout particulièrement aux utilisateurs de disques durs classiques (rotatifs), et les performances pour le cas d'utilisation en mode « append only » (par exemple pour les événements temporels) ont été énormément améliorées si l'on se sert d'Elasticsearch pour autogénérer des ID de documents. La modification interne de la prise en charge en temps réel du GET des documents a également permis d'augmenter l'espace disponible pour la mémoire-tampon d'indexation et de diminuer le temps de Garbage Collection.

Selon votre utilisation, vous pourrez constater entre 25 % et 80 % d'amélioration pour la vitesse d'indexation.

Alimenter Elasticsearch avec vos données est devenu un jeu d'enfant. Logstash est un outil puissant, mais pour de nombreux cas d'usage, seuls les filtres sont vraiment utiles car il n'y a pas de besoin des options de routage avancées. Nous avons repris les filtres les plus populaires de Logstash comme grok, split, convert et date, et nous les avons intégrés directement dans Elasticsearch en tant que processeurs. Plusieurs processeurs sont associés dans un même pipeline, lequel peut être appliqué aux documents au moment de l'indexation via les API d'indexation ou de bulk.

Désormais, grâce à l'API Ingest, ingérer des messages logs est devenu aussi facile que de configurer un pipeline et de paramétrer Filebeat pour qu'il envoie un fichier log à Elasticsearch. Vous pouvez même lancer des nœuds d'ingestion dédiés pour séparer le travail d'extraction et d'enrichissement des opérations de recherches, agrégations et indexations. Pour en savoir plus, consultez A New Way to Ingest - Part 1.  Si vous avez des idées pour de nouveaux processeurs ou si vous souhaitez soumettre votre propre processeurs, dites-le nous !

L'utilisation de scripts est omniprésente dans Elasticsearch et c'était très frustrant de ne pas pouvoir l'activer par défaut pour des raisons de sécurité. Nous sommes donc ravis d'annoncer que nous avons développé un nouveau langage de script, rapide, sûr, sécurisé et activé par défaut, appelé Painless. Pour ne rien gâcher, Painless est 4 fois plus rapide Groovy et il ne cesse de s'améliorer. Nous aimons tellement Painless que nous en avons fait notre langage script par défaut et que nous avons déprécié Groovy, Javascript et Python. Evidemment vous pouvez utiliser Painless dans une script query ou déclencher des alertes basées sur des conditions définies par des scripts Painless lorsque vous utilisez X-Pack mais vous pouvez aussi utiliser un script Painless avec l'API de ré-indexation ou avec Ingest Node pour manipuler vos documents de façon efficace

Pour en savoir plus sur Painless, lisez l'article Painless: A New Scripting Language.

Lucene 6 a apporté une nouvelle structure de données Points pour les champs numériques et géo-points appelés Block K-D trees, ce qui a révolutionné l'indexation et la recherche de valeurs numériques. Notre banc d'essai montre que les Points sont 36 % plus rapides pour les requêtes, 71 % plus rapide pour l'indexation et ils utilisent 66 % d'espace disque en moins et 85 % d'espace mémoire en moins (cf. Searching numb3rs in 5.0). L'ajout de Points signifie que le champ ip peut désormais prendre en charge les adresses IPv6 ainsi que IPv4. Qui plus est, nous avons changé les champs geo_point afin d'utiliser le nouveau LatLonPoint de Lucene, car ce dernier double la performance des requêtes de géolocalisation.

Nous avons également ajouté un type de champ half_float pour les virgules flottantes de demi-précision (16 octets) ainsi qu'un type scaled_float mis en œuvre en interne en tant que champ long, de sorte à bénéficier des techniques de compression utilisées pour les longs. Ces nouveaux types sont synonymes d'une utilisation d'espace disque sensiblement réduite, en particulier pour les données métriques.

Les champs de type chaînes analysées et non analysées ont été remplacés par des champs de type text pour les recherches type full text, et par des champs de keyword pour les recherches par identifiant, les tris et les agrégations. Consulter Strings are dead, long live strings!

Enfin, les noms de champs contenant des points (« . ») sont de retour, mais correctement pris en charge cette fois-ci : un champ contenant des points, comme foo.bar est l'équivalent d'un champ bar à l'intérieur d'un champ objet foo. Pour ceux d'entre vous qui restent fidèles à 1.7 parce que les noms de champs contenant des points ne sont pas pris en charge dans 2.x, consultez Elasticsearch 2.4.0 qui fournit un plan de migration.

Les magnifiques graphiques de Kibana qui représentent les statistiques sur une journée, un mois ou une année vont bénéficier d'un sérieux coup d'accélérateur grâce à Instant Aggregations. La plupart des données de ces graphiques provient d'index qui ne sont plus actualisés, mais Elasticsearch devait recalculer l'agrégation depuis le début pour chaque requête car il était impossible de mettre en cache une gamme de type { "gte": "now-30d", "lte": "now" }. Après toute une année passée à retravailler l'API de recherche, Elasticsearch peut désormais exécuter une gamme de requête de manière bien plus intelligente en ne recalculant l'agrégation que pour les index qui ont changés.

De plus, les agrégations ont subi d'autres améliorations : les histogrammes prennent désormais en charge les « buckets » fractionnels et peuvent arrondir les buckets négatifs correctement, les agrégations de termes sont calculées plus efficacement afin de réduire le risque d'explosion combinatoire et l'API Profile.

Au niveau algorithme de calcul de pertinence, nous sommes passés de l’historique TF/IDF au plus moderne BM25 qui est maintenant actif par défaut. La gestion de la pagination au delà des 10 000 premiers résultats est désormais possible avec la fonctionnalité search_after, qui de façon efficace va éviter de relire les premiers résultats pour juste retourner les résultats de la page courante. Les recherches de type « scroll » pour faire notamment de l’extraction de données peuvent désormais être exécutées en parallèle. Cette dernière fonctionnalité sera d’ailleurs ajoutée aux API de reindex, update-by-query et delete-by-query. 

Le completion suggester a été complètement réécrit afin de tenir compte des documents supprimés ; il renvoie désormais les documents au lieu des « payloads ». Les contextes sont plus flexibles et les suggestions peuvent être demandées pour un seul contexte, plusieurs contextes ou tous les contextes à la fois. Non seulement les suggestions peuvent être pondérées au moment de l'indexation, mais les scores peuvent aussi être ajustés en fonction de la longueur du préfixe, des contextes ou de la géolocalisation.

Percolator a également été réécrit afin d'être plus rapide et d'occuper moins d'espace mémoire. Les conditions dans les requêtes du Percolator sont maintenant indexées de sorte que seules celles qui trouvent une correspondance sont vérifiées, au lieu de l'approche « brute force » privilégiée auparavant. L'API Percolator a été remplacée par la la requête percolate qui active toutes les fonctions de l'API de recherche pour la percolation : highlighting, scoring, pagination, etc.

L'une des principales préoccupations de la version 5.0.0 a été de rendre Elasticsearch plus sûr et plus simple. Nous avons adopté l'approche « signaler les problèmes haut et fort et le plus tôt possible » — si quelque chose ne fonctionne pas, nous devons vous le dire immédiatement au lieu de vous laisser tourner avec un risque potentiel de perdre des données par la suite. Cette attitude est illustrée par les améliorations apportées aux réglages de l'index et du cluster.

Les settings sont désormais validés de manière stricte. Si Elasticsearch ne comprend pas la valeur d'un setting, il se plaint. S'il ne reconnaît pas un setting, il se plaint et vous propose des suggestions par rapport à ce que vous avez voulu probablement faire. De plus, les settings du cluster et de l'index peuvent maintenant supprimés (en utilisant la valeur null) et vous pouvez consulter les settings par défaut en spécifiant le paramètre include_defaults. De même, les paramètres des requêtes et le corps de vos requêtes sont analysés de manière stricte. Les paramètres invalides ou inconnus génèrent désormais des exceptions.

Les API rollover et shrink offrent une nouvelle manière de gérer efficacement les index temporels : à l'aide de plusieurs shards, afin d'exploiter au mieux vos ressources matérielles lors de l'indexation, puis en ramenant les index à un seul shard (ou quelques shards) pour des recherches et stockages optimums.

La gestion des index a également été quelque peu améliorée. C'est maintenant plus simple de créer un index — au lieu d'attendre le message wait_for_status=green, la requête « create index » ne répond que lorsque l'index est effectivement disponible. Et la création d'un index ne fait plus passer l'état du cluster à red, il laisse les sysadmins dormir tranquillement la nuit.

Si l'allocation des shards ne fonctionne pas correctement, Elasticsearch ne cherche plus à les réallouer éternellement (tout en remplissant vos logs). La réallocation sera abandonnée au bout de 5 essais et patientera jusqu'à ce que vous ayez résolu le problème. Pour aider à le résoudre, la nouvelle API cluster-allocation-explain est un outil essentiel pour comprendre pourquoi un shard n'est pas alloué.

Enfin, le deprecation logging est désormais activé par défaut pour vous avertir comme il se doit à propos d'une fonctionnalité dépréciée dont vous vous servez encore. Ainsi, la transition vers les nouvelles versions majeures devrait être bien moins stressante.

Cette version s'accompagne de tout un tas de changements qui rendent Elasticsearch plus sûr que jamais. Chaque partie du modèle distribué a été réétudiée, retravaillée, simplifiée et améliorée. Maintenant, les mises à jour de l'état du cluster attendent d'être validées par tous les nœuds du cluster. Lorsqu'un shard répliqué est noté défaillant par son shard primaire, le primaire attend désormais une réponse du noeud maître. Les index utilisent maintenant un identifiant universel unique sur le disque au lieu du nom de l'index, et ce afin d'éviter les conflits de noms.

Votre système doit être configuré de manière appropriée (par exemple disposer de suffisamment de descripteurs de fichiers), sinon, vous vous exposez au risque de perdre des données par la suite. Elasticsearch propose maintenant des vérifications bootstrap pour s'assurer que vous n'aurez pas de mauvaise surprise. Mais une configuration système appropriée peut s'avérer onéreuse, en particulier si vous voulez juste essayer avec votre ordinateur portable. Elasticsearch démarre en mode développeur, tolérant l'écoute sur localhost seulement, qui vous alerte en cas de mauvaise configuration. Dès que vous configurez le réseau pour créer un cluster, il passe automatiquement en mode production, qui bloque en cas de configuration système incorrecte. Lire Bootstrap checks: Annoying you now instead of devastating you later!

Nous avons ajouté un circuit breaker qui limite la quantité de mémoire susceptible d'être utilisée par une requête en cours d'exécution, et nous avons élargi le circuit breaker de requête afin de suivre la mémoire utilisée par les buckets d'agrégation et d'abandonner les requêtes pathologiques qui demandent des milliards de buckets. Même si les exceptions de mémoire pleine sont bien moins fréquentes qu'auparavant, si elles surviennent malgré tout, le nœud va désormais mourir avec dignité au lieu de rester dans un état second.

Quant aux sysadmins, nous leur avons ajouté de nombreuses soft limits afin de protéger le cluster contre les utilisateurs malveillants et pour alerter les étourdis qui s'aventureraient en territoire hostile. Par exemple, nous avons ajouté une durée de timeout pour les recherches par défaut, désactivé le chargement de fielddata pour les champs de type text, limité le nombre de shards qu'une requête de recherche peut cibler, limité le nombre de champs dans un mapping, etc.

Après des années d'attente, nous vous présentons enfin le client HTTP/REST de langage Java bas niveau. Il fournit un simple client HTTP avec des dépendances minimales, qui répond aux besoins de sniffing, logging, round robinning des requêtes et fait une nouvelle tentative en cas d'échec du nœud. Il utilise la couche REST, traditionnellement bien plus stable que l'API Java, ce qui signifie qu'il peut être utilisé avec toutes les mises à jour, voire les mises à jour des versions majeures. Il fonctionne avec Java 7 et présente une dépendance minime, ce qui engendre moins de conflits de dépendance qu'avec le client Transport. Comme c'est du HTTP, on peut installer un pare-feu/proxy comme pour tous les autres clients HTTP. Sur nos bancs d'essai, le client REST Java est aussi efficace que le client Transport.

N'oubliez pas qu'il s'agit d'un client de bas niveau. À ce stade, nous n'offrons pas encore de query builders ni d'assistants d'auto-complétion pour votre IDE. C'est « JSON-in, JSON-out » : tout dépend de la façon dont vous construisez votre JSON. Mais le développement n'est pas terminé — nous envisageons d'ajouter une API qui vous aidera à élaborer des requêtes et à parser les réponses. Vous pouvez suivre les évolutions sur GitHub #19055.

L'assistant de migration d'Elasticsearch est un plugin de type site conçu pour vous aider à préparer votre migration de Elasticsearch 2.3.x/2.4.x à Elasticsearch 5.0. Il se compose de trois outils :

Instructions pour installer l'assistant de migration d'Elasticsearch. 

Les instructions pour une migration directement depuis Elasticsearch 1.x sont disponibles dans la documentation de mise à niveau..

Téléchargez Elasticsearch 5.0.0, essayez-le et laissez votre avis sur Twitter (@elastic) ou sur notre forum. Vous pouvez aussi signaler vos éventuels problèmes sur notre page GitHub.