Elasticsearch : index et mapping explicite

Le problème exposé dans ce sujet a été résolu.

Salut à tous,

Aujourd’hui je viens vers vous avec une question sur Elasticsearch 8.4 qui concerne les indexes et la définition explicite de leurs mappings.

La doc définit le concept de mapping comme la donnée qui permet d’associer à un document et/ou aux champs qu’il contient leur façon d’être stockés et indexés. Exemples donnés :

Which string fields should be treated as full text fields.

Which fields contain numbers, dates, or geolocations.

The format of date values.

Custom rules to control the mapping for dynamically added fields.

Partant de ces équivalences … :

Elasticsearch(index) = BDD_Relationnelle(BDD)

Elasticsearch(type) = BDD_Relationnelle(table)

Elasticsearch(JSON_document) = BDD_Relationnelle(lignes (+ colonnes) )

… , on pourrait s’attendre à ce que le mapping soit placé sur Elasticsearch(type). Or, depuis Elasticsearch v8, le mapping n’est plus placé sur Elasticsearch(type). A la place, la documentation v8 le définit sur Elasticsearch(index).

Depuis v8, la définition du mapping se fait par exemple comme suit :


curl -X PUT "localhost:9200/my-index-000001?pretty" -H 'Content-Type: application/json' -d'
{
  "mappings": {
    "properties": {
      "age":    { "type": "integer" },  
      "email":  { "type": "keyword"  }, 
      "name":   { "type": "text"  }     
    }
  }
}
'

REMARQUE IMPORTANTE : On n’y voit aucunement mention du Elasticsearch(type).

Question

Cela ne pose-t-il pas de problème si, au sein d’un même Elasticsearch(index), on a plusieurs Elasticsearch(types) avec chacun au moins une propriété de document JSON dont l’identificateur (celui de la propriété) serait le même ? D’autant plus que la définition d’un mapping n’indique pas le Elasticsearch(type) auquel appartient la propriété mappée (cf. : la remarque importante au-dessus) !

Merci d’avance et passez une bonne journée !

+0 -0

Attention : Elasticsearch n’est pas une base de données relationnelle. Raisonner en équivalence base de données relationnelle, c’est la certitude de mal comprendre quelque chose et de finir par faire une erreur.

D’ailleurs, c’est en partie à cause de ces mauvaises équivalences qui faisaient faire des choses bizarres (d’un point de vue Elasticsearch) que le mapping de types a été supprimé en v7 – et Zeste de Savoir est bien placé pour savoir les problèmes que cette suppression peut poser, puisqu’on utilisait ce mapping.

Il me semble important, face à ce genre d’outils (indexations, bases de données no-SQL) de bien comprendre les concepts associés sans essayer de faire un parallèle avec les BDD relationnelles « habituelles ».

PS : en l’occurrence je te conseille de lire en détail cette page, donnée par celle-ci que tu as cité, qui devrait te permettre de comprendre le pourquoi du comment il n’y a plus de mapping de types, et surtout pourquoi ça n’est pas un problème, au contraire.

Il y a aussi cette documentation sur ce qu’est Elasticsearch, en particulier son rapport aux documents et à leurs éventuels schémas.

+1 -0

Je m’auto-corrige sur un point : c’est bien Elasticsearch qui était à l’origine de la mauvaise comparaison avec les BDD. Ils ont présenté leur produit comme ça au début, avant de se rendre compte que ça posait problème.

Why are mapping types being removed

Initially, we spoke about an “index” being similar to a “database” in an SQL database, and a “type” being equivalent to a “table”.

This was a bad analogy that led to incorrect assumptions. In an SQL database, tables are independent of each other. The columns in one table have no bearing on columns with the same name in another table. This is not the case for fields in a mapping type.

In an Elasticsearch index, fields that have the same name in different mapping types are backed by the same Lucene field internally. In other words, using the example above, the user_name field in the user type is stored in exactly the same field as the user_name field in the tweet type, and both user_name fields must have the same mapping (definition) in both types.

This can lead to frustration when, for example, you want deleted to be a date field in one type and a boolean field in another type in the same index.

On top of that, storing different entities that have few or no fields in common in the same index leads to sparse data and interferes with Lucene’s ability to compress documents efficiently.

For these reasons, we have decided to remove the concept of mapping types from Elasticsearch.

Toujours la même page de la doc

Pour toi @Herbe concrètement, ce que ça veut dire, c’est que l’équivalence que tu cites n’a pas de sens, et donc ton raisonnement qui en découle non plus. J’en profite pour attirer ton attention sur le fait que le lien sur l’équivalence en question date de 2013 (« answered Feb 22, 2013 at 14:29 ») ce qui est une éternité en informatique. Le post a bien été édité en 2018, mais sans qu’on sache ce qui a été modifié et donc s’il a vraiment été mis à jour sur des points importants.

+1 -0

Merci beaucoup @SpaceFox !

Effectivement, j’avais préalablement à Elasticsearch (que j’ai déjà un peu utilisé à la fac) des connaissances sur les différences entre les db relationnelles et les db nosql qui répartissent et duppliquent les docs json sur plusieurs nodes voires clusters, mais j’avoue que j’ai récemment succombé à ces notions d’équivalences avancées par la réponse de SO et qui apparemment étaient à l’origine dues à la doc d’ES elle-même. :honte: je t’avouerais que ça me facilitait la révision/apprentissage de ce dernier :honte:

Du coup je vais revoir intégralement cette histoire de types et de pourquoi leur suppression ne peut engendrer de problème en cas de noms de propriétés de JSON docs identiques mais de mappings pourtant différents (même dans le cas d’un type de propriété JSON identique d’un doc à un autre, genre une date ou bien un booléen pour une propriété "date_expiration").

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte