Adiós, tipos. Hola, lenguajes sin tipos.

By
Adrien Grand

Desde la versión 5.0, hemos estado haciendo mas fácil el camino para la eliminación de los tipos en Elasticsearch y, con la versión 7.0, llegó el momento de dejar de usarlos. El objetivo de los tipos era proporcionar una tenencia múltiple en un solo índice, que era incompatible con Lucene. Lamentablemente, se probó que los tipos causaban más problemas de los que resolvían. Después de largas discusiones sobre si debíamos recurrir a otras opciones para solucionar el problema, por ejemplo, mediante el uso de campos únicos por tipo o el mantenimiento de un índice por tipo, decidimos en cambio eliminar el soporte para tipos. Para facilitarles la transición a nuestros usuarios, distribuimos los cambios en cuatro versiones principales:

  • En la versión 5.0, se implementó que los campos que comparten el mismo nombre en varios tipos tengan asignaciones compatibles.
  • En la versión 6.0, se comenzó a evitar que los nuevos índices tuvieran más de un tipo y se desaprobó el uso del mappint _default_.
  • En la versión 7.0, se desaprobó el uso de las API que aceptan tipos, presentó nuevas API sin tipo y eliminó el soporte para el mapping _default_.
  • En la versión 8.0, se eliminarán las API que aceptan tipos.

API sin tipos

Para todas las API que aceptan tipos en su ruta URL, cuerpo de solicitud o cuerpo de respuesta, se están desarrollando nuevas contrapartes "sin tipos". Tal es el caso de algunas API bastante comunes, como las de creación de índices, las de gestión de índices y las API GET. Un ejemplo vale más que mil palabras: así se ve una interacción en un cluster 7.0 con API sin tipo: 

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"
      }
    }
  }
}

¿Qué debo hacer?

Algunos cambios son disruptivos y requerirán que implementes cambios en tu cluster antes de actualizarte a la versión 7.0. Otros cambios solo serán necesarios para la actualización a la versión 8.0 y se deben realizar después de la actualización a la versión 7.0.

Antes de la actualización

Asegurarte de estar usando la versión 6.8

Si planeas actualizarte sin tiempo de inactividad de forma periódica, primero debes actualizarte a la versión 6.8, que es la única versión 6.x con algunas características como la compatibilidad con el parámetro include_type_name, que es necesario para una actualización a la versión 7.0 sin problemas.

Dejar de usar el _default_ mapping

A partir de la versión 7.0, ya no se usará el mapping _default_. Si algunos índices actuales en versiones 6.x tienen un mapping _default_, no habrá problema, ya que el mapping _default_ solo se rechazará en índices nuevos.

Debes actualizar tus plantillas de índice y el código de tu aplicación para agregar estas asignaciones al tipo real, en lugar de incluirlas en un mapping _default_. Si el nombre del tipo no es tan importante para ti, te recomendamos que uses _doc, lo que facilitará la transición a las API sin tipo en el futuro.

Pasar include_type_name=true a las API de creación de índices, plantillas y mappings

La transición a las API sin tipo significa que las API cuyos cuerpos de solicitud requieren un tipo ahora van a esperar un formato diferente:

  • create index
  • put mapping
  • put template

Mientras que otras API que devolvían tipos en la respuesta van a tener un formato de respuesta diferente:

  • get index
  • get mapping
  • get field mapping
  • get template

Para que este cambio no resulte demasiado disruptivo, debes hacer que tu aplicación pase include_type_name=true para estas llamadas a la API, que es una instrucción de no operación en las versiones 6.x; esta instrucción les dirá a las versiones 7.x que hagan que estas API se comporten como lo hacían en las versiones 6.x. Veamos, por ejemplo, la siguiente llamada de creación de índice con este parámetro. Funciona de la misma manera en las versiones 6.8 y 7.x. 

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"
        }
      }
    }
  }
}

Después de la actualización

Si seguiste los pasos recomendados previos a la actualización, todo debería seguir funcionando bien. Sin embargo, en esta etapa todavía estás usando API que aceptan tipos, lo cual desencadena advertencias de desuso. Para eliminar estas advertencias, debes implementar el uso de API sin tipos.

Para las API de creación de índice, plantillas y mappings, tendrás que eliminar include_type_name=true de los parámetros de URL y cambiar los cuerpos de solicitud o las expectativas sobre el formato de respuesta, que ya no incluye tipos. Por lo general, si el cuerpo de la solicitud o la respuesta incluían mappings, tenía una sección que se veía más o menos así: 

{
  "my_type": { // this key is no longer accepted in mappings as of 7.0
    "properties": ...
  }
}

Ahora, debe actualizarse de manera que ya no incluya un nombre de tipo, por lo que debe verse así: 

{
  "properties": ...
}

Para otras API como las de índice, GET o actualización, tienes que reemplazar el nombre del tipo en la URL con _doc. Esto funcionará independientemente del nombre del tipo de tu índice. Por ejemplo, si habitualmente realizabas llamadas de índice para un índice cuyo nombre de tipo era my_type, la llamada de índice se veía así: 

PUT index/my_type/1
{
  "@timestamp": "2019-02-20"
}

Ahora, debe reemplazarse con: 

PUT index/_doc/1
{
  "@timestamp": "2019-02-20"
}

Conoce más

Si te gustaría obtener más información acerca de la eliminación de tipos y cómo migrar a las API sin tipo, te recomendamos que revises nuestra documentación sobre la eliminación de tipos, donde profundizamos en más detalles acerca de lo que estos cambios implican y cómo uno puede prepararse para ellos.

Descarga la versión 7.0.0, prueba estas nuevas API sin tipos y cuéntanos qué te parece en la sección de Debate.