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>

types-typeless-banner.jpg

types-typeless-thumb.jpg

Goodbye, types. Hello, typeless.

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

headshot-adrien-grand-300x300.jpg

Tech lead - Elasticsearch

Adrien Grand

speaker-adrien-grand.jpg

Adrien Grand (FR)

Articles By

Register to Attend

Sign In to Attend

Register to Watch

You'll also receive an email with related content

Watch Now

Learn More

Contact Info

See All Posts

What to explore next...

Load more news

Load more press releases

Load More

Translate Content

Articles by Adrien Grand

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

Produits

Enterprise

Resources

SaaS

Orchestration

Articles by Adrien Grand

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