Должен ли я указывать сопоставление, чтобы использовать контроллер document.search в Kuzzle? - PullRequest
Новая
       51

Должен ли я указывать сопоставление, чтобы использовать контроллер document.search в Kuzzle?

2 голосов
/ 07 мая 2020

Я использую Kuzzle для создания простого Slack-подобного приложения. У меня есть простая коллекция с документами, содержащими только идентификаторы других документов. Я хотел запросить список идентификаторов из этой коллекции и застрял с пустым массивом совпадений в ответе, независимо от того, какие значения идентификаторов я пробовал в запросе. Это заставило меня прочитать о синтаксисе запросов Elasticsearch, сопоставлении, и я обнаружил, что мне нужно указать сопоставление.

Когда коллекция создается без указания сопоставления, document.search:

  • возвращает пустой массив совпадений, если задано свойство тела «query», например следующее: 

    {"query": {"terms": {"id": <ids array>}}}

  • выдает следующее, если задано «sort»: 

    // {"sort": [{"id": {"order": "desc"}}]}
Error: No mapping found for [id] in order to sort on

  • и возвращает пустой список сегментов для таких «агрегатов»: 

    "aggregations": {
    "groupById": {
        "terms": {
            "field": "id"
        }
    }
}

Я не понимаю, что такое происходит за этим. Это нормально, что только один случай рассматривается как ошибка? Я работал над частью запроса, и не было очевидно, что ошибка возникла не из-за содержимого моего массива ids!

Добавление простого сопоставления по «id» с типом «keyword» делает все кейсы работают по назначению, но я читал о сопоставлениях динамических c в Elasticsearch. Есть ли способ их использовать? Или есть другое решение для запроса (единственного) параметра в моем документе?

Я использую kuzzle-sdk v7.1.4

Большое спасибо!

1 Ответ

2 голосов
/ 07 мая 2020

Сопоставления Elasticsearch - это способ сообщить базовому механизму, как индексировать поля ваших документов.

Например, поле текст не будет индексироваться так же, как ключевое слово поле, и вы не сможете выполнить такой же запрос.

keyword поля индексируются «как есть», поэтому вы можете выполнять очень быстрый поиск по точным условиям ( с запросом term ), но поля text анализируются различными методами, чтобы можно было выполнить, например, запрос нечеткого соответствия .

Если не объявлено сопоставление поля, Elasticsearch не сможет получить к нему доступ ни в одном запросе.

Дополнительную информацию можно найти в нашей Поваренной книге Elasticsearch .

О динамические сопоставления c политика , по умолчанию для этой политики установлено значение false, что означает, что ES не будет выводить новые типы полей.

Мы выбрали это значение по умолчанию, потому что вы не можете изменять тип поля, поэтому лучше d Уточните это самостоятельно, чем наличие неточных типов, выводимых ES.

Вы можете изменить эту политику для всего сопоставления, но также, например, только для вложенного объекта (что считается лучшей практикой) 

{
  "dynamic": "false",
  "properties": {
    "id": { "type": "keyword" },
     "metadata": {
       "dynamic": "true",
       "properties": {
         // field types will be automatically inferred in the "metadata" object
       }
     }
  }
}

Затем, если вы создадите следующий документ: 

{
  "id": "your-unique-uuid",
  "name": "aschen",
  "metadata": {
    "avatar": "http://url.com"
  }
}

  • id поле уже было объявлено как keyword, вы можете сделать запрос по этому полю.

  • name поле не было объявлено, а политика Dynami c - false, поэтому вы не можете делать запросы по этому полю.

  • metadata.avatar поле не было объявлено, но политика динамического c для этого вложенного объекта - true, поэтому ES добавит тип text для этого поля, вы можете сделать запрос по этому полю.

И последнее: вы используете поле id внутри своего документа, но Elasticsearch уже генерирует уникальный идентификатор (_id) для каждого документа, поэтому вы можете использовать его вместо этого.

Я разработчик ядра Kuzzle

...