Contrairement aux versions précédentes, Elasticsearch 7.7 utilise un segment de mémoire bien moindre, ce qui améliore la stabilité des clusters Elasticsearch et diminue le coût du stockage de grands volumes de données.

<p>Les utilisateurs d'Elasticsearch repoussent toujours les limites des volumes de données qu'ils peuvent stocker sur un nœud Elasticsearch. Ainsi, il arrive que le segment de mémoire vienne à manquer avant de ne plus avoir d'espace disque à disposition. Ce problème est très frustrant. Souvent, les utilisateurs ont besoin de pouvoir <a href="/fr/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster">stocker autant de données que possible dans chaque nœud</a> afin de diminuer leurs coûts.
</p><p>Pourquoi Elasticsearch a-t-il besoin d'un segment de mémoire pour le stockage des données&nbsp;? L'espace disque n'est-il pas suffisant&nbsp;? La réponse est multiple. La raison principale est la nécessité pour Lucene de stocker certaines informations en mémoire afin de savoir où mener les recherches sur le disque. Par exemple, l'index inversé de Lucene comprend un dictionnaire qui regroupe les mots en blocs sur le disque et les trie selon des critères spécifiques, mais aussi un index de termes afin d'accélérer les recherches dans le dictionnaire. Cet index mappe les préfixes des termes en tenant compte de l'offset sur le disque au début de l'emplacement du bloc qui contient les termes avec les préfixes concernés. Le dictionnaire des termes se trouvait sur le disque, tandis que l'index était sur le segment de mémoire jusqu'à récemment.
</p><p>De quelle quantité de mémoire les index ont-ils besoin&nbsp;? En règle générale, quelques Mo par Go d'index suffisent. Or, les utilisateurs connectent de plus en plus de téraoctets de disque à leurs nœuds. Par conséquent, les index ont besoin de 10 à 20&nbsp;Go de segment de mémoire afin de stocker ces téraoctets. Étant donné qu'Elastic recommande de ne pas dépasser 30&nbsp;Go de segment de mémoire, il ne reste pas grand-chose pour d'autres opérations gourmandes, comme les agrégations. En outre, cela ouvre la porte à des problèmes de stabilité si la Machine virtuelle Java (JVM) n'a plus assez de place pour les opérations de gestion des clusters.
</p><p>Étudions le problème sous un angle pratique. Elastic exécute <a href="https://benchmarks.elastic.co">toutes les nuits des évaluations</a> de plusieurs ensembles de données et met en place un suivi de divers indicateurs dans le temps afin d'étudier l'utilisation particulière de la mémoire par les segments. L'ensemble de données <a href="https://www.geonames.org/">Geonames</a> est un cas intéressant&nbsp;: il <a href="https://elasticsearch-benchmarks.elastic.co/index.html#tracks/geonames/nightly/default/6M">montre clairement l'impact des différents changements apportés à Elasticsearch&nbsp;7.x</a>.
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb41b157438550179/5ea2ddf2ae23d30cd1dfb100/heap-reduction-7-7-nightly-geonames-blog.png" data-sys-asset-uid="bltb41b157438550179" alt="Évaluation quotidienne de l'ensemble de données geonames" style="display: block; margin: auto;">
</p><p>Cet index représente environ 3&nbsp;Go sur le disque et nécessitait environ 5,2&nbsp;Mo de mémoire il y a 6&nbsp;mois, soit un ratio segment de mémoire-stockage d'environ 1 à 600. Ainsi, si 10&nbsp;To au total sont connectés à chaque nœud, vous aurez besoin de 17&nbsp;Go de segment de mémoire (10&nbsp;To&nbsp;/&nbsp;600) simplement pour garantir le fonctionnement des index stockant des données similaires à geonames. Toutefois, comme vous pouvez le voir ci-dessous, les choses se sont améliorées au fil du temps&nbsp;: les points (en bleu foncé) nécessitent moins de mémoire, suivis par les termes (en rose), les champs stockés (en vert) et enfin les termes à nouveau de manière plus importante. Désormais, le ratio segment de mémoire-stockage est d'environ 1 à 4&nbsp;000, ce qui représente des capacités quasiment 7&nbsp;fois plus performantes par rapport aux versions&nbsp;6.x et 7.x. Vous avez donc besoin de seulement 2,5&nbsp;Go de segment de mémoire pour garantir le fonctionnement de 10&nbsp;To d'index.
</p><p>Ces chiffres varient <strong>considérablement</strong> selon les ensembles de données. La bonne nouvelle est que Geonames est l'un des ensembles de données à présenter la plus petite réduction de l'utilisation du segment de mémoire. Cette dernière a été quasiment divisée par 7 sur Geonames. En comparaison, elle a été divisée par plus de 100 sur les ensembles de données concernant <a href="https://elasticsearch-benchmarks.elastic.co/index.html#tracks/nyc-taxis/nightly/default/6M">les taxis de New York</a> et <a href="https://elasticsearch-benchmarks.elastic.co/index.html#tracks/http-logs/nightly/default/6M">les logs HTTP</a>. Ce changement favorise la réduction des coûts en stockant bien plus de données par nœud par rapport aux capacités des versions précédentes d'Elasticsearch.
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt7c2002e630ac3974/5ea2de1f52608c261aab78aa/heap-reduction-7-7-nightly-taxis-blog.png" data-sys-asset-uid="blt7c2002e630ac3974" alt="Évaluation quotidienne de l'ensemble de données sur les taxis de New York" style="display: block; margin: auto;">
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb15c6244ebc49571/5ea2de6952608c261aab78b0/heap-reduction-7-7-nightly-http-logs-blog.png" data-sys-asset-uid="bltb15c6244ebc49571" alt="Évaluation quotidienne de l'ensemble de données sur les logs HTTP" style="display: block; margin: auto;">
</p><p>Comment cela fonctionne-t-il et quels sont les écueils à éviter&nbsp;? La même recette a été appliquée sur le long terme à plusieurs composants d'index Lucene. Les structures de données sont passées du segment de mémoire de la JVM au disque. En outre, le cache du système de fichiers (souvent appelé cache de page ou cache du système d'exploitation) a permis de conserver en mémoire les bits "chauds". On peut supposer que cette mémoire est toujours en utilisation et attribuée à d'autres opérations. Or, une part importante de cette mémoire n'a tout simplement jamais été utilisée, selon vos cas d'utilisation. Par exemple, la goutte d'eau qui a fait déborder le vase pour <code>Terms</code> a été le transfert de l'index des termes du champ <code>_id</code> sur disque, qui permet seulement d'utiliser l'API GET ou d'indexer les documents avec des identifiants explicites. La grande majorité des utilisateurs qui indexent des logs et des indicateurs dans Elasticsearch n'effectuent jamais aucune de ces opérations. Ils pourraient ainsi bénéficier d'un réel gain de ressources.
</p><h2>Diminution de votre segment de mémoire Elasticsearch avec la version&nbsp;7.7</h2><p>Nous sommes ravis de vous présenter les améliorations qui seront disponibles dans Elasticsearch&nbsp;7.7. Nous espérons qu'elles vous plairont. Le lancement de cette nouvelle version sera bientôt annoncé. Ne passez pas à côté et n'hésitez pas à la tester. Essayez-la dans votre déploiement existant ou <a href="/fr/elasticsearch/service">inscrivez-vous à un essai gratuit</a> d'Elasticsearch Service sur Elastic Cloud (qui comprend toujours la dernière version d'Elasticsearch). Nous aimons connaître votre opinion. Donc, n'hésitez pas à nous faire part de vos commentaires sur <a href="https://discuss.elastic.co/">Discuss</a>.
</p>

blog-banner-release-elasticsearch.png

blog-thumb-release-elasticsearch.png

Coming in 7.7: Significantly decrease your Elasticsearch heap memory usage

Nouveauté de la version 7.7 : diminution significative de votre utilisation du segment de mémoire d'Elasticsearch

Elasticsearch 7.0 s’est détourné des API qui acceptent les types, créé de nouvelles API sans type et supprimé la prise en charge du mapping _default_.

<p>Depuis la version 5.0, nous avons ouvert la voie au retrait des types sur Elasticsearch. La version 7.0 marque leur fin. Le but des types était d'assurer une architecture multi-tenant au sein d'un seul index, ce qui est incompatible avec Lucene. Malheureusement, les types se sont révélés plus problématiques que salutaires.&nbsp;Après avoir longuement débattu afin de savoir si nous devions contourner le problème (ex.&nbsp;: utiliser des champs uniques par type ou disposer d'un index par type), nous avons décidé de supprimer la prise en charge des types. Pour assurer une transition en douceur à nos utilisateurs, nous avons réparti les changements sur quatre versions majeures&nbsp;:
</p>
<ul>
	<li>la version 5.0 a commencé à imposer que les champs partageant le même nom sur plusieurs types aient des mappings compatibles&nbsp;;</li>
	<li>la version 6.0 a commencé à empêcher les nouveaux index de disposer de plus d'un type et n’accepte plus le mapping <code>_default_</code>&nbsp;;</li>
	<li>la version 7.0 a rejeté les API qui acceptent les types, créé de nouvelles API sans type et supprimé la prise en charge du mapping <code>_default_</code>&nbsp;;</li>
	<li>la version 8.0 supprimera toutes les API qui acceptent les types.</li>
</ul>
<h2>API sans type</h2>
<p>Toutes les API qui acceptent les types dans leur chemin URL, leur corps de requête ou leur corps de réponse obtiennent un nouvel équivalent "sans type". C'est le cas de certaines API très courantes telles que les API GET, de création d'index et d'index. Un exemple valant toujours mieux qu'un long discours, voici à quoi ressemble une interaction avec un cluster 7.0 avec des API sans type&nbsp;:
</p>
<pre class="prettyprint">PUT index
{
  "mappings": {
    "properties": { // Note how there is no top-level key with the type name
      "@timestamp": {
        "type": "date"
      }
    }
  }
}
PUT index/_doc/1 // _doc becomes the new endpoint for document index, get and delete requests
{
  "@timestamp": "2019-02-20"
}
POST index/_bulk
{"index": {"_id": "2"}} // no _type in the URL or in document metadata
{"@timestamp": "2019-03-01"}
{"update": {"_id": "1"}}
{"@timestamp": "2019-02-21"}
GET index/_doc/2
GET index/_search // unchanged, the `GET index/{type}/_search` endpoint is deprecated however
{
  "query": {
    "range": {
      "@timestamp": {
        "gte": "2019-01-01"
      }
    }
  }
}
GET index/_explain/1 // note how the type does not appear in the URL anymore, this would have been "GET index/{type}/1/_explain" in 6.x
{
  "query": {
    "range": {
      "@timestamp": {
        "gte": "2019-01-01"
      }
    }
  }
}
</pre>
<h2>Que dois-je faire&nbsp;?</h2>
<p>Certains changements sont majeurs et vous obligent à procéder à des modifications sur votre cluster <strong>avant</strong> de passer à la version 7.0. D'autres ne seront requis que pour la mise à niveau vers la version 8.0 et ne doivent être effectués qu'après la mise à niveau vers la version 7.0.
</p>
<h3>Avant la mise à niveau</h3>
<h4>Assurez-vous d'être à la version 6.8</h4>
<p>Si vous prévoyez d'effectuer une mise à niveau propagée sans aucune indisponibilité, vous devez d'abord passer à la version 6.8. En effet, c'est la seule version 6.x à disposer de fonctionnalités telles que la prise en charge du paramètre <code>include_type_name</code> qui permet de passer à la version 7.0 sans encombre.
</p>
<h4>Arrêtez d'utiliser les mappings _default_</h4>
<p>Le mapping <code>_default_</code> n'est plus pris en charge par la version 7.0. Si certains index 6.x existants disposent d'un mapping <code>_default_</code>, ce n'est pas grave, car le mapping <code>_default_</code> ne sera rejeté que sur les nouveaux index.
</p>
<p>Vous devez mettre à jour vos modèles d'index ainsi que votre code d'application pour ajouter ces mappings au type réel, plutôt que de les inclure à un mapping <code>_default_</code>. Bien que le nom du type ne soit pas important, nous vous recommandons d'utiliser <code>_doc</code>. Cela permettra de faciliter la transition vers les API sans type.
</p>
<h4>Passez le paramètre <code>include_type_name=true</code> aux API de mapping, de modèle et de création d'index</h4>
<p>Le passage aux API sans type implique que les API dont les corps de requête nécessitaient un type vont à présent exiger un format différent&nbsp;:
</p>
<ul>
	<li>create index</li>
	<li>put mapping</li>
	<li>put template</li>
</ul>
<p>tandis que d'autres API ayant retourné des types dans la réponse vont avoir un format de réponse différent&nbsp;:
</p>
<ul>
	<li>get index</li>
	<li>get mapping</li>
	<li>get field mapping</li>
	<li>get template</li>
</ul>
<p>Afin de ne pas être perturbé par ce changement, vous devriez faire en sorte que votre application passe le paramètre <code>include_type_name=true</code> à ces appels d'API, qui est une instruction nulle sur la version 6.x. La version 7.x indiquera ainsi à ces API de se comporter comme elles le faisaient dans la version 6.x. Par exemple, voici un appel de création d'index avec ce paramètre. Il fonctionne de la même façon sur 6.8 et 7.x.
</p>
<pre class="prettyprint">PUT index?include_type_name=true
{
  "mappings": {
    "my_type": {
      "properties": { // Note how there is no top-level key with the type name
        "@timestamp": {
          "type": "date"
        }
      }
    }
  }
}
</pre>
<h3>Après la mise à niveau</h3>
<p>Si vous avez suivi les étapes préalables à la mise à niveau qui vous ont été recommandées, tout devrait fonctionner normalement. Toutefois, pour le moment, vous continuez d'utiliser des API qui acceptent des types, et donc de recevoir des avertissements de désapprobation. Pour vous en débarrasser, vous devez migrer vers les API sans type.
</p>
<p>Pour les API de mapping, de modèle et de création d'index, vous devrez retirer <code>include_type_name=true</code> des paramètres d'URL et modifier les corps de requêtes ou les attentes concernant le format de réponse, qui n'inclut plus les types. Si le corps de requête ou de réponse incluait des mappings, il affichait probablement une section semblable à celle-ci&nbsp;:
</p>
<pre class="prettyprint">{
  "my_type": { // this key is no longer accepted in mappings as of 7.0
    "properties": ...
  }
}
</pre>
<p>Il doit être mis à niveau pour ne plus inclure de nom de type et devrait à présent ressembler à cela&nbsp;:
</p>
<pre class="prettyprint">{
  "properties": ...
}
</pre>
<p>Pour les autres API (Index, GET ou Update, par exemple), vous devez remplacer le nom de type dans l'URL par <code>_doc</code>. Cela fonctionnera, quel que soit le nom du type de votre index. Par exemple, si vous aviez l'habitude d'effectuer des appels d'index pour un index dont le nom de type est <code>my_type</code>, l'appel d'index ressemblait à cela&nbsp;:
</p>
<pre class="prettyprint">PUT index/my_type/1
{
  "@timestamp": "2019-02-20"
}
</pre>
<p>et doit être remplacé par&nbsp;:
</p>
<pre class="prettyprint">PUT index/_doc/1
{
  "@timestamp": "2019-02-20"
}
</pre>
<h2>En savoir plus</h2>
<p>Si vous souhaitez en savoir plus sur le retrait des types et la migration vers des API sans type, je vous recommande de jeter un œil à notre <a href="/guide/en/elasticsearch/reference/7.0/removal-of-types.html">documentation sur la suppression des types</a>. Vous y trouverez des informations détaillées concernant les répercussions de cette évolution, ainsi que des conseils pour vous y préparer.
</p>
<p><a href="/fr/downloads/elasticsearch">Téléchargez la version 7.0.0</a>, donnez une chance à ces nouvelles API sans type et dites-nous ce que vous en pensez sur le <a href="https://discuss.elastic.co/">forum</a>.
</p>

AUTHOR

Article de Adrien Grand

Nouveauté de la version 7.7 : diminution significative de votre utilisation du segment de mémoire d'Elasticsearch

Oubliez les types, l'avenir est au sans type.

Inscrivez-vous à un essai gratuit d'Elastic Cloud

Produits et solutions

Entreprise

Ressources

Solutions

La Suite Elastic (ELK)

NOUVEAUTÉ