Aucun mappage trouvé pour le champ à trier dans ElasticSearch

Elasticsearch lance une SearchParseExceptionrequête d'analyse while s'il y a des documents trouvés ne contenant pas de champ utilisé dans les critères de tri.

SearchParseException: Échec d'analyse [Aucun mappage trouvé pour [prix] afin de trier]

Comment puis-je réussir une recherche dans ces documents, même si certains manquent le pricechamp?

Après avoir creusé davantage, j'ai trouvé la solution ci-dessous. ignore_unmappeddoit être explicitement défini truedans la clause de tri.

"sort" : [
       { "rating": {"order" : "desc" , "ignore_unmapped" : true} },
       { "price": {"order" : "asc" , "missing" : "_last" , "ignore_unmapped" : true} }
]

Pour plus d'informations, consultez les références Elasticsearch pour:

• valeurs manquantes
• ignorer les champs non mappés

Pour ceux qui recherchent un exemple des deux ignore_unmappedet unmapped_types'il vous plaît voir ma réponse ici .

Notez que "ignore_unmapped" est désormais obsolète au profit de "unmapped_type". Cela a été fait dans le cadre de # 7039

De la documentation: Avant la 1.4.0, il y avait le paramètre booléen ignore_unmapped, qui n'était pas assez d'informations pour décider des valeurs de tri à émettre et ne fonctionnait pas pour la recherche d'index croisé. Il est toujours pris en charge mais les utilisateurs sont encouragés à migrer vers le nouveau unmapped_type à la place.

Par défaut, la demande de recherche échouera si aucun mappage n'est associé à un champ. L'option unmapped_type permet d'ignorer les champs qui n'ont pas de mappage et de ne pas les trier. La valeur de ce paramètre est utilisée pour déterminer les valeurs de tri à émettre. Voici un exemple de la façon dont il peut être utilisé:

{
    "sort" : [
        { "price" : {"unmapped_type" : "long"} },
    ],
    "query" : {
        "term" : { "user" : "kimchy" }
    }
}

Si l'un des indices interrogés n'a pas de mappage pour le prix, Elasticsearch le traitera comme s'il y avait un mappage de type long, tous les documents de cet index n'ayant aucune valeur pour ce champ.

Apparemment, ElasticSearch ne triera pas sur les valeurs nulles. Je supposais qu'il traiterait null comme étant au début ou à la fin (comme avec la commande SQL) mais je pense que cela déclenche également cette erreur.

Donc, si vous voyez cette erreur, vous devrez peut-être vous assurer que l'attribut de tri a une valeur par défaut lorsqu'il est envoyé à ElasticSearch.

J'ai eu cette erreur avec Rails + ElasticSearch + Tire parce que la colonne de tri n'avait pas de valeur par défaut, elle était donc envoyée à ES comme null.

Ce problème indique que les valeurs nulles sont gérées, mais ce n'était pas mon expérience. C'est quelque chose qui vaut la peine d'essayer de toute façon.

J'ai rencontré le même problème (en quelque sorte; j'obtiendrais des erreurs, mais des résultats), mais dans mon cas, ma recherche était émise à la racine (aucun index spécifié), et les erreurs que j'obtenais étaient parce que la recherche / l'ordre était également à la recherche d'un index Kibana.

Erreur stupide, mais peut-être que cela aidera quelqu'un d'autre qui se retrouvera ici.

Elasticsearch 6.4

spécifiez simplement l'index et c'est tout dans Kibana

AVANT

GET /_search
{
 
  "query": {
    "exists": {
      "field": "document_id"
    }
  },
  "sort": [
    {
      "document_id": { "order": "asc"  },
      "created_at":  { "order": "desc" }
    }
  ]
}

APRÈS

GET /document-index/contact/_search  (here)
{

  "query": {
    "exists": {
      "field": "document_id"
    }
  },
  "sort": [
    {
      "document_id": { "order": "asc"  },
      "created_at":  { "order": "desc" }
    }
  ]
}

si vous utilisez es 6.7

essaye celui-là

sort : ["title.keyword:desc"]

Vous pouvez également utiliser un script qui vous donne une certaine flexibilité:

"sort" : {
    "_script" : {
        "type" : "number",
        "script" : {
            "lang": "painless",
            "source": "return !doc['price'].empty ? doc['price'].value : 0"
        },
        "order" : "desc"
    }
}

Lorsque nous utilisons le code ci-dessous, où added_on est la date, que se passe-t-il !! le texte d'attribut est analysé, ce qui signifie qu'il est divisé en mots distincts lorsqu'il est stocké, et permet des recherches en texte libre sur un ou plusieurs mots du champ

il y a donc "texte" et "mot-clé" associés aux champs, donc si nous devons utiliser l'agrégation dans la requête, nous avons besoin de la valeur du champ en général, du mot-clé.

BEFORE

"_source":{....}
"query" : {...}
"sort": [
{
  "added_on": {
    "order": "desc"
  }
}
]

AFTER
"_source":{....}
"query" : {...}
"sort": [
{
  "added_on.keyword": {
    "order": "desc"
  }
}
]